martes, 28 de julio de 2015

Contenido www y embriones sobre IPv6. Region Lacnic

Buenas tardes,
  En esta oportunidad les quiero compartir un pequeño análisis sobre estadísticas de penetración de IPv6 en el mundo de contenido. En otras oportunidades (*1) hemos conversado
sobre estadísticas de penetración de IPv6 desde la perspectiva del usuario final. En lo personal me alegra mucho contar con este tipo de mediciones porque es algo que nos faltaba.
¿Qué quiere decir estadísticas de penetración de IPv6 en el mundo de contenido?Básicamente es saber cuánto contenido/servidores existe sobre IPv6, NO cuántos usuarios NI cuánto tráfico sobre IPv6 está siendo cursado. 
ProblemasEl mayor problema que se encuentra es determinar con certeza cuál contenido se encuentra en un país. Recordemos que Internet es una red globalizada, saber que donde se encuentra el "host" de un dominio es algo muy complejo. Ciertamente existen muchas técnicas pero de igual manera no son 100% confiables. Ejemplo: indicar que el dominio www.example.com.ve está en Venezuela puede ser totalmente cierto, parcialmente cierto o totalmente negativo. Para poder llevar a cabo este estudio decidimos tomar únicamente dominios con ccTLD de nuestra región.
¿Cómo se realizó este estudio?Vamos a indicarlos por pasos para visualizarlo mejor:
1) Se toma un archivo con los TOP 1 millón de dominios del mundo (*2)
2) Se toma el ccTLD de los mismos (.ar, .uy, .br, .ve, etc)
3) Del punto 2 se averigua si tienen registros AAAA en su www
4) Del punto 2 se hace un estudio para averiguar si existen "embriones
IPv6", es decir, dominios que no tienen IPv6 en su www pero si tienen host con los nombres w6, www6, ipv6, v6 + dominio
Procesamiento:
- Del archivo Majestic Million con un millón de dominios, aproximadamente 8000 tienen ccTLD de la región de Latinoamérica y Caribe.
- Posteriormente se utiliza el dominio y se buscan registros AAAA para:
www + dominio
ipv6|v6|www.ipv6|www6|ip6|w6 + dominio
Resultados:De puede apreciar lo siguiente:
1.- Para Websites con IPv6 actuales:El top 5 de los países con Websites con AAAA tenemos:


Gráfico #1. Resumen países con sitios con registros AAAA

1.- Brasil cuenta con 180 sitios que representa el 57.3% del total
2.- Colombia con 47 sitios que representa el 15% del total
3.- México con 33 sitios que representa el 10.5% del total
4.- Argentina con 10 sitios que representa el 3.2% del total
5.- Chile con 7 sitios que representa el 2.2 del total

(estadísticas para el 22 de Julio, 7709 dominios estudiados y 314 Websites con AAAA)


Gráfico #2. Resumen sitios actuales con AAAA
2.- Para Websites embriones:El top 5 de los países con Websites embriones tenemos:

Gráfico #3. Resumen países con embriones IPv6


1.- Brasil 25 (con 45.5 %)
2.- Colombia 18 (32.7%)
3.- Mexico (9.1%)
4.- Perú 2 (3.6 %)
5.- Chile 2 (3.6 %)

(estadísticas para el 22 de Julio, 7709 dominios estudiados y 55 Websites embrios encontrados)

Gráfico #4. Resumen sitios embriones IPv6


Es muy interesante apreciar que Brasil, Colombia, México y Chile se encuentran en ambos cuadros mientras que Perú y Argentina se intercambian la 4ta posición.
Los resultados pueden ser obtenidos en el sitio: http://stats.labs.lacnic.net y buscando por “Websites actuales con IPv6” y “Embriones Websites (AAAA)” en la columna de la izquierda.


Conclusión:  Primero, que nada, es una alegría observar que existen más sitios con IPv6 que embriones por nacer ( claro, de alguna manera se entiende que lo anterior tiene sentido y en realidad no quise caer en comparaciones de otras índoles).
  Segundo, se entiende que puede existir un aspecto también de idiosincrasia donde algunos países y administradores sean más cuidadosos -o menos- y no usen un URL de embriones y coloquen su sitio en v6 directamente.
  Tercero, de alguna manera podemos esperar que en un futuro consigamos que los sitios embrionarios se conviertan en sitios formales (www) con IPv6.
