Introducción

Tabla de contenido

Implementaciones

El formato y la representación de las direcciones son las modificaciones más notables para el usuario experimentado y para el ingeniero de red en esta nueva versión del protocolo: las direcciones en IPv6 también son fijas pero pasan de 32 a 128 bits. Aunque los principios son muy similares a los utilizados en IPv4, en una primera instancia el nuevo direccionamiento parece mucho más complejo. Resulta interesante conocer los principios y las reglas de atribución antes de entrar en los detalles del protocolo.

El presente capítulo muestra los distintos tipos de direcciones. Explica en detalle el plan de direccionamiento agregado que ha sido elegido para construir la Internet IPv6. También describe la forma de constituir una dirección IPv6.

Aspectos fundamentales del direccionamiento IPv6

Representación de direcciones

La representación textual de una dirección IPv6 se efectúa dividiendo la palabra de 128 bits en 8 palabras de 16 bits en formato hexadecimal, separadas por el caracter ":". Por ejemplo:

2001:0DB8:0000:0000:0400:A987:6543:210F

No es necesario escribir los ceros a la izquierda de un campo:

2001:DB8:0:0:400:A987:6543:210F

Además, varios campos nulos consecutivos, pueden abreviarse como "::". Así, la dirección anterior puede escribirse como:

2001:DB8::400:A987:6543:210F

Naturalmente, para evitar ambigüedades, la abreviación "::" sólo puede usarse una vez en una dirección. Los casos extremos son la dirección indefinida (utilizada para designar las rutas por omisión), que tiene todos los bits en cero y que se escribe de manera compacta como:

::

y la dirección de bucle local (loopback), equivalente al prefijo 127/8 en IPv4, en la que todos los bits son cero excepto el último. Ésta se escribe de forma compacta como:

::1

La representación de prefijos de red IPv6 es similar a la notación CIDR (RFC 1519) para los prefijos IPv4. Así, un prefijo IPv6 sigue el formato representado por la notación:

dirección-ipv6/longitud-del-prefijo-en-bits

Se permite el uso de formatos abreviados con "::"

2001:0DB8:7654:3210:0000:0000:0000:0000/64
2001:DB8:7654:3210:0:0:0:0/64
2001:DB8:7654:3210::/64

Debe tenerse precaución al utilizar esta notación con prefijos que no terminan en un bloque de 16 bits. Por ejemplo, el prefijo 3EDC:BA98:7654:3::/56 equivale en realidad a 3EDC:BA98:7654:0000::/56 pues se escribe 3EDC:BA98:7654:0003::/56.

Es posible combinar el prefijo de red y el identificador de la interfaz en una sola notacion. Así, esta dirección IPv6 2001:DB8:7654:3210:945:1321:ABA8:F4E2/64 indica que el prefijo de red está constituido por los primeros 64 bits.

Estas representaciones pueden parecer mucho más complejas que con IPv4, pero en realidad, las direcciones lógicas o concisas se forman a través de reglas precisas. Estas reglas facilitan fuertemente la manipulación y la memorización de direcciones, como se verá más adelante (cf Direccionamiento global).

En algunos casos una dirección (o varias direcciones) IPv4 puede estar contenida en una dirección IPv6. Para destacarlas puede utilizarse la notación clásica de IPv4, es decir cuatro octetos en representación decimal separados por un punto, dentro de una dirección IPv6. De esta forma,

::128.12.13.14

representa una dirección IPv6 compuesta por 96 bits en cero, seguidos de los 32 bits de la dirección IPv4 128.12.13.14

En ocasiones es necesario manipular las direcciones IPv6 literalmente. El caracter ":" utilizado para separar las palabras, puede crear ambigüedades. Ese es el caso, por ejemplo, con las URL en las que el mismo caracter también se puede utilizar para especificar el número de puerto. Así, la URL:

http://2001:DB8:12::1:8000/

podría representar tanto el puerto 8000 en el dispositivo con dirección IPv6 2001:DB8:12::1, como el dispositivo 2001:DB8:12::1:8000 que utiliza el puerto por omisión. Para evitar esta ambigüedad, el RFC 2732 propone delimitar la dirección IPv6 entre corchetes cuadrados "[ ]". Dependiendo del caso, la dirección precedente se escribiría:

http://[2001:DB8:12::1]:8000/

o

http://[2001:DB8:12::1:8000]/

