NAT66 en Linux

Hola,

  El dia de hoy voy a hacer un post el cual no deseo que sea tomado de mala manera. Indiscutiblemente no estoy a favor del NAT pero aun asi pienso que es un mecanismo que no desaparecera en IPv6 (se reducira drasticamente) pero siempre existira. En lo posible recomiendo evitar hacer NAT cuando exista la posibilidad.

  Pueden haber muchas razones para implementar NAT66, a) seguramente los clientes acostumbrados a hacer NAT querran hacerlo en IPv6 (suene feo o bonito), b) personas que quieran ocultar su topologia a Internet, c) empresas que consideren NAT como mecanismo para cambiar los IPs de sus redes, d) la tendencia mundial de no permitir tethering en los celulares, e) querer ofrecer IPv6 detras de un dispositivo y mi proveedor no tenga DHCPv6-PD o solo me entregue una red /64, f) alguien que piense que NAT sirve de mecanismo de seguridad, etc, etc, etc, etc.

  En base a lo anterior la intencion de este post no es estar a favor o en contra de NAT, solo deseo indicar que esta disponible en el mundo de IPv6 y ofrecer un sencillo ejemplo. Para bien o para mal puede ser utilizado en algunos escenarios.

Requerimientos:

  El equipo a realizar el NAT66 debe tener:

  - Kernel > 3.9 

  - iptables > 1.4.18

  Ubuntu 14.04 cubre ambos requerimientos "out-of-the-box" y por ello es muy sencillo hacerlo.

  Existen patch para hacer NAT66 en versiones previas pero no lo indicare en este momento.

Escenario:

  Esta es la topologia en la que estoy trabajando. Deseo que "Device 2"  traduzca la direccion IPv6 origen de "Device 1" con la direccion IPv6 de la interfaz saliente (eth2). Con el comando NAT implementado estoy realmente haciendo NAT de toda la subred 2001:db8:12::/48

Configuraciones:

En DEVICE 1:

#ifconfig eth0 inet6 add 2001:db8:12::2/48

#route -A inet6 add default gw 2001:db8:12::1

En DEVICE 2:

Configurar las direcciones IPv6 en el equipo

#ifconfig eth1 inet6 add 2001:db8:12::1/48

#ifconfig eth2 inet6 add 2001:db8:23::1/48

Habilitar enrutamient o IPv6 entre las interfaces:

#sysctl -w net.ipv6.conf.all.forwarding=1

Configurar el NAT66:

#ip6tables -t nat -A POSTROUTING -o eth2 -s 2001:db8:12::/48 -j MASQUERADE

(es de notar que existen muchas otras maneras de hacer NAT con ip6tables)

En DEVICE 3:

#ifconfig eth1 inet6 add 2001:db8:23::2/48

#route -A inet6 add default gw 2001:db8:23::1

  Del lado de Device 3 pueden verificar de muchas maneras que todo funcione, incluso sin ruta por default en Device 3, DEVICE 1 puede llegarle. De igual manera tcpdump, wireshark o una sencilla revision de los logs puedes verificar que efecticamente el NAT esta llevandose a cabo.

  Espero sea de tu utilidad

Solucion a tres errores cuando queremos arrancar ISC DHCP 4.3

Error 1: 
Can't open lease database /var/lib/dhcp/dhcpd6.leases: No such file or directory --
  check for failed database rewrite attempt!

Ejemplo:
root@IPv6-RTR:/etc#  /usr/sbin/dhcpd -6 -f -cf /etc/dhcp/dhcpd.conf eth5
Internet Systems Consortium DHCP Server 4.3.0a1
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Can't open lease database /var/lib/dhcp/dhcpd6.leases: No such file or directory --
  check for failed database rewrite attempt!
Please read the dhcpd.leases manual page if you
don't know what to do about this.
root@IPv6-RTR:/etc# touch /var/lib/dhcp/dhcpd6.leases


Solucion a error 1:
#touch /var/lib/dhcp/dhcpd6.leases

Adicionalmente verificar si el usuario con el que se esta ejecutando dhcpd posee escritura en /var/lib/dhcp

Quizas tambien hay que:
#cd /var/lib/
#chown -R root.root dhcp

--------------------------

Error 2:
   No subnet6 declaration for eth5 (fe80::a00:27ff:fee7:b7c)

Ejemplo del error:
root@IPv6-RTR:/etc/dhcp# /usr/sbin/dhcpd -6 -f -cf /etc/dhcp/dhcpd.conf eth5
Internet Systems Consortium DHCP Server 4.3.0a1
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Wrote 0 NA, 0 TA, 0 PD leases to lease file.

No subnet6 declaration for eth5 (fe80::a00:27ff:fee7:b7c).
** Ignoring requests on eth5.  If this is not what
   you want, please write a subnet6 declaration
   in your dhcpd.conf file for the network segment
   to which interface eth5 is attached. **


Not configured to listen on any interfaces!


Solucion a error 2:
   Quitar la declaracion de subnet6 en dhcpd6.conf y copiarla a dhcpd.conf

-------------------------

Error 3:
   Can't set SO_REUSEPORT option on dhcp socket: Protocol not available

Ejemplo del error:

root@IPv6-RTR:/etc/dhcp# /usr/sbin/dhcpd -6 -f -cf /etc/dhcp/dhcpd.conf eth5
Internet Systems Consortium DHCP Server 4.3.0a1
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Wrote 0 NA, 0 TA, 0 PD leases to lease file.
Can't set SO_REUSEPORT option on dhcp socket: Protocol not available

Solucion a error 3:
 Actualizar el kernel a una version >= 3.9

SO_REUSEPORT es requerido por ISC DHCP 4.3 por ello es necesario tener un kernel > 3.9

Instalar ISC DHCP 4.3 en Linux (Ubuntu 13.04) (IPv6)

Situacion:
  Deseo instalar DHCP ISC 4.3 en Linux para mejorar el soporte de DHCP para IPv6.

Procedimiento:
  1) Agregar la siguiente linea al final de /etc/apt/sources.list:

deb http://ftp.de.debian.org/debian experimental main

  2) Eliminar cualquier dhcp de ISC que tuviesemos antes:

#apt-get purge isc-dhcp-server  (notese que podemos usar purge o remove, lo dejo a tu criterio)


  3) Actualizar la DB de repositorios:
#apt-get update

  4) Instalar el isc-dhcp-server indicando que use el repositorio experimental:

 #apt-get -t experimental install isc-dhcp-server


Importante:
  La configuracion del DHCP(d) debe estar funcionando, sino, el DHCPD no levantara y dara un error (logico, no?)


Más información:
http://blog.acostasite.com/2014/04/solucion-tres-errores-cuando-queremos.html

Configurando Quagga para manipular prefijos (Local Preference) utilizando RPKI

Objetivo:
   En el siguiente mini laboratorio configuraremos Quagga para manipular prefijos BGP y asignar Local Preference segun el estado RPKI (valid, invalid, Not Found).
 
