<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body wsmode="reply" text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Estimados<br>
<br>
Se me ha informado, lo cual agradezco sobremanera, que mi supuesto
sobre la asignación aleatoria de números IPv6 no es correcto. Por
lo tanto mi análisis deviene en invalido.<br>
<br>
El documento
<a class="moz-txt-link-freetext" href="http://www.si6networks.com/presentations/ipv6kongress/mhfg-ipv6-kongress-ipv6-security-assessment.pdf">http://www.si6networks.com/presentations/ipv6kongress/mhfg-ipv6-kongress-ipv6-security-assessment.pdf</a>
es mencionado como una de las fuentes que demuestran que las
direcciones IPv6 NO SON ASIGNADAS ALEATORIAMENTE.<br>
<br>
Revisado el documento, encontramos que habla de como se encuentra
la distribución de direcciones IPv6 para servidores web, para
servidores de correo, para servidores DNS, y para "clientes"
finales (los usuarios los llamaría yo). Este es el único grupo en
cuestión que interesa para resolver mi pregunta: <u><b>cuantos
usuarios finales / clientes, con IPv6, se encuentran
actualmente activos / operativos en mi país (Perú).</b></u><br>
<br>
<u><b>Análisis de los weblogs de ISOC</b></u><b>. </b>El gráfico
adjunto, base de un espectacular trabajo (presentado el 6 de Junio
presente en el IPv6 Kongress, en Alemania, por Gont & Heuse),
está basado en calculos realizados por Matthew Ford, en base a los
accesos al sitio web de ISOC internacional. El documento original
se encuentra aquí:
<a class="moz-txt-link-freetext" href="http://www.internetsociety.org/blog/2013/05/ipv6-address-analysis-privacy-transition-out">http://www.internetsociety.org/blog/2013/05/ipv6-address-analysis-privacy-transition-out</a>
Allí se indica que los números IPv6, en manos de "clientes /
usuarios finales", se dividen del siguiente modo:<br>
<br>
<img alt="chart detailing ipv6 interface ID analysis"
src="cid:part1.00080604.00020901@outlook.com" style="width:
470px; height: 283px;"> Esta data es de Mayo del 2013 (el mes
pasado).<br>
<br>
<br>
<tt>Podemos agruparlos así:<br>
<br>
<b>Usuarios finales / clientes</b><b><br>
</b>69.73 % Son números IPv6 generados de manera randómica (al
azar)</tt><tt><br>
<br>
<b>Routers realizando N</b><b>AT:</b><br>
</tt><tt><tt>13.87 % Son números IPv6 originados por un "Embeded
IPv4" </tt><tt><tt><br>
(IPv6 address configurada manualmente, generalmente<br>
usada para Routers/NATs)</tt></tt></tt><br>
<tt><tt><tt><tt><tt><tt><tt><tt> </tt></tt></tt>6.23 % </tt><tt><tt><tt>Son
números IPv6 "</tt></tt>Low Byte"</tt><tt> (IP
address configurada <br>
manualmente, generalmente usada para Routers</tt><tt><tt><tt><tt>/NATs</tt></tt></tt>)</tt></tt></tt></tt></tt><br>
<tt><tt><tt><tt><tt><tt><tt> </tt>0.01 % Embed IPv4 (64)</tt><tt><tt>(IP
address configurada manualmente, <br>
generalmente usada para Routers</tt></tt><tt><tt><tt><tt><tt>/NATs</tt></tt></tt>)<br>
</tt></tt><br>
<b>Accesos mediante elementos de transición (IPv6 sobre
IPv4,</b><b> tunneling, etc.)</b><br>
</tt></tt></tt></tt></tt><tt><tt><tt><tt><tt><tt><tt> 1.06
% ISATAP </tt></tt><tt><tt>(Intra-Site Automatic
Tunnel Addressing Protocol)</tt><tt><br>
</tt></tt></tt></tt></tt></tt></tt><tt><tt><tt><tt><tt><tt> 0.74
% Embed Port (IPv6 address son generadas para realizar
una <br>
transición, se basan en el IPv4 del servidor
que contiene el <br>
IPv4 y el puerto UDP) <br>
</tt></tt></tt></tt></tt></tt><tt><tt><tt><tt><tt><tt> 0.44
% Embed Port (r)</tt><tt>(IPv6 address son generadas
para realizar una <br>
transición, se basan en el IPv4 del servidor
que contiene el <br>
IPv4 y el puerto UDP)<br>
</tt><br>
<b>Otros</b>
</tt><br>
7.72 % </tt></tt></tt></tt><tt><tt><tt><tt><tt><tt>Son
números IPv6 "</tt></tt>IEEE Based" (IPv6 address
generadas a<br>
partir de "IEEE" identifiers, obtienen la
dirección IPv6 a partir de<br>
una dirección IEEE 802.15.4 que es propio de red
wireless personales <br>
definidas como de bajo consumo: 10 metros de
diámetro y 250kbps)</tt><tt><br>
</tt></tt></tt></tt><tt> 0.20 % Byte Pattern (IPv6 address
donde los bytes 4 y 5, de dicho número IP,<br>
tienen un valor prefijado (0xff, 0xfe) por lo tanto
pierde, el<br>
número IP, su caracter de randómico)</tt><br>
<tt><tt><br>
</tt></tt>100% del total de IPv6 distribuidos a clientes.<br>
(Las definiciones de cada categoría pueden ser halladas en
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-00">http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-00</a>)<br>
<br>
<u><b>Data de Google</b></u>. Parte de estos datos son
ratificados por los servidores de Google
(<a class="moz-txt-link-freetext" href="http://www.google.com/ipv6/statistics.html">http://www.google.com/ipv6/statistics.html</a>) que nos muestran que
al 12 de este mes, el total de usuarios que accesan a Google
mediante conexiones "nativas" de IPv6 es de 1.30%, mientras que
los que llegan mediante Teredo o 6to4 son solamente 0.01%
Lamentablemente esa data no está disponible pais por pais (<i>lo
cual, probablemente, aclararía si ese espectacular décimo lugar
que Perú ostenta en cuanto a implementación de IPv6 es debido a
la topología de la red configurada, donde algún servidor
central, encargado del enrutamiento o de la traslación NAT,
estaría realizando un proceso de transición y tomando las
solicitudes de clientes y usuarios con IPs v4, sin dual stack, y
"trasladándolos" hacia IP v6 y llevándolos, bajo este protocolo,
hacía los servidores con dual stack de Google, Facebook y otros</i>).<br>
<br>
<u><b>Las políticas de asignación de los RIRs</b></u> indican que
el cómo asignan los IPs, correspondientes a los usuarios finales,
en IPv6 queda totalmente en manos de los LIRs/ISPs. La idea se
repite en varios niveles ("There is no specific policy for an
organisation (LIR) to allocate address space to subordinate
ISPs.", "The size of the assignment is a local decision for the
LIR or ISP to make, using a minimum value of a /64 (only one
subnet is anticipated for the End Site)"
(<a class="moz-txt-link-freetext" href="http://www.ripe.net/ripe/docs/ripe-552#initial_allocation">http://www.ripe.net/ripe/docs/ripe-552#initial_allocation</a>).<br>
<br>
Similares medidas se toman en LACNIC:
<a class="moz-txt-link-freetext" href="http://lacnic.net/en/politicas/ipv6.html">http://lacnic.net/en/politicas/ipv6.html</a><br>
<br>
<u><b>Las RFCs al respecto</b></u> (..."IPv6 addressing schema
recomendations from the ISP"...) no indican, en ningún momento que
se haga una asignacion secuencial o randómica. Dejan en manos de
cada ISP el como asigna los números IPs version 6.
(<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc5375.html#ref-LACNIC_IPv6">http://tools.ietf.org/html/rfc5375.html#ref-LACNIC_IPv6</a> y <br>
<br>
<u><b>Conclusiónes:</b></u><u><b><br>
</b></u><br>
a) El 70% de los números IPv6 en uso son generados al azar, de
manera randómica.<br>
b) Los ISPs usa diversos métodos para asignar los números IPv6 que
entregan a los usuarios finales. Esta realidad es la que genera
el 70% anterior.<br>
c) Hay que ajustar la metodología estadística para que refleje el
hecho de que SOLAMENTE el 70% de los números escogidos al azar
corresponden a usuarios finales / clientes.<br>
<br>
Mas tarde procedo a ajustar los números para que reflejen el hecho
de que solamente el 70% de los números generados al azar
corresponderían realmente a usuarios finales con conexiones
"nativas" IPv6.<br>
<br>
Un fraterno abrazo para todos,<br>
<br>
Javier<br>
<br>
On 06/14/2013 10:01 AM, <a class="moz-txt-link-abbreviated" href="mailto:InternetLibre@outlook.com">InternetLibre@outlook.com</a> wrote:
</div>
<blockquote cite="mid:51BAFB6D.2010708@si6networks.com" type="cite">
<blockquote type="cite">
<pre wrap="">Usaré los datos nacionales de mi país (Perú) para establecer el ejemplo.
Lo llevaré hasta donde de mi capacidad. Otros podrán, estoy seguro,
complementar lo faltante y, juntos, podremos acercarnos al tema con la
mayor rigurosidad posible.
Nivel de confianza 99.00%
Margen de error 1.00%
Población 3,169,126,500,570,580,000,000,000,000
Tamaño de muestra 16641
Segundos x muestra 5
Total de segundos 83205
Total de minutos 1386.75
Total de horas 23.1125
Explicación: Tomamos el total de números IPv6 "allocated" para Peru, la
"Población"
por estudiar (data actualizada al 14 de Junio del 2013, hoy!). Luego
aplicamos
las más estrictas reglas para calcular el tamaño de la muestra necesaria
para
alcanzar resultados estadísticamente válidos: 99% de nivel de confianza
y con
un margen de error de 1%. Se necesitan "solamente" muestrear 16,641
direcciones
IPv6 para obtener toda la data posible de ellas (si están operativas,
responden
al PING u otras medidas de testeo).
Si estimamos en CINCO SEGUNDOS el tiempo necesario para hacer un PING y
recibir
(o no recibir) respuesta del número IP (IPv6) analizado, tenemos, al
final que
se requiere UN COMPUTADOR conectado 24 horas (un día) para poder culminar la
prueba. Si le damos más holgura, digamos 10 segundos para hacer y
evaluar el
PING... evidentemente culminaremos el test en DOS DIAS.
Cualquier administrador, economista, estadístico puede validar que con los
parámetros tan estrictos tomados (99% y 1%) NO ES NECESARIO muestrear mayor
cantidad de conexiones IP porque los resultados serán los mismos (dado que
tomaremos la muestra de manera aleatoria).
Si, por alguna razón adicional, se decidiera "testear" más direcciones IP,
adicionales a las 16,641 indicadas, se podría hacer un procesamiento
paralelo
repartiendo una lista aleatoria entre "computadores" voluntarios que hagan
el proceso de "PING" y luego envien la data hacia un computador que
CONSOLIDE
los resultados y entregue el reporte final.
Siguiente paso?
Javier
--
</pre>
</blockquote>
</blockquote>
<br>
<br>
<pre class="moz-signature" 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 | ISOC-Perú | LimaNet | AxisNet | redPE
------------------------------------------------------------------
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 | ISOC-Peru | LimaNet | Axisnet | redPE
----------------------------------------------------------------
Computing (1980). PC business (1983). UUCP (1985). Internet (1990).
Commercial Internet (1995). eCommerce (2000). Net Intelligence (2003).
----------------------------------------------------------------------
@NetLiberum <a class="moz-txt-link-abbreviated" href="mailto:InternetLibre@outlook.com">InternetLibre@outlook.com</a>
<a class="moz-txt-link-freetext" href="http://InternetLibrePeru.wordpress.com">http://InternetLibrePeru.wordpress.com</a>
<a class="moz-txt-link-freetext" href="http://paper.li/NetLiberum/1361689316">http://paper.li/NetLiberum/1361689316</a>
------------------------------------------------------------------
</pre>
</body>
</html>