Esta representación puede extenderse a otros dominios, como X-window o al protocolo de señalización para telefonía SIP.

Tipos de direcciones

IPv6 reconoce tres tipos de direcciones: unicast, multicast y anycast. El tipo de dirección define la cardinalidad de la comunicación, es decir, a cuántos destinatarios debe ser entregado el paquete.

El primero de estos tipos, la dirección unicast, identifica de manera única una interfaz. Un paquete enviado a ese tipo de dirección será entregado a la interfaz correspondiente. Entre las direcciones unicast, se pueden distinguir aquéllas que tienen una cobertura global, es decir, designan sin ambigüedad un destinatario sobre la red Internet, y las que tienen cobertura local (en el enlace o en el sitio). Estas últimas no pueden ser enrutadas sobre Internet. Es decir, un paquete que tenga una dirección destino con cobertura local, será ignorado y eliminado por un enrutador de Internet. La cobertura de una dirección señala el límite de la propiedad de unicidad.

Una dirección tipo multicast (difusión restringida) designa a un grupo de interfaces que pertenecen, en general, a nodos distintos que pueden ubicarse en cualquier parte de Internet. Cuando un paquete tiene una dirección destino multicast, éste se envía por la red a todas las interfaces miembros de ese grupo.

Cabe resaltar que desaparecen las direcciones de difusión (broadcast) que existían en IPv4; éstas son remplazadas por direcciones tipo multicast. La dirección de difusión puede ser imitada por una dirección mulitcast constituyendo un grupo que incluya todos los nodos. La ausencia de direcciones de difusión evita los problemas de saturación en las redes locales conmutadas. Por ello, una red IPv6 tiene un mejor desempeño en términos de factor de escala, sobre este tipo de redes.

El último tipo de dirección, anycast, se deriva de la oficialización de propuestas hechas para IPv4 (RFC 1546). Como en el caso multicast, una dirección de tipo anycast designa un grupo de interfaces. La principal diferencia consiste en que cuando un paquete tiene una dirección destino anycast, éste es enviado a alguno de los miembros del grupo, no a todos. El receptor del paquete podría ser, por ejemplo, el más cercano de acuerdo a la métrica de usada por los protocolos de enrutamiento. Este tipo de dirección es principalmente experimental. Consulte Direcciones anycast para más información.