Escenario:
- R1 publica un prefijo con un AS que no le corresponde (segun ROA)
- R2 publica el mismo prefijo que R1 pero desde un AS que si es valido
- R2 publica un prefijo sin ROA.
- En este escenario el validador y el router Quagga estan en el mismo equipo

Diagrama del laboratorio:

Requisitos:
- Quagga con soporte para RPKI
- RPKI Validator de RIPE NCC
- Un prefijo que sepamos que se tiene ROA valido. En nuestro caso utilizamos el prefijo 200.85.64.0 que sabiamos que tiene un ROA que indica que debe ser publicado por el AS 7908
- Ejecutar el validador de RIPE NCC antes de ejecutar Quagga


Configuraciones de todos los equipos

Conf-Quagga-RPKI-Mini-LAB.txt

hostname RPKI-RTR
password test
!
router bgp 65000
 bgp router-id 10.0.0.10
 bgp bestpath prefix-validate allow-invalid
 neighbor 10.0.0.1 remote-as 65001
 neighbor 10.0.0.1 route-map rpki in
 neighbor 10.0.0.2 remote-as 7908
 neighbor 10.0.0.2 route-map rpki in
 neighbor 10.0.0.3 remote-as 65003
 neighbor 10.0.0.3 route-map rpki in
!
route-map rpki permit 10
 match rpki invalid
 set local-preference 10
!
route-map rpki permit 20
 match rpki valid
 set local-preference 30
!
route-map rpki permit 30
 match rpki notfound
 set local-preference 20
!        
line vty
!
enable-rpki
  rpki polling_period 1000
  rpki timeout -1216757171
!
  rpki group 1
    rpki cache 127.0.0.1 8282
! 

R1.cfg

!

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
enable password test
!
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
!
ip cef
ip audit po max-events 100
!
!
!
!
ip tcp synwait-time 5
! 
!
!
!
interface Ethernet0
 ip address 10.0.0.1 255.255.255.0
 half-duplex
!
interface FastEthernet0
 no ip address
 shutdown
 speed auto
!
router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 network 200.85.64.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 200.85.64.0 255.255.255.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 password test
 login
!
end

R2.cfg

!
!
!
!
hostname R2
!
no ip domain lookup
no ip icmp rate-limit unreachable
ip tcp synwait 5
!
!
interface Ethernet0
 ip address 10.0.0.2 255.255.255.0
 half-duplex
!
!
router bgp 7908
 no synchronization
 bgp log-neighbor-changes
 network 200.85.64.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 200.85.64.0 255.255.255.0 Null0
no ip http server
!
line con 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
line aux 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
!
!
end

R3.cfg

!

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R3
!
boot-start-marker
boot-end-marker
!
!
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
!
ip cef
ip audit po max-events 100
!
!
!
!
ip tcp synwait-time 5
! 
!
!
!
interface Ethernet0
 ip address 10.0.0.3 255.255.255.0
 half-duplex
!
interface FastEthernet0
 no ip address
 shutdown
 speed auto
!
router bgp 65003
 no synchronization
 bgp log-neighbor-changes
 network 192.168.0.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 192.168.0.0 255.255.255.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 login
!
end

Salida final en Quagga:
(Notese los flags N, I, V) (Notese los local preference)

RPKI-RTR# sh ip bgp
BGP table version is 0, local router ID is 10.0.0.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
N*> 192.168.0.0      10.0.0.3                 0     20      0 65003 i
I*  200.85.64.0      10.0.0.1                 0     10      0 65001 i
V*>                  10.0.0.2                 0     30      0 7908 i

Total number of prefixes 2

IPv6, no te vistas que no vas. Ahora IPv4S

Netland, Diciembre 2013
  Luego de una reunion casi secreta de una semana en Suiza, los principales fabricantes de hardware y software a nivel mundial tomaron la drástica decisión de no continuar con el desarrollo e implementación de IPv6. Como alternativa decidieron de manera únanime utilizar el mismo protocolo IPv4 y crear un nuevo concepto de sub-IP (IPv4S).
  Los detalles técnicos se describieron así: "Vamos a utilizar un bit que se encuentra reservado en la cabecera IPv4 desde su origen (RFC 791), dicho bit al estar encendido los hosts leeran los campos de datos indicando más direcciones IPv4, es decir, es un subgrupo de IPv4". Según el PhD Tniv Frec: "Esto es algo que debió hacerse hace mucho".
  A la reunión asistieron en gran cantidad los mejores programadores del mundo los cuales se mostraban muy contentos con esta nueva idea. Ms Avaj, una reconocida en programadora orientada a objetos indicó "Al fin", esto es lo que todos necesitamos, ahora el desarrollo de software será tres veces más rápido.
  Con la nueva metodología los fabricantes de hardware y software pueden realizar los ajustes pertinentes de manera más sencilla, rápida y funcional. Para los ISPs y programadores este cambio será transparente debido que ahora cuentan con "SP&P" (Super Plug & Play) donde servidores Web y Mail se autoconfigurarán de manera mágica; Ms Cin indicó que incluso los registros DNS serán realizados sin intervención humana gracias el nuevo registro SeIP (sub enhance IP) donde todos los host hablan con todos los DNSs (full mesh).
  Otro participante lllamado Pir, indica que si esto hubiese existido hace 5 años el Internet actual fuera 400 veces más grande y según Mr. Lrep unas 8 veces rápido.
  Desde el aspecto social, Ms. Locotorp, menciona que esta nueva versión servirá para disminuir el hambre en el mundo gracias a que es un protocolo pensado en el consumo eléctrico, indica que es 34% más eficiente gracias a su inteligencia incorporada, todo gracias al nuevo bit que nadie había querido usar. Al final de la entrevista dió a atender que es una verguenza que ingenieros de todo el mundo no hubiesen hecho esto años atrás.
  Un entrevistado de apellidos Tan Tap que no quiso salir a la luz pública lamenta que IPv6 no hubiese crecido más, indicó que el mal uso del NAT y la gran cantidad de mecanismos de transición le quitaron el impulso a la implementación de IPv6, nuestro reportero indica que Mr Tan Tap siempre tuvo una sonrisa fingida y se rió de todos los que habían implementado IPv6.
  Referente a las redes internas, en base a la información de este grandioso bit, dependiendo de si esta completamente encendido o solo un poco se auto-determina si la dirección IP es interna o externa, a su vez reconoce si el host está en una MZ o DMZ, y simultaneamente aplica las políticas de seguridad pertinentes, los administradores de red no tienen necesidad de modificar ninguna política.
  Mr. Lufetats indica que apoyándose en IPv4S los firewall serán muy sencillos de implementar, unicamente es necesario colocarlo y voila!.., BCP 38, servicios y otras politicas se autoconfiguran.
  Finalmente, dieron a conocer que los conceptos de EGPs e IGPs desaparecerán en unos años. La nueva versión puede hablar inter-AS e  intra-AS gracias a sus mecanismos de reconocimiento de rutas, se adapta de Distance Vector a Link State automaticamente según convenga, reconoce saturación de los enlaces, delay, pérdida de paquetes y comprime los datos cuando es necesario. Incluso percibe cuando el CPU del enrutador está sobre cargado y toma acciones correctivas.
  Estiman que en solo un año todos los hosts de internet contaran con IPv4S, luego, las capas 4 y 7 del modelo OSI desapareceran porque IPv4S puede a su vez llevar directamente los protocolos de aplicación, con ello se espera que la enseñanza de redes sea trivial.


