[LAC-TF] Peru con mas de 9% de Trafico Nativo IPv6
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Wed Oct 8 21:03:58 BRT 2014
NAT46 no daría esas mediciones.
Leeros los RFC correspondientes, hay que estudiar un poco mas antes de
armar tanto ruido !
-----Mensaje original-----
De: Jaris Aizprua <jarisaizprua at gmail.com>
Responder a: <lactf at lac.ipv6tf.org>
Fecha: jueves, 9 de octubre de 2014 01:53
Para: <lactf at lac.ipv6tf.org>
Asunto: Re: [LAC-TF] Peru con mas de 9% de Trafico Nativo IPv6
>Entonces en resumen: Perú implementó NAT46; una idea original pero fuera
>de lugar considerando que el despliegue es orientado a usuarios
>residenciales o masivos, y sabiendo que existen aún aplicaciones comunes
>como Skype que todavía no funcionan sobre IPv6.
>Saludos!!!
>
>Sent from my Mobile device
>El oct 8, 2014 6:31 PM, "InternetLibre at outlook.com"
><InternetLibre at outlook.com> escribió:
>
>
>
>
>
> La razón de la sinrazón
> (or How to skin a cat in five pretty easy steps)
>
> Paso 2: ¿Qué se está midiendo? ¿El origen o la llegada?
>
> Los servidores de medición (o detección de si estamos o no usando
> IPv6) miden el origen: es decir examinan el encabezado del paquete
> de origen y determinan si se ha emitido la petición desde un IPv4
> o un IPv6. Esto es lo normal dentro de la red Internet. Pero el
> caso es que en mi país se usa "NAT" y los usuarios no recibimos un
> IPv4 o IPv6 público, sino uno privado (de IPv4).
>
> Los datos de la gran implementación de IPv6 en Perú (como veremos
> en otro mensaje) provienen de un solo carrier nacional (es decir,
> mi país, Perú, muestra una media de 7.5% de conexiones con IPv6,
> alcanzada desde Marzo del 2013 hasta Marzo del 2014, de allí la
> curva se aplana y no hay un incremento que siga la misma
> proporción, los datos específicos en otro mensaje. Los datos de
> un solo carrier coinciden con los datos nacionales. La conclusión
> es que la "alza" en conexiones peruanas con IPv6 se debe a un solo
> carrier y no a todos los carrier peruanos).
>
> La salida que realiza este carrier para los servicios de internet
> domiciliarios es a través de Números IPs privados pertenecientes
> al IPv4. De esta manera el usuario es protegido pues su
> computadora no pertenece NUNCA a una red Internet reconocida por
> todos los servidores del mundo u otros usuarios que si están
> perteneciendo a la red Internet. Este servicio es muy común y lo
> conocemos, desde siempre, como "NAT" (Network Address Translation,
> o Reemplazo de la Dirección de Red). Reitero: normalmente no
> existen conexiones con IPs públicos para los usuarios
> domiciliarios. Las empresas que requieren un IP público deben
> pagar otras tarifas (tengo los datos oficiales a la mano, si se
> requieren los comentaré).
>
> Para los que conocen el servicio NAT les pido ahorrarse el
> siguiente párrafo.
>
>
>"Con el equipo que realiza el NAT todas las
> comunicaciones enviadas a servidores externos a la red privada
> contienen un numero IP externo... en vez de la dirección interna
> del host... cuando una computadora en la red privada (interna)
> envia un paquete hacia la red externa (internet), el equipo que
> realiza el NAT reemplaza la IP interna en el campo del
> encabezado del paquete (packet header) con una IP externa que
> posee el equipo que realiza el NAT. La computadora que recibe
> el paquete (que ha sido afectado por el equipo que realiza el
> NAT) establece una comunicación con el número IP especificado en
> el paquete alterado, sin conocer, ignorando el hecho que la
> direccion IP proporcionada ha sido "traducida" o "trasladada"
> (de IP privada a IP pública)... El NAT reemplaza las direcciones
> y puertos de la dirección IP interna.... escondiendo el
> verdadero punto de destino final, es decir el host interno de la
> red privada... Visibilidad de la operación:
> El host externo solamente conoce la dirección pública del
> dispositivo NAT.... la operación NAT es tipicamente transparente
> para los servidores internos y externos."
> Traducción libre de
>http://en.wikipedia.org/wiki/Network_address_translation
>
> Revisemos el párrafo agregando (para claridad absoluta) cuales
> son los números IPv4 e IPv6 en cuestión:
>
> "Con el equipo que realiza el NAT (el servidor del carrier)
> todas las comunicaciones enviadas a servidores externos
> (al servidor de Google que realiza la medición... o al
> servidor X que realiza la medición) a la red privada
> (la red privada es la red que el carrier tiene aquí y a la que
> se conectan todos los usuarios, antiguamente mediante modems y
> discado, hoy directamente, de igual modo al conectarse un
> servidor les otorga un número IPv4 privado, no público)
> contienen un numero IP externo (este es el número IPv6)...
> en vez de la dirección interna del host (que es una
> dirección privada perteneciente al IPv4)... cuando una
> computadora en la red privada
> (interna) envia un paquete hacia la red externa (internet),
> el equipo que realiza el NAT reemplaza la IP interna (el
> IPv4 privado) en el campo del encabezado del paquete (packet
> header) con una IP externa (un IPv6 público) que
> posee el equipo que realiza el NAT. La computadora que recibe
> el paquete (que ha sido afectado por el equipo que realiza
> el NAT) establece una comunicación con el número IP
> especificado (es decir registra y se comunica con el IPv6
> público del equipo NAT) en el paquete alterado, sin
> conocer, ignorando el hecho que la direccion IP proporcionada es
> producto de un reemplazo (de IP privada versión 4 a IP
> pública versión 6)... Lo que ve el servidor que realiza la
> medición: El NAT reemplaza las direcciones y puertos de la
> dirección IP interna (la IPv4).... escondiendo el
> verdadero punto de destino final, es decir el host interno de la
> red privada... Visibilidad de la operación:
> El host externo (el servidor que está evaluando el tipo de
> conexión) solamente conoce la dirección pública del
> dispositivo NAT (la IPv6).... la operación NAT es
> tipicamente transparente para los servidores internos y
> externos. (es decir el servidor que mide, por ejemplo Google,
> no tiene forma de ver, medir, registrar, que la petición de
> información, por ejemplo, viene de un equipo con IPv4 de una
> red privada, solamente ve que 'llega' al servidor de medición
> mediante una dirección IPv6, que pertenece al equipo que
> realiza la función de NAT"
>
>
>
> Hay que agregar que se le puede decir al servidor NAT que otorgue
> direcciones IPv6 de manera aleatoria de un pool de direcciones
> IPv6 que me han sido asignadas. De este modo el servidor de
> medición (google o cualquier otro) verá que son multiples
> direcciones de IPv6 las que realizan las peticiones, consultas o
> solicitan servicio alguno del servidor de medición (o pasan por él
> con destino final hacia otro servidor). Ya sabemos que las
> direcciones IPv6 existen en un número muy grande. Por lo tanto
> resulta muy difícil que el servidor de medición pueda hallar el
> patrón aleatorio por el cual se asignan estas direcciones al azar.
>
> Visto que técnicamente se puede realizar (sin ningún problema y
> con muy poco esfuerzo) una modificación a la arquitectura de la
> red (asignándole bloques de direcciones IPv6 a los servidores
> encargados de realizar la función NAT) y esto modifica
> definitivamente los resultados que registran los servidores de
> medición (que no tienen forma de ver una dirección IP privada que
> se encuentra "detrás", protegida por un servidor NAT), cabe
> preguntarse:
>
>
>* ¿Es esto lo que está pasando?
>
>* ¿Es esto una casualidad o es intencional?
>
>* ¿Para qué se estaría realizando esta "distorsión"?
>
>* ¿Quién se beneficia de esta distorsión?
>
>
> Cabe aclarar que todo esto es lo que es posible, factible,
> realizable, técnicamente. No hemos realizado un estudio
> estadístico, cientifico, que pueda permitirnos asegurar
> categóricamente que esta posibilidad técnica es la que está
> originando resultados (en los servidores de medición) tan
> espectaculares para mi país (Perú) y que, como veremos más
> adelante, corresponden al tráfico de un solo carrier que opera
> en mi país.
>
> Dejo pendiente el remitirles un enlace (no lo encuentro en este
> momento) de los que desarrollaron el sistema de medición de
> Google, donde indican que los resultados mostrados pueden ser
> alterados por... justamente casos como el del NAT que he
> descrito lineas arriba. Era un "paper" presentado a alguna
> conferencia y lo vi hace como seis meses. Si alguien lo tiene,
> conteniendo esta advertencia que hacen los desarrolladores del
> sistema de medición, quedaré agradecido de publicar el enlance.
> Caso contrario, sigo atento y buscando.
>
> JR
>
>
>
>
>
>
> <http://en.wikipedia.org/wiki/Street_address>
>
>
>
>
>
>
>
> --
>
>----------------------------------------------------------------------
>Javier Rodriguez
>Por una mayor y mejor Internet(1995).
>Internet libre, abierta, inclusiva y gratuita para todos (2013).
>Fundador de: eCOML at C, GAC, LimaNet , Axisnet, redPE.
>Fundador y primer presidente de ISOC-Perú
>Miembro de ISOC Internacional, DIPLO IGC, CircleID, cgiPE, i17Peru.
>----------------------------------------------------------------------
>I believe in a bigger & better Internet (1995).
>I work for an open, free, inclusive and cero cost internet (2013).
>Founder of: eCOML at C, GAC, LimaNet, Axisnet, redPE.
>Founder and first president of ISOC-Perú.
>Member of ISOC International, DIPLO IGC, CircleID, cgiPE, i17Peru.
>----------------------------------------------------------------------
>Computing (1980). PC business (1983). UUCP (1985). Internet (1990).
>Commercial Internet (1995). eCommerce (2000). Net Intelligence (2003).
>----------------------------------------------------------------------
>CONTACTO | SOCIAL LINKS
>NetLiberum at gmail.comInternetLibre@outlook.comhttp://facebook.com/NetLiberu
>mhttp://facebook.com/InternetLibrePeruhttps://twitter.com/NetLiberum
>@NetLiberum
>
>PUBLICACIONES | PAPERS
>http://netliberum.blogspot.com/http://InternetLibrePeru.wordpress.com
>http://www.circleid.com/members/6980/http://www.diplointernetgovernance.or
>g/profile/JavierRodriguezhttp://paper.li/NetLiberum/1361689316 (Internet
>Libre en Español)
>http://paper.li/NetLiberum/1399039265 (NetLiberum | English edition)
>----------------------------------------------------------------------
>
>
>
>_______________________________________________
>LACTF mailing list
>LACTF at lacnic.net
>https://mail.lacnic.net/mailman/listinfo/lactf
>Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>
>
>
>_______________________________________________
>LACTF mailing list
>LACTF at lacnic.net
>https://mail.lacnic.net/mailman/listinfo/lactf
>Cancelar suscripcion: lactf-unsubscribe at lacnic.net
More information about the LACTF
mailing list