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.

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

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

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

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:

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,

Tecno-cuento: La triste historia de un ISP sin IPv6

Erase una vez.....
  Erase una vez, en un tiempo no muy lejano, un ISP muy grande que
dominaba las telecomunicaciones de un país, se sentía poderoso y sin
competencia. Cuando alguien necesitaba conectarse a Internet siempre
recurrian a ellos. Tenían una penetración en el mercado envidiable
para todos.

  Sin embargo, este ISP tan grande no había querido implementar nunca
IPv6, pensaba que tenía suficientes direcciones IP para abastecerse, no
percibían indicador alguno que dijera: tengo que tener el nuevo protocolo.

  Durante esos años, otro pequeño ISP si implementó IPv6,
comenzaron a crecer lentamente, se dieron cuenta que el protocolo si
marcaba una diferencia en sus clientes, ganaban usuarios gracias a tener
soporte de dicho protocolo. Su penetración en el mercado crecía,
ganaban más dinero y más respeto. Siendo más grandes le era más
fácil conseguir mejores precios de equipos, de tráfico, de
interconexión. Todo funcionaba muy bien. El ISP pequeño sencillamente
no lo podía creer, algo tan sencillo de implementar como IPv6 le
rendía frutos inimaginables. Sus clientes le decian que tenian crear
VPNs y conferencias contra otras partes del mundo, que sus subsidiarias, clientes y
aliados de negocio en Europa y Asia si tenían IPv6, por ello IPv4 no les
era importante.

 El ISP grande, a pesar de ser tan poderoso comenzó a tener
problemas internos, no eran problemas de facturación o dinero. Eran
quejas del personal de ventas que no podían cerrar las mismas porque
los clientes empezaron a pedir IPv6 y ellos siendo tan grandes e
importantes sencillamente no tenían!!. Clientes corporativos pedían
IPv6, usuarios residenciales solicitaban lo mismo, incluso grandes
licitaciones del estado. Cuando eso empezó a ocurrir el Gerente de
Ventas tuvo quejas hacia los departamentos de Producto, Ingeniería y
Operaciones. Estos últimos se quedaron sin palabras y algunos empleados
fueron removidos por los dueños de las empresas. Al final, a Ventas no
les importaba donde estaba la culpa, sencillamente no podían obtener
nuevos clientes.

 Posteriormente algunos vendedores al percatarse que estaban
perdiendo clientes fueron contratados por el ISP pequeño que estaba
buscando personal, total ahora sí podían pagar a importantes vendedores
porque en realidad ya no eran tan chicos. Lo mismo ocurrió con el jefe
de redes del ISP grande que sabía mucho de IPv6 pero la burocracia no
le había permitido llevar a producción el novedoso protocolo. Luego el
jefe de redes lógicamente trajo a su administrador de servidores de
confianza y su persona de seguridad. El ISP grande no podía creer lo
que estaba pasando.

 Los vendedores contratados por el ISP chico (provenientes del ISP
grande) venían con su enorme cartera de clientes, todos potenciales para
ser instalados. Se avecinaba una estampida de clientes del ISP grande.
Pasaban los meses y el ISP chico ya no solo ofrecía Internet, su Data
Center era mucho más grande, importantes empresas trajeron servidores
nuevos, de cache y mucho más. Ahora ofrecían co-location, hosting,
virtual hosting, voz, video y más.

 Cuando el proveedor grande quiso implementar IPv6, tuvo que hacer las
cosas muy rápidas, les salian mal, varios errores, además
consultores y empresas se aprovecharon de sus problemas y cobraban mucho
más para hacer las tareas con la premura que solicitaban. Aumentó el
downtime de red, las llamadas al call center y la prestigiosa reputación se venía
abajo.

 Como es de esperar, al final de la historia todos en el cuento:
clientes y proveedores terminaron implementando IPv6, unos más felices que otros
pero todos con IPv6 en sus redes

  Espero lo hayan disfrutado, y Colorín Colorado este cuento se ha acabado

Abrazos a todos,

Alejandro,

Get ready for Black Friday deals in South Africa with bidorbuy. We at bidorbuy are as excited as you are! We are hard at work to find the best deals at the best price to bring you a whole week of awesome Black Friday deals!