Direccionamiento en IPv6: El Fin del Broadcast

Introducción

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.

Comencemos con una comparació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.

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 2³² direcciones en IPv4,  a uno de 2¹²⁸ direcciones en IPv6, es decir, se está incrementando el espacio actual por un factor de 2⁹⁶. A modo referencial pensemos que el número de átomos que se estima que existen en el universo son entre unos 4×10⁷⁸ a 6×10⁷⁹. Entonces, solo para el planeta tierra tenemos suficientes direcciones, se habla de unas 6,7x10²⁷ (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.

Direcciones IPv6

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.

 Autoconfiguración del Interface ID

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:

1. Se toma la dirección MAC de la interfaz, por ejemplo, 22:AC:9E:18:BE:80

       

2. Se pica la dirección MAC en partes iguales, y se inserta FF:FE en medio. Se prepara el último bloque de 8 bits de la izquierda (los 8 bits más significativos) para una modificación.

   

3. Se cambia el segundo bit menos significativo del último bloque de 8 bits de la izquierda. Se obtiene el Interface ID deseado de 64 bits.

   

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.

Prefijos IPv6

En la Tabla 2 se presentan los prefijos más importantes definidos para el direccionamiento en IPv6, que son comentados a continuación.

 Tabla 2: Prefijos IPv6

• Link-Local (fe80::): todas las direcciones IPv6 cuya parte de red sea del tipo fe80:: (el rango de prefijos completo se define con la notación /[longitud-prefijo], al estilo de CIDR en IPv4) solo válidas sólo a nivel del enlace local donde se encuentra conectada la interfaz, es decir, estas direcciones no son re-enviables ni enrutables más allá del enlace. Apenas se conecta una interfaz a un segmento físico de red, el sistema dispara un proceso de autoconfiguración para colocarle a la interfaz una dirección Link-Local, con el prefijo fe80::, y el Interface ID que corresponda de acuerdo a mecanismos como el MEUI-64, descrito anteriormente. Así, por ejemplo, una interfaz con dirección MAC 00:0c:29:f7:10:b6, en un sistema basado en Linux que usa MEUI-64, tendrá la dirección Link-Local fe80::20c:29ff:fef7:10b6. Así, cada nodo que se vaya conectando al mismo segmento será alcanzable porque pertenece a la misma red fe80::. Todo esto sin la participación de ningún servidor centralizado como un DHCP. Se podría hacer una analogía de este tipo de direcciones IPv6, con las direcciones IPv4 de la red 169.254.0.0/16, definidas en los RFC 3330 y RFC 3927, justamente para autoconfiguración de direcciones de enlace local, no enrutables, en los casos en que los hosts no encuentren respuesta a una petición DHCP.
• Unspecified (::): direcciones no especificadas, para momentos de transición entre cambios de configuración de direccionamiento, para definir rutas por defecto en una tabla de rutas, entre otros propósitos. Similar a las direcciones 0.0.0.0 en IPv4.
• Loopback (::1): a diferencia de IPv4 que define una red clase A entera para direcciones de loopback, en IPv6 solo se define una: ::1, con longitud de prefijo 128.
• Multicast (ff00::): Todas las direcciones IPv6 que comiencen por “ff” serán direcciones multicast, y dependiendo de los bits que siguen a este prefijo, se definirán el alcance, la temporalidad y el significado, del grupo multicast. Por ejemplo, la dirección ff02::2 se refiere al grupo multicast de todos los routers en el enlace local.
• IPv4 Mapped (::ffff/96): este prefijo se define para escenarios de transición (interoperabilidad entre redes IPv4 e IPv6) en los cuales se desee expresar una dirección única IPv4 en formato IPv6. Por ejemplo, supongamos la siguiente dirección IPv4 pública: 200.2.11.121. Usando este prefijo se define una dirección IPv6 equivalente, simplemente colocando después del prefijo la misma dirección IPv4 en formato punto-decimal: ::ffff:2.11.121. Un dispositivo IPv6 entenderá, apenas observe el prefijo ::ffff, que los últimos 32 bits de la dirección corresponden en una dirección IPv4. De igual manera, la dirección IPv4 se puede expresar en el formato hexadecimal utilizado en IPv6 y estaríamos hablando de la misma dirección. En el ejemplo, 200.2.11.121 se puede expresar como b79:c802, quedando la dirección IPv4 mapeada ::ffff:b79:c802.
• ULA (Unique Local Address, fc00::): se definen en el RFC 4193, y todas las direcciones que llevan este prefijo son enrutables en redes privadas, y no son válidas en la internet global. Tienen el mismo objetivo de las direcciones privadas de IPv4. A diferencia de las direcciones fe80, estas direcciones ULA sí son enrutables entre segmentos diferentes de redes privadas.
• Globales unicast (2000::): las direcciones “globales” son las equivalentes a las direcciones “públicas” de IPv4. La red 2000::/3 define este rango completo para el caso de IPv6.
• Anycast: En IPv6 se introduce formalmente el concepto de anycast, para el cual no se necesita definir ningún prefijo. Anycast se refiere a la comunicación entre un emisor y el receptor más cercano de un grupo de posibles receptores. A diferencia del multicast, donde un emisor único transmite a todos los receptores que pertenecen a un grupo, en anycast se transmite solo al “más cercano” de acuerdo con la tabla de rutas. Una dirección IPv6 anycast es una dirección del rango de direcciones unicast que ha sido asignada a un conjunto de interfaces que típicamente pertenecen a diferentes nodos. Sintácticamente no se diferencian del grupo de direcciones unicast. Los nodos a los cuales se les configura una dirección anycast deben ser explícitamente configurados de esta manera para que reconozca que se trata de una dirección unicast. Finalmente, las direcciones anycast solo pueden recibir tráfico, es decir, no deben ser usadas nunca como la dirección de origen en un paquete IPv6. Por ejemplo, para un nodo Cisco con IOS (release 15.2 M&T), el siguiente comando muestra cómo se añade una dirección anycast a una interfaz de un dispositivo, resaltando la palabra anycast al final del comando:

Device(config-if)# ipv6 address 2002:db8:c058::/128 anycast

Multicast en IPv6

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.

Direccionamiento Multicast en IPv6

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

• X = 4 bits con flags que definen la temporalidad del grupo multicast: Indica si la dirección es permanente (asignada por la IANA) o transitoria. Los valores manejados hasta el momento son:
  • 0 (0000 binario) – Grupo multicast permanente
  • 1 (0001 binario) – Grupo multicat transitorio
• Y = 4 bits con flags que definen alcance (scope) del grupo multicast. Los valores manejados hasta el momento son:
  • 0 (0000 binario) – Reservado
  • 1 (0001 binario) – Interfaces locales del nodo
  • 2 (0010 binario) – Nodos en el enlace local (link-local)
  • 5 (0101 binario) – Nodos en el “sitio“ (site) local
  • 8 (1000 binario) – Nodos en la “organización”
  • E (1110 binario) – Nodos a nivel global (Internet)
  • F (1111 binario) – Reservado

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.

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

Grupo Multicast de los “Nodos Solicitados”

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”