Saludos,

Att.
Rebif Citpo VI

Resumen de FLIP6 en Medellin 2013

Hola todos,
    Es un honor para mi escribir en esta ocasión y compartir mis
impresiones de la 11va. edición del FLIP6 (Foro Latino Americano de
IPv6) en la ciudad de Medellin - Colombia durante los días 7 y 9 de
Mayo de 2013.

    Cada evento es un desafío. es un reto nuevo; cosas inesperadas pueden
ocurrir, tanto cosas buenas como cosas malas. Lo  importante es saber
manejar las situaciones, poderlas llevar y eventualmente poder
superarlas. Tuvimos un gran evento, tanto en el especto técnico,
académico y social.

    Antes de entrar de lleno en el resumen del evento, deseo mencionar que
cuando en la vida se presentan situaciones complicadas no hay que
colocar mala cara y mucho menos rendirse, todo lo contrario, hay que
saber canalizar las preocupaciones y angustias en energía y
entusiasmo, esta es la única manera para poder salir adelante.
Recientemente me enteré que Thomas Alva Edison tenía problemas
auditivos, él, en vez de quejarse decía que menos mal, con ello podía
concentrarse más en sus inventos

Resumen del evento:
Antes de cada evento siempre existe un grado de preocupación, las
preocupaciones van desde “ójala no falte ningún speaker”, que el salón
este lleno y que ójala tengamos tiempo para la agenda completa. Me
complace indicar que en esta oportunidad -igual que las anteriores- el
Foro fue un éxito total y hemos salido aún con más fuerza para seguir
trabajando por la promoción de IPv6 en Latinoamérica y Caribe.

El evento tuvo una duración de casi 7 horas dividido en dos días. Por
primera vez compartirmos un espacio de 3 horas con LACSEC, el objetivo
era unir en la agenda aquellas presentaciones con contenido de
seguridad e IPv6. Más adelante les doy los detalles.

Se contó con la asistencia de unas 400 personas en total, que se apreciaba con
el salón lleno en todo momento. Existen muchos puntos a destacar en
esta oportunidad:

- El cumplimiento de los horarios de los ponentes fue excepcional.
- Cantidad de preguntas realizadas
- El evento estuvo acompañado por una gran difusión vía Twitter,
Facebooks y listas de correo.
- Calidad de los expositores
- Temas novedosos en el foro

    Como siempre, hay que destacar al comité evaluador de LACTF quienes tuvieron la
importante labor de seleccionar los trabajos presentados en la 11va.
edición del FLIP6. Sin el comité el evento no sería lo mismo. Es
sensacional los estudios y charlas que existen tras bastidores para
seleccionar los temas.

    A continuación un breve resumen de cada una de las ponencias:

- Evaluación de la seguridad y diagnóstico de problemas en redes IPv6
- Fernando Gont

    Fernando tuvo la oportunidad de abrir FLIP6, con su tradicional estilo
de exposición: sencillo pero con un alto contenido de nivel técnico
expuso una combinación muy llamativa del toolkit de seguridad de IPv6
y problemas existentes en el área. Vale la pena volver a ver.

- El caso de negocio para IPv6 - Mark Townsley, Cisco.
     Nuestra presentación Keynote vino dada por el Ing. Mark Townsley,
quien es co-chair del WG Homenet de la IETF y además fellow de Cisco.
Expuso un tema sumamente interesante y necesario: “El caso de negocio
para IPv6”. Su presentación fue dinámica y amena, una vez más quedó
expresado porque es importante la implementación de IPv6. Es una
exposición cuya láminas sin duda muchos de nosotros volveremos a
revisar.

- Conexión a Internet IPv6 de redes corporativas - Álvaro Retana, Cisco.
      El Ing Alvaro Retana (Ing distinguido de Cisco) realizó una
presentación de mucho impacto sobre las posibilidades, modalidades y
alternativas de las conexiones a Internet IPv6 en redes corporativas.
Muy interesante, gracias por compartir esta información. Esperemos que
crezca significativamente el sector corporativo en su implementación
de IPv6 en los próximos años.

- Mejores prácticas en nubes públicas para garantizar su seguridad,
respaldo y alta disponibilidad - Efraín Soler, CEO de O4IT.
       Efarin Soler realizó una exposición sobre la plataforma,
tecnología implementada, marco de seguridad y la sencilla interfaz Web
que O4IT tiene para ofrecer. Sin duda alguna muchos de los asistentes
apredimos de este prestigioso sponsor.

- Actualización sobre IPv6 en redes de Gobierno - Jordi Palet, Consulintel.
      Jordi, con su acostumbrado estilo de enseñar y transmitir
información brindó un rápido repaso pero muy importante sobre los
avances en la implementación en algunos países y gobiernos. Mil
gracias por compartir esta información con nosotros. Te esperamos para
que compartas nuevos avances.

- Casos de éxito en implementaciones de IPv6. Evandro Varonil,
Guillermo Cicileo.
      Los Ingenieros Evandro Varonil y Guillermo Cicileo
expusieron muy vividamente sus experiencias implementando IPv6 en sus
organizaciones. Desde FLIP6 estamos muy agradecidos por compartir este
contenido debido a que el mismo ayuda a los interesados que aún  no lo
han hecho a prever algunas situaciones.

- Mobile IPv6 Test Bed: una implementación actualizada - Sebastián
Tobar y Cristian Pérez Monte, Grupo UTN GridTICS (AR)
      Sebastian Tobas y Cristian Perez Monte realizaron una
llamativa exposición sobre IPv6 y movilidad. La ponencia fue muy
ilustrativa y decarácterr novedoso. Ojalá tengamos la oportunidad de
conocer los avances en los próximos meses y/o años.


- Análisis de las técnicas de transición para un mundo sin IPv4 -
Rodrigo Regis dos Santos, NIC.br.
      El Ing. Rodrigo Regis dos Santos realizó una exposición muy
completa cubriendo la mayoría los métodos de transición puntualizando
muy bien las ventajas y desventajas de cada uno de ellos.
¡Muchas gracias por una presentación tan agradable!

- Consideraciones operativas sobre planificación y despliegue de IPv6
- Álvaro Retana, Cisco
     Alvaro Retana le tocó aperturar el estreno en el espacio
compartido de LACSEC/FLIP6. Una vez más realizó una fantástica
presentación sobre las consideraciones operativas durante el
despliegue de IPv6, hizo mucho énfasis en la planificación. Fue
probablemente unas de las presentaciones con mayor participación de
los asistentes, Hubo al menos una hora de preguntas, respuestas y
comentarios luego de finalizar la ponencia. Ojala podamos repetir esta
experiencia.