Algunos tipos de direcciones se identifican por su prefijo (RFC 3513). La tabla siguiente muestra la lista de estos prefijos (fuente: http://www.iana.org/assignments/ipv6-address-space). El bloque "reservado" del prefijo 0::/8 es utilizado por las direcciones llamadas especiales (dirección indeterminada, de bucle (loop), mapeada, compatible). Se observa que más del 70% del espacio disponible no se ha asignado, lo que permite contar con una gran flexibilidad para el futuro.

Prefijo IPv6	Asignar	Referencia
0000::/8	Reservado para la transición y para loopback	RFC 3513
0100::/8	Reservado	RFC 3513
0200::/7	Reservado (Ej. NSAP)	RFC 4048
0400::/6	Reservado (Ej. IPX)	RFC 3513
0800::/5	Reservado	RFC 3513
1000::/4	Reservado	RFC 3513
2000::/3	Unicast global	RFC 3513
4000::/3	Reservado	RFC 3513
6000::/3	Reservado	RFC 3513
8000::/3	Reservado	RFC 3513
A000::/3	Reservado	RFC 3513
C000::/3	Reservado	RFC 3513
E000::/4	Reservado	RFC 3513
F000::/5	Reservado	RFC 3513
F800::/6	Reservado	RFC 3513
FC00::/7	Unicast local única	RFC 4193
FE00::/9	Reservado	RFC 3513
FE80::/10	Local al enlace	RFC 3513
FEC0::/10	Reservado	RFC 3879
FF00::/8	Multicast	RFC 3513

Generalmente, una interfaz poseerá varias direcciones IPv6. En IPv4 este comportamiento es excepcional, pero resulta trivial en IPv6.

Direccionamiento global: Plan de direccionamiento agregado

Este plan, propuesto en el RFC 3587, especifica la estructura de direccionamiento IPv6 definida en el RFC 3513, estableciendo el tamaño de cada bloque. Se gestiona de la misma manera que CIDR en IPv4. Una dirección incluye tres niveles de jerarquía:

Figure : Direcciones Globales

• una topología pública (llamada "Prefijo Global") codificada en 48 bits asignados por el proveedor de acceso (ISP, Internet Service Provider;
• una topología de sitio codificada en 16 bits (denominada "ID de subred, SID"). Este campo se utiliza para codificar los números de subred del sitio;
• un identificador de interfaz de 64 bits (llamado "ID de interfaz") para distinguir los diferentes dispositivos en el enlace.

Estructuración del prefijo global (GP)

Aparte del prefijo 2002:: que está reservado para el mecanismo de transición 6to4, este espacio es administrado jerárquicamente como en IPv4. El IANA delega a las cinco autoridades regionales (RIR) prefijos (con una longitud actual de 12 bits, cf http://www.iana.org/assignments/ipv6-unicast-address-assignments) que redistribuyen entre los ISP de su región. En función de su tamaño, los operadores reciben un prefijo mayor o menor. En el sitio http://www.sixxs.net/tools/grh/ se pueden observar en tiempo real las asignaciones de prefijos por región, operador y país.

En la actualidad se reconoce que el prefijo asignado por un operador a sus clientes puede ser también de longitud /56, pues si se mantiene la asignación de prefijos de longitud 48 para los sitios terminales y se integran las redes domésticas, los operadores pueden justificar la necesidad de un número importante de direcciones, que las autoridades regionales no podrían rechazar.

TODO	Añadir cómo obtener un prefijo en RIPE-NCC (o en otro RIR)

Estructuración del identificador de subred (SID)

No se tienen reglas para la asignación de identificadores de subred dentro de un sitio. Se pueden utilizar varias técnicas (no excluyentes) como:

• enumerar de forma incremental las subredes: 0001, 0002, ... Esta técnica es fácil de implementar en las redes experimentales, pero puede dar lugar a un esquema de direccionamiento plano, difícil de recordar. Se puede utilizar, por ejemplo, para una subred dedicada a los servidores con el fin de simplificar la escritura y la memorización de direcciones;
• utilizar el número de VLAN. Permite no tener que memorizar múltiples niveles de numeración;
• separar los tipos de redes y utilizar las cifras a la izquierda para designarlos. Esta técnica facilita las reglas de filtrado, utilizando al mismo tiempo reglas adecuadas para la gestión de estas subredes en el segmento del lado derecho. A manera de ejemplo, la siguiente tabla contiene el plan de numeración de una universidad con varios planteles, tomando en cuenta las diferentes comunidades de usuarios:

Asignación de SID en una universidad

Comunidad	4bits	8bits	4bits
Infraestructura	0	valores específicos
Pruebas	1	valores específicos
Túneles	6	asignación de /60 a los usuarios
Invitados Wi-Fi	8	valores específicos
Personal	A	Entidad	Subred
Estudiantes	E	Entidad	Subred
Otros (Start up, etc.)	F	valores específicos

De esta manera, el prefijo:

• 2001:DB8:1234::/52 será para la creación de la infraestructura; en particular, las direcciones de interfaz de los enrutadores, serán asignadas de este espacio;
• 2001:DB8:1234:8000::/52 será para la red Wi-Fi de los invitados. La forma en que los 12 bits del SID sobrantes serán administrados, no se especifica;
• 2001:DB8:1234:E000::/52 será para la red de los estudiantes. La entidad representa la localización geográfica del plantel. En cada uno de estos campi, será posible tener hasta 16 subredes diferentes para cada comunidad.

Direccionamiento local: Direcciones locales al enlace

Las direcciones del tipo Enlace_local (link local use address) sólo son válidas dentro del enlace, es decir, sobre el conjunto de interfaces directamente accesibles sin la intervención de un enrutador, por ejemplo, dispositivos en una misma red local Ethernet, máquinas unidas por una conexión PPP, o puntos extremos de un túnel. Las direcciones locales al enlace se configuran automáticamente al inicializar la interfaz y permiten la comunicación entre nodos vecinos. La dirección se obtiene concatenando el prefijo FE80::/64 a los 64 bits del identificador de interfaz. Aunque generalmente el identificador de interfaz está basado en la dirección MAC, no se compromete la privacidad ya que, a diferencia de las direcciones globales, las locales al enlace nunca salen de la red donde son utilizadas.

Figure : Direcciones locales al enlace

Estas direcciones se utilizan por los protocolos de configuración de dirección global, de descubrimiento de vecinos (neighbor discovery) y de descubrimiento de enrutadores (router discovery). Se trata de mecanismos, el primero de ellos para suplantar al protocolo ARP (Address Resolution Protocol), que permiten que una red local se configure automáticamente (ver Descubrimiento de vecinos). También son muy utilizadas por los protocolos de enrutamiento tanto para el intercambio de datos (cf RIPng, OSPFv3), como en las tablas de enrutamiento dado que el campo "siguiente enrutador" se refiere siempre a un dispositivo directamente accesible dentro del enlace.

En ningún caso un enrutador podrá retransmitir un paquete que tenga como dirección fuente o destino una dirección de tipo Enlace_local.

El hecho de que estas direcciones tengan una cobertura tan corta, las limita en la práctica a casos en los que se necesita un arranque automático (bootstrap). Su uso no debe generalizarse para aplicaciones convencionales en condiciones de operación estable.

Ámbito de una dirección (scoped address)

Una dirección local al enlace (o una multicast) no indica de forma intrínseca la interfaz de salida ya que todas las interfaces comparten el mismo prefijo fe80::/10. Por consiguiente, es necesario indicar explícitamente a través de qué interfaz deben emitirse los paquetes. Bajo algunos sistemas operativos (BSD, Mac OS, Windows), ésta se puede especificar agregando al final de la dirección el nombre de la interfaz deseada, precedida del caracter "%". Bajo Linux, la interfaz de salida se designa mediante un argumento, generalmente "-I".

Dirección local única

El RFC 4193 define un nuevo formato de dirección unicast: las direcciones locales únicas (ULA: Unique Local Address). Estas direcciones son para uso local. No están pensadas para ser enrutadas en Internet, sino dentro de un área acotada, como un sitio o un número limitado de sitios. Con un prefijo de 48 bits, pueden ser manipuladas como las direcciones globales, con un identificador de Subred (SID) de 16 bits y un identificador de interfaz (IID) de 64 bits.

Las direcciones locales únicas se crean utilizando un identificador global (Global ID) generado de forma pseudo-aleatoria. Estas direcciones tienen el formato siguiente:

• Prefix (7 bits): FC00::/7 prefijo para identificar las direcciones IPv6 locales (ULA)
• L (1 bit): Puesto a 1, el prefijo es asignado localmente. El valor 0 está reservado para usos futuros.
• Global ID (40 bits): Identificador global utilizado para la creación de un prefijo "único" (Globally Unique Prefix).
• Subnet ID (16 bits): Identificador de subred al interior del sitio.
• Interface ID (64 bits): El identificador de interfaz, tal como está definido en Identificador de interfaz.

El sitio http://www.sixxs.net/tools/grh/ula/ permite crear y registrar su propia dirección ULA a partir de una dirección MAC.

Figure : Direcciones locales únicas

Este tipo de dirección permite aislar la numeración externa e interna. En IPv4, el uso de un prefijo privado (como 10/8) evita que un sitio deba renumerar su red si cambia de proveedor de acceso. Un traductor de direcciones, NAT (que llamaremos NAT44 en lo que resta de este documento), permite convertir el direccionamiento privado en público.

Con las direcciones tipo ULA es posible reproducir este comportamiento en IPv6. Un dispositivo en la orilla de la red convertirá el prefijo privado en público. Este equipo, inicialmente llamado NAT66, ha sido renombrado NPTv6 (Network Prefix Translation) para enfatizar que no tiene las mismas limitaciones que el NAT de IPv4.

Los prefijos ULA se caracterizan por una secuencia aleatoria de 40 bits después del prefijo FC::/7. Este valor único permite esquivar los problemas encontrados en IPv4 al fusionar dos redes privadas. Dado que el riesgo de colisión entre dos valores aleatorios de 40 bits es relativamente bajo, si dos redes se fusionan, el hecho de tener prefijos únicos evita problemas de interconexión.

Estructuración del identificador de interfaz (IID)

Si en un principio el identificador de interfaz debía derivarse de la dirección de nivel 2 para facilitar la auto-configuración, esto es cada vez menos necesario. De hecho, existen varios métodos para formar el identificador de interfaz de 64 bits:

• manual,
• a partir de la dirección de nivel 2 de la interfaz,
• aleatorio,
• criptográfico

Manual

Para los servidores más utilizados, puede ser recomendable asignar manualmente las direcciones a sus interfaces, pues en este caso la dirección IPv6 es fácil de recordar y el servidor se puede acceder incluso si el DNS no está activo. Existen varias técnicas más o menos mnemotécnicas:

• Incrementar el número de identificador de interfaz para cada nuevo servidor creado

2001:DB8:1234:1::1
2001:DB8:1234:1::2
...

• recuperar el último octeto de la dirección IPv4 como identificador de interfaz. Por ejemplo, si un servidor tiene la dirección IPv4 192.0.2.123, su dirección IPv6 será:

2001:DB8:1234:1::7B

o simplemente

2001:DB8:1234:1::123

• recuperar la dirección IPv4 como identificador de interfaz, aunque ello tenga el inconveniente de generar direcciones más largas a escribir:

2001:DB8:1234:1::192.0.2.123

A partir de la dirección de nivel 2 de la interfaz

La ventaja de utilizar una dirección de nivel 2 para formar el identificador de interfaz, es que casi siempre puede asegurarse que este valor es único. Además, se mantiene estable mientras la tarjeta de red de la máquina no cambie. Sin embargo, estos valores son difíciles de memorizar.

Las direcciones locales al enlace se construyen de esta manera. Para las direcciones globales, su uso sólo es aconsejable para los equipos cliente y privilegiar los identificadores de interfaz manuales para los servidores.

Dado que estos identificadores de interfaz son estables en el tiempo, cada vez que un individuo cambia de red, cambia de prefijo, pero se mantiene el mismo identificador de interfaz. En consecuencia, este identificador podría ser utilizados para rastrear los movimientos de un individuo. En realidad este es un riesgo bajo, pues las cookies creadas por los servidores Web son mucho más eficaces para ello (aunque ese ya no es un problema de red). Otra desventaja es que, como la dirección MAC contiene el identificador del fabricante, es posible mostrar al exterior de la red qué tipo de equipo se está utilizando.

Si estos inconvenientes son considerados importantes por la empresa, el identificador de interfaz de direcciones globales se pueden generar al azar.

EUI-64

Figure : Transformación de una dirección MAC en identificador de interfaz

La IEEEE definió un identificador global de 64 bits (formato EUI 64) para las redes IEEE 1394 (firewire) o IEEE 802.15.4 (redes de sensores) con miras a su utilización en el dominio de las redes domesticas. El IEEE describe las reglas para transformar un identificador MAC de 48 bits en un EUI-64.

Existen varios métodos para construir el identificador:

• Si un dispositivo o una interfaz posee un identificador global IEEE EUI-64, éste tendrá la estructura descrita en la figura "Identificador global IEEE EUI-64.

Los primeros 24 bits del identificador EUI-64 designan al constructor (al igual que en las direcciones MAC IEEE 802). Los otros 40 bits corresponden al número de serie (las direcciones MAC IEEE 802 solo utilizan 24 bits). Los dos bits u (séptimo bit del primer octeto) y g (octavo bit del primer octeto) tienen un significado especial:

• u (Universal) vale 0 si el identificador EUI-64 es universal;
• g (Grupo) indica si la dirección es individual (g = 0), es decir, designa un solo dispositivo en la red, o de grupo (g = 1), por ejemplo, una dirección multicast.

Figure : Identificador de interfaz derivado de EUI-64

• El identificador de interfaz de 64 bits se deriva de EUI-64 invirtiendo el bit u (ver figura Identificador de interfaz derivado de EUI-64), ya que para la formación de direcciones IPv6 se ha optado por utilizar 1 para denotar la unicidad mundial de la dirección. Este cambio en la semántica del bit permite conservar el valor 0 para una numeración manual en la que las interfaces simplemente comienzan a enumerarse a partir del valor 1.

MAC-48

Figure : Transformación de una dirección MAC en identificador de interfaz

• Si una interfaz posee una dirección MAC IEEE 802 universal de 48 bits (es el caso, por ejemplo, de las interfaces Ethernet o Wi-Fi), la dirección primero se convierte en EUI-64, después el bit u se pone a 1 como en el caso anterior. La figura muestra este proceso.

Casos Particulares

• Si una interfaz posee una dirección local única en el enlace pero no universal (es el caso, por ejemplo, del formato de dirección IEEE 802 de dos octetos, o de una dirección de red Appletalk), el identificador de interfaz se forma a partir de esta dirección, agregando bits a 0 en la cabecera hasta completar los 64 bits.

• Si una interfaz no cuenta con ninguna dirección (por ejemplo, las interfaces utilizadas para los enlaces PPP), y si la máquina no tiene un identificador EUI-64, no hay un método único para formar el identificador de interfaz. Se aconseja utilizar el identificador de otra interfaz (si esta existe y tiene una dirección MAC), una configuración manual, o bien, la generación de un identificador aleatorio con el bit u puesto en 0.
  En caso de conflicto (por ejemplo, si los dos extremos de un enlace escogieron el mismo valor), éste será detectado al inicializar la dirección Enlace_local de la interfaz y el conflicto deberá resolverse de forma manual.

Valor aleatorio

Como ya se ha mencionado, un identificador de interfaz basado en las direcciones MAC, podría acarrear problemas de privacidad, pues identifica claramente la máquina de un usuario que, aún si se desplaza de una red a otra, conserva este identificador. Por ello, seria posible ubicar a un individuo que utiliza un dispositivo móvil, en su oficina, en su hogar, o durante sus desplazamientos. Este es un problema similar al del identificador que se encuentra en los procesadores Pentium III.

Para terminar pronto con cualquier amenaza de boicot a un protocolo que "pudiera comprometer la vida privada", se han propuesto otros algoritmos para formar un identificador de interfaz, basados en la generación de valores aleatorios (ver RFC 3041). Un usuario especialmente desconfiado puede utilizar estos mecanismos. El identificador de interfaz podría ser elegido aleatoriamente, o bien formado a partir de valores precedentes como lo hace MD5, o generado al azar si la máquina no puede recordar los valores entre una inicialización y otra. Periódicamente la dirección es colocada en el estado "depreciado" y se elige un nuevo identificador de interfaz. Las conexiones ya establecidas continuarán utilizando el valor anterior, mientras que las conexiones nuevas tomarán la dirección actualizada.

Este método fue adoptado por Microsoft. En Windows XP, la interfaz tiene dos direcciones IPv6 globales. La primera posee un identificador de interfaz derivado de la dirección MAC y se utiliza para las aplicaciones s que esperan una conexión sobre la máquina (i.e. las aplicaciones de servidor). Esta dirección, siendo estable, puede ser publicada en el DNS. La segunda posee un identificador de interfaz generado aleatoriamente que cambia todos los días y se utiliza para las aplicaciones cliente. En Windows 7, se generaliza este comportamiento, ya que el identificador de interfaz de la dirección permanente también es generado al azar. Con ello se evita anunciar la marca de la máquina o el tipo de tarjeta de red, contenido en los primeros octetos del identificador de interfaz.

Este método también está presente, pero de forma opcional, en Linux y en los sistemas operativos BSD como Mac OS.

Por supuesto, estos mecanismos tienen una razón de ser; es necesario que el dispositivo no se registre bajo un mismo nombre en un servidor DNS inverso, o que el registro de cookies en un navegador Web para identificar al usuario, esté imposibilitado.

Como contra partida, resulta mucho más difícil para un administrador de red el poder filtrar el tráfico de estas máquinas precisamente porque cambian su dirección periódicamente.

Criptografia

Si bien un identificador aleatorio ofrece un fuerte anonimato para la fuente del paquete, se han hecho propuestas en el IETF para vincular el identificador de interfaz a la llave pública del emisor. El RFC 3972 define este principio (CGA : Cryptographic Generated Addresses). Esto podría servir para asegurar los protocolos de descubierta de vecinos, o bien, para la gestión de la multi-domiciliación.

Direcciones multicast

Esta sección describe brevemente el sistema de direccionamiento multicast IPv6. Se centra únicamente en las direcciones utilizadas localmente por los protocolos vinculados directamente con IPv6 (Descubrimiento de vecinos, DHCPv6, ...). Para más información sobre multicast en general, consulte el capítulo Multicast. La figura 'Estructura de la dirección IPv6 Multicast' presenta el formato de las direcciones IPv6 de multicast descrito en el RFC 3513.

Figure : Estructura de la dirección IPv6 Multicast

Las direcciones multicast IPv6 se derivan del prefijo FF00::/8. El campo bandera de 4 bits se define de la siguiente manera:

• Inicialmente, sólo el bit T (Transient) de este campo se describe en el RFC 3513. El valor 0 indica una dirección multicast bien conocida, administrada por una autoridad. El valor 1 indica una dirección temporal.
• Los bits P y R se describen en el RFC 3306 y en el draft Internet sobre RP embebido (RFC 3956).
• El bit más significativo de este campo aún no ha sido asignado.

El campo bandera permite definir varias direcciones multicast IPv6, las cuales se describirán en las secciones siguientes.

El campo ‘‘scope’’ de la dirección multicast IPv6 permite limitar la cobertura. Mientras que en IPv4 la cobertura de un paquete está limitada por el campo TTL (Time To Live), aquí también se pueden definir prefijos para limitar el alcance de las direcciones. Los siguientes valores han sido definidos en el RFC 2373:

• 1 - node-local : Los paquetes no salen del dispositivo; esta dirección sirve para la comunicación entre aplicaciones dentro de la máquina.
• 2 - link-local : La cobertura se limita a la red local; los paquetes no pueden cruzar enrutadores multicast. Este valor se utiliza en especial por el protocolo de descubrimiento de vecinos.
• 3 - subnet-local : Este tipo no se ha definido oficialmente, pero aparece en algunos documentos. Permite diferenciar entre un enlace físico y uno lógico (formado por un agrupamiento de varios enlaces físicos) que comparten el mismo prefijo IPv6.
• 4 - admin-local
• 5 - site-local
• 8 - organisation-local
• E - global
• Los valores de cobertura 0 y F están reservados.

El sitio http://www.iana.org/assignments/ipv6-multicast-addresses muestra las direcciones multicast definidas. La tabla siguiente enlista las más utilizadas:

Dirección multicast	Uso
FF01::1	All Nodes Address
FF01::2	All Routers Address
FF02::1	All Nodes Address
FF02::2	All Routers Address
FF02::5	OSPFIGP
FF02::6	OSPFIGP Designated Routers
FF02::9	RIP Routers
FF02::C	UPnP [1]
FF02::1:2	All-dhcp-agents
FF03::C	UPnP [2]
FF04::C	UPnP [3]
FF05::2	All Routers Address
FF05::C	UPnP [4]
FF05::1:3	All-dhcp-servers
FF0X::101	Network Time Protocol (NTP)

Direccionamiento Multicast Solicitado

IPv6 no permite el uso de la difusión generalizada (Broadcast) cuando la difusión restringida (multicast) está disponible. Así, los protocolos como Neighbor Discovery, encargado de establecer la relación entre las direcciones IPv6 y las direcciones MAC (en vez de ARP en IPv4) deben utilizar una dirección multicast. Para incrementar la eficacia, en vez de utilizar la dirección FF02::1, que involucra a todos los dispositivos en el enlace, las direcciones multicast solicitado permiten reducir considerablemente el número de equipos que recibirán la solicitud.

Figure : Construcción de la dirección Multicast Solicitada

La figura Construcción de la dirección Multicast Solicitada muestra cómo transformar una dirección IPv6 unicast en una dirección multicast solicitada. Se deben tomar los últimos tres octetos de la dirección unicast, y concatenarlos al prefijo IPv6 multicast FF02::1:FF00:0/104.

En el ejemplo mostrado, las dos direcciones derivadas de una dirección MAC, conducen a la misma dirección de multicast solicitada, mientras que la configuración manual de una interfaz genera otra dirección multicast solicitada. Puede observarse que el riesgo de que dos máquinas sobre un enlace tengan la misma dirección multicast solicitada, es muy bajo. Para las generadas a partir de una dirección MAC, sería necesario que los últimos tres octetos sean idénticos, lo cual es imposible para un mismo fabricante y la probabilidad de tener sobre el mismo enlace, tarjetas de red de dos fabricantes distintos que coincidan en el número de serie (tres últimos octetos), es muy baja. Bajo la enumeración manual de las interfaces, un dispositivo que tenga la dirección GP::0100:0001 llevaría a generar la misma dirección multicast solicitada FF02::1:FF00:0001, pero esta numeración manual de interfaces, no resulta lógica.

El ejemplo muestra la conversión de la dirección multicas a nivel IPv6, en dirección multicast de nivel 2. Es muy específico a la tecnología y a la forma en que se implementa el multicas de nivel 2. Para las redes Ethernet (y sus derivados, como WiFi), los cuatro últimos olctetos de la dirección multicast solicitada se agregan al prefijo 33-33.

Introducción

Tabla de contenido

Implementaciones