<p dir="ltr">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.</p>
<p dir="ltr">Saludos!!!<br></p>
<p dir="ltr">Sent from my Mobile device</p>
<div class="gmail_quote">El oct 8, 2014 6:31 PM, "<a href="mailto:InternetLibre@outlook.com">InternetLibre@outlook.com</a>" <<a href="mailto:InternetLibre@outlook.com">InternetLibre@outlook.com</a>> escribió:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div><big><big><u><b>La razón de la sinrazón</b></u></big></big><br>
(or <b><u>How to skin a cat in five pretty easy steps</u></b>)<br>
<br>
Paso 2: ¿Qué se está midiendo? ¿El origen o la llegada?<br>
<br>
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).<br>
<br>
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). <br>
<br>
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é).<br>
<br>
Para los que conocen el servicio NAT les pido ahorrarse el
siguiente párrafo.<br>
<br>
<blockquote>"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... <span>Visibilidad de la operación</span>:
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."<br>
<i>Traducción libre de </i><i><a href="http://en.wikipedia.org/wiki/Network_address_translation" target="_blank">http://en.wikipedia.org/wiki/Network_address_translation</a></i><br>
<br>
Revisemos el párrafo agregando (para claridad absoluta) cuales
son los números IPv4 e IPv6 en cuestión:<br>
<br>
"Con el equipo que realiza el NAT <b>(el servidor del carrier)</b>
todas las comunicaciones enviadas a servidores externos
<b> (al servidor de Google que realiza la medición... o al
servidor X que realiza la medición)</b> a la red privada<b>
(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)</b>
contienen un numero IP externo <b>(este es el número IPv6)</b>...
en vez de la dirección interna del host <b>(que es una
dirección privada perteneciente al IPv4)...</b> cuando una
computadora en la red privada <b>
(interna)</b> envia un paquete hacia la red externa <b>(internet)</b>,
el equipo que realiza el NAT reemplaza la IP interna <b>(el
IPv4 privado)</b> en el campo del encabezado del paquete <b>(packet
header)</b> con una IP externa <b>(un IPv6 público) </b>que
posee el equipo que realiza el NAT. La computadora que recibe
el paquete <b>(que ha sido afectado por el equipo que realiza
el NAT)</b> establece una comunicación con el número IP
especificado<b> (es decir registra y se comunica con el IPv6
público del equipo NAT)</b> en el paquete alterado, sin
conocer, ignorando el hecho que la direccion IP proporcionada es
producto de un reemplazo <b>(de IP privada versión 4 a IP
pública versión 6)</b>... Lo que ve el servidor que realiza la
medición: El NAT reemplaza las direcciones y puertos de la
dirección IP interna <b>(la IPv4).</b>... escondiendo el
verdadero punto de destino final, es decir el host interno de la
red privada... <span>Visibilidad de la operación</span>:
El host externo<b> (el servidor que está evaluando el tipo de
conexión)</b> solamente conoce la dirección pública del
dispositivo NAT <b>(la IPv6)</b>.... la operación NAT es
tipicamente transparente para los servidores internos y
externos.<b> (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</b>"<br>
</blockquote>
<br>
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.<br>
<br>
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:<br>
<ul>
<li>¿Es esto lo que está pasando?</li>
<li>¿Es esto una casualidad o es intencional?</li>
<li>¿Para qué se estaría realizando esta "distorsión"?</li>
<li>¿Quién se beneficia de esta distorsión?</li>
</ul>
<p>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. <br>
</p>
<p>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.<br>
</p>
<p>JR<br>
<br>
</p>
<br>
<br>
<br>
<br>
<i><a href="http://en.wikipedia.org/wiki/Street_address" title="Street address" target="_blank"></a></i><span><br>
</span><br>
<br>
<br>
<br>
<br>
<br>
</div>
<pre cols="72">--
----------------------------------------------------------------------
Javier Rodriguez
Por una mayor y mejor Internet(1995).
Internet libre, abierta, inclusiva y gratuita para todos (2013).
Fundador de: eCOML@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@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
<a href="mailto:NetLiberum@gmail.com" target="_blank">NetLiberum@gmail.com</a>
<a href="mailto:InternetLibre@outlook.com" target="_blank">InternetLibre@outlook.com</a>
<a href="http://facebook.com/NetLiberum" target="_blank">http://facebook.com/NetLiberum</a>
<a href="http://facebook.com/InternetLibrePeru" target="_blank">http://facebook.com/InternetLibrePeru</a>
<a href="https://twitter.com/NetLiberum" target="_blank">https://twitter.com/NetLiberum</a>
@NetLiberum
PUBLICACIONES | PAPERS
<a href="http://netliberum.blogspot.com/" target="_blank">http://netliberum.blogspot.com/</a>
<a href="http://InternetLibrePeru.wordpress.com" target="_blank">http://InternetLibrePeru.wordpress.com</a>
<a href="http://www.circleid.com/members/6980/" target="_blank">http://www.circleid.com/members/6980/</a>
<a href="http://www.diplointernetgovernance.org/profile/JavierRodriguez" target="_blank">http://www.diplointernetgovernance.org/profile/JavierRodriguez</a>
<a href="http://paper.li/NetLiberum/1361689316" target="_blank">http://paper.li/NetLiberum/1361689316</a> (Internet Libre en Español)
<a href="http://paper.li/NetLiberum/1399039265" target="_blank">http://paper.li/NetLiberum/1399039265</a> (NetLiberum | English edition)
----------------------------------------------------------------------
</pre>
</div>
<br>_______________________________________________<br>
LACTF mailing list<br>
<a href="mailto:LACTF@lacnic.net">LACTF@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lactf" target="_blank">https://mail.lacnic.net/mailman/listinfo/lactf</a><br>
Cancelar suscripcion: <a href="mailto:lactf-unsubscribe@lacnic.net">lactf-unsubscribe@lacnic.net</a><br></blockquote></div>