[lacnog] Como calcular el número de conexiones IPv6 en un país. Paso 1. Tamaño de la muestra
InternetLibre en outlook.com
InternetLibre en outlook.com
Vie Jun 14 18:17:08 BRT 2013
Estimados
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.
El documento
http://www.si6networks.com/presentations/ipv6kongress/mhfg-ipv6-kongress-ipv6-security-assessment.pdf
es mencionado como una de las fuentes que demuestran que las direcciones
IPv6 NO SON ASIGNADAS ALEATORIAMENTE.
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: _*cuantos usuarios finales / clientes, con IPv6,
se encuentran actualmente activos / operativos en mi país (Perú).*_
_*Análisis de los weblogs de ISOC*_*. *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í:
http://www.internetsociety.org/blog/2013/05/ipv6-address-analysis-privacy-transition-out
Allí se indica que los números IPv6, en manos de "clientes / usuarios
finales", se dividen del siguiente modo:
chart detailing ipv6 interface ID analysis Esta data es de Mayo del
2013 (el mes pasado).
Podemos agruparlos así:
*Usuarios finales / clientes**
*69.73 % Son números IPv6 generados de manera randómica (al azar)
*Routers realizando N**AT:*
13.87 % Son números IPv6 originados por un "Embeded IPv4"
(IPv6 address configurada manualmente, generalmente
usada para Routers/NATs)
6.23 % Son números IPv6 "Low Byte"(IP address configurada
manualmente, generalmente usada para Routers/NATs)
0.01 % Embed IPv4 (64)(IP address configurada manualmente,
generalmente usada para Routers/NATs)
*Accesos mediante elementos de transición (IPv6 sobre IPv4,**tunneling,
etc.)*
1.06 % ISATAP (Intra-Site Automatic Tunnel Addressing Protocol)
0.74 % Embed Port (IPv6 address son generadas para realizar una
transición, se basan en el IPv4 del servidor que contiene el
IPv4 y el puerto UDP)
0.44 % Embed Port (r)(IPv6 address son generadas para realizar una
transición, se basan en el IPv4 del servidor que contiene el
IPv4 y el puerto UDP)
*Otros*
7.72 % Son números IPv6 "IEEE Based" (IPv6 address generadas a
partir de "IEEE" identifiers, obtienen la dirección IPv6 a
partir de
una dirección IEEE 802.15.4 que es propio de red wireless
personales
definidas como de bajo consumo: 10 metros de diámetro y 250kbps)
0.20 % Byte Pattern (IPv6 address donde los bytes 4 y 5, de dicho
número IP,
tienen un valor prefijado (0xff, 0xfe) por lo tanto pierde, el
número IP, su caracter de randómico)
100% del total de IPv6 distribuidos a clientes.
(Las definiciones de cada categoría pueden ser halladas en
http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-00)
_*Data de Google*_. Parte de estos datos son ratificados por los
servidores de Google (http://www.google.com/ipv6/statistics.html) 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 (/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/).
_*Las políticas de asignación de los RIRs*_ 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)" (http://www.ripe.net/ripe/docs/ripe-552#initial_allocation).
Similares medidas se toman en LACNIC:
http://lacnic.net/en/politicas/ipv6.html
_*Las RFCs al respecto*_ (..."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.
(http://tools.ietf.org/html/rfc5375.html#ref-LACNIC_IPv6 y
_*Conclusiónes:*__*
*_
a) El 70% de los números IPv6 en uso son generados al azar, de manera
randómica.
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.
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.
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.
Un fraterno abrazo para todos,
Javier
On 06/14/2013 10:01 AM, InternetLibre en outlook.com wrote:
>> 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
>>
>> --
>>
>>
--
------------------------------------------------------------------
Javier Rodriguez
Por una mayor y mejor Internet(1995).
Internet libre, abierta, inclusiva y gratuita para todos (2013).
Fundador de eCOML en 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 en 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 InternetLibre en outlook.com
http://InternetLibrePeru.wordpress.com
http://paper.li/NetLiberum/1361689316
------------------------------------------------------------------
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20130614/397b7470/attachment.html>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: Address-analysis2_0.png
Type: image/png
Size: 83589 bytes
Desc: no disponible
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20130614/397b7470/attachment.png>
Más información sobre la lista de distribución LACNOG