[LAC-TF] Peru con mas de 9% de Trafico Nativo IPv6

Wed Oct 8 20:53:07 BRT 2014

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
> <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 LINKSNetLiberum at gmail.comInternetLibre@outlook.comhttp://facebook.com/NetLiberumhttp://facebook.com/InternetLibrePeruhttps://twitter.com/NetLiberum
> @NetLiberum
>
> PUBLICACIONES | PAPERShttp://netliberum.blogspot.com/http://InternetLibrePeru.wordpress.com http://www.circleid.com/members/6980/http://www.diplointernetgovernance.org/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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20141008/ca64cf31/attachment.html>