- Avances recientes en seguridad de IPv6 - Fernando Gont, SI6 Networks.
    Fernando Gont, por segunda vez durante FLIP6 de 2013 conversó sobre
IPv6 y la seguridad, dejando como moraleja que las implementaciones de
este protocolo a su vez deben venir acompañado de políticas de
seguridad, existen problemas que son similares a IPv4 y otros que son
únicamente de IPv6. Ojala contemos con Fernando Gont en futuras
reuniones de FLIP6.


Conclusión:
  Para concluir, tuvimos otra edición de FLIP6 inolvidable, una vez más
intentamos empujar difundir már IPv6 en los asistentes. Después de
cada evento nos despedimos con la intención de que regresen a sus
casas y oficinas con el objetivo de implementar IPv6. Una vez escuché:
“IPv6 is not optional anymore, it’s a must.” (IPv6 ya no es opcional,
es obligatorio)

Para finalizar una pequeña cita para que siga la evolución informática
y con ello IPv6:

 “El verdadero progreso es el que pone la tecnología al alcance de todos.”
— Henry Ford



Att.
Alejandro Acosta
Chair LACTF/FLIP6 2013
http://aaaa.acostasite.com
Twitter: @lactf

Comics + Humor + IPv6

Publicar prefijos IPv4 sobre una sesión eBGP IPv6

Situación:
  Deseo publicar redes/prefijos IPv4 sobre una sesión eBGP en IPv6

Historia:
  A pesar de no ser común este caso pueden ocurrir en algunas situaciones.

Solución:
  Afortunadamente BGP soporta llevar información de enrutamiento de distintos protocolos (pe. IPv6/IPv4). Por ello es posible intercambiar información IPv4 dentro de una sesión eBGP IPv6.

Configuración:
  En un escenario con R1 conectado a R2 back-to-back la configuración queda de la siguiente manera (deseo que el prefijo anunciado por R2 lo aprenda R1).


R1:
!
interface Ethernet0
 ip address 22.22.22.21 255.255.255.252
  ipv6 address 2001:DB8::1/64
!        
router bgp 1
 bgp log-neighbor-changes
 neighbor 2001:DB8::2 remote-as 2
 neighbor 2001:DB8::2 ebgp-multihop 3
 !       
 address-family ipv4
 neighbor 2001:DB8::2 activate
 neighbor 2001:DB8::2 route-map IPv4 in
 no auto-summary
 no synchronization
 exit-address-family

!      
route-map IPv4 permit 5
 set ip next-hop 22.22.22.22
! 
R2:
!
 interface Ethernet0
 ip address 22.22.22.22 255.255.255.252
 half-duplex
 ipv6 address 2001:DB8::2/64
!
router bgp 2
 bgp log-neighbor-changes
 neighbor 2001:DB8::1 remote-as 1
 neighbor 2001:DB8::1 ebgp-multihop 3
 !       
 address-family ipv4
 neighbor 2001:DB8::1 activate
 no auto-summary
 no synchronization
 network 2.2.2.0 mask 255.255.255.0
 exit-address-family
!        

 








"El truco":
  * La sesión eBGP debe ser obligatoriamente multihop, sino, R1 no aprenderá la ruta. Reconozco que no entiendo 100% porque ocurre sin embargo en base a las lecturas el router se queja que el next-hop y el IP de establecimiento son diferentes y no en la misma subred (lógico, uno es IPv6 y el otro IPv4!). 
  * En R1 quien aprende la ruta debe tener un route-map aplicado cuando aprende las mismas (in) forzando el next-hop con la dirección IPv4 de R2

Mas información:
- http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/15-2mt/ip6-mptcl-bgp.html#GUID-06407EF3-4FAD-4519-A2A9-6CC6037288C0
- Publicando prefijos IPv6 sobre sesiones BGP IPv4 en Cisco




Espero sea útil!

Publicando prefijos IPv6 sobre sesiones BGP IPv4 en Cisco

Situación:
  Deseo publicar redes/prefijos IPv6 sobre una sesión eBGP en IPv4

Historia:
  A pesar de no ser común este caso pueden ocurrir en algunas situaciones. En esta oportunidad, tengo un router Cisco con soporte IPv6 (routing) pero su configuración BGP no permite definir neighbors IPv6

Error:
  Mensaje que quizás estas recibiendo y el mismo te trajo a esta página  :)

*Mar  1 02:05:00.663: BGP: 1.1.1.1 Advertised Nexthop ::FFFF:1.1.1.1: Non-local or Nexthop and peer Not on same interface
*Mar  1 02:05:00.663: BGP(1): 1.1.1.1 rcv UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, metric 0, originator 0.0.0.0, path 1, community , extended community
*Mar  1 02:05:00.667: BGP(1): 1.1.1.1 rcv UPDATE about 2001:db8::/32 -- DENIED due to:
*Mar  1 02:05:00.667: BGP(0): Revise route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table
*Mar  1 02:05:00.771: BGP(0): 1.1.1.1 computing updates, afi 0, neighbor version 0, table version 25, starting at 0.0.0.0

Solución:
  Afortunadamente BGP soporta llevar información de enrutamiento de distintos protocolos (pe. IPv6). Por ello es posible intercambiar información IPv6 dentro de una sesión eBGP IPv4.

Configuración:
  En un escenario con R1 conectado a R2 back-to-back la configuración queda de la siguiente manera (deseo que el prefijo anunciado por R1 lo aprenda R2).


R1:
!
 interface Ethernet1/0
 ip address 1.1.1.2 255.255.255.252
 full-duplex
 ipv6 address 2001:db8::1/64
 ipv6 enable
!
router bgp 1
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 1.1.1.2 remote-as 2
 neighbor 1.1.1.2 ebgp-multihop 2
 no auto-summary
 !
 address-family ipv6
 neighbor 1.1.1.2 activate
 network 2001:db8::/32
 no synchronization
 redistribute static
 exit-address-family
!
ipv6 route 2001:db8::/32 Null0


R2:
!
 interface Ethernet1/0
 ip address 1.1.1.2 255.255.255.252
 full-duplex
 ipv6 address 2001:db8::2/64
 ipv6 enable
!
router bgp 2
 no synchronization
 bgp router-id 1.1.1.2
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 ebgp-multihop 2
 no auto-summary
 !
 address-family ipv6
 neighbor 1.1.1.1 activate
 neighbor 1.1.1.1 route-map IPv6-NextHop in
 exit-address-family
!
route-map IPv6-NextHop permit 10
 set ipv6 next-hop 2001:db8::1
!

