miércoles, 27 de enero de 2010

Transición a IPv6

Posted by Nicolas | miércoles, 27 de enero de 2010 | Category: , , , |

Existen diversos modos de enfrentar la transición de IPv4 a IPv6. Para aquellos que no entienden las diferencias básicas entre estos protocolos se recomiendan leer los RFC respectivos (791 y 2460) o al menos revisar Introducción a IPv6. En esta ocasión se revisará el caso en que se quiera tener conectividad IPv6, pero nuestro proveedor de servicios no soporta IPv6.

Se tiene entonces un escenario como el que se ve en la figura, donde R5 no soporta IPv6, el que bien podría representar un conjuntos de routers o más bien Internet (hacer click en la figura para ver con mayor claridad).



Las configuraciones iniciales de estos equipos son:

hostname R4
!
no ip domain lookup
ipv6 unicast-routing
!
interface Loopback0
ip address 192.0.2.4 255.255.255.255
ip ospf 1 area 0
!
interface Loopback1
no ip address
ipv6 address 2001:DB8:AAAA::1/48
!
interface FastEthernet0/0
ip address 198.51.100.4 255.255.255.0
ip ospf 1 area 0
duplex auto
speed auto
!
router ospf 1
log-adjacency-changes

hostname R5
!
no ip domain lookup
!
interface Loopback0
ip address 192.0.2.5 255.255.255.255
ip ospf 1 area 0
!
interface FastEthernet0/0
ip address 198.51.100.5 255.255.255.0
ip ospf 1 area 0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 203.0.113.5 255.255.255.0
ip ospf 1 area 0
duplex auto
speed auto
!
router ospf 1
log-adjacency-changes

hostname R6
!
no ip domain lookup
ipv6 unicast-routing
!
interface Loopback0
ip address 192.0.2.6 255.255.255.255
ip ospf 1 area 0
!
interface Loopback1
no ip address
ipv6 address 2001:DB8:BBBB::1/48
!
interface FastEthernet0/0
ip address 203.0.113.6 255.255.255.0
ip ospf 1 area 0
duplex auto
speed auto
!
router ospf 1
log-adjacency-changes

Es lógico pensar que no se tendrá conectividad IPv6 entre R4 y R6.

R4#ping 2001:DB8:BBBB::1 r 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2001:DB8:BBBB::1, timeout is 2 seconds:

% No valid route for destination
Success rate is 0 percent (0/1)
R4#

Ok, en los dos primeros ejemplos se verán cómo enfrentar esto con túneles point-to-point con diferente encapsulación. En primer caso se utilizará un túnel GRE (General Routing Encapsulation). Las configuraciones adicionales en R4 y R6 se muestran a continuación.

hostname R4
!
interface Tunnel1
no ip address
ipv6 address 2001:DB8:CCCC::4/48
tunnel source Loopback0
tunnel destination 192.0.2.6

ipv6 route 2001:DB8:BBBB::/48 Tunnel1

hostname R6
!
interface Tunnel1
no ip address
ipv6 address 2001:DB8:CCCC::6/48
tunnel source Loopback0
tunnel destination 192.0.2.4

ipv6 route 2001:DB8:AAAA::/48 Tunnel1

Se prueba conectividad entre ambas LAN IPv6.

R4#ping 2001:DB8:BBBB::1 repeat 1 source loopback1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2001:DB8:BBBB::1, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:AAAA::1
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 0/0/0 ms
R4#

Si se analiza el detalle de los paquetes se verá que a los paquetes IPv6 se les agregó un encabezado GRE (número de protocolo IP 47 de acuerdo a: Protocol Numbers) y luego un encabezado IPv4 con origen y destino las direcciones del túnel. Es decir el mensaje tiene dos encabezados adicionales; |IPv4|GRE|IPv6|.

*Jan 26 16:58:26.983: IP: s=192.0.2.4 (local), d=192.0.2.6 (FastEthernet0/0), len 124, sending, proto=47
*Jan 26 16:58:26.987: IP: s=192.0.2.6 (FastEthernet0/0), d=192.0.2.4, len 124, rcvd 4, proto=47

Lo bueno es que se puede evitar la encapsulación de GRE utilizando IPv6 sobre IPv4 como es especificado en el RFC 2529: Transmission of IPv6 over IPv4 Domains without Explicit Tunnels. Para esto simplemente es necesario cambiar la encapsulación del túnel.

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#interface tunnel 1
R4(config-if)#tunnel mode ipv6ip

R6#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R6(config)#interface tunnel 1
R6(config-if)#tunnel mode ipv6ip

Se repite el test de conectividad.

R4#ping 2001:DB8:BBBB::1 repeat 1 source loopback1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2001:DB8:BBBB::1, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:AAAA::1
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 4/4/4 ms
R4#

*Jan 26 19:15:09.458: IP: s=192.0.2.4 (local), d=192.0.2.6 (FastEthernet0/0), len 120, sending, proto=41
*Jan 26 19:15:09.462: IP: s=192.0.2.6 (FastEthernet0/0), d=192.0.2.4, len 120, rcvd 4, proto=41

Con debug ipv6 icmp se puede ver el detalle de los mensajes ICMP IPv6.