¿Posibles próximos pasos?- En el presente estudio se evaluó únicamente dominios listados en el TOP 1 millón de Majestic
filtrados por ccTLD de la nuestra región Latam y Caribe, se puede evaluar la manera de extender este estudio a otros listados
- Identificar si la dirección IPv6 que apunta el AAAA es de Lacnic
- Estudiar cuánto tiempo pasa un sitio embrión a un sitio formal con IPv6.

Margen de error:- Se entiende que puede existir un margen de error, un host embrión no significa que sea
necesariamente movido al www del dominio.
Tecnisismos:- Todos los scripts fueron realizados en python3 sobre Linux Ubuntu 13.04

Por:
Alejandro Acosta
Lacnic
@ITandNetworking
*1. Retrospectiva: Acceso IPv6 en la region Latinoamerica y Caribe (LAC) en: http://portalipv6.lacnic.net/retrospectiva-acceso-ipv6-en-la-region-latinoamerica-y-caribe-lac/
*2. https://majestic.com/reports/majestic-million

miércoles, 27 de mayo de 2015

Sinopsis FLIP6 Lima Peru 18-22 de Mayo 2015

Buenas dias a todos(as),


 Una vez más para mi es un honor realizar este resumen. En esta
oportunidad me corresponde sobre el Decimotercer Foro Latinoamericano de
IPv6 (FLIP6) llevado a cabo durante el evento de Lacnic 23 en Lima -
Perú entre los días 18 al 22 de Mayo del presente año.

 Todos los eventos son especiales, cada uno tiene su propia magia, sin
embargo esta oportunidad venía acompañado de un contexto adicional por
ser mi último año como moderador del foro.

 En Lima, FLIP6 tuvo una duración de 6 horas divididas en tres días
consecutivos. Para el evento hubo más de 450 personas en sitio y
aproximadamente 100 personas haciendo seguimiento vía Webcasting. Para
el momento que se escriben estas líneas parte de las presentaciones se
encuentran en youtube.com ([1]) y en el sitio guindadas en la web de
Lacnic ([2]).

 Hablando del evento per sé: contamos con los siguientes expositores más
un panel (la agenda puede ser conseguida también en [2]):


Expositores:

- John Correa

 John Correa estaba exponiendo por primera vez durante FLIP6, su tema
fue "Asegurando servicios IPv6 en Linux". El tópico indiscutiblemente es
considerado un tema muy importante en estos tiempo donde las
implementaciones de IPv6 se están llevando a cabo a un ritmo acelerado.
Desde FLIP6 además de incentivar el protocolo lo queremos promover de
manera segura.


- Panel: Fabricantes e IPv6

 El Panel fue una iniciativa de Lacnic que vino como resultado de las
encuestas realizadas en eventos previos donde los asistentes
manifestaban que sería buena idea contar con los propios fabricantes
hablando directamente de su soporte de IPv6 en sus productos.

 El Panel estuvo compuesto por los siguientes panelistas:

 - Tomás Lynch, Ericsson
 - Hugo Peña - Alcatel-Lucent
 - Wardner Maia, Mikrotik
 - Enrique Dávila, Cisco


 Al final esta presentación fue muy exitosa, en lo personal tuve muy
buen feedback y siempre escuchar del propio vendor hablar de su soporte
IPv6 es muy beneficioso.


- John Brzozowski - KeyNote

 Como es costumbre, dentro del FLIP6 contamos con la presencia de un
Keynote, en esta oportunidad le correspondió a un amigo de la casa: John
Brzozowski. Durante su presentación cubrió diferentes temas relevantes a
IPv6: Desde estadísticas, novedades en Comcast, importancia de IPv6
entre otros. Este tipo de exposiciones esperemos apoyen a la difusión
del protocolo a lo largo y ancho de nuestra región.


- Jordi Palet - 464XLAT

 Jordi, viejo amigo de la casa, expuso sobre una interesante tecnología
la cual ha tenido mucha  adopción y probablemente se masifique más su
implementación en un corto tiempo. Su presentación trató sobre el
mecanismo de transición 464XLAT. Esperamos haya sido educativo y le
sirva de puente a muchos para implementar IPv6 en sus redes


- Gregorio Manzano - Iniciativa comunitaria para despliegue del
protocolo IPv6 en Venezuela

 Esta presentación trató sobre como un grupo de lideres en Internet en
Venezuela llevaron a cabo la formación de un grupo para promover IPv6 en
su país. Gregorió abarcó desde sus inicios hasta la entrega de un
documento al gobierno de Venezuela. Felicitamos esta iniciativo y ojalá
existan más en la región.


- Kathleen Moriarty - IETF CodeMatch

 Por primera vez en FLIP6 tuvimos a Kathleen Moriarty quien trabaja muy