"El truco":
  * La sesión eBGP debe ser obligatoriamente multihop, sino, R2 no aprenderá la ruta (el mismo error que se ve arriba). Reconozco que no entiendo 100% porque ocurre sin embargo en base a las lecturas el router se queja que el next-hop y el IP de establecimiento son diferentes y no en la misma subred (lógico, uno es IPv6 y el otro IPv4!). 
  * En R2 quien aprende la ruta debe haber un route-map aplicado cuando aprende las rutas (in) forzando el next-hop con la dirección IPv6 de R1

Después de aplicar ebgp-multihop (todo funciona):

*Mar  1 02:01:42.539: BGP(1): 1.1.1.1 rcvd UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, metric 0, path 1
*Mar  1 02:01:42.539: BGP(1): 1.1.1.1 rcvd 2800:26::/32
*Mar  1 02:01:42.543: BGP(0): Revise route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table
*Mar  1 02:01:42.543: BGP(1): Revise route installing 2001:db8::/32 -> 2001:db8::1 (::) to main IPv6 table

Mas información:
- https://supportforums.cisco.com/docs/DOC-21110
- http://ieoc.com/forums/p/15154/130174.aspx
- http://ieoc.com/forums/p/15154/130174.aspx


Espero sea útil!

Crucigrama IPv6

http://goo.gl/lVuv6

Espero les guste!....

DNS64 y NAT64 paso a paso con explicación

Introducción:
DNS64 y NAT64 son dos tecnología diferentes que comunmente trabajan en conjunto.

DNS64 y NAT64 es ideal para colocar en el borde una red donde unicamente existan host con IPv6, algo cada día es más común sobre todo en el mundo de redes celulares y se gran cantidad de sensores.

En Internet hay mucha información sobre como configurar NAT64 y DNS64, la mayoría dice que muy fácil, otros lo colocan más complicado. En lo personal no conseguí ninguna que explicara paso a paso como hacerlo y adicionalmente que explicara la topología de red donde se estaba configurando.

En este post comienzo instalando DNS64 y luego procedemos con NAT64. Se puede instalar en cualquier orden.

Que se necesita antes de comenzar:

- Una subred IPv6 libre (una /96 esta bien) para realizar el mapeo DNS entre IPv4 e IPv6. Esta misma subred la utilizaremos dentro de Tayga para el NAT64

- Logicamente conectividad IPv6 entre los clientes y el servidor DNS64 y NAT64 (no se requiere IPv4)



Topología:
a) Servidor realizando. Solo tiene una interfaz (eth1)

IPv6: 2001:db8:1:1::/64 (eth1).
IPv4: 192.168.124.107

b) IP de un cliente (eth2):

2001:db8:1:1::2/64


c) Subredes IPv6:

Red que "retorna" el DNS64 2001:db8:1:ffff::/96
Pool de NAT en el NAT64: 2001:db8:1:ffff::/96

(si, son el mismo bloque)


d) Interfaz dns64:

192.168.124.107/32
2001:db8:1::1/128


(correcto!, la IPv6 e IPv4 de eth1 se solapan con interfaz dns64)



Procedimiento de DNS64.

Paso 1:

Instalar BIND9:

#aptitude install bind9


Paso 2:

Configurar /etc/bind/named.conf.options:

a) Asegurar que BIND escuche en IPv6 (recordemos que los clientes van a estar en IPv6)

listen-on-v6 { any; };

b) Permitir consultas desde cualquier IP. Si estas utilizando un servidor público o en producción favor restringir las consultas a tus clientes

allow-query { any; };

c) Realizar el DNS64 con la siguiente directiva.

dns64 2001:db8:1:ffff::/96 { 
    clients { 
      any; };
 };

La configuración del punto "c" lo que indica es que aquellas consultas DNS de aquellos registros que SOLO tienen tienen registro A (no tienen registro AAAA) serán entregadas a los clientes añadiendo 2001:db8::1:ffff::/96


d) Reiniciar bind9

#/etc.init.d/bind9 restart


Probar DNS64:

a) En un PC cliente colocar como servidor DNS: 2001:db8:1:1::1


b) Ubicarse en un cliente y realizar consultar DNS de hosts solo con direcciones IPv4 (registros A). Por ejemplo:


root@ubuntu-VirtualBox:~# dig ipv4.google.com aaaa @2001:db8:1:1::1

; <<>> DiG 9.8.0-P4 <<>> ipv4.google.com aaaa @2001:db8:1:1::1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- 64252="64252" br="br" id:="id:" noerror="noerror" opcode:="opcode:" query="query" status:="status:">;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;ipv4.google.com.               IN      AAAA

;; ANSWER SECTION:
ipv4.google.com.        0       IN      CNAME   ipv4.l.google.com.
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8268
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8269
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:826a
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8293
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8263
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8267

;; AUTHORITY SECTION:
google.com.             171975  IN      NS      ns1.google.com.
google.com.             171975  IN      NS      ns4.google.com.
google.com.             171975  IN      NS      ns2.google.com.
google.com.             171975  IN      NS      ns3.google.com.

;; Query time: 219 msec
;; SERVER: 2001:db8:1:1::1#53(2001:db8:1:1::1)
;; WHEN: Wed Jan  2 16:11:57 2013
;; MSG SIZE  rcvd: 294



Nota: La parte a destacar en esta salida son las direcciones IPv6 que comienzan por: 2001:db8:1:ffff..., ya en este momento sabemos que DNS64 esta funcionando.



Ahora NAT64

1) Utilizamos Tayga. El sitio oficial y link para descargarlo se encuentra en: http://www.litech.org/tayga/


2) Lo descomprimimos y desempaquetamos:

#tar -jxvf tayga-0.9.2.tar.bz2
#cd tayga-0.9.2
#./configure
#make
#make install

3) Creamos el directorio donde Tayga guardará los logs:

#mkdir /var/log/tayga

4) Editamos el archivo /usr/local/etc/tayga.conf

y copiamos y pegamos:

tun-device nat64
ipv4-addr 192.168.255.1
prefix 2001:db8:1:ffff::/96
dynamic-pool 192.168.255.0/24
data-dir /var/log/tayga


Tayga es stateless y realiza un nat 1:1 entre IPv6 e IPv4. En la configuración anterior a cada cliente IPv6 se le asignará un IP del pool 192.168.255.0/24; por ello si tenemos más de 255 hosts será necesario utililzar un pool más grande que /24. En caso de que tengas IPv4 públicas suficientes puede ser útil para evitar un doble NAT IPv4.

La directiva prefix indica el prefijo que utilizará Tayga para reconocer los 32 bits de IPv4, es decir, cuando el destino IPv6 sea: 2001:db8:1:ffff::/96, Tayga tomará los ultimos 32 bits para reconocer que ese es el destino IPv4

5) Habilitar routing IPv6 e IPv4 en el servidor.

#echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
#echo "1" > /proc/sys/net/ipv4/ip_forward

6) Creación y configuración de la interfaz nat64:

#tayga --mktun
#ip link set nat64 up
#ip addr add 192.168.124.107 dev nat64
#ip addr add 2001:db8:1::1 dev nat64

(estos comandos crean la interfaz nat64 con las direcciones ip 192.168.0.1/32 y 2001:db8:1::1/128, como dije anteriormente no importa que se solape con los IPs de eth1).

