IPv6 in da house!

Durante mi viaje espiritual a Amsterdan del verano pasado, Saghul y yo estuvimos jugando a lo que más nos gusta. Darle a la tecla, aka molar!.

Entre muchas otras cosas que hicimos esa semana, montamos un entorno de IPv6 que hemos publicado en el blog de Saul y que reproduzco a continuación:

Vamos a ver cómo conectar no solo un ordenador, sino toda la casa al mundo IPv6. Para ello vamos a suponer que no tenemos IPv6 de manera nativa, pero que disponemos de un servidor en algún datacenter (también sin IPv6 de manera nativa) y un router con GNU/Linux. También vamos a suponer que algo sabemos de OpenVPN y Quagga.

Dado que no disponemos de conectividad real IPv6 necesitaremos los servicios de un broker que nos provea de un túnel para la conexión al backbone de IPv6. Para este montaje utilizaremos el servicio proporcionado por el ISP Hurricane Electric. Para poder crear el túnel necesitamos que nuestro extremo disponga de una IP fija, pero como vamos a configurarlo en el host que tenemos en el datacenter esto no debería suponer un problema.

Al finalizar la solicitud través de la web obtendremos un rango /64 para nosotros. Suficiente, ¿no? pues no. Hemos dicho que queremos tener IPv6 en toda la casa, e IPv6 nos ofrece un mecanismo para asignar una dirección IP a cada dispositivo sin la necesidad de utilizar DHCP: Router Advertisement + EUI-64. Básicamente nuestro router tendrá una IP en este rango y se anunciará mediante paquetes RA y los dispositivos generarán una IP única en ese rango utilizando su MAC + FFFE.

Esto significa que necesitamos un rango más grande si queremos crear varias subredes /64  para cada cliente o sede y darles salida a la Internet IPv6. Hurricane nos da la posibilidad de obtener un rango /48, así que no hay problema :-)

A continuación podéis ver una captura de pantalla de los datos de la red IPv6 /64 que Hurricane nos ha dado y la /48 que nos enruta a través de ella:

Ya que hemos dicho que teníamos un servidor en un datacenter, lo utilizaremos para crear múltiples subredes IPv6 que saldrán al mundo real por un único túnel a través de Hurricane. Veamos una imagen con la estructura que queremos montar:

Como se aprecia en la imagen, todos los nodos (los routers de nuestras casas) están conectados mediante una VPN sobre IPv4 al servidor. Utilizaremos una subred que actuará como red de tránsito entre nuestro server y cada una de las subredes de los clientes que conectemos. Los clientes se conectarán mediante una VPN sobre IPv4. En éste túnel, implementaremos tanto IPv4 como IPv6, teniendo así soporte dual stack
en la VPN. Para publicar la red que nos ha sido asignada como cliente, usaremos OSPFv3 mediante Quagga para que el servidor conozca. ¡Vamos al lio!

Primero configuramos el tunel con Hurricane tal y como se nos indica en la web:

ip tunnel add he-ipv6 mode sit remote 216.66.84.42 local
91.121.117.27 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f12:286::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr

Es una buena idea poner esto en un script y ejecutarlo en el post-up de la interfaz a través de la cual tiraremos el túnel, para no tener que lanzarlo manualmente al reiniciar.

Una vez tenemos el túnel levantado ya deberíamos poder hacer ping6 a ipv6.google.com y molar. Ahora elegiremos una subred (de la /48 que nos enrutan) que usaremos como red de tránsito. En nuestro caso, nos enrutan la siguiente subred:

2001:470:c846::/48

Y elegiremos la primera subred como red de transito:

2001:470:c846:1::/64

En el extremo de la VPN del servidor, nos pondremos la primera IP de la subred de transito, y cada cliente podrá elegir cualquier IP en su extremo. Con 2^64 posibilidades creo que no habrá muchas colisiones

;-)

2001:470:c846:1::1/64

Veamos la configuración de Quagga para el servidor:

interface tap0
 ipv6 address 2001:470:c846:1::1/64
 ipv6 nd suppress-ra
 ipv6 ospf6 cost 1
 ipv6 ospf6 dead-interval 40
 ipv6 ospf6 hello-interval 10
 ipv6 ospf6 instance-id 0
 ipv6 ospf6 priority 255
 ipv6 ospf6 retransmit-interval 5
 ipv6 ospf6 transmit-delay 1
 link-detect
!
router ospf6
 router-id 2.2.2.2
 redistribute kernel
 redistribute static
 interface tap0 area 0.0.0.0

Lo importante de todas opciones arriba listadas son:

  • IPv6 address: indica la IP del interfaz tap0
  • Router-id, nos lo podemos inventar
  • Area, necesiaremos que sea el mismo en el servidor y los clientes
  • Redistribute kernel: hará que se publique la IP del servidor por
    OSPF para que los clientes la usen como ruta por defecto para el
    tráfico IPv6

Ahora veamos la configuración en un cliente:

interface eth1
 ipv6 address 2001:470:c846:2::1/64
 ipv6 nd prefix 2001:470:c846:2::/64
 ipv6 nd ra-interval 30
 ipv6 nd ra-lifetime 600
 link-detect
 no ipv6 nd suppress-ra
!
interface tap0
 ipv6 address 2001:470:c846:1::666/64
 ipv6 nd suppress-ra
 ipv6 ospf6 cost 1
 ipv6 ospf6 dead-interval 40
 ipv6 ospf6 hello-interval 10
 ipv6 ospf6 instance-id 0
 ipv6 ospf6 priority 1
 ipv6 ospf6 retransmit-interval 5
 ipv6 ospf6 transmit-delay 1
 link-detect
!
router ospf6
 router-id 1.1.1.1
 redistribute connected
 interface tap0 area 0.0.0.0

Aquí tenemos varias cosas. Por un lado, tenemos que elegir una subred (al azar, la posibilidad de colisión es casi nula) que será la que usemos en ese cliente (nuestara casa):

  • IPv6 address (eth1): indica la IP que tendrá este router en la subred que hemos seleccionado para este cliente
  • IPv6 nd prefix (eth1): indica el prefijo por el cual se hará el neighbour discovery
  • “no ipv6 nd suppress-ra”: indica que se utilizará Router Advertisement para que los dispositivos que tengamos por casa de autoprovisionen. Podríamos haber utilizado radvd, pero ya que se usa Quagga para el OSPF…
  • IPv6 address (tap0): indica la IP del extremo del túnel del lado del cliente. Ha de pertenecer a la red de tránsito que hemos definido arriba.
  • Redistribute connected: indica que se publicarán las rutas directamente conectadas, para que el servidor llegar hasta ésta subred por OSPF. De esta manera el servidor sabrá cómo enrutar los paquetes que tengan como destino la subred que hemos elegido y habremos habilitado el enrutamiento entre clientes/casas de frikis y también desde/hacia Internet.

Los que entendáis algo del asunto estaréis pensando que hemos matado moscas a cañonazos. Y tenéis razón. ¿Entonces porqué hacerlo? Porque podemos y porque sabemos!

Happy routing!

This entry was posted in Uncategorized and tagged , , , , , , . Bookmark the permalink.
  • pedro

    Un poco flipando , no ?

    • http://mikeljimenez.net Mike

      Define flipando…

  • Victor!

    excelente lab!
    matando moscas con el mejor estilo
    felicitaciones, excelente blog!

    salu2