de cerca con ISOC y la IETF. Nos expuso sobre una excelente iniciativa
llamada CodeMatch donde se busca acercar a las universidades de la
región a la IETF. Kathleen explicó en que consiste y como convertirse en
parte de esta interesante iniciativa. Deseamos ver muchas universidades
de la región involucradas en este tipo de proyectos.


- Fernando Gont - Avances recientes en seguridad de IPv6 y Evaluaciones
de seguridad y resolución de problemas con el IPv6 Toolkit v2.0 de SI6

 Fernando, otro amigo de la casa, tuvo la oportunidad de realizar dos
exposiciones durante FLIP6, ambas muy relaciones a seguridad de red.
Expuso de una manera muy pedagógica basado en ejemplos de como utilizar
IPv6 Toolkit y adicionalmente indicó temas muy importantes de seguridad
en el mundo de IPv6. Una vez para nuestro foro no es solo fomentar IPv6
sino promoverlo dentro de un contexto de implementación segura y basado
en mejores prácticas. Esperamos que con este tipo de charlas educar al
asistentes y fortalecer las redes en la región.


- Enrique Davila - Operar en forma segura redes IPv6

 Enrique Dávila, exponía por primera vez en FLIP6, explicó de una manera
práctica diversas tareas que pueden llevar a cabo los administradores de
redes para operar de mejor manera una red IPv6. Indicó diversos consejos
y prevenciones que pueden tomarse en cuenta con el objetivo de aumentar
la seguridad de una red IPv6. Estamos seguro que esta junto a otras
exposiciones llevadas a cabo durante el FLIP6 permitirán al asistente en
incrementar la seguridad de sus redes.


- Gianpietro Lavado - Segment-Routing in IPv6

  Gianpietro expuso sobre un tema muy novedoso llamado Segment-Routing,
específicamente lo enfocó al área de IPv6. Indicó sus ventajas y
posibles implementaciones que existirán en el futuro cercano. Desde
FLIP6 nos encantan este tipo de temas porque nos permiten estar
enterados en lo que acontece en el marco de la IETF y a su vez
prepararnos mejor para lo que viene en el mundo de enrutamiento en un
futuro no muy lejano


- Mariela Rocha - Informe Portal IPv6

 Mariela Rocha (ex-moderadora de FLIP6*)* nos acompañó en esta
oportunidad para indicarnos avances que existen en el portal IPv6 de
Lacnic [3]. Nos explicó diferentes aspectos y noticias que se guindan en
el mismo, contenido nuevo que tiene y como participar en el mismo. Nos
recordó que el portal es de la comunidad y cada uno de nosotros puede
ser participe del mismo. Ójala esta exposición incentive al asistente a
engranarse con el portal IPv6.


Miscelaneos.

 En este oportunidad el moderador también hizo algunos anuncios:


- Se presentó la canción IPv6 [4]  (favor escucharla y recordar colocar
los subtítulos)

- Se presentó una animación llamada: "La triste historia de un ISP sin
IPv6" [5]

- El actual moderador anunció próximas elecciones para Junio 2015
indicando su intención de no postularse para las mismas. De igual manera
enfáticamente indicó que este cargo ha sido muy enriquecedor dentro de
su vida profesional.


Reciban todos un fuerte abrazo y como siempre quedando a sus ordenes.



Att.

Alejandro Acosta

Moderador
FLIP6 2015



[1] https://www.youtube.com/playlist?list=PLU6Q4ZhHN2Q6Iw4rb9paNKIwYGhEMLCZK

[2] http://www.lacnic.net/en/web/eventos/lacnic23-foro-flip6

[3] http://portalipv6.lacnic.net

[4] https://www.youtube.com/watch?v=99Qw9cfpyEg
Créditos a:
Antonio Esguerra: Head Engineer
Michae Schulze: Co-producer
Eidan Molina: Co-producer. Composer.
Music and Lyrics by Eidan Molina
Agrupacion de producción: Fifth Floor Studios
Idea: Alejandro Acosta

[5] https://www.youtube.com/watch?v=BswW2uVHoX0*
Créditos a:

Guion: Alejandro Acosta,
Producido en: Universidad de
Guadalajara Coordinacion General de Tecnologia de Informacion, Animacion
y Diseno: Marco Sierra,

Voz:**Dolores Hernandez - Red Radio Universidad de Guadalajara,
Grabacion: Mauricio Urbina - Red Radio

Universidad de Guadalajara, Edicion: de Sonido Marco Sierra, Tema
Musical: "Children" Matti Paalanen.