Para revisar:
root@aacosta-ThinkPad-E420:~# ifconfig nat64
nat64     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.0.1  P-t-P:192.168.0.1  Mask:255.255.255.255
          inet6 addr: 2001:db8:1::1/128 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:2393 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2395 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:1615556 (1.6 MB)  TX bytes:1614316 (1.6 MB)

7) Creación de rutas:
#ip route add 192.168.255.0/24 dev nat64
#ip route add 2001:db8:1:ffff::/96 dev nat64

8) Ejecutamos Tayga

#tayga -d

(el -d es opcional, solo es para tener más información)


PROBAR NAT64
a) Probamos que todo este bien (el ping debe ser satisfactorio):

root@aacosta-ThinkPad-E420:~# ping6 2001:db8:1:ffff::192.168.0.1
PING 2001:db8:1:ffff::192.168.0.1(2001:db8:1:ffff::c0a8:1) 56 data bytes
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=109 ttl=63 time=2.18 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=110 ttl=63 time=0.209 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=111 ttl=63 time=0.190 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=112 ttl=63 time=0.126 ms


b) Realizamos NAT con la interfaz IPv4 saliente (solo si el pool IPv4 en Tayga es privado):

#iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 
#iptables -A FORWARD -i eth0 -o nat64 -m state --state RELATED,ESTABLISHED -j ACCEPT 
#iptables -A FORWARD -i nat64 -o eth0 -j ACCEPT

c) Ahora solo debes dirigirte a la máquina cliente y todo debe estar funcionando. Ejemplos de ping y trace:


[root@localhost ~]# traceroute6 www.algo.com -n
traceroute to algo-com-prod-elb-170663297.us-east-1.elb.amazonaws.com (2001:db8:1:ffff::36f3:7ac3) from 2001:db8:1:1::2, 30 hops max, 16 byte packets
 1  2001:db8:1:1::1  1.224 ms  3.8 ms  0.352 ms
 2  2001:db8:1:ffff::c0a8:ff01  0.787 ms  0.772 ms  0.268 ms
 3  2001:db8:1:ffff::c0a8:1  0.76 ms  0.869 ms  0.278 ms

[root@localhost ~]# ping6 www.parmalat.com.ve -n
PING www.parmalat.com.ve(2001:db8:1:ffff::c82f:4f04) 56 data bytes
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=1 ttl=56 time=7.30 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=2 ttl=56 time=5.82 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=3 ttl=56 time=5.93 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=4 ttl=56 time=8.38 ms


  Puedes ver un estado de las asignaciones de Tayga en: /var/log/tayga/dynamic.map



Voila!... todo debe estar funcionado en este momento!


Mas información: 
http://www.litech.org/tayga/
http://www.litech.org/tayga/README-0.9.2

http://kurser.iha.dk/eit/itifn/workshops/vne_workshop_2.html
http://ipvsix.me/?tag=tayga

Notas importantes:
- El DNS64 no funciona cuando la respuesta DNS tenga registros AAAA y A. En realidad no es una eroor porque se asume que el host tiene acceso IPv6 a Internet
- Es importante que el DNS64 y NAT64 compartan el mismo prefijo IPv6 (en el ejemplo de este post 2001:db8:1:ffff::/96. 
- Durante todo el post describo el procedimiento utilizando la subred IPv6 2001:db8::/32. Favor notar que esta subred debe ser sustituida por sus redes respectivas (al igual que la información referente a IPv4).
- Pueden utilizar 2001:db8::/32 y va a funcionar igualmente pero sin acceso a destinos a IPv6
- El servidor DNS64 y NAT64 pueden ser diferentes equipos/máquinas



to get detailed information about Managed IT Services visit https://wetheitteam.com

Solucion: Apache solo escucha sobre IPv6

Situación:
  Apache solo funciona sobre IPv6

Troubleshoooting:
a)  Para que escuche en IPv4:
  - Editar el archivo  /etc/apache2/ports.conf
  - En la directiva Listen colocar por ejemplo:
     Listen 192.168.1.10:80  

  Se pueden colocar varias directivas Listen. Tales como:
     Listen 192.168.1.10:80  
     Listen 127.0.0.1:80 

  Para escuchar en todo IPv4 (cualquier IPv4 configurado en el server):
     Listen 0.0.0.0:80 
 
b) Para escuchar en IPv6:
  - Editar el archivo  /etc/apache2/ports.conf
  - En la directiva Listen colocar <[direccionIPv6]:puerto>. Por ejemplo:

Listen [2001:db8::4]:80

  Reiniciar apache..., por ejemplo: /etc/init.d/apache2 restart

Diagnóstico:
  Para saber que servicios, a que direcciones IP escucha y que proceso esta asociado recomiendo utilizar el comando: netstat -pan

#netstat -pan | more
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      965/mysqld     
tcp        0      0 127.0.0.1:587           0.0.0.0:*               LISTEN      1020/sendmail: MTA:
tcp        0      0 0.0.0.0:10000           0.0.0.0:*               LISTEN      1162/perl      
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      8478/vsftpd    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      816/sshd       
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1020/sendmail: MTA:
tcp        0      0 192.168.1.10:22          192.168.1.2:57997       ESTABLISHED 19601/sshd: aacosta
tcp6       0      0 ::1:587                 :::*                    LISTEN      1020/sendmail: MTA:
tcp6       0      0 :::80                   :::*                    LISTEN      1134/apache2   
tcp6       0      0 :::22                   :::*                    LISTEN      816/sshd       

  En el extracto anterior la ultima linea indica que se está escuchando en todas las direcciones IPv6 (se puede comprender gracias a la culumna de la izquiera que indica tcp6 y luego en la cuarta columa indica ::22). El puerto está en estado listen por el proceso sshd y el pid 816
  Para el primera linea se entiende que mysqld está escuchando en la dirección IPv4 127.0.0.1 en el puerto 3306 bajo el pid (process id) 965. Es decir, mysql no esta habilitado para escuchar conexiones de red (solo escucha localhost)


Mas información:
- http://serverfault.com/questions/332409/how-to-set-apache-virtualhost-to-work-with-ipv6- http://www.linuxweblog.com/blogs/sandip/20081027/forcing-apache-listen-ipv4
- http://www.linuxask.com/questions/limit-apache-only-listen-to-ipv4-address

Entrevista en la radio sobre IPv6

http://tecnologiahechapalabra.com/archivo/media.asp?i=858

Gustavo Terrero, Presidente de CAVEDATOS; Ricardo Holmquist, Presidente de ISOC Venezuela; y Alejandro Acosta, director del Foro Latinoamericano de IPv6; conversan con Peter Cernik en la oportunidad de explicar la necesidad de migrar toda la estructura de direcciones de internet al Protocolo de Internet version 6, que debe sustituir al IPv4, ya que este último ha agotado su capacidad de manejar identificaciones únicas para cada dispositivo conectado y por conectarse en la red de redes.

