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

Alejandro Guzman alejog at google.com
Wed Oct 8 21:12:23 BRT 2014 

+1 al comentario de Jordi.

Adicionalmente es totalmente esperable que la gráfica de Telefonica y de
Perú se parezcan... si es el operador que atiende 75% o más de los usuarios
en Perú.

Telefonica Perú efectivamente fue escogida como el piloto por el grupo.
Compraron 200,000 CPEs que permiten dual stack en 2013. Jordi les ayudó a
configurar IPv6 hace varios años en su core y tienen IPv6 con su upstream
provider Para qué usar métodos raros si no necesitan?

De verdad por favor no generemos ruidos innecesarios sin falta de
fundamento técnico ni conocimiento cercano de las situaciones...

Alejandro G


2014-10-08 17:03 GMT-07:00 JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
:

> 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
>
>
>
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf
> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>



-- 


Alejandro Guzman | Director - Content Distribution   | alejog at google.com | +1
(650) 4268561
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20141008/588d3bba/attachment.html>

More information about the LACTF mailing list