Uno de los aspectos más interesantes de IPv6 es su esquema de direccionamiento, que viene con características que van desde la posibilidad de autoconfiguración de direcciones sin servidores centralizados como el DHCP, hasta características que nos dejarán sorprendidos al revelar la expectativa que sugiere el título de este artículo, que es la eliminación del broadcast como herramienta de comunicación multinodo. La única manera de comunicación multinodo disponible de ahora en adelante será el multicast, de la cual no es necesario explicar las ventajas que presenta frente al uso del broadcast.
En IPv6 se definen los llamados prefijos, mediante los cuales de diferenciarán los tipos de direcciones que tendremos en IPv6. En ese sentido veremos que será como volver al esquema de direccionamiento por clases de IPv4, en el cual solo con ver el valor de los bits más significativos de la dirección IP se determinaba rápidamente a qué clase pertenecía. Pero ahora con IPv6 no solo nos quedamos con la clasificación, sino que se definirán prefijos especiales que ayudarán a optimizar el manejo del tráfico en la red, como el uso de prefijos especiales para grupos multicast, la definición de túneles, entre otras funcionalidades muy interesantes que pasamos a describir a continuación.
Antes de presentar el esquema de direccionamiento diseñado para IPv6 a través de los llamados prefijos, hagamos, a manera de repaso, una breve comparación de las nuevas direcciones IPv6 con las antiguas direcciones IPv4. En la Tabla 1 se muestra esta breve comparación, comparando propiedades que van desde el tamaño de las direcciones en bit, hasta las formas de simplificación válidas en cada caso.
PROPIEDAD |
DIRECCIÓN IPV4 |
DIRECCIÓN IPV6 |
Cantidad de bits |
32 |
128 |
Tamaño espacio de direcciones |
3.758.096.384 unicast 268.435.456 multicast 268.435.456 Experimentales (clase E) |
42+ undecillon asignables 297+ undecillon reservadas por la IANA |
Tamaño de red predominante |
/24 (2^8 - 2 direcciones de hosts) |
/64 (2^64 direcciones de host) |
Notación |
Octetos en punto-decimal (192.0.2.239) |
Bloques de 4 hexadecimales separados por dos puntos (2001:db8:1234:9fef::1) |
Forma de simplificación de la dirección |
Suprimir ceros a la izquierda en cada octeto |
> Suprimir ceros a la izquierda en cada bloque > Reemplazar el grupo más largo de ceros seguidos por :: |
Tabla 1: Comparación entre direcciones IPv4 e Ipv6
Tomando en cuenta el tamaño de la dirección en bits, se hace claro un espectacular incremento del espacio de direcciones disponibles, al pasar de un espacio total de 232 direcciones en IPv4, a uno de 2128 direcciones en IPv6, es decir, se está incrementando el espacio actual por un factor de 296. A modo referencial pensemos que el número de átomos que se estima que existen en el universo son entre unos 4×1078 a 6×1079. Entonces, solo para el planeta tierra tenemos suficientes direcciones, se habla de unas 6,7x1027 (más de 670 mil billones) por metro cuadrado. Con este diseño estamos preparados para el inminente escenario de direccionamiento ya no solo de personas (a través de sus dispositivos), sino del direccionamiento de los dispositivos en sí mismos, y las cosas que nos rodean. Por otro lado, sabemos que el tamaño típico de una red en IPv4, especialmente las redes privadas, es una /24, mientras que en IPv6 será /64; más adelante veremos por qué. La notación ya fue repasada en el artículo anterior, resaltando que para el direccionamiento en IPv6 recurrimos a los caracteres hexadecimales en lugar de sólo los números decimales, como ocurría en IPv4; ya saben, muchos bits que codificar, necesitamos más opciones.
En la Figura 1 se muestra la composición típica de la dirección de un nodo en IPv6. Similar a lo que ocurría en IPv4, tendremos los bits de la izquierda (los más significativos) destinados a la identificación de la red, y los de la derecha (los menos significativos) destinados a la identificación de la interfaz. Como sabemos, un host o nodo en una red IP puede tener más de una interfaz, por lo cual digamos que se sincera el significado de los bits menos significativos en IPv6.
Figura 1: Formato de las direcciones IPv6
Por otro lado resaltamos la división de la dirección típicamente en 2 partes de 64 bits. Decimos típicamente porque no será así de forma obligatoria, pero no configurar manualmente el Interface ID será lo más recomendado, ya que, como veremos más adelante, los bits del Interface ID se definirán típicamente por mecanismos de autoconfiguración. En el RFC 4291 (IP Version 6 Addressing Architecture) se describen los detalles del direccionamiento en IPv6 y los prefijos definidos, que describimos en el siguiente apartado.
En IPv6 tendremos diferentes mecanismos de autoconfiguración de la dirección IPv6 para la interfaz de un nodo que ingresa a una red: DHCPv6, Router Advertisements, entre otros. Independientemente del mecanismo utilizado, el Interface ID será definido normalmente a partir de parámetros unívocos asociados a la interfaz, como puede ser la dirección MAC de una interfaz Ethernet. Ahora bien, sabemos que por ejemplo la dirección MAC de una interfaz tipo Ethernet tiene 48 bits, los cuales necesitaremos expandir de alguna manera a 64 bits para completar los bits necesarios del Interface ID en una dirección IPv6. En el caso de los sistemas basados en Unix/Linux, el interface ID se define mediante el mecanismo MEUI-64 (Modified Extended Unique Identifier 64 bits), que funciona de la siguiente manera:
A manera de ejemplo, veamos en la Figura 2 la configuración de IPv6 que tiene mi servidor Linux, visualizada a través de comando ifconfig.
Figura 2: Configuración IPv6 de un servidor Linux con el mecanismo MEUI-64
Como vemos la dirección MAC 00:0c:29:f7:10:b6 fue el insumo para la configuración de la dirección IPv6 fe80::20c:29ff:fef7:10b6. Se identifica la parte de red fe80:: con la simplificación de la dirección suprimiendo bloques de ceros consecutivos por el símbolo “::”, y el uso del prefijo fe80¸cuyo significado se presenta más adelante. El Interface ID 20c:29ff:fef7:10b6, siendo la parte azul definida a partir de la dirección MAC, donde visualiza la modificación del bloque de la izquierda de la dirección MAC (00:0c) que produce el bloque de la izquierda 20c.
En la Tabla 2 se presentan los prefijos más importantes definidos para el direccionamiento en IPv6, que son comentados a continuación.
TIPO DE DIRECCIÓN |
BITS DE PREFIJO |
PREFIJO |
Link-Local |
1111 1110 10 |
FE80::/10 |
Unspecified |
0000 … 0 (128 bits) |
::/128 |
Loopback |
0000 … 01 (128 bits) |
::1/128 |
Multicast |
1111 1111 |
FF00::/8 |
IPv4-Mapped |
000 … 01111111111111 (96 bits) |
::FFFF/96 |
ULA |
1111 110 |
FC00::/7 |
Global Unicast |
001 |
2000::/3 |
Anycast |
Tabla 2: Prefijos IPv6
Device(config-if)# ipv6 address 2002:db8:c058::/128 anycast
Finalmente llegamos a la explicación del funcionamiento del multicast en IPv6. La forma como se utiliza el multicast en IPv6 es tan determinante, que gracias a ello se elimina el uso del broadcast tal como se empleaba en IPv4 para servicios como DHCP, ARP, entre otros. En este apartado nos proponemos explicar cómo se logra eliminar ese mecanismo tan dañino para la red como era el broadcast.
Como ya hemos mencionado, se define el prefijo especial ff00::/8 para todos los grupos multicast. Dependiendo de los valores que tome el resto del prefijo, y los sufijos (Interface ID), el grupo multicast tendrá un alcance, una temporalidad y un significado. A continuación se explican los elementos referentes al alcance y la temporalidad.
FFXY:: prefijo multicast en IPv6
Sufijos de los grupos multicast
Dependiendo del sufijo (Interface ID), y combinando con la codificación anterior para la temporalidad y el alcance del grupo multicast, éste tendrá un significado definido según dicho sufijo. En la Tabla 3 se refinen algunos de los más importantes. En ella se puede ver, por ejemplo, que el sufijo ::2 se refiere al grupo multicast de los routers, pero dependiendo del prefijo dicho grupo puede ser permanente y de alcance a nivel del nodo (FF01), alcance a nivel del enlace local (FF02), o alcance a nivel del site (FF05). Incluso, si se deseara alcanzar a todos los routers a nivel global en IPv6 (toda la Internet) se utilizaría la dirección FF0E::2.
DIRECCIÓN MULTICAST |
DESCRIPCIÓN |
FF01::1 |
Todas las interfaces en el nodo local |
FF02::1 |
Todos los nodos en el enlace local |
FF01::2 |
Todos los routers en el nodo local |
FF02::2 |
Todos los routers en el enlace local. Define todos los routers en el mismo enlace del nodo |
FF05::2 |
Todos los routers en el site local |
FF02::B |
Agentes móviles en el enlace local |
FF02::1:2 |
Todos los agentes DHCP en el enlace local |
Tabla 3: Algunos grupos multicast en IPv6
Obsérvese por ejemplo que los agentes/servidores DHCP tienen en IPv6 un grupo multicast definido (::1:2). Podemos inferir entonces que en IPv6 un nodo que se conecte a una red mediante una interfaz con configuración de IP dinámica, solicitará una dirección global diferente a la Link-Local que describimos anteriormente (que se configura sin necesidad de ningún servidor), dirigiendo la petición DHCP al grupo multicast FF02::1:2, en lugar de enviar un broadcast, como sucede en IPv4. En la Figura 3 se presenta un ejemplo del intercambio de mensajes (Solicit-Advertise-Request-Reply) que existe entre el nodo que accede a la red (cliente) y solicita una nueva dirección IPv6 (fe80::a00:27ff:fe1b) y el servidor DHCPv6 (fe80::a00:27ff:fe20) que la entrega, el cual es alcanzable a través del grupo multicast ff02::1:2. De hecho, más que “una dirección”, el Servidor DHCP entregará “un prefijo”, dejándole al nodo cliente la tarea de completar la dirección IPv6 configurando el Interface ID mediante mecanismos como el MEUI-64, descrito anteriormente.
Figura 3: Configuración de dirección IPv6 mediante DHCP - Uso de multicast en lugar de broadcast
Finalmente, para terminar el artículo, e ilustrar una vez más como vamos a prescindir del broadcast en IPv6, explicamos el grupo multicast de los “Nodos Solicitados”. Este grupo será uno de los más importantes en el tema del direccionamiento en IPv6, puesto que gracias a él se evita el broadcast en mecanismos de descubrimiento de direcciones físicas, descubrimiento de vecinos, detección de direcciones duplicadas, entre otros. El proceso de descubrimiento de vecino lleva implícito el descubrimiento de su dirección física.
Todo nodo que accede a una red en IPv6 a través de una de sus interfaces pasa a formar parte del grupo multicast de Nodos Solicitados, que se define con el prefijo ff02::1:ff00:0/104. Los últimos 24 bits de este prefijo se definen mediante los últimos 24 bits de cualquier dirección unicast que posea dicha interfaz. Por ejemplo, si la interfaz tiene configurada la dirección IPv6 global 3ffe:0db8::fedc:ba98:7654:3210, tomando los últimos 24 bits de esta dirección se crea automáticamente el grupo multicast de nodos solicitados correspondiente: ff02::1:ff54:3210. Supongamos la siguiente situación: Se conecta a la red otro nodo con la dirección IPv6 2000:24e1::abdc:4321:7654:3210. Puesto que los último 24 bits son los mismos del caso anterior, el grupo multicast de Nodos Solicitados ff02::1:ff54:3210 ahora tendrá 2 integrantes. En un proceso de descubrimiento de dirección física ya no se requerirá realizar un broadcast como ocurría con ARP en IPv4; en este caso se envía un mensaje al grupo multicast de Nodos Solicitados correspondiente con la dirección IPv6 de la cual quiero saber la dirección física. El proceso se denomina LAR (Link Address Resolution) en IPv6. La siguiente figura, que cierra el artículo, describe el proceso tomando como ejemplo las direcciones indicadas anteriormente.
Figura 4: Ejemplo de Proceso LAR (Link Address Resolution) en IPv6 usando multicast con el grupo de “Nodos Solicitados”