El protocolo de Internet versión 6, IPv6, es definido por la IETF en el RFC 2460 (la versión en español se encuentra en: http://www.rfc-es.org/rfc/rfc2460-es.txt). La sección 3 de éste denota el encabezado de los paquetes de la siguiente manera:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Con:

• Version (4 bits): 6. El salto de versión de 4 a 6 se debe básicamente a que el número de versión 5 fue asignado al protocolo STD2 (Internet Stream Protocol Version 2) definido en el RFC 1819.
• Traffic Class (8 bits): Similar al campo DS en IPv4, el que se revisó en Tipos de Servicio con DSCP.
• Flow Label (20 bits): Puede ser utilizado por la fuente de los paquetes para clasificar distintos flujos. Por lo general los flujos IPv4 son determinados a partir de las direcciones IP de origen/destino, puertos y transporte; udp/tcp. Este campo es definido en detalle en el RFC 3697.
• Payload Length (16 bits): Número de octetos que componen la información que sigue al encabezado IPv6. Las extensiones de encabezado son también consideradas como parte del payload.
• Next Header (8 bits): Identifica el tipo de encabezado que sigue al de IPv6. Utiliza los mismos número de protocolo definidos para IPv4 que se pueden revisar de manera online como dicta el RFC 3232 en http://www.iana.org/assignments/protocol-numbers/.
• Hop Limit (8 bits): Es decrementado en 1 por cada nodo que transmite el paquete, siendo éste descartado si el valor llega a 0. Reemplaza a TTL cumpliendo la misma función, pero sin hacer referencia en su nombre a una función relacionada con tiempo, sino más bien a número de saltos.
• Source Address (128 bit): Lo más relevante es que pasa de 32 a 128 bits en esta nueva versión del protocolo como se verá en detalle más abajo.
  
• Destination Address (128 bit): Es posible no sea el destino final si un encabezado de ruteo está presente.

La nueva representación de direcciones se define en el RFC 4291, en particular en la sección 2.2 (Text Representation of Addresses) se señala existen tres modos convencionales de representación para las direcciones IPv6.

1. El modo predilecto es x:x:x:x:x:x:x:x, donde las 'x' representan entre uno y cuatro números hexadecimales que conforman uno de los ocho fragmentos de 16 bits de la dirección. Ejemplos:

ABCD:EF01:2345:6789:ABCD:EF01:2345:6789
2001:DB8:0:0:8:800:200C:417A

No es necesario denotar los ceros a la izquierda de cada fragmento, sin embargo debe existir al menos un número en cada campo.

2. Existe un método de comprimir una seguidilla de ceros. Para esto se utiliza "::" indicando uno o más grupos de 16 bits de ceros, apareciendo una única vez por dirección. También "::" se puede utilizar para comprimir los ceros al comienzo o final de la dirección. Ejemplos:

2001:DB8:0:0:8:800:200C:417A  <-> 2001:DB8::8:800:200C:417A
FF01:0:0:0:0:0:0:101          <-> FF01::101
0:0:0:0:0:0:0:1               <-> ::1
0:0:0:0:0:0:0:0               <-> :: 

3. Una forma alternativa de denotar estas direcciones en ambientes mixtos IPv4/IPv6 es de la forma x:x:x:x:x:x:d.d.d.d, donde las 'x' representan los valores hexadecimales de los seis primeros fragmentos de 16 bits, mientras las 'd' los valores decimales de los últimos cuatro fragmentos de 8 bits (dos últimos fragmentos de 16 bits). Ejemplos:

0:0:0:0:0:0:13.1.68.3         <-> ::13.1.68.3
0:0:0:0:0:FFFF:129.144.52.38  <-> ::FFFF:129.144.52.38

Por otra parte hay que considerar que al igual que los prefijos IPv4, los prefijos IPv6 se denotan de la forma; ipv6-address/prefix-length, con ipv6-address un valor tal como los mostrados anteriormente y prefix-length un valor decimal que determina cuántos bits de izquierda a derecha componen el prefijo.

Existen distintos tipos de direcciones IPv6, los cuales quedan definidos por los primeros bits de las direcciones como muestra la siguiente tabla (sección 2.4 del RFC 4291).

Address type         Binary prefix        IPv6 notation
------------         -------------        -------------
Unspecified          00...0  (128 bits)   ::/128
Loopback             00...1  (128 bits)   ::1/128
Multicast            11111111             FF00::/8
Link-Local unicast   1111111010           FE80::/10
Global Unicast       (everything else)

Será de interés revisar la estructura de las direcciones Global Unicast delegadas por IANA.

|         n bits         |   m bits  |       128-n-m bits         |
+------------------------+-----------+----------------------------+
| global routing prefix  | subnet ID |       interface ID         |
+------------------------+-----------+----------------------------+

Todas estas direcciones con excepción de aquellas que comienzan con 000 tienen un interface ID de 64 bits, es decir n + m = 64 y construido a partir del formato modificado EUI-64, que inserta 0xFFFE en medio de la MAC de 48 bits del dispositivo, es decir justo después del OUI (que identifica al fabricante). Además el bit universal/local es modificado de 0 a 1 (séptimo bit de izquierda a derecha de la MAC). Los detalles se pueden ver en el apéndice A del RFC 4291, así como en un ejemplo al final de este post.

El RFC 3587 (IPv6 Global Unicast Address Format) muestra un ejemplo de dirección unicast global bajo el 2000::/3 (como inicialmente se pretendía encasillar a las direcciones globales, cosa que ya no tiene efecto) .

| 3 |     45 bits         |  16 bits  |       64 bits              |
+---+---------------------+-----------+----------------------------+
|001|global routing prefix| subnet ID |       interface ID         |
+---+---------------------+-----------+----------------------------+

Este ejemplo considera las recomendaciones del RFC 3177, el que señala en su sección 3 (Address Delegation Recommendations) que la distribución de direcciones debe seguir el siguiente patrón.

• /48 en caso general, excepto para suscriptores que demanden un mayor número de direcciones
• /64 cuando se sabe una única subnet es necesaria
• /128 cuando es un único dispositivo el que se está conectando

El esquema jerárquico de asignación global de las direcciones queda representado en IPv6 Address Allocation and Assignment Policy como se ve a continuación.

                +--------+
               |  IANA  |
               +--------+
                   |
             +-----------+
             |           |
         +--------+  +--------+
         |   RIR  |  |   RIR  |  Regional Internet
         +--------+  +--------+  Registries (APNIC, ARIN, RIPE NCC,
             |           |       plus possible future RIRs)
             |           |
             |        +-----+
             |        | NIR |     National Internet
             |        +-----+     Registries (AP region)
             |           |
        +--------+   +--------+
        |LIR/ISP |   |LIR/ISP |   Local Internet
        +--------+   +--------+   Registries (ISPs)
             |           |
       +--------+        |
       |        |        |
   +-------+  +----+   +----+
   |EU(ISP)|  | EU |   | EU |     End users
   +-------+  +----+   +----+

Además en este documento se señala que la asignación mínima que deben realizar los RIR's a los ISP's para direcciones IPv6 es /32. Por lo tanto si además se considera la actual distribución de IANA detallada en IPv6 Global Unicast Address Assignments, que asigna en su mayoría bloques /23 a los RIR's, se puede ver que la estructura es bastante estricta lo que permite mantener una tabla de ruteo reducida. El cliente final (EU) recibe un bloque /48, contando con 16 bits para su organización interna. Esta jerarquía puede ser evitada con el uso de direccionamiento independiente del proveedor (usualmente utilizado en casos de multihoming) como se detalla en IPv6 Provider Independent (PI) Assignments.

Por último señalar que de acá en adelante se utilizarán direcciones IPv6 del prefijo 2001:DB8::/32 para ejemplos tal como dicta la sección 4 del RFC 3849 (IPv6 Address Prefix Reserved for Documentation).

A continuación un ejemplo de asignación de dirección IPv6 utilizando la subnet 0 del prefijo mencionado anteriormente.

R2#
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#interface FastEthernet2/0
R2(config-if)#ipv6 address 2001:DB8::/64 eui-64
R2(config-if)#^Z
R2#

R2#show interfaces FastEthernet 2/0 | include Hardware
Hardware is DEC21140A, address is 001a.6c7c.0038 (bia 001a.6c7c.0038)

R2#show ipv6 interface FastEthernet 2/0 | include address|subnet
IPv6 is enabled, link-local address is FE80::21A:6CFF:FE7C:38
No Virtual link-local address(es):
Global unicast address(es):
2001:DB8::21A:6CFF:FE7C:38, subnet is 2001:DB8::/64 [EUI]
Joined group address(es):
Hosts use stateless autoconfig for addresses.
R2#

Como se ve la MAC de la interface es 001a.6c7c.0038. Si se inserta 0xFFFE en medio se tiene 001a.6cff.fe7c.0038. Por otra parte los primeros ocho bits son 00 = 0000 0000, que se transforman en 02 = 0000 0010, por ende el interface ID queda en 021a.6cff.fe7c.0038. Con esto se tiene material suficiente para formar la dirección global (comienza con 2001:DB8::) y la dirección de link-local (comienza con FE80::).