Click Aqui

- - - 

Duración = 00:24:38. 


Tomado de/Información original en:
http://tecnologiahechapalabra.com/archivo/media.asp?i=858

Alejandro Acosta - Coordinador de LAC IPv6 TF / Su visión luego de la 10ma edición del FLIP6

(tomado de http://portalipv6.lacnic.net/es/acosta-vision-es)

Luego de escuchar por dos días consecutivos la exitosa reunión del décimo Foro Latinoamericano de IPv6 durante el evento de Lacnic XVII en Quito - Ecuador me atrevo a asegurar que el año 2012 será el despegue definitivo del nuevo protocolo.

Durante el evento tuvimos el honor de escuchar a ponentes de un gran renombre internacional como lo son Fred Baker, Cameron Byrne, Jordi Palet y muchos otros. Lo que pudimos tomar de manera implícita y a su vez de manera explícita son los enormes avances y despliegues que existen de IPv6 a nivel mundial.

Si uno tuviese la oportunidad de unir en una sola presentación lo escuchado estos días no nos quedaría duda que IPv6 es el futuro cercano, lo que hace pocos años se parecía más al cuento del lobo ahora dejó de ser una utopía.

La enorme cantidad de empresas, universidades e ISPs desplegando IPv6, sumado a las principales empresas de contenido tales como Facebook, Google y Yahoo es una clara demostración de estos importantes pasos. ¿Se necesitan más pruebas?, hay que agregar los aportes de muchos gobiernos a nivel mundial que se unen a la implementación de IPv6.

En FLIP escuchamos experiencias Latinoamericanas cercanas como son los países Colombia y Ecuador. Lo que resta del año a su vez torna muy interesante, luego del World IPv6 Launch day, se espera un crecimiento exponencial en el tráfico de IPv6. En lo personal comparto esta predicción y no aguanto las ganas de saber que ocurrirá en los próximos meses.

Reciban un enorme un abrazo, y espero no te pierdas el próximo evento de FLIP6 el año que viene!

10a. Edición FLIP6. LACNIC XVII. QUITO - ECUADOR RESUMEN

Hola todos,
Es un placer para mi escribir en esta oportunidad y contarles mis
impresiones de la 10a. edición del FLIP6 (Foro Latino Americano de
IPv6) en la ciudad de Quito - Ecuador durante los días 6-7 de Mayo de
2012.

Debo reconocer que al comienzo estaba preocupado por el desafío, pero
una vez finalizado el evento, he quedado sumamente satisfecho y con
muchísimo entusiasmo para seguir trabajando por la difusión de IPv6 en
Latinoamérica y Caribe.

El evento tuvo una duración de 7 horas divididos en dos días, contando
con una asistencia de unas 400 personas en total, que se apreciaba con
el lleno en todo momento del salón. Un aspecto significativo que
muestra la calidad alcanzada por el FLIP6 es el hecho de que luego de
los horarios previstos de finalización de la actividad la gente
continuaba en la sala, un claro indicador del interés en la temática
de IPv6 y a su vez de la calidad de los ponentes. Otro hecho
importante fueron la cantidad de preguntas realizadas por diferentes
asistentes, incluso a la hora que se debía finalizar la actividad. No
menos importante fue el alto porcentaje de participantes remotos vía
Webcasting (sobre las 50 personas en cada dia de evento FLIP).

Lo anterior estuvo acompañado por una gran difusión vía Twitter,
Facebooks y listas de correo. Ejemplo de ello es un mensaje en Twitter
que decía algo como “IPv6 es la estrella de LACNIC XVII”.

En líneas generales, me atrevo asegurar que todo funcionó
correctamente, con muy buenas y claras presentaciones, expositores de
muy alta calidad.

Una mención especial al comité evaluador LACTF quienes tuvieron la
importante labor de seleccionar los trabajos presentados en la 10a.
edición del FLIP6.

A continuación un breve resumen de cada una de las ponencias:

Fernando Gont - First Hop Security in IPv6:
Fernando expuso sobre uno de los factores de seguridad a considerar al
momento de implementar IPv6. Parte de la labor de LACTF es también
apoyar no solo la difusión de IPv6, sino también la implementación de
IPv6 bien realizada. Gracias por insistir en la seguridad de redes.

Augusto Espín (Vice-Ministro MINTEL Ecuador) - IPv6 en Ecuador
           El Ing Augusto Espín habló sobre el estado de IPv6 en
Ecuador, ¿por qué?, retos, tiempos y otros temas muy interesantes del
sector gobierno en cuanto a IPv6. Esperamos ver más avances en futuros
FLIPs.

Antonio Moreiras (NIC.br) - Resumen semana IPv6:
           Antonio nos ofreció un resumen de los resultados de la
semana IPv6 acontecida en Febrero de 2012 en Brasil, muy buenos sus
resultados. Felicitaciones y que sigan más iniciativas de este estilo.

Carlos Egas (Escuela Politécnica Nacional de Quito) - Estudio y
análisis del estado actual de la implementación de IPv6 en los
proveedores de servicios de Internet en Ecuador
          El Ing Carlos nos presentó estadísticas muy interesantes y
reveladores sobre el estado de los ISPs en Ecuador. Muy valiosos
resultados, gracias por compartirlos.

Antonio Moreiras (NIC.br) - RIPE 501:
           Antonio Moreiras nuevamente expuso pero esta vez sobre un
muy importante documento que está realizando nuestros amigos de RIPE,
muy importante conocer esta información para todos.

Jordi Palet (Consulintel/6Deploy) - IPv6 en gobiernos y resultados:
           Jordi, con su acostumbrado estilo de enseñar y transmitir
información brindó un rápido repaso pero muy importante sobre los
avances en la implementación en algunos países y gobiernos. Mil
gracias por compartir esta información con nosotros. Te esperamos para
compartas nuevos avances.

Dr. Rafael Sandoval (Asesor MINTIC) - IPv6 en Colombia:
           El Dr Rafael Sandoval resumió brevemente el estado de IPv6
en Colombia, ¿por qué?, planes e información concernientes a los
próximos pasos del gobierno Colombiano en cuanto a la implementación
de IPv6 en el país del vallenato y de la cumbia. Ojalá tengamos la
oportunidad de conocer los avances en los próximos meses y/o años.

Marcus Grando (Terra Networks Brasil) - Experiencia de Terra en IPv6
           El Ing Marcus hizo una exposición muy buena exponiendo
ambos sabores (lo bueno y lo malo) al momento de implementar IPv6 en
Terra. ¡Mucha suerte para los Juegos Olímpicos!

Arturo Servín (LACNIC) - Los 7 pecados capitales al implementar IPv6
           Arturo Servin hizo una inusual presentación realizando una
analogía entre los pecados capitales y los posibles errores en IPv6.
¡Muchas gracias por una presentación tan agradable!

 Y por supuesto, no podemos dejar a un lado a nuestros invitados:

Invitado especial: Cameron Byrne de T-Mobile con “IPv6-only services:
a mobile provider's perspective”
           Cameron Byrne expuso de una manera muy sencilla su
experiencia en cuanto a la implementación de IPv6 en T-Mobile. Cómo lo
obtuvieron con cero Capex, qué esperan ellos en el futuro y por qué lo
realizaron. Gracias por compartir tu experiencia.


Keynote:  Fred Baker de Cisco Systems con “Bringing up IPv6 and taking
down IPv4”
           El Keynote de FLIP fue el Ing. Fred Baker quien ostenta un
largo y destacado CV por lo que solo solo voy a señalar que ha sido
Chair de la IETF y actualmente es chair del v6ops WG de la IETF. Su
presentación, muy enriquecedora, nos mostró un escenario futurista,
cuando IPv6 pueda ser considerado más importante que IPv4. Un
agradecimiento enorme a Fred por su excelente ponencia.


En definitiva, espero no se pierdan la próxima edición del FLIP6 el
año que viene que seguramente estará cargado de muchas nuevas ideas e
información.

Para finalizar una pequeña cita para que siga la evolución informática
y con ello IPv6:

 “No temo a los ordenadores; lo que temo es quedarme sin ellos”
— Isaac Asimov



Att.
Alejandro Acosta
Moderador LACTF/FLIP6 2012
http://blog.acostasite.com
Twitter: @lactf

Como deshabilitar IPv6 en Mandriva & RedHat

Situación:
  Deseo deshabilitar IPv6 en mi distribución Linux

Solución:
  Hay dos soluciones que pueden ser implementadas:

• OPCION 1: Deshabilitar IPv6 solo en una interfaz en especifico

   a) Editar el archivo: /etc/sysconfig/network-scripts/ifcfg-
   b) Al final del mismo colocar: IPV6INIT=no

  Luego subir y bajar la interfaz, por ejemplo:
   c) #ifdown eth0; #ifup eth0