*Jan 26 19:15:09.458: ICMPv6: Sent echo request, Src=2001:DB8:AAAA::1, Dst=2001:DB8:BBBB::1
*Jan 26 19:15:09.462: ICMPv6: Received echo reply, Src=2001:DB8:BBBB::1, Dst=2001:DB8:AAAA::1

El número de protocolo IP es ahora 41 (IPv6). El mensaje tiene sólo un encabezado adicional; |IPv4|IPv6|.

A continuación se verá el caso de túneles point-to-multipoint, o sea que lo túneles no tiene dirección de destino. Para esto conviene revisar el RFC 3056: Connection of IPv6 Domains via IPv4 Clouds. Básicamente ahí se definen las direcciones del rango 2002::/16 como sigue:

     | 3 |  13  |    32     |   16   |          64 bits               |
     +---+------+-----------+--------+--------------------------------+
     |FP | TLA  | V4ADDR    | SLA ID |         Interface ID           |
     |001|0x0002|           |        |                                |
     +---+------+-----------+--------+--------------------------------+

Lo más importante es que sigan este patrón básico: 2002:V4ADDR::/48 donde V4ADDR representa la dirección IPv4 del host ó red en notación hexadecimal. A continuación la configuración necesaria y luego se explicará la lógica que siguen los paquetes para ser transmitidos.

hostname R4
!
interface Tunnel1
no ip address
ipv6 address 2002:C000:204::1/48
tunnel source Loopback0
tunnel mode ipv6ip 6to4
end

ipv6 route 2001:DB8:BBBB::/48 2002:C000:206::1
ipv6 route 2002::/16 Tunnel1

hostname R6
!
interface Tunnel1
no ip address
no ip redirects
ipv6 address 2002:C000:206::1/48
tunnel source Loopback0
tunnel mode ipv6ip 6to4
end

ipv6 route 2001:DB8:AAAA::/48 2002:C000:204::1
ipv6 route 2002::/16 Tunnel1

R4#ping 2001:DB8:BBBB::1 repeat 1 source loopback1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2001:DB8:BBBB::1, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:AAAA::1
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 4/4/4 ms
R4#

*Jan 26 20:38:06.918: IP: s=192.0.2.4 (local), d=192.0.2.6 (FastEthernet0/0), len 120, sending, proto=41
*Jan 26 20:38:06.918: IP: s=192.0.2.6 (FastEthernet0/0), d=192.0.2.4, len 120, rcvd 4, proto=41

*Jan 26 20:38:06.918: ICMPv6: Sent echo request, Src=2001:DB8:AAAA::1, Dst=2001:DB8:BBBB::1
*Jan 26 20:38:06.922: ICMPv6: Received echo reply, Src=2001:DB8:BBBB::1, Dst=2001:DB8:AAAA::1

OK, todo parece funcionar, pero cómo hizo R4 para sabe dónde enviar el mensaje ICMP y R6 para retornarlo si es que el túnel no tiene destino?.

Bueno, vamos por partes. R4 hace ping a 2001:DB8:BBBB::1 y gracias a la ruta estática configurada (ipv6 route 2001:DB8:BBBB::/48 2002:C000:206::1) se sabe ese host es alcanzado con next-hop 2002:C000:206::1. Recursivamente se sabe que las direcciones 2002::/16 se alcanzan a través del túnel configurado (ipv6 route 2002::/16 Tunnel1). A su vez la encapsulación en el túnel especifica "IPv6 automatic tunneling mode using a 6to4 address" (tunnel mode ipv6ip), por lo que descifra el destino IPv4 a partir del nexthop IPv6 especificado. Para esto se deben extraer los primeros 48 bits de la direccion IPv6 para obtener 2002:V4ADDR::/48 y por ende V4ADDR. Para el ejemplo se tiene 2002:C000:206::1, por eso V4ADDR corresponde a C000:206.

C0 -> 1100 0000 -> 192
00 -> 0000 0000 ->  0
02 -> 0000 0010 ->  2
06 -> 0000 0110 ->  6

-> Next-hop: 192.0.2.6

Para el camino de vuelta es lo mismo, notar que V4ADDR es C000:204 -> 192.0.2.4.

Si bien este método resulta interesante, tiene alguna connotaciones negativas. Básicamente por que este método asegura que los paquetes que host que utilizan 6to4 alcanzen destinos IPv6, pero no asegura que estos hosts sean alcanzables por host con direcciones IPv6 nativas (sin 6to4). Además un ISP que anuncia el prefijo 2002::/16 puede recibir paquetes que no son destinados a sus clientes. Para más detalles se recomienda leer el RFC 5569: IPv6 Rapid Deployment on IPv4 Infrastructures (6rd).

Existe un segundo método de la forma point-to-multipoint, el cual está orientado a permitir la conectividad IPv6 dentro de una red en la que no está aún implementada IPv6 nativa. Se hace referencia a ISATAP. Para más detalles al respecto se recomienda leer el RFC 5214: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).

Explicaciones más didácticas sobre este tópico pueden encontrarse en:

En total 0 comentarios:


Leave a Reply

Suscribirse a: Enviar comentarios (Atom)