lunes, 25 de mayo de 2015

Animacion: La triste historia de un ISP sin IPv6

`




La triste historia de un ISP sin IPv6. Guion: Alejandro Acosta, Producido en: Universidad de Guadalajara - Coordinacion General de Tecnologia de Informacion, Animacion y Diseno: Marco Sierra, Voz: Dolores Hernandez - Red Radio Universidad de Guadalajara, Grabacion: Mauricio Urbina - Red Radio Universidad de Guadalajara, Edicion: de Sonido Marco Sierra, Tema Musical: "Children" Matti Paalanen.

Historia original en: https://blog.acostasite.com/2015/01/tecno-cuento-la-triste-historia-de-un.html

miércoles, 6 de mayo de 2015

Demostracion de Secuestro de Prefijos - RPKI - BGP (parte 2/2)


En este segundo video se muestra como manipular Quagga para que tome decisiones en base al estado del prefijo RPKI. Continuacion de: https://blog.acostasite.com/2015/05/demostracion-de-secuestro-de-prefijos.html


martes, 5 de mayo de 2015

Demostracion de Secuestro de Prefijos - RPKI - BGP (parte 1/2)


El video muestra un ejemplo de como ocurre un secuestro de un prefijo de red en Internet y a su vez muestra como RPKI ayudaría a prevenir esta situación

lunes, 27 de abril de 2015

Construyendo una topología de red 464XLAT (mecanismo de transicion)

Introducción:
  El siguiente post indica el procedimiento que puedes seguir para tener una topología de red con 464XLAT


Topología:



Que se necesita:
Del lado del cliente:
- Un cliente CLAT, en nuestro ejemplo utilizamos: https://github.com/toreanderson/clatd
- Tayga como NAT64 (http://www.litech.org/tayga/)  En este post puedes conseguir el procedimiento de instalación (más abajo dejo todos los archivos de configuración)


y del lado del servidor:
- Tayga como NAT64 (http://www.litech.org/tayga/)  En este post puedes conseguir el procedimiento de instalación (más abajo dejo todos los archivos de configuración)
- Para nuestro ejemplo un DNS Server pero si tienes otro puedes obviarlo. Es recomendable utilizar DNS64 para facilitar el reconocimiento de red cuando se ejecute el clatd.
- radvd (para hacer los anuncios RA y que el cliente se auto-configure), una vez puedes obviarlo y hacer tus configuraciones manuales


Configuraciones:
Del lado del cliente:
En lineas generales no es necesario configuar nada. El tayga utiliza un archivo de ejemplo construido en el momento y el clatd verifica todo lo necesario. Por favor asegura que el archivo /etc/resolv.conf contenga la línea;

nameserver 2001:13c7:100:f101::1


IMPORTANTE: Del lado del cliente lo unico que hay que hacer es ejecutar el cliente clatd. El procedimiento es el siguiente:
#unzip clatd-master
#cd clatd-master
#./clatd  

Con este último comando el clatd será capaz de reconocer que NO hay direcciones IPv4 en el equipo donde se ejecuta y reconocer como es su conectividad hacia el exterior.

Del lado del servidor (6 pasos):
1) El radvd se configura en el archivo /etc/radvd.conf y debe quedar así:

interface eth0 { 
        AdvSendAdvert on;
        MinRtrAdvInterval 3; 
        MaxRtrAdvInterval 10;
        prefix 2001:13c7:0100:f101::/64 { 
                AdvOnLink on; 
                AdvAutonomous on; 
                AdvRouterAddr on; 
        };
};


2) Tayga: Del lado del servidor si es muy importante realizar una configuración de tayga. Para nuestro ejemplo:

En /usr/local/etc/tayga.conf:
tun-device nat64
ipv4-addr 192.168.64.1
prefix 64:ff9b::/96
dynamic-pool 192.168.64.0/24
data-dir /var/log/tayga
ipv6-addr 2001:13c7:100:f101::1


3) Las interfaces del lado del servidor deben quedar así:
/usr/local/sbin/tayga --mktun
/sbin/ip link set nat64 up
/sbin/ip addr add 10.0.3.15 dev nat64
/sbin/ip addr add 64:ff9b::1 dev nat64
/sbin/ip route add 192.168.64.0/24 dev nat64
/sbin/ip route add 64:ff9b::/96 dev nat64

4) Levantar tayga:
/usr/local/sbin/tayga -d &


5) Hacer NAT de la red IPv4:
/sbin/iptables -t nat -A POSTROUTING -s 192.168.64.0/24 -o eth10 -j MASQUERADE


6) El DNS Server debe quedar con la siguiente directiva dentro de /etc/bind/named.conf.options:

        dns64 64:ff9b::/96 {
          clients {
           any; };
        };  // End of DNS64 Section


Un poco mas de como quedas las interfaces. La salida de ifconfig del lado del servidor:

eth10      Link encap:Ethernet  HWaddr 00:0c:29:06:e9:cc
          inet addr:10.0.3.15  Bcast:10.0.3.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe06:e9cc/64 Scope:Link
          inet6 addr: 2001:13c7:7001:500::21/64 Scope:Global   ---> HACIA WAN
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:42282238 errors:0 dropped:307 overruns:0 frame:0
          TX packets:11377224 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5706072894 (5.7 GB)  TX bytes:2226397897 (2.2 GB)

eth9      Link encap:Ethernet  HWaddr 00:0c:29:06:e9:d6
          inet addr:10.64.0.1  Bcast:10.64.0.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe06:e9d6/64 Scope:Link
          inet6 addr: 2001:13c7:100:f101::1/64 Scope:Global  --- HACIA LAN
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:652093 errors:0 dropped:72 overruns:0 frame:0
          TX packets:2662969 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:84197892 (84.1 MB)  TX bytes:1461857730 (1.4 GB)

nat64     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.0.3.15 P-t-P:10.0.3.15  Mask:255.255.255.255
          inet6 addr: 64:ff9b::1/128 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1135938 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1074859 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:939693414 (939.6 MB)  TX bytes:931853538 (931.8 MB)




Explicando todo lo anterior:

1) Supongamos que el cliente quiere acceder una direcciones IPv6.., no pasa nada extraño  :-). El routing es 100% IPv6, no hay NAT, todo normal.

2) En el supuesto que el cliente quiera acceder a una dirección IPv4:

a) El cliente clatd otorgará un socket IPv4 a la aplicación
b) El paquete que construya el cliente será 100% IPv6. Será su dirección IPv6 origen y el destino será 64:ff9b::/96 + 32 bits de la dirección IPv4 destino. Recordemos que no hay IPv4 en el core de la red.
c) El PLAT (Tayga del lado del servidor)  al recibir un paquete con destino 64:ff9b::/96 lo enruta por la interfaz TUN NAT64 (interfaz lógica) donde tayga remueve los primeros 96 bits del destino dejando unicamente los 32 bits menos significativos (la dirección IPv4). Al origen (IPv6) se le hace una mapeo stateless con una direccion IPv4 (del pool en el archivo de configuración (192.168.64.0/24).
d) Cuando el paquete con el origen 192.168.64.0/24 del servidor desee salir del equipo será nateado con iptables al IPv4 que tenga eth10 (/sbin/iptables -t nat -A POSTROUTING -s 192.168.64.0/24 -o eth10 -j MASQUERADE)




Anexo:
a) ping a un destino IPv4 desde el cliente:




b) Clatd ejecutándose:



c) Captura en Wireshark de un ping desde el cliente (IPv6 only) a un destino IPv4:









martes, 17 de febrero de 2015

Solucion a: quagga vtysh " Exiting: failed to connect to any daemons."

Situacion:
  Al ejecutar el comando vtysh en el shell de linux para conectarse a los demonios de quagga (bgpd, ospfd, etc) da el siguiente error "Exiting: failed to connect to any daemons"

alejandro@miserver:~$ vtysh -d bgpd
Exiting: failed to connect to any daemons.

alejandro@miserver:~$ vtysh 
Exiting: failed to connect to any daemons.


Solucion:
  La solución es agregar al usuario con el que ejecutas vtysh al grupo quagga, para ello edita el archivo /etc/group.
  La linea en /etc/group debe quedar algo asi:

quagga:x:1003:alejandro

puedes especificar varios haciendo:

quagga:x:1003:alejandro, john


  Lo anterior es necesario porque la conexión a los demonios de quagga los realiza con UNIX domain socket y no todos los usuarios tienen acceso a dichos sockets.

Otra solución:
  Otra solución puede ser durante la compilación especificar el grupo para la creación de los sockets pasando lo siguiente durante el configure:

./configure --enable-vty-group=group

 


  Suerte, espero haya sido útil,






BGP Stream: un año de análisis sobre incidentes BGP

BGP Stream: un año de análisis sobre incidentes BGP 04/03/2024 Por  Alejandro Acosta , Coordinador de I+D en LACNIC LACNIC presenta  la prim...