• OPCION 2: Deshabilitar IPv6 en todo el sistema operativos

    a) Editar /etc/modprobe.conf y agregar:

      alias ipv6 off
      alias net-pf-10 off
      options ipv6 disable=1

     b) Editar el archivo /etc/sysconfig/network y agregar:
     NETWORKING_IPV6=no

  Reiniciar todo lo relacionado con networking (por ejemplo con /etc/rc.d/network restart)

Espero haya sido útil,

Hitler presenta: Problema de agotamiento de direcciones IPv4

Preferir 6to4 sobre IPv4 en Windows 7

Introduccion:
  El dia de hoy un buen amigo me pidio que hiciera unas pruebas en una pagina Web sobre IPv6. Ocurre que en mi casa no uso tunel porque tengo 6to4 configurado sobre dd-wrt y en la oficina tengo IPv6 nativo.Como sabemos los SO tienen algun tipo de inteligencia donde deciden navegar y utilizar IPv6 dependiendo de la configuracion TCP/IP del mismo, es decir dependiendo de que lo que necesite utiliza IPv6 o IPv4. Generalmente es algo como: IPv4 tiene preferencia sobre IPv6 6to4 el cual tiene preferencia sobre IPv6 Teredo.

Problema:
  Windows 7 prefiere IPv4 sobre IPv6 cuando la direccion IPv6 corresponde a un prefijo 6to4 (2002:/16). Yo quiero que prefiriera IPv6 sobre IPv4 aun con el prefijo IPv6 6to4.

Solucion:
1. Start -> Run -> "cmd" -> "netsh" -> "interface" -> "ipv6"

2. Configurar IPv6 (6to4) como el protocolo por default en Windows
set prefix ::1/128 50 0
set prefix ::/0 40 1
set prefix 2002::/16 30 1
set prefix ::/96 20 3
set prefix ::ffff:0/96 10 4
set prefix 2001::/32 5 5

3. Si queremos volver a dejar todo original (Preferencia IPv4)
set prefix ::1/128 50 0
set prefix ::/0 40 1
set prefix 2002::/16 30 2
set prefix ::/96 20 3
set prefix ::ffff:0/96 10 4
set prefix 2001::/32 5 5

Link referencial y base de este articulo:
Win7 seems to prefer IPv4 native to IPv6/6to4 - which is not what the policy table says - which is right?

Certificacion IPv6 de Hurricane Electric

  En esta oportunidad voy a dejarles mis impresiones sobre la certificacion IPv6 que tiene Hurricane Electric en http://ipv6.he.net/certification
na primera oportunidad la habia ignorado pero en esta oportunidad la curiosidad me llamo.
  Les comento que me parece muy interesante la misma; me gusta la manera como esta organizada. Les cuento un poco:

- La certificacion se puede hacer por pasos y en varios dias. Esto da bastante comodidad.
- Para cada nivel te mandan a hacer varias "tareas" tales como: Configurar un servidor Web, de Correo, DNS, prueban conectividad a equipos tuyos etc.
- Es didactica y divertida
- Logicamente para comenzar la certificacion debes estar desde una maquina IPv6
- Existen varios niveles de certificacion: Newbie, Entusiasta, Administrator, Professional, Guru, Sage. A pesar de que me agrada la idea de varios niveles, creo que los nombres le quedan grande al nivel, por ejemplo, obtener el grado de Administrator me parece sencillo y su nombre suena casi a experto.
- Te mandan una franela/remera gratis de IPv6!!!!

  Desde mi punto de vista las personas que manejen servidores y conectividad directamente tienen una enorme ventaja sobre los que no.

Consejos previos para prepararse para la certificacion:
  - Como recomendacion, antes de comentar el examen, tengan un dominio con el cual puedan trabajar, quiero decir, que puedas crear zonas, modificar registros, etc.
  - Maquina servidor (preferiblemente Linux) con conectividad a IPv6
  - Acceso y configuracion a servicios tales como Web Server y Mail Server

Mas informacion
  - La pagina para los que esten interesados es: http://ipv6.he.net/certification/
  - En este blog hay mucha informacion sobre IPv6 sobre Linux y algunos servicios como Apache y Sendmail http://acostanetwork.blogspot.com

  Saludos y suerte a los que deseen tomar la certificacion!!.    

Twitters sobre IPv6 en español

Introducción:
   Deseo seguir información de Tweets en español sobre IPv6.

A quienes seguir:
@lactf  (Latin American & Caribbean Task Force sobre IPv6)
@MendozaIPv6Day 
@ipv6cl 
@SI6NetworksES (sobre IPv6 pero con mayor tendencia a Seguridad y hacking)

  Indiscutiblemente hay muchos más sin embargo los anteriores son exclusivamente de IPv6 y en español. Muchas veces existe información en otros idiomas (ejemplo retweets) pero la mayoría son idioma español.

Mas info
http://www.twitter.com
Lista de correo LACTF: http://acostanetwork.blogspot.com/2011/06/lista-de-correo-de-ipv6-lac-tf-de.html
@lactf tambien tiene un grupo en  linkedin: http://t.co/IGBx8iB