IPv 6 AEGFinal

IPV6
Centro de Estudios A.E.G.
1. IPV6 BÁSICO 1
1.1. DISTRIBUCIÓN DE DIRECCIONES IPV4 1

1.2. EVOLUCIÓN DE LA NECESIDAD DE DIRECCIONES 3
1.3. INCONVENIENTES TÉCNICOS DE IPV4 3
1.4. LA SOLUCIÓN: IPV6 5
1.5. HISTORIA DE IPV6 7
2. CABECERA, DIRECCIONAMIENTO Y CONFIGURACIÓN BÁSICA. 9
2.1. LA NUEVA CABECERA 10

2.1.1. LIMPIEZA EN IPV4 10
2.1.2. LOS CAMPOS BIT A BIT 12
2.1.3. LAS CABECERAS DE EXTENSIÓN 15
2.2. DIRECCIONAMIENTO 19
2.2.1. LOS PREFIJOS 21
2.2.2. DIRECCIÓN NO ESPECIFICADA Y DIRECCIÓN DE LOOPBACK 22
2.2.3. DIRECCIONES UNICAST GLOBALES 23
2.2.4. DIRECCIÓN UNICAST DE ENLACE LOCAL 25
2.2.5. DIRECCIÓN UNICAST LOCAL ÚNICA 27
2.2.6. DIRECCIONES ANYCAST 28
2.2.7. DIRECCIONES MULTICAST 30
2.2.8. DIRECCIONES DE CADA NODO 33
2.2.9. SELECCIÓN DE DIRECCIONES POR DEFECTO 33
2.3. INSTALACIÓN Y TIPOS DE CONFIGURACIÓN DE IPV6 36
2.3.1. INSTALACIÓN Y CONFIGURACIÓN BÁSICA DE IPV6: 36
2.3.2. CONFIGURACIÓN AVANZADA DE IPV6: 48
2.4. ORDENES BÁSICAS EN GNU/LINUX Y WINDOWS 50
2.4.1. ORDENES BÁSICAS EN UBUNTU-LINUX 50
2.4.2. ORDENES BÁSICAS EN WINDOWS 55
2.5. PRUEBAS DE CONECTIVIDAD EN LAN (PING6) 60
3. CONFIGURACIÓN AVANZADA. 64
3.1. ICMPV6. 64
3.1.1. LOS MENSAJES 65
3.1.2. NEIGHBOR DISCOVERY 71
3.1.3. OTRAS POSIBILIDADES DE ICMPV6 78
3.2. CONFIGURACIÓN STATELESS. 84
3.2.1. INTRODUCCIÓN 84
3.2.2. DESCRIPCIÓN 84
3.2.3. AUTOCONFIGURACIÓN DE DIRECCIONES GLOBALES 85
3.2.4. OBTENCIÓN DE DIRECCIONES DE AUTOCONFIGURACIÓN 87
3.2.5. ALGORITMOS DE GENERACIÓN DE DIRECCIONES GLOBALES 88
3.2.6. ROUTER IPV6 89
3.3. DHCPV6. 94
3.3.1. DHCPV6 UBUNTU 9.10 SERVER 95
Paseo de Heríz, 82 DONOSTIA GIPUZKOA TEL: 943313907 1

3.3.2. DHCPV6 WINDOWS 2008 SERVER 97

3.3.3. DHCPV6 CLIENTE UBUNTU 9.10 104
3.3.4. DHCPV6 CLIENTE WINDOWS XP 107
3.3.5. DHCPV6 CLIENTE WINDOWS 7 113
3.4. CONFIGURACIÓN MANUAL. 115
3.4.1. CONFIGURACIÓN MANUAL EN UBUNTU-LINUX 115
3.4.2. CONFIGURACIÓN MANUAL EN WINDOWS 121
3.5. PLANIFICACIÓN DE UNA RED IPV6 130
4. MECANISMOS DE TRASICIÓN PARA CONSEGUIR CONECTIVIDAD. 132
4.1. IPV6 IN IPV4 133

4.2. IPV6 TO IPV4 136
4.3. TEREDO. 139
5. EJEMPLOS DE TUNELES: TUNNEL BROKER Y TEREDO 142
5.1. CREACIÓN DE TÚNEL EN UN HOST CON WINDOWS CON FREENET6. 142

5.2. CREACIÓN DE TÚNEL DE UN FIREWALL DE BEBIAN CON HURRICANE. 152
5.3. CREACIÓN DE TÚNEL TEREDO 160
6. INYECCIÓN Y CAPTURA DE PAQUETES. 164
6.1. WIRESHARK 164
7. NUEVAS AMENAZAS CON IPV6 170
7.1. COMUNICACIONES A TRAVÉS DE IPV6 170

7.2. ATAQUES CONTRA LA AUTOCONFIGURACIÓN IPV6 170
7.3. VULNERABILIDADES CON TEREDO 171
7.3.1. PUERTA ABIERTA A INTERNET 171
7.3.2. SUPLANTACIÓN DE IDENTIDADES 172
7.3.3. ATAQUES DE DENEGACIÓN DE SERVICIOS 172
7.4. VULNERABILIDADES CON 6TO4 173
7.4.1. PUERTA ABIERTA A INTERNET 173
7.4.2. SUPLANTACIÓN DE IDENTIDADES 173
7.4.3. ATAQUES DE DENEGACIÓN DE SERVICIOS 174
7.5. USOS DE IPV6 CON FINES MALICIOSOS 174
8. ASPECTOS DE SEGURIDAD MEJORADOS CON IPV6. 175

1. IPv6 Básico
A pesar de no tener dueño y de dar la sensación de ser un mundo incontrolable,
desde el punto de vista técnico, Internet está totalmente regulada.
Ejemplos:
Todos los equipos del mundo que se conectan a Internet, están identificados de
forma unívoca por medio de una especie de matrícula digital: la dirección IP.
Todos los datos que circulan por la red van empaquetados y tienen su origen y
destino perfectamente identificados, así como cuál es la aplicación que les espera.
Las comunicaciones que se establecen entre equipos, tanto vía Internet como en
nuestras redes locales, se rigen por una serie de protocolos estándar totalmente
definidos.
Todos los protocolos empleados conviven en la llamada pila de protocolos TCP/IP.

El nombre de la pila es en "honor" a sus protocolos más famosos, aunque no son los
únicos.
El IP (Internet Protocol) que aparece en el nombre de la pila hace referencia al

protocolo IPv4, que es el que se ha utilizado hasta ahora para cuestiones de
enrutamiento, esto es, para decidir por donde irán los datos del origen al destino en
función de las direcciones IP que llevan "grabadas".
1.1. Distribución de direcciones IPv4

Debido a la longitud de la direcciones IPv4, que es de 32 bits, hay un total de 2³² =
4.294.967.296 direcciones disponibles.
Estas direcciones se representan en 4 grupos de 8 bits, con notación decimal y

separados por puntos. Cada grupo de 8 bits puede tomar en total 256 valores (2⁸) entre
0 y 255.
Las direcciones están organizadas por rangos de modo que hay direcciones
públicas y direcciones privadas.
Las privadas se pueden utilizar en cualquier tipo de red local sin mayores
problemas, ya que son direcciones que no se enrutan hacia Internet y por lo tanto no
pueden provocar conflictos. Los rangos de las direcciones privadas son:
10.0.0.0 a 10.255.255.255 (10.0.0.0/8)
172.16.0.0 a 172.31.255.255 (172.16.0.0/12)
192.168.0.0 a 192.168.255.255 (192.168.0.0/16)

Las públicas son las que nos identifican en Internet y deben ser únicas para cada
equipo. Precisamente por su carácter global es necesario que existan mecanismos de
control para organizar el reparto de las mismas.
La jerarquía para el reparto se ilustra en la siguiente figura:
Puede parecer que más de 4.000 millones de direcciones deberían ser suficientes
para abastecer de direcciones a todo el planeta, pero como vamos a ver, no es así.
El total de las direcciones disponibles se organiza en 256 bloques de 16.777.216

direcciones. Actualmente la situación en cuanto al reparto de estos bloques es el
siguiente:
Fuente: www.arin.net/knowledge/stats.pdf
Como puede verse, quedan tan solo 26 bloques /8 de los 256 teóricamente
disponibles, esto es, poco más de un 10%. Incluso aunque las direcciones no disponibles
(por estar preasignadas o reservadas) se agregaran a las direcciones disponibles, se ve
claro que, con la tendencia actual, en cuestión de unos pocos años no habría direcciones
IPv4 que repartir.
En este enlace se pueden ver estadísticas diarias de la progresión del reparto de

direcciones IPv4 que nos lleva a la extinción del espacio disponible. Incluso se prevé
cuál será la fecha del día "X" (en el momento de escribir este documento -marzo de
2010- se hablaba de finales de 2011.
Un problema adicional al agotamiento de las direcciones es lo descompensado que

está el reparto de las mismas. Que un estado como El Vaticano, con algo menos de 1000
habitantes, tenga algo más de 8 direcciones IPv4 por cabeza no parece demasiado
problemático. Pero que un país como Estados Unidos, con más de 300 millones de
habitantes, tenga casi 5 direcciones por habitante, da que pensar, especialmente cuando
en el otro extremo del baremo países como Nigeria disponen de una IP para más de
5000 habitantes.
Por ello, el achacar el problema del agotamiento a las economías emergentes como
China (1 dirección IPv4 para cada 5 habitantes) o India (1 dirección IPv4 para cada 50
habitantes) no es muy riguroso. El verdadero problema es que hay pocas direcciones y
están mal repartidas.
1.2. Evolución de la necesidad de direcciones

En septiembre de 1981 se publicó la RFC 791 "Internet Protocol". Desde
entonces el crecimiento de la necesidad de este protocolo ha sido imparable e
impredecible.
Por un lado, como se ha comentado en el punto anterior, las economías emergentes

exigen su parte del pastel de las direcciones.
Por otro lado, el número de dispositivos que se pueden conectar a Internet es cada
vez mayor: PDAs, móviles, consolas, sistemas de seguridad (alarmas, cámaras),
televisores y hasta frigoríficos...
Las previsiones indican que en un futuro cercano elementos como los contadores de
agua, gas o electricidad estarán también online y lo mismo ocurrirá con los coches..
Además, las soluciones para monitorización remota de todo tipo de máquinas serán
cada vez más frecuentes.
Todo esto nos lleva a un escenario "Always-on" en el que el usuario no solo

dispondrá siempre de acceso a Internet, sino que además, estará siempre localizable.
1.3. Inconvenientes técnicos de IPv4

La evolución de las necesidades de Internet ha supuesto un reto para IPv4.
Cuando fue diseñado, a finales de los años 70, no había preocupación por hacer
frente a la saturación de los medios disponibles debido al alto número de equipos
conectados ni era una prioridad la seguridad.

Por ello, a parte del ya comentado problema del agotamiento del rango de
direcciones, IPv4 presenta otros inconvenientes que se repasan a continuación.
Problemas de rendimiento:
Los problemas de rendimiento vienen ocasionados por:
El mal uso de los medios disponibles.
La manipulación a que son sometidos los datos.
El resultado final es la acumulación de retardos que producen fallos en aplicaciones

sensibles a los mismos, como por ejemplo VoIP.
Por ejemplo, en IPv4 existe la posibilidad de generar tráfico de broadcast. Esto son
paquetes de datos que parten de un equipo con la pretensión de llegar a todos los
equipos que estén a "tiro de PING", es decir, a todos los equipos que se encuentran en
el mismo dominio de difusión.
El uso indiscriminado de este tipo de tráfico, incluso por algunos de los protocolos
incluidos en TCP/IP, provoca el colapso de las redes debido a las colisiones que tienen
lugar. Colisiones que se solucionan con la retransmisión de los datos después de esperar
cierto tiempo. Ya tenemos un retardo.
Otra situación que desemboca en retardos es el procesamiento a que son sometidos

los paquetes de información.
Cada vez que un paquete viaja de un equipo al siguiente que le acerca a su destino se
dice que ha realizado un salto (hop). En cada salto se analiza la información recibida
para determinar si el paquete se queda en la red a la que acaba de llegar o si hay que
enviarlo a otra red diferente. Aquí surgen nuevos retardos.
Por último, los routers que reciben la información, después de analizarla y decidir
que tienen que reenviarla, tienen que aplicar algoritmos de selección de rutas para que
la elección sea la óptima. En la aplicación de estos algoritmos aparecen nuevos retardos.
Problemas de IPv4 relacionados con seguridad
En el diseño de IPv4 se pensó en garantizar la conectividad. El tema de la seguridad

quedó al margen y esto se refleja en que no hay ningún tipo de control de seguridad en
su estructura.
Con el paso de los años empezaron a surgir diversas técnicas que aprovechaban estas
debilidades y que hacían las delicias de los aficionados a la "seguridad" informática
(hackers).
Actualmente la seguridad en IPv4 se garantiza por medio de dos parches: SSL

(Secure Socket Layer) e IPsec (encriptación a nivel de red).

El aplicar estas técnicas implica una carga adicional para el procesamiento de los
datos (nuevos retardos) y por lo tanto, una nueva reducción del rendimiento.
Problemas de la utilización de NAT (Network Address Translation)
Ante la necesidad de dosificar las direcciones IP públicas disponibles se ha ideado el

NAT, cuyo objetivo es hacer posible que una red privada al completo pueda acceder a
Internet a través de una única dirección IP pública.
Algunas de las consecuencias de la utilización de NAT son las siguientes:
Rompe el modelo end-to-end.
Debido a NAT se pierde la "transparencia" original de Internet, cuando había un

esquema de direccionamiento único y universal y los paquetes podían fluir del origen al
destino sin alteraciones intermedias.
Afecta a protocolos y aplicaciones.
Proporciona una falsa sensación de seguridad.
Hay varios documentos que explican los motivos de la no conveniencia del NAT:
RFC 2775 "Internet transparency"
RFC 3027 "Protocol Complication with the IP Network Address Translator"
RFC 2993 "Architectural Implications of NAT"
1.4. La solución: IPv6

Efectivamente, la solución a los problemas comentados se logra mediante IPv6
En relación a la escasez de direcciones:
En IPv6 el número de bits para direccionamiento pasa de los 32 de IPv4 a 128.
Para hacernos a la idea de la cantidad de direcciones disponibles en IPv6 se suele

recurrir a varios ejemplos típicos como los millones de millones de direcciones que
podríamos asignar a cada m² del planeta Tierra. Pero quizás sea más significativo pensar
que con IPv6 podríamos dar una dirección a cada grano de arena que hay en la Tierra.
La cantidad de direcciones es tan grande que parece imposible que se puedan agotar,
independientemente de que la gestión de las mismas sea más o menos acertada.
En relación a los retardos:
En IPv6 el formato de las cabeceras de los paquetes se ha simplificado. Tienen un

tamaño fijo y no hay información redundante. Todo esto hace que sea más sencillo su
procesamiento y por lo tanto se reducen los retardos del mismo.

En IPv6 no existe tráfico de broadcast. Cada paquete de información tiene un origen

y un destino.
No hay reconstrucción de tramas en cada salto. Esa reconstrucción la hará

únicamente el equipo final.
Los campos de carga útil tienen un tamaño de 64Kb, para que sean más fácilmente
"digeridos" por los micros de 64bits.
Las tablas de los routers se descongestionan, y necesitan menos tiempo para decidir
cuál será el siguiente salto.
Todo esto hace que mejore el rendimiento de la red.
En relación a la seguridad:
IPsec está integrado en IPv6, de modo que se reduce el procesamiento externo para
implementarlo y se consigue por un lado mejorar la seguridad y por otro reducir los
retardos.
Hay nuevos campos en la cabecera cuyo objetivo es mejorar la seguridad: AH =

Authentication Header y ESP = Encapsulating Security Payload. Estos campos permiten
que la seguridad se base en la encriptación de la información transmitida. Para
garantizar la autenticación de las entidades se recurre a los certificados digitales.
En relación a los problemas de NAT, la implantación de IPv6 supone la vuelta al

modelo end-to-end, con lo que los problemas que sufrían las protocolos y las
aplicaciones desaparecen.
Otras ventajas de IPv6:
El control del tráfico es más efectivo, ya que hay reservados campos para QoS
(Quality of Service) y CoS (Class of Service), con los que se puede regular el tráfico en
función de su sensibilidad al retardo de red.
Las VPNs se soportan de forma nativa, y por ello resulta más barato implementarlas
pues no es necesario adquirir productos de terceros.
Además se facilitan ciertas tareas administrativas con nuevas funcionalidades:

autoconfiguración, renumeración, movilidad IP...

Como se puede ver, IPv6 ha aprendido de las carencias de su antecesor y ofrece un

amplio abanico de mejoras que solo están esperando a ser aprovechadas por los
servicios y programas que están por desarrollar.
Lo que no va a ser posible es establecer una fecha para realizar una transición total
de IPv4 a IPv6. En otras palabras, de momento no va a producirse un "Apagón IP".
La situación requiere una transición gradual en la que los dos protocolos convivan,
cosa que se ilustra en la siguiente figura.
1.5. Historia de IPv6

El organismo encargado del desarrollo del nuevo protocolo fue el IETF (Internet
Engineering Task Force).
En el año 1991 comienza a trabajar sobre el problema de expandir el número de

direcciones de Internet.
Puesto que la IP es uno de los datos incluidos en la cabecera del protocolo, el hecho
de ampliar el rango de direcciones implicaba un rediseño de la cabecera, esto es, había
que desarrollar una versión nueva de IP.
Los objetivos inicialmente planteados fueron:
Gran número de direcciones disponibles.
Soportar un esquema de direccionamiento jerárquico.
Seguridad embebida (tanto encriptación como autenticación).
Autoconfiguración “plug and play”.
Mejoras a la Calidad de Servicio.
Movilidad IP.
Las alternativas barajadas inicialmente fueron las siguientes:
CATNIT (Common Architecture for the Internet): este era un protocolo compatible
con IP, IPX y OSI que aportaba un largo de direcciones variable.
SIPP (Simple Internet Protocol Plus): este era una evolución de IPv4, con
encabezado más simple y 64 bits para direccionamiento.
TUBA (TCP and UDP with Bigger Addresses): este era la propuesta usando
direcciones de red OSI (CLNP).
Finalmente, a partir de SIPP se diseñó el IPng (Internet Protocol next generation),

que fue rebautizado posteriormente con el nombre de IPv6.
El motivo por el que saltaron de IPv4 a IPv6 omitiendo IPv5 fue que dicho nombre
ya había sido utilizado para un protocolo experimental descrito la RFC 1819 (Internet
Stream Protocol Version 2).
La especificación general de IPv6 se describe en la RFC 2460 (en sustitución a la

RFC 1883), y su estructura de direccionamiento en la RFC 4291 (en sustitución a la
RFC 3513).
A partir de ahí se han ido creando distintos grupos para fomentar la implantación de
IPv6. Entre los más destacables tendríamos el IPv6 Forum.También se pusieron en
marcha proyectos como 6bone (1996-2006) mediante el que se fomentaba la
experimentación sobre una red mundial IPv6.
A día de hoy, aunque el protocolo es completamente operativo, no se puede decir

que se haya terminado su desarrollo. De hecho, se sigue trabajando en guías operativas,
en la adaptación de IPv6 - WiMAX, en algunos detalles de las cabeceras de extensión...

2. Cabecera, direccionamiento y configuración básica.

En esta sección se hará, en primer lugar, una incursión en la nueva cabecera de IPv6,
comentando su estructura y el funcionamiento de las nuevas cabeceras de extensión.
Por otro lado se hablará del direccionamiento en IPv6, repasando los distintos tipos
de direcciones existentes y explicando su utilidad.
Por último se mostrará como realizar la instalación y configuración básicas en

algunos de los sistemas operativos más usuales.
Antes de continuar conviene repasar algunos conceptos habituales. Las siguientes

definiciones suelen aparecer al comienzo de muchas RFCs.
• Nodo: es un dispositivo que utiliza el protocolo en estudio (IP, IPv6...)
• Router: es un nodo que reenvía paquetes actuando como intermediario en

una comunicación entre dos nodos.
• Host: cualquier otro nodo que no sea un router.
• Upper Layer o Capa Superior: cuando se habla de protocolos de la capa

superior se hace referencia a la capa que está justo por encima de la capa de
IP, por lo que los mencionados protocolos serán TCP, UDP, ICMP, etc.
• Link o Enlace: un medio sobre el que los nodos se pueden comunicar en la

capa de enlace, es decir, la capa que está justo debajo de IP. Un ejemplo de
enlace sería Ethernet, X.25, Frame Relay...
• Interface o Interfaz: es la conexión de un nodo a un enlace.
• Neighbors o Vecinos: son los nodos conectados a un mismo enlace.
• Dirección: es un identificador de la capa IP para una interfaz o un conjunto

de interfaces.
• Paquete: es la cabecera IP junto al payload, es decir, junto a los datos a

enviar.
• Link MTU(Maximum Transmission Unit): es el tamaño máximo de los

paquetes que pueden ser manejados en un enlace.
• Path MTU: el path es la ruta que siguen los datos desde el host de origen al
de destino y el Path MTU es el valor de MTU que se puede utilizar a lo largo
de dicha ruta. Para no tener problemas en ningún punto, el valor a adoptar
debería ser el más pequeño de los MTU que aparezcan en el path.

2.1. La nueva cabecera

Entender la estructura de la cabecera de un protocolo y el tipo de información que se
puede transportar con la misma es el mejor camino para aprender a trabajar con un
protocolo.
Este conocimiento ayuda a identificar cómo se puede configurar el protocolo de la

mejor manera posible y qué opciones ofrece.
También ayuda a identificar posibles fuentes de problemas y soluciones de

problemas.
La estructura de la cabecera de un paquete IPv6 está especificada en la RFC 2460
Durante el diseño de IPv6 se ha analizado la cabecera IPv4, simplificándola y

eliminado aquello que era superfluo.
En la siguiente imagen se pueden comparar los campos de las dos cabeceras.
Como se puede ver, la cabecera IPv6 es mucho más simple que la de IPv4 y esto
acelera el procesamiento de los datos.
La cabecera IPv6 tiene una longitud fija de 40 bytes, organizados en dos grupos de
16 bytes para las direcciones de Origen y Destino y solo 8 bytes más para información
general.
En el siguiente punto se explican los motivos por los que se han eliminado ciertos
campos de la cabecera IPv4.
A continuación se analizarán los distintos campos de la cabecera IPv6.
Por último nos centraremos en el funcionamiento de las nuevas cabeceras de

extensión.
2.1.1. Limpieza en IPv4
Los 6 campos de IPv4 eliminados en IPv6 son: Longitud de la cabecera,

Identificación, Flags, Fragment Offset, Checksum de cabecera y Opciones.

A continuación se explican los motivos por los han desaparecido.
Longitud de la cabecera
En IPv4, la mínima longitud de cabecera es de 20 bytes, pero si se añaden opciones,

puede crecer en incrementos de 4 bytes hasta los 60 bytes. Por lo tanto, con IPv4 sí es
importante la información sobre la longitud de la cabecera.
En IPv6 las cabeceras tienen una longitud fija de 40 bytes, por lo tanto el campo
"Longitud de la cabecera" no tiene sentido.
El tema de las opciones se resuelve en IPv6 por medio de las cabeceras de

Extensión.
Identificación, Flags y Fragment Offset
Estos campos permiten gestionar la fragmentación de un paquete en IPv4.
La fragmentación tiene lugar cuando un paquete grande tiene que ser transmitido en
una red que sólo soporta paquetes más pequeños.
En ese caso, el router IPv4 trocea el paquete original en otros más pequeños y los
envía.
El host de destino los recoge y recompone el mensaje original.
Si se detecta que falta algún fragmento (aunque solo sea uno), hay que volver a
retransmitirlos todos.
Esta forma de actuar es muy poco eficiente.
Ya en IPv6, el host emisor utiliza un proceso llamado "Path MTU Discovery" para
saber el cuál es el mayor tamaño de paquete que se puede gestionar en el camino que
seguirán los datos desde el origen hasta el destino, esto es, en el Path. Esa información
es lo que se llama "Path MTU" (Maximum Transmission Unit).
Con esta información, el host emisor decide si hay que fragmentar el paquete o no.
En caso de tener que hacerlo utiliza la cabecera de Extensión correspondiente.

Debido a esto, no es necesario que los routers IPv6 proporcionen fragmentación

como se hacía en IPv4.
También por eso no hacen falta los campos de Identificación, Flags y Fragment
Offset en la cabecera IPv6. En caso de necesitar la fragmentación estos campos serán
insertados por el host origen en la correspondiente cabecera de Extensión.
Checksum de cabecera
Cuando se desarrolló IPv4, no era habitual el checksum a nivel de acceso al medio

(capa de enlace de datos), por lo que tenía sentido el campo de checksum en la cabecera
de IPv4.
Hoy en día, el riesgo de que lleguen a nivel de IP errores no detectados y paquetes

mal enrutados es mínimo.
En IPv6 se ha considerado que la responsabilidad de comprobar la integridad de los

datos debe recaer en las capas superiores.
Así, si subimos de la capa de red a la capa de transporte y nos fijamos en el

protocolo UDP, nos encontramos que el checksum que era opcional trabajando con IPv4
es obligatorio al trabajar con IPv6.
Al eliminar la comprobación del checksum en la capa de red, los routers no tienen

ya que comprobarlos ni actualizarlos y, de nuevo, se mejora la gestión de los paquetes.
Opciones
En IPv6 las opciones se manejan por medio de las ya mencionadas cabeceras de

Extensión, por lo que no son tratadas como un campo al uso.
2.1.2. Los campos bit a bit
Como se ha dicho antes, entender la función de los campos de la cabecera de un

protocolo, es fundamental para comprenderlo.
Version (4 bits)

Este campo de 4 bits contiene la versión del protocolo. Para IPv6 su valor es 6.
Traffic Class = Clase de Tráfico (1 Byte)
Este campo sustituye al "Type of Service" de IPv4. no obstante, su función es la

misma en los dos protocolos. De hecho la RFC que regula su funcionamiento es la
misma: RFC2474 ("Definition of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers"). En dicha RFC se usa el término “DS Field” (Differentiated
Services Field) para hacer referencia tanto al campo "Type of Service" de IPv4 como al
de “Traffic Class” de IPv6.
Por medio de este campo ("Traffic Class) los equipos que envían los paquetes y los
routers pueden identificar y distinguir distintas clases o prioridades de paquetes IPv6.
Gracias a este campo, algunos datos que requieran un tratamiento especial se pueden
manejar, en tiempo real, con mayor facilidad.
Flow Label = Etiqueta de flujo (20 Bits)
Este campo sirve para marcar paquetes que requieren un mismo tratamiento, de
forma que se facilita su manipulación en tiempo real.
El equipo emisor puede etiquetar secuencias de paquetes con un conjunto de

opciones.
Los routers pueden mantener bajo control los flujos y pueden procesar los paquetes
pertenecientes al mismo flujo de forma más eficiente porque no tienen que reprocesar
cada cabecera de paquete.
La “etiqueta de flujo” y la dirección de la fuente identifican el flujo de forma única.

A los nodos que no soportan las funciones del campo “Flow Label” se les pide que no
toquen dicho campo cuando reenvían un paquete y que lo ignoren cuando lo reciben.
Todos los paquetes pertenecientes al mismo flujo deben tener las mismas direcciones de
Origen y Destino.
La RFC3697 es la "IPv6 Flow Label Specification".
Payload Length = Longitud de carga útil (2 Bytes)
El PAYLOAD son los datos enviados después de la cabecera. En el campo "Payload

Length" se indica qué cantidad de datos están siendo enviados.
La forma de medir esta carga es distinta en IPv6 y en Ipv4.
En IPv4 el campo “Longitud” incluye la longitud de la cabecera IPv4, mientras que

el “Payload Length” de IPv6 contiene solo los datos que siguen a la cabecera IPv6. Las
cabeceras de Extensión también se consideran parte del Payload.
El hecho de que la longitud de este campo sea de 2 bytes, limita el tamaño máximo
del payload a 64KBytes. (2¹⁶ = 65536 Bytes = 64KB)
Los paquetes de tamaños mayores son soportados por IPv6 por medio de la cabecera
de Extensión "Jumbograma".
Los Jumbogramas se especifican en la RFC 2675 y cobran importancia sólo cuando

los nodos IPv6 están asociados a enlaces que tienen un enlace MTU mayor que 64KB.
Next Header = Siguiente cabecera (1 Byte)
En IPv4 este campo se llama “Protocol Type”. En IPv6 se ha renombrado porque

ahora la forma de organizar los paquetes es distinta, ya que se utilizan las llamadas
Cabeceras de Extensión que son explicadas en la siguiente sección.
Si la siguiente cabecera es UDP o TCP, este campo contendrá los mismos números
de protocolo que en IPv4 (TCP = 6, UDP = 17...)
En caso de que usen las cabeceras de Extensión de IPv6, este campo contiene el tipo
de la siguiente cabecera de Extensión.
Estas cabeceras de Extensión están localizadas entre las cabecera IP y la cabecera

TCP o UDP.
En la página www.iana.org/assignments/protocol-numbers se puede encontrar un

listado actualizado de los números asignados a los protocolos.
Hop Limit = Límite de Saltos (1 Byte)
Este campo es análogo al campo TTL (Time-To-Live) de IPv4. El campo TTL

contiene un número de segundos que indican cuánto tiempo puede permanecer un
paquete en la red antes de ser destruido. En IPv4, la mayoría de los routers simplemente
decrementan este valor en uno con cada salto.
En IPv6, este campo ha pasado a llamarse "Hop Limit". Su valor representa ahora el
número de saltos en lugar del número de segundos. Cada nodo retransmisor decrementa
este valor en uno. Si un router recibe un paquete con “Hop Limit” = 1, lo decrementa a
0, descarta el paquete, y envía al equipo emisor original el mensaje ICMPv6 “Hop Limit
exceeded in transit”.
Source Address =Dirección Origen (16 Bytes)
Este campo contiene la dirección IP del equipo que generó el paquete
Destination Address = Dirección Destino (16 Bytes)
Este campo contiene la dirección IP del destino del paquete.
Esta dirección puede ser la del destino final.
En caso de estar presente una cabecera de Enrutado, puede ser la dirección del
siguiente router.

2.1.3. Las cabeceras de Extensión
En la cabecera de IPv4, después de los campos de información general y de las

direcciones de origen y destino, y antes de los datos, se coloca en campo de "Opciones".
• Estas "Opciones" ocupan un máximo de 40 bytes y dan indicaciones a los

nodos que se encuentran en el camino (o path) que va del equipo origen al
destino, acerca de cuestiones relacionadas con seguridad, enrutamiento,
timestamping, etc. Concretamente, las opciones disponibles en IPv4 son:
• Crear un registro de la ruta.
• En el datagrama se van guardando las direcciones IP de los routers visitados.

Cada router intenta poner su dirección al final de la lista existente. Si la lista
está llena y no puede hacerlo, simplemente reenvía el datagrama sin añadir
su dirección.
• Marcas de tiempo (Timestamp).
• Seguridad básica del Departamento de Defensa.
• Permite asegurar que el origen del datagrama tiene autorización para ser
transmitido. Son opciones usadas por la NSA, la CIA...
• Seguridad extendida del Departamento de Defensa.
• Es una opción que permite a los departamentos antes mencionados hacer

configuraciones de seguridad específicas según sus necesidades.
• Sin operación (No Operation).
• Se usa como relleno entre opciones, para alinear la siguiente opción en un

marco de 16 o 32 bits.
• Fin de la lista de opciones.
En este caso se pretende rellenar el final del campo de opción para que el tamaño
total sea múltiplo de 32 bits.
En IPv4 no suelen utilizarse estas opciones porque ralentizan la transmisión.
En IPv6 las opciones se manejan por medio de las llamadas Cabeceras de Extensión
(Extension Headers). Estas cabeceras se insertan en el paquete solo si las opciones son
necesarias.
En la siguiente figura se pueden ver varios casos de utilización de cabeceras IPv6 y

cabeceras de Extensión.

En el primer paquete hay una única cabecera IPv6 que precede a los datos de la capa
superior de transporte.
En el segundo paquete se ha insertado una tercera cabecera entre las dos anteriores.
Ahora, la cabecera IPv6 indica que la siguiente cabecera es una cabecera de Extensión
del tipo Routing, cuyo código identificativo es el 43 y que se utiliza para dar una lista de
uno o más nodos que deben estar en la ruta seguida por un paquete.
En el campo Next Header de esa cabecera de Routing se indica ya que a

continuación van los datos de TCP.
En el tercer paquete se ha insertado una cabecera más. En este caso es una cabecera
de Extensión de Fragmento, cuyo código es el 44.
Como se puede ver los campos Next Header de las distintas cabeceras mantienen la
lógica explicada.
Podemos enumerar ya algunas cuestiones generales relativas a las cabeceras de

Extensión:
• En un paquete IPv6 puede haber cero, una o más cabeceras de Extensión.
• Estas cabeceras se sitúan entre la cabecera IPv6 y la cabecera del protocolo

de la capa superior (capa de transporte).
• Las cabeceras existentes deben ser procesadas en el orden exacto en que

aparecen en la cabecera del paquete.
• Cada cabecera de Extensión es identificada por el campo “Next Header” de

la cabecera precedente.
• Las cabeceras de Extensión son examinadas o procesadas solo por el nodo

identificado en el campo dirección de Destino de la cabecera IPv6...
• ... con una única excepción:

o Si la cabecera de Extensión es del tipo Opciones Hop-by-Hop, la

información que lleva debe ser examinada y procesada por cada uno
de los nodos que se encuentran en la ruta del paquete.
o Este tipo de cabecera debe seguir inmediatamente a la cabecera IPv6

y su valor de "Next Header" es 0.
• Si en el campo "Dirección de destino" hay una dirección multicast, las

cabeceras de Extensión serán examinadas y procesadas por todos los nodos
que pertenezcan al grupo multicast.
• La longitud de cada cabecera de Extensión es un múltiplo de 8 bytes de

forma que, independientemente del número de ellas que se utilicen, siempre
quedan alineadas.
Tipos de cabecera
Los 6 tipos de cabeceras de Extensión que se definen en la RFC 2460 son:
De opción Hop-by-Hop (RFC 2460).
La información de esta cabecera debe ser examinada Salto-a-Salto, es decir, en cada

uno de los nodos de la ruta que ha de seguir el paquete.
• De enrutado (RFC 2460). Se utiliza para dar una lista de uno o más nodos
que deben estar en la ruta seguida por un paquete.
• De fragmento (RFC 2460). Un host IPv6 que quiere enviar un paquete a un

destino IPv6 utiliza el llamado “Path MTU discovery” para determinar el
tamaño máximo de paquete que se puede utilizar en el path hasta ese destino.
Si el paquete que hay que enviar es más grande que el MTU soportado, el
host origen fragmenta el paquete. Gracias a esta forma de actuar, la
fragmentación se gestiona de extremo a extremo, liberando a los routers del
path de este trabajo. En caso de que el "Path MTU discovery" falle, se usará
el valor mínimo de "Path MTU" en IPv6, 1280 bytes. El valor máximo es de
65536 bytes, en los cuales se incluye la carga o payload del datagrama y los
40 bytes de la cabecera.
• De opciones de destino (RFC 2460). Estas cabeceras llevan información que

será procesada, exclusivamente, por el nodo de destino.
• De autenticación (AH) (RFC 4302). Proporciona integridad y autenticación

(que no confidencialidad) para todos los paquetes de datos IP. Soporta
distintos mecanismos de autenticación.

• De carga útil de seguridad encriptada (Encrypted Security Payload =ESP)

(RFC 4303). Proporciona integridad, confidencialidad, autenticacion de
datos y otras funciones para todos los paquetes de datos IP.
La flexibilidad de esta arquitectura permitirá el desarrollo de nuevas cabeceras de

Extensión en el futuro, a medida que sean necesarias. Lo bueno de este sistema es que
las nuevas cabeceras de Extensión se pueden definir y usar sin cambiar la cabecera
IPv6.
Orden de ejecución
Si se le pide a un nodo que procese la siguiente cabecera pero no identifica el valor

del campo “Next Header”, descartará el paquete y enviará un mensaje “ICMPv6
Parameter Problem” al equipo origen del paquete.
Según la RFC 2460, si en un paquete se usa más de una cabecera de Extensión, se

debería respetar el siguiente orden:
1. Cabecera IPv6.
2. Cabecera de Opciones Hop-by-Hop
3. Cabecera de opciones de destino (para opciones que tienen que ser

procesadas por el primer destino que aparece en el campo de dirección de
destino, además de los destinos posteriores enumerados en la cabecera de
Routing).
4. Cabecera de enrutamiento (Routing)
5. Cabecera de Fragmento.
6. Cabecera de autenticación (Authentication header).
7. Cabecera de carga útil de seguridad encapsulada (Encapsulating Security

Payload)
8. Cabecera de Opciones de Destino (para opciones a ser procesadas solo por el

destino final del paquete)
9. Cabecera de capa superior.
Cuando se encapsula IPv6 en IPv4, la cabecera de capa superior puede ser otra
cabecera IPv6 y puede contener cabeceras de Extensión que tienen que seguir las reglas
mencionadas.

2.2. Direccionamiento
Una vez analizados y aclarados los problemas de IPv4 en relación a la gestión de
direcciones y a la disponibilidad de las mismas, nos centraremos en el direccionamiento
de IPv6.
Capacidad de direccionamiento IPv6
Las direcciones utilizadas son de 128 bits, por lo que la capacidad de

direccionamiento es de 2¹²⁸.
Para entender de qué cantidad estamos hablando, un ejemplo:
Teniendo en cuenta que la superficie terrestre es de 510.065.284,702 x 10⁶ m²...
... con 2¹²⁸ direcciones podríamos asignar 667.134.927.874.467.426.204.012

direcciones IPv6 por m².
Parece suficiente para hacer frente a cualquier necesidad presente y futura.
Tipos de direcciones IPv6
El documento base que regula las direcciones y el direccionamiento es la RFC 4291.
Hay tres tipos principales de direcciones: las unicast, multicast y anycast.
Unicast: dirección para un único dispositivo. El paquete enviado a una dirección

unicast es recibido sólo por el propietario de la dirección.
Multicast: este es el sustituto del broadcast de IPv4. La diferencia entre broadcast y

multicast es que en el broadcast se envían paquetes a todos los equipos que se
encuentran en la misma subred y en multicast se envían paquetes solo a los equipos que
tienen la misma dirección multicast. Es una especie de broadcast controlado.
Anycast: es una dirección para varios dispositivos. Cuando se envía un paquete a

una dirección Anycast, se entregará al equipo más cercano que sea propietario de dicha
dirección.

Cuando trabajamos con IPv4 estamos acostumbrados a tener que asignar una
dirección IP del estilo 192.168.0.10 a la tarjeta de red de nuestro ordenador, y solo en
situaciones concretas tenemos varias direcciones IPv4 asignadas a nuestra interfaz de
red. Esto último ocurre, por ejemplo, cuando usamos "interfaces de red virtuales", las
cuales permiten, entre otras cosas, ofrecer distintos servicios de red en cada una de las
direcciones empleadas.
En IPv6 lo normal es que una tarjeta de red tenga varias direcciones asignadas. En la
RFC 4291 "IP Version 6 Addressing Architecture" se especifica cuáles son las
direcciones IPv6 que tiene que tener cada host.
• Su dirección de enlace local para para cada interfaz.
• Todas las direcciones unicast y anycast asignadas.
• La dirección de loopback.
• La dirección multicast All-nodes.
• La dirección multicast Solicited-node para cada una de sus direcciones

unicast y anycast.
• Las direcciones multicast de todos los grupos a los que pertenezca el host.
En apartados posteriores se analizarán las peculiaridades de los tipos y subtipos

mencionados.
Representación de las direcciones
Tienen una longitud de 128 bits y para su representación se organizan en 8 grupos

de 4 dígitos hexadecimales (8grupos x 4dígitosHex x 4bits = 128 bits).
Los grupos se separan con dos puntos (:).
Esto serían ejemplos de dirección IPv6:
ABFE:CD67:2143:6574:AFDE:DB87:6543:2109
2191:0:0:7:0:900:300B:528B
Como se puede ver, en la segunda dirección no aparecen 4 dígitos hexadecimales en

todos los casos. Esto es debido a que no hace falta representar los ceros que aparecen
más a la izquierda.
Pero el trato especial que reciben los ceros no termina aquí, de hecho, existe incluso
una "Notación abreviada para los ceros":

Si hay varias cadenas de 4 ceros hexadecimales, es decir, 16 ceros (...:0000:....), se

pueden sustituir por ::
Esta sustitución solo puede hacerse una vez en cada dirección.
Por ejemplo:
2191:6:0:0:0:700:311B:528D = 2191:6::700:311B:528D
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 = ::
En entornos mixtos en los que hay nodos IPv4 e IPv6 hay también un formato válido
que permite representar una dirección IPv4 como IPv6. Esto se hace poniendo
0:0:0:0:0:0 y a continuación la dirección IPv4. Hay que tener en cuenta que la
representación se puede hacer expresando la dirección IPv4 en decimal o en
hexadecimal y que también se puede emplear la notación abreviada. Teniendo todo esto
en cuenta, las siguientes notaciones son equivalentes:
0:0:0:0:0:0:192.168.44.1
::192.168.44.1
0:0:0:0:0:0:C0A8:2C01
::C0A8:2C01
2.2.1. Los prefijos
Notación de los prefijos
Esta notación está descrita en la RFC 4291 "IP Version 6 Addressing Architecture".
Un prefijo es un conjunto de bits (en la zona de mayor peso) en una dirección IPv6,
que se utiliza para identificar subredes o el tipo de dirección.
El nombre exacto que reciben estos bits es “prefijo de enrutado global”.
La notación de prefijo es muy similar a la forma en que se escriben las direcciones

IPv4 en notación CIDR (Classless Interdomain Routing), indicando detrás de la
dirección IP el número de bits que determinan el ID de la red (192.168.0.10/24 equivale
a una máscara 255.255.255.0):
En IPv6 tenemos:
Dirección IPv6 / Longitud del prefijo

El campo “Longitud del prefijo” especifica cuantos bits de la parte izquierda de la

dirección forman el prefijo.
Gracias al prefijo, los routers saben como dirigir los paquetes que les llegan hacia su
destino correcto en una subred determinada.
Un ejemplo, en la siguiente dirección IPv6, puesto que cada carácter hexadecimal

consta de 4 bits, el prefijo es la parte marcada en azul (10 caracteres hexadecimales):
2E78:DA53:1200::/40
La notación abreviada (sustitución de ceros con un doble “:”) se puede aplicar

también a la representación del prefijo, siguiendo las reglas ya explicadas.
Prefijos de enrutado global
En este enlace se puede ver cómo organiza la IANA los prefijos reservados y las
direcciones especiales (direcciones de enlace local, multicast...).
Vamos a comentar algunos de estos prefijos:
0000::/8 → Las direcciones que empiezan con 8 ceros están reservadas para la IETF.
2000::/3 → Direcciones Unicast Globales. Estas serán todas aquellas direcciones

cuyos 3 primeros dígitos binarios (los de mayor peso) sean 001.
Estas son las direcciones Unicast que gestiona la IANA. A efectos prácticos serían
como las direcciones públicas que venimos usando con IPv4.
FC00::/7 → Dirección Unicast Local Única (ULA = Unique Local Unicast

Address). Son direcciones cuyos 7 bits de mayor peso son 1111 110.
FE80::/10 → Dirección Unicast de Enlace Local. Aquellas cuyos primeros 10 bits

son 1111 1110 10.
FF00::/8 →Direcciones Multicast. Aquellas cuyos 8 primeros bits son 1.
En cuanto a las direcciones Anycast, se toman del rango de direcciones Unicast, por
lo tanto, no es posible saber si una dirección es Anycast tan solo con mirar su prefijo.
2.2.2. Dirección No Especificada y Dirección de Loopback
Vemos a continuación dos direcciones que se podrían catalogar como direcciones

especiales:
Dirección no especificada (Unspecified address)

Es la dirección 0:0:0:0:0:0:0:0 y también se le llama la dirección de “todo ceros”

(all-zeros address)
Se puede representar en notación abreviada como ::
Su función es la misma que la de la dirección 0.0.0.0 de IPv4: actuar como dirección

de origen cuando se solicita una configuración de arranque en un momento en que el
equipo solicitante no tiene una dirección válida. Esto ocurre, por ejemplo, cuando se
buscan servidores DHCP o BOOTP para pedirles la configuración de la interfaz de red.
Dirección de Loopback
Es la dirección 0:0:0:0:0:0:0:1, que en notación abreviada queda en ::1
Su función es la misma que la dirección 127.0.0.1 de IPv4: hacer referencia a la

interfaz de red local y permite hacer pruebas para determinar el buen funcionamiento de
la misma o de algún servicio ubicado en el equipo local.
2.2.3. Direcciones Unicast Globales
Estas son las direcciones que se reconocen a nivel global, por lo que, a efectos
prácticos, juegan el papel de las direcciones públicas IPv4.
Puesto que van a ser direcciones válidas a nivel global es lógico pensar que deben
estar controladas como lo están las IPs públicas de IPv4. En seguida veremos que es así.
Todas las Direcciones Unicast Globales tienen 001 en sus tres bits de mayor peso,
por lo que el prefijo es 2000::/3. Esto indica que si la dirección empieza tanto por 0010
(0x2) como por 0011(0x3), estaremos ante una dirección unicast global.
En la RFC 4291 se define el formato de estas direcciones.
Como se puede ver en la imagen, los 128 bits se descomponen en tres campos:
Prefijo de enrutado global (n bits).
Este prefijo limita el rango de direcciones asignado al sitio.

Para redes de tamaño pequeño y medio suele constar de 48 bits y es gestionado por
los servicios de registro internacionales y los ISPs.
La IANA (Internet Assigned Numbers Authority) es el organismo responsable de la

coordinación, a nivel mundial, del direccionamiento.
El reparto de direcciones se realiza de forma jerárquica y hay una entidad

responsable para cada región del mundo.
En la imagen se pueden ver los nombres de dichas entidades.
Fuente: http://www.iana.org/numbers
Aunque el prefijo para las direcciones unicast globales es 2000::/3, IANA solo
permite el uso de ciertos rangos. En este enlace se puede ver cuál es el reparto actual.
Todo el espacio de direcciones del bloque 2000::/3 no listado en la tabla anterior

está reservado por la IANA para una futura asignación.
Aparte de la asignación para cada uno de los servicios de registro internacionales,

hay también un rango reservado para la propia IANA.
Por ejemplo, el prefijo 2001::/23, que incluye el prefijo 2001:0000::/32 utilizado en

Teredo (RFC 4380: Tunneling IPv6 sobre UDP a través de NAT).
Igualmente aparece el prefijo 2002:0000::/16, utilizado para 6to4 (RFC 3056:

Connection of IPv6 Domains via IPv4 Clouds).
Identificador de Subred ((64 - n) bits).
El ID de Subred identifica un enlace dentro de un sitio. Puesto que normalmente n

= 48 bits, quedan un total de 16 bits para hacer subredes en la organización. Es decir,
una vez obtenido el prefijo de enrutado global, la organización puede descomponerse en
65.535 subredes.
Lógicamente, la gestión de este identificador es responsabilidad del administrador

local.

En caso de que la organización sea muy grande, puede solicitar un prefijo de

enrutado global de menos de 48 bits, de modo que pueda disponer de más espacio para
crear subredes.
Identificador de Interfaz (64 bits).
El Identificador de Interfaz identifica una interfaz en una subred y debe ser único
dentro de esa subred. Este identificador se puede configurar de varias maneras.
Configuración estática (Manual).
Autoconfiguración (Identificador de Interfaz basado en EUI-64).
Configuración dinámica (DHCPv6).
Identificador de Interfaz Pseudo-Aleatorio.
Identificador generado criptográficamente.
En el caso de la autoconfiguración EUI-64 (EUI = Extended Unique Identifier), se

consigue un identificador de interfaz único que se basa en la dirección MAC de la
propia interfaz (de ahí su exclusividad).
El procedimiento a aplicar para conseguir el identificador es sencillo. Se parte de la

MAC que tiene 48 bits y hay que agregarle 16 bits para alcanzar los 64 bits del
identificador de interfaz. Esto se hace dividiendo la MAC por el centro e insertando los
dígitos hexadecimales 0xff-fe.
00– 03 – cd – 39 – 2b – 42
00 – 03 – cd – ff – fe – 39 – 2b – 42
Para terminar hay que complementar el bit universal/local, que es el segundo bit de
menor peso en el primer byte (el de mayor peso). En este ejemplo el primer byte es
0000 0000, y complementando el bit marcado en rojo se convierte en 0000 0010, es
decir, 0x02. Por lo tanto el identificador de interfaz obtenido mediante
autoconfiguración es:
02 – 03 – cd – ff – fe – 39 – 2b – 42
2.2.4. Dirección Unicast de Enlace Local
En IPv4 las organizaciones utilizan direcciones IP privadas (RFC 1918) para

identificar a los nodos de sus redes.
Estas direcciones privadas no se utilizan nunca fuera de la organización, por lo que

para salir de la misma hace falta un mecanismo para mapear las direcciones IPv4
privadas con la dirección IPv4 pública disponible. Ese mecanismo es el NAT (Network
Address Translation).
Ya en IPv6, tenemos la "Dirección de Enlace Local" (Local-Link Address) que

funciona como una dirección IPv4 privada asignada automáticamente. Por ello, por ser
una dirección privada, no se enruta nunca, o lo que es lo mismo, no se envía a Internet.
En IPv4, cuando un equipo configurado para obtener su dirección de un servidor

DHCP no encuentra al servidor, toma una dirección del rango 169.254.0.0/16. Las
Direcciones de Enlace Local serían el equivalente a las direcciones IPv4 de la red
169.254.0.0/16. Estas Direcciones de Enlace Local se pueden utilizar en
Autoconfiguración, para Neighbor Discovery, en redes sin routers y para crear redes
temporales (por ejemplo, cuando se conectan dos equipos mediante un cable cruzado).
Por ser de uso privado, no necesitan un "prefijo de enrutado global", de hecho, en su

lugar se coloca el "prefijo de enlace local" FE80::/10. Por eso, todas las direcciones de
enlace local empiezan por FE80.
En la siguiente imagen, se puede ver dónde aparece la Dirección de enlace local en

un equipo con Ubuntu y en otro con Windows XP.
Como se puede ver en la captura de Ubuntu, hay una relación directa entre la MAC
de la tarjeta de red y la dirección de enlace local. El procedimiento mediante el que se
crea el Identificador de Interfaz a partir de la dirección MAC ha sido ya explicado al
hablar de las “Direcciones Unicast Globales”.

2.2.5. Dirección Unicast Local Única
Cuando se definió la Dirección de Enlace Local se hizo lo propio con la llamada

"Dirección de Sitio Local".
Con el tiempo, ese último término fue sustituido por el de "Dirección Unicast Local
Única" o simplemente "Dirección IPv6 Local". En inglés se suele usar el término ULA
(Unique Local Unicast Address).
En la RFC 4193 "Unique Local IPv6 Unicast Addresses" se puede encontrar la

descripción original de este tipo de dirección.
A pesar de que estas direcciones son únicas a nivel global, no deben ser enrutadas,
es decir, no deben ser utilizadas en comunicaciones fuera de los límites de la red
corporativa. Están diseñadas para ser usadas en local (dentro de sitios corporativos o
conjuntos de redes).
Las características de las Direcciones Unicast Locales Únicas son las siguientes:
Tienen un prefijo global único que facilita el filtrado en los límites de la red.
Permiten la interconexión de redes privadas sin que haya riesgo de que surjan
conflictos por direcciones duplicadas, lo cual implicaría la renumeración de una de las
redes.
No dependen de los ISPs.
Se pueden usar en comunicaciones internas sin conexión a Internet.
Si se enrutan accidentalmente a Internet, no surgen conflictos de direcciones
Pueden ser utilizadas por las aplicaciones del mismo modo que utilizan las
direcciones unicast globales.
El formato de estas direcciones se muestra en la siguiente figura:
El bit L puesto a 1 indica que la administración del prefijo es local.
Por ello, siempre que la administración sea local, el prefijo será FD::/8 (1111 1101).

Y esto está relacionado con el siguiente bloque de 40 bits, el IDENTIFICADOR

GLOBAL. Cuando la administración es local, este Identificador Global se crea
aplicando un algoritmo pseudo-aleatorio, que garantiza con una probabilidad altísima su
exclusividad.
Se parte de la hora y fecha del día en formato NTP (Network Time Protocol) de
64bits. NTP es un protocolo que permite sincronizar los relojes de equipos conectados a
Internet.
Se obtiene un identificador EUI - 64 a partir de la MAC.
Se concatenan los resultados obtenidos en (1) y (2).
Aplicar el algoritmo SHA-1 al resultado de (3) y tomar los 40 bits menos

significativos como Identificador Global.
2.2.6. Direcciones Anycast
En networking hay ocasiones en las que un servicio se ofrece por medio de varios
hosts o routers.
De este modo se consigue:
• Redundancia: el servicio no depende de un único servidor, de modo que si

un equipo falla, los demás asumen sus funciones y el servicio sigue
disponible.
• Balanceo de carga: los distintos servidores se reparten el trabajo de modo

que no haya un equipo sobrecargado (con la consiguiente merma de
rendimiento) y otro inactivo.
Cuando un usuario, aplicación o host quiere acceder al servicio, no le importa cuál

de los múltiples servidores que lo ofrecen le está atendiendo.
Las direcciones Anycast permiten esta forma de funcionamiento. Cuando un host

envía un datagrama a una dirección anycast, la infraestructura de red buscará el camino
más corto hasta uno, y preferiblemente solo uno, de los equipos que aceptan datagramas
dirigidos a la dirección anycast utilizada.
La gran ventaja del "Anycasting" es que simplifica la búsqueda del servidor más
apropiado (que suele ser el más cercano).
Realmente Anycast se planteó en la RFC 1546 (1993) como especificación

experimental para IPv4 y estaba destinado a ser utilizado para servicios tales como DNS
y HTTP.
Una forma de implementar el Anycast es usando el método llamado "Dirección

Unicast Compartida", que consiste en asignar direcciones unicast “normales” a

múltiples interfaces. Esto es lo que se usa, por ejemplo, en los servidores DNS raíz en
Internet.
Dentro de una red donde un grupo de routers puede proporcionar acceso a un

dominio de enrutamiento común, se puede asignar una dirección única a todos los
routers y cuando un cliente envía un paquete a esta dirección, será enviado al siguiente
router disponible.
Esto se utiliza en 6to4 (RFC 3068) y en Mobile IPv6.
También hay que ser conscientes de que al utilizar direcciones anycast, el emisor no
tiene control sobre cuál será la interfaz a la que se entregará el paquete, ya que esta
decisión se toma sobre el nivel del protocolo de enrutamiento.
Debido a esto pueden darse errores si un emisor envía varios paquetes a una
dirección anycast y los paquetes llegan a diferentes destinos. Lo mismo ocurre si hay
que establecer un diálogo con una serie de peticiones y respuestas o si hay que
fragmentar el paquete.
Como extensión a lo explicado, y ya en IPv6, la dirección anycast es una dirección

que se asigna a más de una interfaz (normalmente pertenecientes a distintos nodos).
Se sigue manteniendo que un paquete enviado a una dirección anycast es enrutado a

la interfaz más cercana con esa dirección anycast. La distancia es medida por los
protocolos de enrutado.
Las direcciones anycast están dentro del espacio de las direcciones unicast, por lo
que, sintacticamente, no se puede distinguir una dirección anycast de una unicast.
Cuando se convierte una dirección unicast en dirección anycast, asignando la

dirección unicast a más de una interfaz, los nodos que han recibido la dirección deben
ser configurados de modo que reconozcan la dirección anycast.
A modo de ejemplo, se muestra el formato de la "dirección anycast del router de la

subred" (subnet-router anycast address), que está predefinido y tiene el aspecto indicado
en la siguiente figura:
El "prefijo de subred" en una dirección anycast es el prefijo que identifica un enlace

específico.
Esta dirección anycast es sintácticamente igual que cualquier otra dirección unicast
de una interfaz del enlace, con el identificador de interfaz a cero.
Los paquetes enviados a la "dirección anycast del router de la subred" serán

entregados a un router de la subred.
Todos los routers están obligados a soportar las "direcciones anycast del router de la
subred" de todas las subredes en las que tiene conectada una interfaz.
2.2.7. Direcciones Multicast
Se las identifica fácilmente porque son direcciones que empiezan por 0xFF (es decir,
por 1111 1111, en binario).
Los nodos que se configuran con una dirección multicast determinada forman lo que
se llama un GRUPO DE MULTIDIFUSIÓN.
Un nodo puede pertenecer a varios grupos de multidifusión.
Cuando un paquete es enviado a una dirección de multidifusión, todos los miembros

del grupo procesan el paquete
En la siguiente figura se muestra el formato de las direcciones multicast:
Los primeros 8 bits (puestos a 1) identifican la dirección como multicast.
Los siguientes 4 bits se utilizan como flags y se definen así:
• El primer bit (O) debe ser cero y está reservado para un uso futuro.
• El segundo bit (R) indica si esta dirección de multidifusión incluye el

llamado Rendezvous Point (Punto de Encuentro).
Esto está relacionado con un problema detectado al realizar multicasting entre

dominios, y es que el protocolo utilizado (PIM - SM) no tiene forma de dar a conocer a
otros dominios de multidifusión cuáles son las fuentes de multidifusión disponibles.
En la RFC 3956 se define cómo codificar la dirección del Rendezvous Point (RP) en
una dirección de grupo multicast y el bit que estamos tratando indica si la dirección
lleva, o no, insertado el "Rendezvous Point". En los usos más habituales, esto no será
así y el bit valdrá 0.
El tercer bit (P) indica si esta dirección de multidifusión incluye información acerca
del prefijo (RFC 3306). Esto se utiliza para realizar la asignación dinámica de

direcciones multicast y se explica más adelante. Cuando no se envía información sobre

el prefijo, este bit se pone a 0.
El último bit del campo de Flags indica si la dirección está asignada de forma
permanente, esto es, si es una de las direcciones de multidifusión llamadas "Well-
known" (bien conocidas), por estar asignadas por la IANA (bit a 0). O se trata de una
dirección de multidifusión de carácter temporal (bit a "1").
La lista actualizada de dirección multicast asignadas está en este enlace
El campo “Scope” (= ámbito de aplicación) se utiliza para limitar el alcance de una

dirección de multidifusión. En función del valor asignado el ámbito puede ser de
interfaz local, de enlace local, de sitio local, global...
1 = nodo local
2 = link local
5 = site local
14 = global (Internet)
Por último, el campo "Identificador de grupo" sirve para delimitar el grupo

objetivo de los paquetes multicast enviados.
1 = all nodes (Scope = 1 ó 2). Con un valor de Scope = 2 nos permitiría enviar un
mensaje a todos los nodos del enlace local.
2 = all routers (Scope = 1, 2 ó 5)
Con todo lo dicho, podríamos utilizar, por ejemplo, la dirección FF02::1. Esta es la
dirección "Link Local All Nodes", con la cual podríamos enviar un paquete a todos los
nodos del enlace local. Esta dirección es la equivalente a la 255.255.255.255 de IPv4.
Otra dirección multicast que suele aparecer es la FF02::2, que es la dirección "Link
Local All Routers" y que nos permite comunicarnos con todos los routers que se
encuentran en el enlace local. Esto se usa, por ejemplo, cuando un nodo necesita
encontrar un router (mensajes "Router Solicitation" de ICMPv6) que le pueda informar
de cuál es la configuración de red que debe tomar.
Dirección multicast de "nodo solicitado" (Solicited-Node)
Es ésta una dirección que todos los nodos tienen que agregar para cada una de sus
direcciones unicast y anycast. Se usa en Neighbor Discovery y se describe en la RFC
4291.
En IPv4, las peticiones ARP se utilizan para encontrar la MAC del nodo con el que
nos queremos comunicar, a partir de la dirección IP del mismo. La búsqueda se hace
mediante mensajes de broadcast, que son examinados por todas las hosts del enlace.
Esto genera mucho tráfico y es una de las cuestiones que se hecha en cara a IPv4.
En IPv6, la resolución de la dirección MAC de una interfaz se realiza mediante el

envío de un mensaje Neighbor Solicitation a la dirección multicast de "nodo solicitado".
De este modo, sólo el nodo que tiene en propiedad esa dirección de multidifusión
examinará el paquete.
Esta dirección se forma tomando los 24 bits menos significativos de una dirección
IPv6 (la última parte del host ID) y añadiendo estos bits al prefijo Well-known
FF02:0:0:0:0:1:FF00:: / 104. Por lo tanto, el rango para direcciones multicast de nodo
solicitado va de FF02:0:0:0:0:1:FF00:0000 a FF02:0:0:0:0:1:FFFF:FFFF.
Por ejemplo, si un host tiene la dirección MAC 00-18-F8-29-F1-D7 y la dirección

IPv6 FE80::218:F8FF:FE29:F1D7, su dirección multicast de nodo solicitado será
FF02::1:FF29:F1D7.
Si este host tiene otras direcciones IPv6 unicast o anycast, cada una podría tener
asociada su propia dirección multicast de nodo solicitado.
Asignación dinámica de direcciones Multicast
La RFC 3306 extiende la arquitectura de la dirección multicast para hacer posible la

propagación de los prefijos unicast por medio de dichas direcciones.
Se basa en un formato modificado la dirección multicast que contiene información

de prefijo.
El objetivo de esta especificación es reducir el número de protocolos necesarios para

la asignación de direcciones multicast
El nuevo formato es el indicado a continuación:
En la especificación original, se utiliza el flag "T" para especificar si la dirección de

multidifusión es Well-known o temporal
En el formato extendido el flag "P" indica si la dirección muticast contiene un

prefijo (P = 1) o no (P = 0). En caso de que P = 1, el flag T también se pondrá a 1,
indicando que se trata de una dirección multidifusión temporal y no de una dirección
Well-known.
El campo de Scope tiene la misma función que en el caso anterior y el campo

Reservado vale 0 cuando P = 1.
Los siguientes 8 bits (PLen) especifican la longitud del prefijo en el campo de

prefijo.Si la longitud de prefijo es menor de 64 bits, los bits no utilizados en dicho
campo se pondrán a 0.
2.2.8. Direcciones de cada nodo
Aunque ya se comentó en la introducción al tema, es el momento de repasar las

distintas direcciones que nos podemos encontrar tanto en los hosts como en los routers.
Respecto a los hosts, podemos tener las siguientes:
• Su dirección de enlace local para para cada interfaz.
• Todas las direcciones unicast y anycast asignadas.
• La dirección de loopback.
• La dirección multicast de todos los nodos (all-nodes).
• La dirección multicast Solicited-node para cada una de sus direcciones

unicast y anycast.
• Las direcciones multicast de todos los grupos a los que pertenezca el host.
En cuanto a los routers, tienen que reconocer todas las direcciones anteriores, y las
siguientes:
• La dirección de anycast de subred-router para las interfaces para las que está
configurado para actuar como un router en cada enlace.
• Todas las direcciones anycast con las que el router ha sido configurado.
• La dirección multicast de todos los routers.
• Las direcciones multicast de todos los demás grupos a los que pertenece el
router.
2.2.9. Selección de direcciones por defecto
Como venimos comentando, la arquitectura de IPv6 permite asignar varias

direcciones de distinto tipo a una interfaz.
Cada vez más, será frecuente que los hosts soporten tanto IPv4 como IPv6.
Por todo ello, en las comunicaciones entre equipos de doble pila habrá que decidir
entre utilizar IPv4 o IPv6 e incluso, cuál de las direcciones IPv6 será la elegida.

Supongamos una situación en la que un cliente envía una petición DNS para un
servicio externo y recibe una dirección IPv6 global y una dirección IPv4 pública como
respuesta. Si este cliente tiene una dirección IPv4 privada y una dirección IPv6 global,
puede tener sentido utilizar IPv6 para acceder a este servicio externo. Pero si el cliente
tiene una dirección IPv6 de enlace local y una dirección IPv4 pública, elegirá la
dirección IPv4 para la conexión al servicio.
Estos son las situaciones y decisiones que tendrán que ser manejadas en un
escenario de redes mixtas con redes sólo-IPv4, redes sólo-IPv6 y redes con doble pila.
La forma en que se trata depende de la programación de la aplicación que están

usando el protocolo.
Los desarrolladores tienen que ser conscientes de ello y tratar de establecer

mecanismos para que sus aplicaciones se comportan de manera óptima en todos los
ambientes posibles.
La RFC 3484 "Default Address Selection for IPv6", define dos algoritmos generales,
uno para la selección de la dirección de origen y el otra para la selección de la dirección
de destino. Esta RFC debe ser soportada por todos los nodos IPv6, es decir, tanto por
host como por routers.
Los algoritmos especifican el comportamiento por defecto para los nodos IPv6, pero
no anulan las decisiones tomadas por las aplicaciones o protocolos de la capa superior.
Antes de enumerar las principales reglas hay que saber que las direcciones asociadas
a las interfaces tienen un tiempo de vida que indica hasta cuándo está dicha dirección
asociada a la interface. Mientras ese tiempo no haya expirado, la dirección se considera
"preferida". Una vez agotado el tiempo, y hasta que se libera totalmente la dirección, se
la considera "obsoleta" (deprecated) y se puede seguir utilizando, aunque no se
recomienda.
He aquí un resumen de las reglas más importantes:
• Son preferibles pares de direcciones del mismo ámbito o tipo (link-local,

global).
• Es preferible un ámbito pequeño para la dirección de destino(utilizar el

ámbito más pequeño posible).
• Es preferible una dirección preferida a una obsoleta.
• Las direcciones de transición (por ejemplo, direcciones ISATAP o 6to4) no

se utilizan si hay direcciones IPv6 nativas disponibles.
• Si todos los criterios son similares, son preferibles los pares de direcciones
con el prefijo común más largo.

• Para la dirección de origen, se prefiere un dirección global a una dirección

temporal.
• En situaciones de Mobile IP, se prefieren las direcciones “home” antes que

las “care-of”.
Las normas de la RFC 3484 se aplicarán cuando no haya otros criterios específicos.
La especificación también permite la configuración de una política que puede
reemplazar estos valores por defecto con combinaciones preferidas de direcciones de
origen y de destino.

2.3. Instalación y tipos de configuración de IPv6

La instalación de IPv6 establece una configuración básica en los adaptadores de red
de nuestro sistema operativo.
Para comprender mejor la instalación y configuración de IPv6 vamos a analizarlo en

dos apartados:
Instalación y configuración básica de IPv6.
Configuración avanzada de IPv6.
Estudiemos cada caso:
2.3.1. Instalación y configuración básica de IPv6:
La configuración de los interfaces de red es completamente automática. Aunque por

supuesto pueden existir, no es necesario ningún elemento externo como puede ser un
router, un servidor de direcciones o una configuración manual por parte del usuario. En
principio el adaptador de red intenta descubrir en la red “alguien” que pueda
suministrarle una dirección. Aunque nadie responda, la dirección local de enlace se
construye utilizando un algoritmo. Al igual que ocurría en IPv4 con las direcciones del
tipo. 169.254.X.X. En aquel caso, si la interfaz estaba configurada para obtener una IP
automaticamente pero no existía ningún servidor DHCP la interfaz obtenía una IP del
tipo 169.254.X.X. En IPv6 la dirección inicial configurada empezará siempre por
FE80::
Para entender mejor los conceptos teóricos vamos a realizar la instalación y

configuración básica de IPv6 utilizando los sistemas operativos más comunes (Ubuntu-
Linux, Windows XP, y Windows 7).
Veamos como se realiza la instalación en cada sistema operativo y analizemos la

configuración básica resultante con un ejemplo:
Instalación y configuración básica de IPv6 en Ubuntu-Linux (9.10)
Instalación y configuración básica de IPv6 en Windows XP (SP3)
Instalación y configuración básica de IPv6 en Windows 7
En general la configuración en otros sistemas operativos como Solaris o en otras

distribuciones de linux como Suse o Debian, es muy parecida.
2.3.1.1. Instalación y configuración básica de IPv6 en Ubuntu-Linux:
Aunque lo más normal en una red es poseer un servidor de direcciones o router, para
comenzar no contemplaremos ningún elemento externo, por tanto la configuración
inicial de las direcciones será automática (stateless) sin router ni sernvidor, y más

adelante contemplaremos la instalación de elementos que posibiliten los distintos tipos

de configuración, por ejemplo "stateful" (DHCPv6).
Tal y como veremos la dirección link-local en la configuración stateless sin router se

obtiene aplicando un algoritmo a la dirección física o MAC de cada interface.
En Ubuntu-Linux IPv6 está integrado y activo por defecto en el sistema operativo.
Por tanto sin hacer nada, si desde la terminal de comandos, ejecutamos el comando
ip addr show . El comando ip sustituye entre otros comandos a ifconfig que ha quedado
obsoleto. Veamos la respuesta que obtenemos en ambos casos:
En ausencia de un router, observamos que se instalan 2 interfaces.
Interfaz Local Loopback o lo: Es la dirección local, ::1 , similar a 127.0.0.1 en IPv4.
Interfaz eth0 : fe80::213:d4ff:fe27:4680 Dirección Link-Local preferida. Es la

dirección preferida en nuestro caso. Se obtiene usando el prefijo fe80 (predeterminado
para direcciones locales de enlace), y a continuación, se aplica un algoritmo

(especificado en RFC 4291) a la dirección MAC 00:13:D4:27:46:80 de nuestro
adaptador. Veamos el algoritmo aplicado en nuestro caso de forma gráfica:
Como sabemos de la teoría, el algoritmo consiste en introducir FFFE entre el tercer

y cuarto byte y complementar el bit universal.
Una vez analizados los interfaces instalados automaticamente para determinar el

correcto funcionamiento podemos utilizar el comando ping6 a las siguientes
direcciones.
ping6 ::1
ping6 al link-local

En el segundo caso, cuando se trata de hacer ping utilizando IPv6 a direcciones

locales de enlace, es necesario utilizar la opción -I para especificar el interface a utilizar.
Los resultados obtenidos son satisfactorios.
2.3.1.2. Instalación y configuración básica de IPv6 en Windows XP:
Antes de nada al contrario de lo que sucede en las últimas versiones de Ubuntu-

Linux o en Windows 7, en Windows XP el protocolo IPv6 no es nativo y primero
deberemos instalarlo.
Instalación de ipv6 en Windows XP, SP3:
Para la instalación se ha venido utilizado el comando "ipv6.exe" desde la consola de

comandos.
Para desinstalar:
Sin embargo, desde hace unos años y para el uso y configuración del entorno y
conexiones de red Microsoft aconseja el uso del comando "netsh" dentro de la consola
de comandos.

Cada opción de ipv6 es sustituida por otra en netsh, profundizaremos en el uso de

netsh más adelante.
Por tanto, para realizar la instalación en lugar de ipv6.exe install, se recomienda:
La instalación también puede hacerse utilizando el modo gráfico.
Inicio--> Mis sitios de red --> Ver conexiones de red--> Configuración de area local
-->Botón derecho --> Propiedades
Pulsamos Instalar

Marcamos TCP/IP versión 6 y pulsamos aceptar.
Cada vez que instalamos y desinstalamos en XP conviene reiniciar el ordenador.
Una vez concluida la instalación, para obtener la información, podemos usar:
ipconfig

o ipconfig /all

o podemos usar el entorno netsh y sus comandos, por ejemplo, para ver la
información IPv4:
La dirección IPv4 y la puerta de enlace han sido establecidas manualmente.
En el caso de IPv6 que estamos analizando:
En nuestro caso observamos que se instalan 4 interfaces:
Interfaz 1 o Loopback: Es la dirección local, ::1 , similar a 127.0.0.1 en IPv4.
La interfaz 2 y 4 corresponden a mecanismos de transición que están siendo

adaptados y en algunos casos quedan obsoletos y su implementación depende del
creador de cada sistema operativo, en el caso de Microsoft para XP se usa la
tunelización automática y Teredo. Se instalan para permitir el uso de IPv4 e IPv6 en la
misma red.
Interfaz 2 de Tunelización automática: fe80::5efe:192.168.0.13 utilizada para

garantizar la compatibilidad de IPv4 e IPv6. Se compone de un prefijo fe80
(especificado para direcciones locales de enlace) . 00005efe determina (corresponde al

protocolo ISATAP) que a continuación se utilizará una IPv4 privada.
Interfaz 4 Tunel Teredo: fe80::ffff:ffff:fffd es utilizado como mecanismo de

transición entre IPv4 e IPv6 cuando se utiliza NAT.
Interfaz 5 : fe80::205:1cff:fe13:a63c Dirección Link-Local preferida. Es la dirección

preferida en nuestro caso. Se obtiene usando el prefijo fe80 (predeterminado para
direcciones locales de enlace), y a continuación, se aplica un algoritmo (especificado en
RFC 4291) a la dirección MAC de nuestro adaptador. Veamos el algoritmo aplicado en
nuestro caso de forma gráfica:
Como hemos podido observar al hacer ipconfig /all la dirección MAC de nuestro
adaptador es:
00-05-1C-13-A6-3C. A continuación detallamos de forma gráfica el algoritmo

utilizado:
Como sabemos de la teoría, el algoritmo consiste en introducir FFFE entre el tercer

y cuarto byte y complementar el bit universal.
Una vez entendida la instalación de IPv6 y su resultado en XP para determinar el

correcto funcionamiento podemos utilizar el comando ping a las siguientes direcciones.
ping ::1
ping al link-local

o ping6 ::1
Para terminar también podríamos hacer ping6 a la dirección local configurada con el
siguiente formatu:
ping6 direcciónipv6local%interfaceautilizar
en nuestro caso escribiríamos en la interfaz de comandos:
ping6 fe80::205:1cff:fe13:a63c%5
La interfaz responderá satisfactoriamente.
De esta forma tan sencilla, hemos incorporado IPv6 a nuestra red local usando
Windows XP.
2.3.1.3. Instalación y configuración básica de IPv6 en Windows 7 :
En Windows 7 ipv6 está integrado y activo por defecto en el sistema operativo.

Microsoft desaconseja desactivar ipv6 pues esto podría acarrear el mal funcionamiento
de algunas aplicaciones.
Por tanto sin hacer nada, si desde la interfaz de comandos, ejecutamos ipconfig
observaremos la configuración existente:

o ipconfig /all
Utilizando netsh podemos ver los interfaces ipv6 instalados por defecto:

En nuestro caso observamos que se instalan 4 interfaces:
Interfaz 1 o Loopback: Es la dirección local, ::1 , similar a 127.0.0.1 en IPv4.
La interfaz 12 y 13 corresponden a mecanismos de transición que están siendo

adaptados y en algunos casos quedan obsoletos y su implementación depende del
creador de cada sistema operativo, en el caso de Microsoft para Windows 7 se usan
Isatap y Teredo. Se instalan para permitir el uso de IPv4 e IPv6 en la misma red.
Interfaz 12 de Tunelización automática: fe80::5efe:192.168.0.15 utilizada para

garantizar la compatibilidad de IPv4 e IPv6. Se compone de un prefijo fe80
(especificado para direcciones locales de enlace) . 00005efe determina (corresponde al
protocolo ISATAP) que a continuación se utilizará una IPv4 privada.
Interfaz 13 Tunel Teredo: fe80::100:7f:fffe es utilizado como mecanismo de

transición entre IPv4 e IPv6. Esta ACTIVO y conectado a internet puede obtener una
dirección global del tipo 2001::/32
Interfaz 11 : Conexión de área local: fe80::e8e0:544c:1875:1c4 Dirección Link-

Local preferida. Es la dirección preferida construida por Windows 7 en nuestro caso.
Una de las controversias en Windows Vista, Server 2008 y Windows 7 es la

utilización del algoritmo de creación de direcciones elegido por Microsoft. Como
vimos anteriormente en Windows XP el algortimo utilizado dependía de la dirección
MAC del adaptador de red. La creación de dicha dirección IPv6 viene determinada en
los RFC 2373 y RFC 2464. Posteriormente, para garantizar la privacidad del usuario se
definió RFC 4941. Windows 7 por defecto NO utiliza EUI-64 para formar la
dirección. Microsoft se ha desmarcado y por defecto utiliza un algoritmo aleatorio para
la creación de direcciones. Por supuesto, Microsoft permite activar o desactivar el uso
de dicho algoritmo especial mediante los siguientes comandos:

netsh interface ipv6 set global randomizeidentifiers=disabled
netsh interface ipv6 set global randomizeidentifiers=enabled
Una vez entendida la instalación de IPv6 y su resultado en W7 para determinar el

En Windows 7 el comando ping viene preparado para usarse con IPv6. Si

analizamos la ayuda del comando ping mediante ping /? incluso podemos forzar el uso
de IPv6 con la opción -6
ping ::1
ping al link-local
Como hemos visto en Windows XP, podemos hacer ping a la dirección local de
enlace, indicando el número de interface tras el símbolo %
2.3.2. Configuración avanzada de IPv6:
La configuración avanzada requiere de un elemento configurador ( router y/o

servidor ) de direcciones o de la intervención manual del usuario en la configuración.
Será analizada con mayor profundidad más adelante. Básicamente puede analizarse
estudiando tres técnicas que resumimos a continuación:

2.3.2.1. Configuración Stateless con router:
El PC IPv6 construye su dirección IPv6 basándose en el paquete “Router

Advertisement” que envía el router IPv6 conectado al mismo segmento de red donde
está conectado el PC. Por ejemplo el router puede estar configurado para establecer un
prefijo a las direcciones IPv6.
2.3.2.2. Configuración automática DHCPv6:
Con DHCPv6 un PC IPv6 puede recibir una dirección IPv6 además de otros
parámetros de configuración. Esta opción puede establecerse utilizando un servidor o un
router que pueda ejercer de tal. Un uso común de DHCPv6 para PCs es recibir y
configurar automáticamente la dirección IPv6 de los servidores DNS, los cuales no se
reciben a través del paquete “Router Advertisement” que envían los routers IPv6 de la
red. El paquete “Router Advertisement” que recibe un PC durante la fase del
descubrimiento de routers contiene un campo que indica si se va a utilizar también
DHCPv6 para configurar la dirección IPv6.
2.3.2.3. Configuración manual de la dirección:
Un PC IPv6 típico no necesita configurar manualmente su dirección IPv6. Este

método está orientado a servidores y/o routers IPv6. Sin embargo en caso necesario, la
configuración manual es muy sencilla y como es habitual en los sistemas operativos
puede hacerse de forma gráfica o mediante la interfaz de comandos.

2.4. Ordenes básicas en GNU/Linux y Windows

El desarrollo del protocolo IPv6 requiere la adecuación de los comandos que
utilizamos para la configuración y gestión de nuestras redes TCP/IP. Los comandos
ping o traceroute han sido adecuados no sabemos si temporal o definitivamente para el
uso de IPv6, pudiendo usar además de ping, ping6 o traceroute6 como alternativa de
traceroute, indicando en ambos casos que las direcciones utilizadas pertenecen a IPv6.
Además, el aumento de posibilidades a la hora de ver, administrar, modificar y

diagnosticar nuestras redes han requerido la administración más centralizada de dichas
posibilidades. Durante mucho tiempo hemos venido utilizando comandos, como
ifconfig (en Linux) o ipconfig (en Windows). Aunque en la mayoría de distribuciones y
versiones dichos comandos siguen siendo válidos, poco a poco muchas de las funciones
están siendo incorporadas dentro del comando ip (en Linux) o de netsh (en windows).
Tanto ip como netsh permiten una administración más centralizada de las diferentes
opciones en la configuración de nuestras redes. Aunque el estudio de las diferentes
posibilidades de dichos comandos debe analizarse en un contexto más amplio, en está
sección vamos a analizar algunas de sus opciones básicas, siempre dentro del contexto
de direccionamiento IPv6 que estamos estudiando. La adecuación al nuevo
direccionamiento IPv6 puede valernos para de paso, sustituir el uso de los anteriores
comandos por las nuevas opciones.
Vamos a analizar algunas de dichas opciones tanto en Ubuntu-Linux como en

Windows:
Ordenes básicas en Ubuntu-Linux
Ordenes básicas en Windows
Para un estudio más profundo de iproute2 o netsh es necesario acudir a las diferentes
manuales de ayuda
2.4.1. Ordenes básicas en Ubuntu-Linux
Para el uso de IPv6 en Linux algunos comandos han sido adecuados. Veamos:
ping6: Para el controlar el estado de la conexión de dispositivos IPv6 se utiliza el

comando ping6 que sustituye al comando ping utilizado para IPv4. Ping6 contiene las
siguientes opciones:

traceroute6: Es la versión IPv6 para traceroute. Su sintaxis

es:
Nuevas utilidades dentro de iproute2:
El paquete utilizado en Ubuntu-Linux para el control de TCP y UDP en redes IP se

llama iproute o iproute2. Muchos manuales de configuración de redes todavía se
refieren a comandos incluidos anteriormente en las denominadas net-tools de Unix,
como ifconfig y route y aunque hoy en día dichos comandos funcionan en la mayoría de
distribuciones su uso está siendo sustituido por nuevos comandos.
iproute2 es un paquete de utilidades desarrollado por Alexey Kuznetsov. Viene

incorporado en las versiones de núcleo posteriores a la 2.2. Contiene un conjunto de
herramientas muy potentes para administrar interfaces de red y conexiones en sistemas
Linux.
iproute2 contiene principalmente dos nuevos comandos:
ip : Controla la configuración de IPv4 e IPv6.
tc (traffic control): Controla el tráfico.
Comando ip:
Algunos ejemplos de las nuevas opciones son:
COMANDO NUEVO
DESCRIPCIÓN
ANTERIOR COMANDO
Configuración de direcciones y ifconfig ip addr

enlaces
ip link
Tablas de rutas route ip route
Vecinos o Neighbors arp ip neigh
Tuneles iptunnel ip tunnel
Multicast ipmaddr ip maddr
Observamos que iproute2 unifica la sintaxis de los comandos. La nueva sintaxis es

más simple y más consistente.

Para facilitar el uso, los comandos pueden también ejecutarse sin introducir un
espacio a continuación del comando ip, es decir:
# iproute (lo que sea) En lugar de :
# ip route (lo que sea)
En definitiva, la sintaxis del comando ip sería:
ip [ OPCIONES ] OBJETO [ COMANDO [ ARGUMENTOS ]]
Graficamente:
Donde cada objeto viene definido como:
Objeto Descripción
Maneja toda la información asociada con la interfaz: si está

levantado o caído, direcciones MAC locales, soporte de
link
multicast, si está en modo promiscuo o no, MTU, nombre de
las interfaces, etc
addr Maneja la asignación de direcciones IP a las interfaces.
route Maneja las tablas de rutas del sistema
Permite las definición de reglas en tablas para su uso por el

rule
sistema de rutado.
neigh Maneja las tablas ARP del sistema
tunnel Maneja la creación de túneles entre sistemas
maddr Maneja las direcciones multicast
mroute Maneja el caché de rutado multicast del sistema
monitor y rtmon Monitorizar diversos objetos del sistema

Veamos algunos EJEMPLOS aplicables a IPv4 o IPv6:
DESCRIPCIÓN COMANDO NUEVO

ANTERIOR COMANDO
Para ver la información sobre los ifconfig –a ip link show

interfaces y direcciones IP ip addr show
Ver la tablas de rutas route o netstat -nr ip route show
Ver la tabla arp arp –na ip neigh ls
ifconfig eth0 up ip link set dev

Activar dispositivos de red
eth0 up
Comando tc:
El comando tc (traffic control) forma parte del nucleo o kernel y se utiliza para
controlar el tráfico. Al formar parte del núcleo no es solamente un “analizador” de
puertos. Permite un control total.
Permite definir diferentes objetos y su sintaxis es bastante compleja. Por ejemplo

podríamos querer gestionar el ancho de banda de un acceso corporativo. Para ello
definiríamos clases dentro de un objeto ( por ejemplo anchos de banda de 1 Mbps,
256Kbps y 24Kbps ) y luego aplicaríamos filtros de uso. El objeto de estos apuntes es
introducir el uso del comando tc en el entorno de direccionamiento IPv6 y no
profundizar en su uso, por tanto, ahora simplemente indicaremos su sintaxis y algún
ejemplo. Si se tiene interes en un estudio más completo existe documentación y
ejemplos en internet. Por ejemplo en Traffic Control HOW To de Martín A. Brown.
http://tldp.org/HOWTO/html_single/Traffic-Control-HOWTO/
Debido a la complejidad de su sintaxis, existe un comando denominado tcng (traffic

control next generation) que incorpora toda la potencialidad de tc pero con una sintaxis
más sencilla.
En definitiva, la sintaxis del comando tc sería:
tc [ OPCIONES ] OBJETO { COMANDO | AYUDA }
Graficamente:

Donde cada objeto viene definido como:
Objeto Descripción
Queueing discipine, generalmente define una especie de

qdisc
caja negra que es capaz de encolar y desencolar paquetes.
Sólo existe dentro de qdisc, y se utiliza para determinar

class
sus características, (HTB, CBQ)
Es el elemento más complejo del control de tráfico, su uso

filter
más habitual es clasificar los paquetes.
action Permite definir diferentes acciones.
monitor Permite monitorizar el tráfico.
Veamos algunos EJEMPLOS:
DESCRIPCIÓN COMANDO
Para listar las reglas tc -s qdisc ls dev eth0

existentes
Agregarle 20ms de espera al tc qdisc add dev lo root handle 1:0 netem delay
dispositivo de retorno (para 20msec
hacer pruebas)
Quitar la espera agregada tc qdisc del dev lo root

antes.
Para borrar todas las reglas tc qdisc del dev eth1 root
Podríamos comprobar el retardo haciendo ping6 a la interfaz antes y después de la

aplicación de la regla de tráfico.
Veamos un segundo ejemplo más completo para la gestión del ancho de banda:
Obviamente esto es válido para direcciones IPv4 e IPv6. En el caso de IPv6 en el

paso 4 podríamos utilizar iptables6 en lugar de iptables.

# /sbin/tc qdisc del dev eth1 root

(Borramos todas la reglas para eth1)
#/sbin/tc qdisc add dev eth1 root handle 1:0 htb

default 10
(Defininimos la disciplina)
Vamos a crear una regla # /sbin/tc class add dev eth1 parent 1:0 classid 1:10
para el control del tráfico de htb rate 512kbps ceil 640kbps prio 0
(Definimos características de la clase)
salida HTTP para la interfaz
eth1. Permitimos un ancho de
banda de 512Kbytes y un # /sbin/iptables -A OUTPUT -t mangle -p tcp --sport
80 -j MARK --set-mark 10
máximo de 640Kbytes para el
(Asignamos el puerto a la clase)
puerto 80
# /sbin/service iptables save

(guardamos iptables)
# tc filter add dev eth1 parent 1:0 prio 0 protocol ip

handle 10 fw flowid 1:10
(Asignamos el filtro al qdisc)
2.4.2. Ordenes básicas en Windows
Aunque en Windows prevalezca la configuración desde el entorno gráfico (En

Windows 7 las opciones de IPv6 pueden configurarse graficamente), vamos a analizar
algunas ordenes básicas en windows
Los comandos en windows para IPv6 varían en función de la versión de Windows

que usemos.
ping: Para IPv6 en Windows XP se utiliza el comando ping6. Sin embargo, en

posteriores versiones de Windows, por ejemplo en Windows 7 el comando ping
incorpora opciones para IPv4 o IPv6. Veamos un ejemplo:

Observamos como existe una opción -6 para forzar el uso de IPv6.
Tracert: Ocurre lo mismo. Windows XP incorpora tracert6 mientras que Windows

7 incluye las opciones para IPv6 dentro del mismo comando. Veamos la ayuda en
Windows 7:
Además, para Windows XP mucha de la documentación existente se refiere al uso

del comando IPv6 definido en el ejecutable IPv6.exe. Por ejemplo para instalar IPv6 en
XP:
Ipv6.exe install
Sin embargo, para facilitar la administración y gestión de redes, al igual que ocurre
con el comando ip en Linux, Microsoft ha desarrollado un entorno para la configuración
de redes englobado dentro del comando netsh (net shell o entorno para redes). Netsh
engloba características tanto para IPv4 como para IPv6. Sin embargo, al profundizar en

el estudio de IPv6 podemos de paso aprovechar para generalizar el uso de netsh en lugar
de los comandos más utilizados hasta ahora como pueden ser ipconfig, route o netstat.
Veamos más en detalle el uso de netsh:
Netsh:
Netsh es una utilidad de línea de comandos que nos ofrece varias opciones para la
configuración de una red.
Entre las principales opciones que se pueden realizar, están la posibilidad de ver,
modificar, administrar y diagnosticar la configuración de una red.
En la línea de comandos podemos escribir los comandos netsh completos o podemos

entrar en el entorno de netsh, y el prompt cambiará a:
C:\>netsh
netsh>
Escribiendo, por ejemplo: interface obtenemos netsh interface> y así con todas las
opciones, podemos usar .. para subir de nivel.
Para obtener ayuda sobre el comando:
C:\>netsh /?
O estando dentro de netsh:
netsh>?
netsh>exit
Para salir.
Algunos Ejemplos
Guardar la configuración actual de

netsh dump > C:\MiRed.cmp
una red
Rescatar una configuración guardada netsh exec C:\MiRed.cmp
Activar Firewall en XP netsh firewall set opmode enable
Desactivar Firewall en XP netsh firewall set opmode disable
Instalar IPv6 netsh interface ipv6 install
Desinstalar IPv6 netsh interface ipv6 uninstall

Restablecer configuraciones de IPv4 netsh interface ipv4 reset
Reinicia las interfaces IPv6 netsh interface ipv6 renew
Restablecer configuraciones de IPv6 netsh interface ipv6 reset
Mostrar las direcciones IPv6 netsh interface ipv6 show address
netsh interface ipv6 add address

Agregar una dirección IPv6
direcciónIPv6
Observamos como a continuación de netsh interface, somos nosotros los que

podemos determinar si lo que nos interesa es actuar sobre direcciones ipv4 o ipv6.
Las opciones de netsh son muchas. Veamos por ejemplo la ayuda que obtenemos en
Windows7:
Por ejemplo para la configuración relativa a interfaces, escribimos: netsh interface o

netsh in en su formato abreviado.
Y observamos las opciones que podríamos ejecutar.
Veamos algunos para IPv6:
Muestra todas las interfaces IPv6 y

netsh in ipv6 show interface
su estado
Muestra las rutas definidas netsh in ipv6 show routes
Muestra entradas en cache de

netsh in ipv6 show neighbors
vecinos
Muestra el estado del tunel Teredo netsh in ipv6 show teredo
Muestra el estado de 6to4 netsh in ipv6 6to4 show state

2.5. Pruebas de conectividad en LAN (ping6)

Para completar el análisis práctico de la configuración stateless estudiada en la
teoría vamos a analizar el comportamiento en una red de área local o LAN sin
Router:
El esquema de la configuración a analizar es el siguiente:
Como hemos visto anteriormente los sistemas operativos actuales mantienen la

configuración IPv4 e IPv6. En caso de ausencia de un servidor o router la configuración
IPv6 se realiza de forma automática.
Conectamos los ordenadores en red utilizando un Switch IPv4 del fabricante D-

Link, es obvio indicar que podríamos utilizar cualquier otro que dispongamos. Esto es
debido a que los sistemas operativos actuales mantienen una pila dual IPv4/IPv6, que
permite al sistema operativo el uso y la coordinación de ambos tipos de direcciones.
Vamos a observar que ocurre si hacemos ping utilizando las direcciones IPv6 entre
todos los ordenadores.
Desde el Host con Windows XP a Windows 7:

Parece que no puede hacer ping, pero este error no debe llevarnos a engaño. La
configuración es correcta. No responde al ping porque por defecto Windows 7 incorpora
un Firewall que por defecto no responde a los ping realizados desde otro Host, en este
caso el nuestro.
Vamos al Host con Windows 7 y desactivamos el firewall o agregamos una regla

que permite responder al ping. Probamos de nuevo:
Responde satisfactoriamente.
Desde el Host con Windows XP a Ubuntu-Linux:
También responde satisfactoriamente.
Desde el Host con Ubuntu-Linux a Windows XP:

La respuesta es satisfactoria.
Desde el Host con Ubuntu-Linux a Windows 7:
Sin problemas.
Desde el Host con Windows 7 a Windows XP:
En este caso utilizamos la opción -6 que permite al comando ping (en Windows 7)
forzar el uso de IPv6.
Desde el Host con Windows 7 a Ubuntu-Linux:

La configuración automática funciona correctamente. El control dual que ejercen los

sistemas operativos, permite el uso de ambos protocolos sobre una red local (LAN)
creada usando un switch IPv4. En nuestro caso el switch es un modelo D-Link DES-
3526, pero podría valer cualquier otro switch del que se disponga.
Un aspecto muy importante a tener en cuenta en IPv6 es que las direcciones locales
de enlace, es decir todas las que comienzan por FE80:: no son enrutables fuera de
nuestra red de área local. Por ello, como veremos más adelante, las tarjetas de red
pueden tener más de una dirección.
En el caso de querer poder acceder a una interfaz concreta desde dentro y también
desde fuera de nuestra red local, deberá configurarse una segunda dirección. Para ello
puede utilizarse un router y/o un servidor o puede añadirse una dirección manualmente
utilizando comandos del sistema operativo como veremos posteriormente.

3. Configuración avanzada.
Hasta aquí hemos tratado cuestiones generales sobre IPv6, tanto desde el punto de
visto del protocolo en si, como desde el punto de vista de distintos sistemas operativos.
A continuación nos centraremos en aspectos más avanzados de la configuración de

IPv6. Empezaremos analizando el protocolo ICMPv6, que sustituye al ICMP de IPv4.
Este protocolo, que para los nos iniciados puede ser desconocido, proporciona una de
las herramientas más populares en el mundo del networking: el comando ping.
Analizaremos cuáles son los mensajes que se intercambian los ordenadores al hacer uso
de ICMPv6 para pasar, a continuación, a analizar las opciones de autoconfiguración que
nos ofrece IPv6.
Dentro de la autoconfiguración tenemos dos variantes, la llamada Stateless y la que

se basa en DHCPv6 (sustituto del DHCP de IPv4) que hasta septiembre de 2007
(momento en que apareció la RFC 4861) era denominada configuración Stateful.
La autoconfiguración es una característica que, en breve, puede convertirse en una

de las más importantes de IPv6, ya que permite que cualquier equipo disponga de una
dirección IPv6 con la que poder comunicarse con su entorno de red, y sin necesidad de
tener que hacer ningún tipo de configuración manual. Si tenemos en cuenta las
predicciones, con televisores, frigoríficos, consolas, móviles... con capacidad de
conexión, no cabe duda de que la autoconfiguración de IPv6 va a facilitar bastante la
vida tanto a los usuarios como a los administradores de red.
3.1. ICMPv6.
Todo el mundo conoce el comando ping y su uso para comprobar si hay
conectividad entre dos equipos. Lo que no suele resultar tan familiar es el protocolo que
está detrás del ping, esto es, el ICMP (Internet Control Message Protocol).
Dicho protocolo, ya en su versión de IPv4, proporciona información importante

sobre la salud de la red por medio de mensajes. La versión de ICMP utilizada en IPv6 se
llama, como no podía ser de otro modo, ICMPv6.
Aunque los dos protocolos tienen un nombre parecido y comparten su filosofía de

funcionamiento, hay que tener en cuenta que son incompatibles entre si debido a la
estructura de las datos empleados.
ICMPv6 es mucho más potente que la versión anterior ya que se han integrado en el
mismo funcionalidades que se lograban en ICMPv4 usando otros protocolos. Por
ejemplo:
• IGMP (Internet Group Management Protocol) para gestión de miembros de

los grupos multicast.

• ARP/RARP (Address Resolution Protocol / Reverse ARP) para mapear

direcciones MAC con direcciones IP y viceversa.
También se ha añadido la función Neighbor Discovery, para descubrir las

direcciones de los host vecinos (conectados en el mismo enlace), routers, etc.
El número de mensajes disponibles es mayor en ICMPv6 que en ICMP (de ahí

también la incompatibilidad).
El protocolo ICMPv6 está definido en la RFC 4443 y Neighbor Discovery lo está en

la RFC 4861.
A continuación se analizará la estructura de los mensajes y el contenido de algunos

de los más utilizados. Después se analizarán las nuevas prestaciones ofrecidas por
ICMPv6, como el Neighbor Discovery, la Autoconfiguración y otras.
3.1.1. Los mensajes
Una de las cosas que hace ICMPv6 es definir una serie de mensajes de error que
pueden ser utilizados por los nodos de la red para informar de situaciones en las que hay
problemas en la transmisión.
El mensaje lo emite el equipo que detecta el problema y es enviado al equipo origen

del paquete problemático.
Por ejemplo, si un router no puede enviar un paquete porque es demasiado largo,

enviará un mensaje ICMP al host de origen indicándoselo. El host de origen interpretará
el mensaje ICMP para elegir un tamaño más adecuado y reenviar los datos.
Además de esto, también hay mensajes definidos para valorar el estado de la red.
Aquí es donde aparecen los mensajes "Echo Request" y "Echo Reply", que son
utilizados por el famoso ping.
Por cierto, en ICMPv6 el nombre del comando ping también cambia en algunos
sistemas operativos, pasando a denominarse ping6. En otros casos seguiremos
utilizando el ping de siempre junto con un atributo que nos permite elegir el modo IPv6.
3.1.1.1. Formato de los mensajes
Al hablar de las cabeceras IPv6 y de las cabeceras de extensión se mencionó el

campo Next Header. Las cabeceras ICMPv6 se identifican por un Next Header = 58.
Respecto a los mensajes de ICMPv6, hay dos tipos:
• Mensajes de error.
• Mensajes informativos.
El formato es el siguiente:

El bit más significativo del campo TIPO es el que determina el tipo del mensaje.
Los mensajes de error siempre empiezan por 0 y los informativos por 1. Por ello, los
mensajes de error tienen un tipo comprendido entre 0 y 127 y los informativos están
entre 128 y 255.
El listado de los códigos asociados a los mensajes se puede encontrar en esta

direción de la IANA:
http://www.iana.org/assignments/icmpv6-parameters
El siguiente campo es el de CÓDIGO, que da información adicional acerca del

TIPO del mensaje. Este campo se utiliza siempre con mensajes de error. Entre los
mensajes informativos, el único que lo utiliza es el 138 (Router Renumbering)
Por ejemplo, si TIPO = 1 = Destination Unreachable (Destino inalcanzable), el

CÓDIGO puede tomar, entre otros, estos valores:
0 → No hay ruta hasta el destino.
1 → Comunicación con el destino prohibida por el administrador.
3 → Dirección inalcanzable.
4 → Puerto inalcanzable.
El campo CHECKSUM permite detectar errores en la transmisión de datos.
Por último, el campo CUERPO. Éste varía en función del tipo y código del
mensaje. En caso de que se trate de un mensaje de error, el CUERPO contendrá una
copia lo más completa posible del paquete problemático, que podrá utilizarse en origen
para buscar una solución al problema planteado.

3.1.1.2. Mensajes de error
La cabecera de los mensajes ICMP sufre ligeras variaciones en función del tipo de
error o de la información que transporta. Estos cambios se localizan en el campo
“CUERPO” comentado en el punto anterior.
A continuación se comentan algunos mensajes de error:
DESTINO INALCANZABLE (Destination Unreachable) → TIPO = 1
Este mensaje es generado cuando no es posible entregar un datagrama IP.
El CÓDIGO indica el motivo por el que no se ha podido hacer la entrega.
Después del checksum, se dejan 4 bytes a cero y a continuación se copia el mensaje

original.
Si el destino es inalcanzable debido a congestión, no se generan mensajes ICMP.
PAQUETE DEMASIADO GRANDE (Packet To Big) → TIPO = 2
El MTU = Maximum Transmission Unit es el tamaño de paquete más grande que

puede manejar un enlace.
En caso de que un router no pueda enviar un paquete porque es más grande que el
MTU permitido, generará un mensaje “Packet To Big” que será enviado a la dirección
fuente del paquete.
En este caso TIPO = 2 y CODIGO = 0.
En el CUERPO se utilizan los 4 primeros bytes para indicar el MTU válido.
TIEMPO AGOTADO (Time Exceeded) → TIPO = 3
Cuando un router envía un paquete, decrementa siempre su “HOP LIMIT” en 1. El

“HOP LIMIT” evita que un paquete pueda viajar indefinidamente a través de la red. Si
un router recibe un paquete con “hop limit” = 1 y lo decrementa poniéndolo a 0,
descartará el paquete y generará un mensaje de “Time Exceeded” que será enviado al
host del origen.
En este caso, el campo “CÓDIGO” = 0. Ya en el “CUERPO”, los primeros 4 bytes

se mantienen a cero y después se copia el mensaje original.
Este error puede ser indicativo de un bucle en el enrutado o de que el “hop limit”
establecido por el emisor es demasiado bajo.
Una aplicación práctica:

El CÓDIGO = 0 indica mensaje “Hop limit exceeded in transit”. Este mensaje se

utiliza en el comando “Traceroute”, que determina el camino o path que sigue un
paquete cuando viaja por la red.
¿Cómo lo hace? Se envía un primer paquete con “hop limit = 1”.
El primer router en el path decrementa el ”hop limit” poniéndolo a cero, descarta

el paquete y envía de vuelta un mensaje ICMP con TIPO = 3 y CÓDIGO = 0. El
host origen sabe ahora la dirección IP del primer router de salto.
A continuación envía un segundo paquete con “hop limit = 2”. Este paquete es
reenviado por el primero router, que pone “hop limit = 1”. El segundo router
decrementa el “hop limit” poniéndolo a cero, lo descarta y envía el
correspondiente mensaje ICMP con TIPO = 3 y CÓDIGO = 0. Ahora el host
origen tiene identificado al segundo router del path.
El proceso continua incrementando en uno el “hop limit” con cada paquete

enviado y termina cuando se alcanza el destino final.
En caso de que haya varios caminos hasta el destino, “traceroute” no tiene por
qué dar siempre los mismos resultados.
PROBLEMA CON PARAMETROS (Parameter Problem) → TIPO = 4
Si un nodo IPv6 no puede completar el procesamiento de un paquete porque tiene

algun problema para identificar un campo en la cabecera IPv6 o en una cabecera de
Extensión, debe descartar el paquete y devolver el mensaje ICMP “Parameter Problem”
Este es el mensaje que se suele utilizar cuando el error que se produce no se ajusta a
ninguno de los anteriores.
En el CUERPO, los 4 primeros bytes actúan como puntero, señalando el punto del
paquete donde se ha detectado la irregularidad. También se envía de vuelta la mayor
porción posible del paquete original.
3.1.1.3. Mensajes informativos
Los mensajes informativos definidos en la RFC 4443 son “Solicitud de eco” (Echo
Request) y “Respuesta de eco” (Echo Reply).
También se usan mensajes ICMP informativos para implementar “Path MTU

Discovery” y “Neighbor Discovery”, pero éstos están definidos en otras RFCs
(concretamente en la 4861 y en la 1981).
Los mensajes de Solicitud y Respuesta de Eco son utilizados en una de las utilidades
TCP/IP más populares: Packet Internet Groper (ping). Ping se usa para determinar si un
host está disponible en la red y está listo para comunicarse. El host de origen pone en
circulación un mensaje “Echo Request” dirigido al destino.
El host destino, si está disponible, responde con un mensaje “Echo Reply”.
MENSAJE DE SOLICITUD DE ECO (Echo Request message) → TIPO = 128
El campo “TIPO = 128” y el “CÓDIGO = 0”.
En el “CUERPO”, los dos primeros bytes se utilizan como “Identificador” y los dos
siguientes como “Número de secuencia”. A continuación se insertan cero o más bytes
arbitrarios para completar el paquete.
Estos dos campos se usan para emparejar las solicitudes con las respuestas. La
respuesta debe contener siempre los mismos números que la solicitud.
El que se utilice un identificador y un número de secuencia y el tipo de datos

arbitrarios que se incluyen en la solicitud depende de la pila TCP/IP que se esté
utilizando.
3.1.1.4. Captura de mensajes
Algunos de los puntos vistos hasta aquí se pueden ver con una simple captura de
paquetes en un sniffer.
En la imagen se muestran la captura mediante Wireshark de un ping6 lanzado desde

un portatil (con sistema operativo GNU/Linux UBUNTU) a un conmutador IPv6 al que
está conectado.
Como se puede ver en la consola de la parte derecha, el comando ejecutado es:
ping6 -I eth0 -c 1 FE80::221:91FF:FEAA:BE00

• El “-I” (es una “i” latina mayúscula) es para indicar el nombre de la interfaz
que se utilizará en el ping.
• El “-c” es para indicar el número de pings que se deben realizar. En este

caso, con uno es suficiente.
• FE80::221:91FF:FEAA:BE00 es la dirección del equipo cuya conectividad

se quiere probar
Como se puede ver en la cabecera IPv6, “Next Header” = 0x3a = 58, que es el valor
indicado anteriormente como asignado a ICMPv6.
También se pueden ver las direcciones de origen y destino, que son ambas del tipo
“de enlace local”, porque empiezan por 0xFE80.
Si nos fijamos ya en la cabecera ICMPv6, el primer campo indica “Type = 128”, que
es el código del mensaje “Echo Request”.
El ID (= Identificador) es 0x2c20 y el número de secuencia es 0x0001
Después van los 54 bytes de datos arbitrarios. Con solo mirar el campo de los datos
arbitrarios podemos saber si el equipo que ha hecho ping es Windows o no, ya que estos
equipos utilizan como datos el alfabeto entre las letras “a” y “w”.
Ya en la respuesta, vemos que en la cabecera IPv6 se mantiene el campo “Next

Header” con el 0x3a = 58 de ICMPv6 y que las direcciones de origen y destino se han
intercambiado.

En la cabecera ICMPv6, el Type = 129 indica que es la respuesta de eco (Echo

Reply).
Los campos ID, Secuence y Data son una copia de los enviados en la Solicitud de
Eco.
3.1.2. Neighbor Discovery
El Neighbor Discovery o Descubrimiento de Vecinos está definido en la RFC 4861

“Neighbor Discovery for IP version 6 (IPv6)” (antes RFC 2461). El Neighbor
Discovery Protocol (NDP) se usa tanto en hosts como en routers.
Algunos de los usos del NDP son los siguientes:
• Neighbor Discovery (ND) = el descubrimiento de vecinos propiamente dicho.

• Autoconfiguración de direcciones IPv6.
• Determinación de prefijos de red (se acabó el tener que configurar a mano las
máscaras de subred), rutas...
• Detección de IPs duplicadas (DAD = Duplicate Address Detection).
• Búsqueda de las MACs de los vecinos y detección de cambios en las mismas.

• Router Discovery (RD) = Búsqueda de routers vecinos que puedan darnos

servicio.
• Llevar el control de qué vecinos están disponibles y cuáles no lo están (NUD =
Neigbor Unreachability Detection).
El protocolo ND consta de 5 mensajes ICMP que serán tratados en las siguientes

secciones:
• Router Solicitation.
• Router Advertisement.
• Neighbor Solicitation.
• Neighbor Advertisement.
• ICMP Redirect.
3.1.2.1. Router Solicitation y Router Advertisement
Estos son los mensajes de "Solicitud de Router" y de "Anuncio de Router". Veamos

cuándo se utilizan.
Los routers envían regularmente mensajes del tipo "Router Advertisement" para
anunciar su presencia.
A su vez, los hosts pueden solicitar mensajes de Router Advertisement poniendo en

circulación mensajes de Router Solicitation, que hacen que el router que lo recibe
responda inmediatamente con un Router Advertisement, aunque no le tocara enviarlo
todavía.
En la cabecera IP del mensaje Router Solicitation se pone como dirección destino la

dirección multicast all-routers, es decir, la FF02::2. El límite de saltos se pone a 255.
Ya en el mensaje ICMP, el TIPO = 133. El CODE es 0 y los 4 primeros bytes

después del CHECKSUM también.

En el campo de Opciones se envía la dirección MAC del solicitante en caso de que

su dirección IP sea conocida. Si el campo Dirección de Origen de la cabecera IP es la
dirección No-Especificada (all-zeros), el campo opciones no se usa.
Los routers que reciben el mensaje Router Solicitation, ponen en circulación un

mensaje Router Advertisement. Como se ha dicho anteriormente, este tipo de paquete se
pone en circulación periódicamente. No obstante, puede ocurrir que se reciba una
petición directa.
¿Es posible saber si un mensaje Router Advertisement es de los enviados

periódicamente o es la respuesta a un mensaje Router Solicitation?
La respuesta es SI. Se puede saber mirando la cabecera IP asociada al mensaje, y más
concretamente, el campo Dirección Destino. En el caso del mensaje periódico, la
dirección Destino es la dirección multicast all-nodes, es decir, la FF02::1.
En el caso de ser respuesta a una solicitud, la dirección destino será la del host que hizo
la petición.
Ya en la cabecera ICMPv6, el formato de los mensajes Router Advertisement es el

mostrado en la siguiente figura.
El campo Current Hop Limit (Límite de Saltos Actual) sirve para informar a los
nodos del enlace de cuál es el valor de Hop Limit por defecto con el que se tienen que
configurar. Si este valor fuera 0, no estaría definido un Hop Limit por defecto y se
utilizaría el valor que tenga asignado por defecto el nodo transmisor.
El siguiente campo es de 1 bit, el flag M (de Managed address configuration).

Cuando está a 1 indica que las direcciones están disponibles vía DHCPv6. Esto es lo
que se llamaba configuración Stateful, pero ese término dejó de utilizarse cuando la
RFC 4861 dejó obsoleta a la RFC 2461 (Sept. 2007).
• Si M = 0, los nodos del link utilizarán la autoconfiguración Stateless

(configuración de dirección autónoma).
• Cuando el flag M está activado, el siguiente flag, O, es redundante y se puede
ignorar porque DCHPv6 dará toda la información disponible para realizar la
configuración.
A continuación va el flag O (de Other Configuration). A 1 indica que hay otra

información disponible vía DHCPv6. Por ejemplo información relativa a DNS o de
otros servidores dentro de la red.
Los 6 bits siguientes que completan este byte van a cero.
Los 2 bytes siguientes son el campo Router Lifetime. Este campo solo es importante
si el router se va a usado como router por defecto por los nodos del enlace. Si el campo
es cero, el router no es el utilizado por defecto. Cualquier otro valor indica, en
segundos, el tiempo que el router será considerado el router por defecto. El mayor
tiempo que se puede poner con 16 bits es de 65535 segundos, lo que equivale a 18,2
horas.
El campo Reachable Time (Tiempo alcanzable) indica el tiempo (en ms) que un host
va a suponer que los vecinos están al alcance después de haber recibido una
confirmación de accesilidad. Un valor de 0 indica que no se especifica.
El algoritmo NUD (Neighbor Unreachability Detection) usa este campo.
El campo Retrans Timer (Tiempo de Retransmisión) indica el tiempo (en ms) entre
retransmisiones de mensajes “Neighbor Solicitation”. Se utiliza en la resolución de
dirección y en los mecanismos de NUD. Si se pone a cero indica que ese router no está
configurado con el temporizador de retransmisión.
Para el campo Opciones hay tres posibles valores:
• Dirección de la capa de enlace de la fuente.
• Tamaño de MTU a utilizar en enlaces donde este parámetro es variable (por

ejempo, Token Ring).
• Información de prefijo. Esta información es importante para la
autoconfiguración Stateless. El router inserta todos sus prefijos de enlace que
tienen que ser conocidos por los nodos del link.
3.1.2.2. Neighbor Solicitation y Neighbor Advertisement
Estos dos mensajes cumplen dos funciones:
• La resolución de direcciones físicas de la que se encargaba ARP en IPv4

• El mecanismo de detección de vecinos no alcanzables (Neighbor Unreachability

Detection).
Si la dirección de destino es una dirección multicast (normalmente la “dirección

multicast de nodo solicitado”), el host de origen está resolviendo una dirección de la
capa de enlace.
Si el host de origen está verificando la disponibilidad de un vecino, la dirección de

destino será una dirección unicast.
Este tipo de mensaje se utiliza también en DAD (Duplicate IP Address Detection).
En la cabecera IP de este tipo de mensaje, la “Source address” puede ser tanto la de

la interfaz del host origen como la “dirección no especificada (all-zeros)”. Esto último
en caso de autoconfiguración Stateless y DAD.
El formato de la cabecera ICMP es el indicado en la figura:
El Tipo = 135, Código = 0 y los 4 bytes que van después del Checksum no se usan y
se ponen a cero.
El campo Dirección Target (= Objetivo) se usa en Neighbor Advertisement y en

redireccionamiento de mensajes. Aquí no debe usarse una dirección multicast.
El campo Opciones puede contener la dirección MAC del origen, pero solo si no se
hace el envío desde la dirección “all-zeros”.

Durante la autoconfiguración Stateless, en un mensaje que usa la dirección no

especificada como dirección Source, el campo Opciones se pone a cero.
La opción de la capa de enlace se debe utilizar en solicitudes multicast (detección de

dirección de capa de enlace) y puede ser usada en solicitudes unicast (Unreachability
Detection = Detección de inalcanzabilidad)
Los mensajes “Neighbor Advertisement” o “Anuncio de vecino” se envían como

respuesta a mensajes “Neighbor Solicitation” o para propagar información rápidamente.
El formato del mensaje es el siguiente:
Se puede saber si el mensaje es la respuesta a una solicitud o si se envía

voluntariamente, mirando el tipo de dirección utilizado en la cabecera IP. En el primer
caso, el mensaje irá dirigido al host que hizo la solicitud, por lo tanto, la dirección IP
destino será la suya. En caso de que el mensaje sea una respuesta a un mensaje DAD
(Duplicate IP Address Detection) originado desde un host desconocido, la respuesta irá
dirigida a la dirección multicast “all-nodes”, esto es, a la FF02::1. Lo mismo ocurre para
los envíos periódicos no solicitados.
Como se puede ver en la figura anterior, ya en la cabecera ICMP, Tipo = 136,

Código = 0 y después del Checksum tenemos unos flags. El primero “R = Router flag”
puesto a “1”, indica que el equipo origen es un router. El siguiente es el “Solicited flag”
= S. A “1” indica que el mensaje es una respuesta a un “Neighbor Solicitation”. Este
flag no se usa en anuncios multicast.

Por último el “flag de Override” = O. Indica que la información enviada en el

mensaje de Advertisement debería anular las entradas de la Neighbor Cache y actualizar
cualquier dirección de enlace “cacheada”. Si este bit está a cero, el mensaje no
actualizará una dirección que ya esté en la caché, pero puede actualizar una entrada de
una “Neighbor Cache” que no tenía la información de la dirección. Este bit no se debe
utilizar en anuncios dirigidos a direcciones anycast.
En anuncios solicitados, la “Dirección Objetivo” (Target Address) contiene la

dirección de la interfaz que envía la solicitud. En los no solicitados, contiene la
dirección de la interfaz. En los anuncios no solicitados, este campo contiene la dirección
de la interfaz cuya dirección de la capa de enlace ha cambiado.
Una posible opción para el campo de Opciones es la dirección destino de la capa de

enlace.
3.1.2.3. Otros usos del protocolo Neighbor Discovery
El mensaje de Redirección ICMP
Son los mensajes de Tipo = 137
Este es un mensaje que los routers ponen en circulación para informar a un nodo de
cuál es el mejor “primer salto” para llegar a un destino determinado. Este tipo de
mensaje también puede informar a un nodo de que el destino solicitado es realmente un
vecino, y no un nodo en otra subred.
Inverse Neighbor Discovery (IND) (RFC 3122)
O lo que es lo mismo, Descubrimiento Inverso de Vecinos.
IND es el equivalente al RARP (Reverse ARP) de IPv4. Es decir, el protocolo que a

partir de una dirección MAC de un equipo es capaz de resolver cuál es su dirección IP.
IND utiliza dos tipos de mensajes:
• IND Solicitation (Tipo = 141), que es enviado por el equipo que quiere hacer la
resolución a la dirección multicast all-nodes (FF02::1).
• IND Advertisement (Tipo = 142), que es enviado por el equipo objetivo y que
contiene las direcciones de dicho equipo.
Resolución de direcciones de capa de enlace.
Equivale al ARP de IPv4, es decir, permite determinar la MAC de un equipo a partir

de su IP.

Se usa solo con nodos vecinos y se lleva a cabo enviando un mensaje Neighbor
Solicitation dirigido a la dirección multicast de “nodo solicitado” del vecino en
cuestión.
Si dicho equipo es alcanzable, responderá enviando al equipo solicitante un mensaje

Neighbor Advertisement.
Neighbor Unreachability Detection (NUD)
Se puede traducir como “Detección de disponibilidad de vecino”
Se considera que un equipo está al alcance si hay alguna prueba de que la

comunicación con el mismo es posible. Esto ocurre si, por ejemplo, su capa IP está
recibiendo los paquetes que se le envían. También puede saberse porque se recibe un
mensaje Neighbor Advertisement como respuesta a un Neighbor Solicitation o porque
se están recibiendo ACKs de TCP.
Para llevar el control de las conexiones activas y alcanzables, Neighbor Discovery

usa dos tablas: la caché de vecinos o Neighbor Cache y la de destino o Destination
Cache.
• Neighbor Cache
o Es como la Caché ARP de IPv4.
o Contiene información de los vecinos con los que se ha intercambiado
tráfico recientemente.
o La información guardada es la dirección IP unicast, su dirección MAC y
un flag que indica si el vecino es un router o un host.
o Además tambíen indica si hay algún paquete en espera para ser enviado,
si el destino está al alcance y cuando se producirá la siguiente
comprobación NUD.
• Destination Cache
o Contiene exactamente la misma información que la Neighbor Cache más
la información de los destinos remotos. Es decir, la Neighbor Cache es
una parte de la Destination Cache.
o Para los destinos remotos, la entrada de la caché contiene la MAC del
siguiente router al que saltar.
o Esta caché se actualiza con los mensajes de Redirección de ICMPv6.
3.1.3. Otras posibilidades de ICMPv6
Autoconfiguración
Esta capacidad ahorrará mucho trabajo a los administradores de red y va a ser una de
las características clave de IPv6.

Permite que cualquier dispositivo (desde una TV hasta un móvil pasando por
frigoríficos, DVDs...) que requiera una dirección IP pueda conseguirla sin necesidad de
tener que ser configurado manualmente.
Hay dos tipos de autoconfiguración: la stateless y la DHCPv6 (antes llamada

“stateful”).
Para generar su dirección IP, los hosts utilizan una combinación de información
local, como su dirección MAC, e información recibida de los routers.
Los routers pueden anunciar múltiples prefijos, y los hosts extraen la información
del prefijo de esos anuncios.
Esto permite la renumeración sencilla de un sitio completo: solo hay que cambiar la
información del prefijo en el router. Por ejemplo, si se cambia de ISP y el nuevo ISP
asigna un nuevo prefijo IPv6, se pueden configurar los routers para que anuncien el
nuevo prefijo, manteniendo el resto de la dirección original. Todos los hosts conectados
a esos routers se renumerarán usando el mecanismo de autoconfiguración.
Si no hay routers, cada host se puede generar una dirección en enlace local (link-
local address) con el prefijo FE80.
La dirección de enlace local es como la dirección que tomaba un nodo en IPv4

cuando no encontraba al servidor DHCP. En ese caso, automáticamente tomaba una
dirección de la red 169.254.0.0/16... y se quedaba aislado del mundo.
La gran diferencia en IPv6 es que ahora, esa dirección FE80... es suficiente para la
comunicación de todos los nodos conectados al mismo enlace.
Las autoconfiguraciones Stateless y DHCPv6 también se pueden combinar. Por

ejemplo, un host puede usar autoconfiguración stateless para generar una dirección IPv6
y utilizar después la autoconfiguración DHCPv6 para conseguir los demás parámetros.
Llegados a este punto, es interesante saber que las direcciones IPv6 se asignan a los
nodos de forma temporal y que existe un intervalo de tiempo definido (lifetime) después
del cual la dirección deja de ser válida. Para asegurar que una dirección es única en un
enlace se usa el algoritmo DAD (= Duplicate Address Detection – RFC 4862).
Los estados por los que puede pasar una dirección IPv6 son los siguientes:
• Tentativa: es el estado de la dirección justo antes de ser asignada, cuando se

está aplicando DAD para garantizar que no está en uso.
• En este estado no es posible la comunicación con el resto de los equipos del

enlace, tan solo permite procesar ciertos mensajes ND para
autoconfiguración.
• Preferida: es el estado de la dirección finalmente asignada.

• Obsoleta (deprecated): es el estado de la dirección cuyo “lifetime” está a

punto de expirar. Una dirección en ese estado se mantendrá en
comunicaciones activas con objeto de no interrumpirlas, pero se evitará su
uso en nuevas comunicaciones.
• Válida: son las direcciones que están activas (tanto la preferida como la
obsoleta).
• Inválida: es el estado de una dirección cuya “lifetime” ha expirado. La

dirección deja de estar vinculada a la interfaz del host.
Renumeración de red.
Este tema se trata en la RFC 4192 "Procedures for Renumbering an IPv6 Network
without a Flag Day". El llamado "Flag Day" (Día de la Bandera) es el día clave en el
que se va a interrumpir el funcionamiento de la red para realizar una tarea de
mantenimiento programada. Para evitar sufrir un "Flag Day" hay que pensar en una
estrategia distinta, que permita realizar un cambio progresivo en la configuración sin
necesidad de detenerla.
Este es el tipo de situación que tiene lugar cuando hay que realizar un cambio en el
prefijo de la red, cosa que puede ocurrir, por ejemplo, debido a un cambio de proveedor
de Internet.
Lo que se permite ICMPv6 es enviar mensajes para informar de cual será el nuevo
prefijo a utilizar, pero manteniendo aún el antiguo en funcionamiento. Una vez todos los
equipos están enterados del nuevo prefijo se "desactiva" el anterior, de modo que
continúan utilizando el nuevo. Se ha modificado la configuración de la red y se ha
evitado el “flag day”.
Path MTU Discovery
En IPv4, si un router detecta que un paquete es demasiado grande para ser enviado
por un enlace determinado, puede fragmentarlo. En IPv6 los routers no se dedican a
fragmentar paquetes, dejando esta tarea en mano del host de origen.
Antes de nada hay que recordar un par de conceptos. Por un lado, el significado de
“Link MTU(Maximum Transmission Unit”, que es el tamaño máximo de los
paquetes que pueden ser manejados en un enlace. Y por otro, el de “Path MTU”, que es
el valor de MTU más grande que se puede utilizar a lo largo de la ruta que siguen los
datos desde el origen al destino.
Para que no haya problemas en ningún punto, el valor de MTU a utilizar debería ser
el más pequeño de los que haya en el path.
Como se ha dicho antes, en IPv6, el unico encargado de fragmentar un paquete es el

host de origen. Para ello necesita conocer cuál es el menor MTU de todos los que hay en
el path. Esta información se obtiene por medio del llamado “Path MTU Discovery” de
ICMPv6.
En el proceso de descubrimiento, el primer “Path MTU” que toma el host origen es

el del primer enlace. Cuando un router detecta que ese tamaño es demasiado grande
para el siguiente enlace devuelve un mensaje de error ICMPv6: “Packet Too Big”, que
incluirá el MTU válido para el siguiente enlace. Ese será el MTU que usará en lo
sucesivo el host origen mientras no reciba un nuevo mensaje de error.
El tamaño mínimo de MTU en IPv6 es de 1280 bytes.
Puesto que la ruta no es fija, el “Path MTU” también puede cambiar.
En el caso de multicast, se usa el MTU más pequeño de los que hay en los caminos a
lo múltiples destinos.
Multicast Listener Discovery (MLD)
Para empezar veremos algunos detalles del multicast de IPv4:
• Hay ocasiones en las que interesa el envío simultáneo de paquetes a un grupo de

hosts.
• En este caso el broadcast no es la opción adecuada, porque no se puede enrutar
(con lo cual el alcance se limita al enlace local) y además obliga a todos los
nodos del enlace a procesar la información.
• La transmisión multicast posibilita el envío simultáneo de paquetes a un grupo
de hosts que están configurados con una dirección multicast de grupo (dirección
de clase D). Solo los hosts que son miembros de ese grupo multicast procesarán
los paquetes.
• Además, los mensajes multicast son enrutables y para asegurar que el mensaje
solo es propagado a aquellos enlaces en los que hay equipos miembro del grupo
multicast, se usa el protocolo IGMP (Internet Group Management Protocol).
Ya en IPv6, tenemos que multicast es una característica propia del protocolo y está
disponible en todos los nodos IPv6.
• Como se ha explicado en su momento, el prefijo de las direcciones multicast es

FF.
• En la propia dirección se indica el ámbito de difusión. Así, FF02 denota el
ámbito local, FF05 el ámbito del site local y FF0E indica ámbito global.
Como se ha comentado más arriba, es necesario un protocolo para limitar el alcance

de los paquetes multicast a aquellos enlaces en los que hay equipos miembro del grupo
multicast.
El IGMP de IPv4, y más concretamente, su 2ª versión (IGMPv2) se implementa en

IPv6 por medio de mensajes ICMPv6 y es lo que se llama MLD (Multicast Listener
Discovery).
Después de una primera versión de MLD se llegó a MLDv2, que está basado en
IGMPv3 de IPv4 y que se diferencia de la versión anterior en soportar SSM (Source
Specific Multicast). Eso significa que un nodo puede elegir escuchar tan solo los
paquetes multicast procedentes de una dirección concreta, o de todas las posibles
fuentes excepto de una determinada. Esto es algo que en MLDv1 no es posible por
utilizar ASM (Any Source Multicast) en lugar de SSM.
Si nos centramos un poco en MLD vemos que este protocolo permite a los oyentes
multicast registrar las direcciones multicast que quieren utilizar, con objeto de conseguir
un enrutado eficiente.
Por otro lado, los routers utilizan MLD para descubrir qué direcciones multicast
tienen oyentes en cada uno de los links a los que están conectados.
El router mantiene una lista de direcciones con oyentes para cada uno de sus enlaces,
pero sin llegar a controlar cuántos oyentes activos hay.
Mientras haya algún miembro del grupo en el enlace, la dirección se mantiene.
El oyente envía un mensaje al router y éste incluye la dirección multicast es su lista

de control.
Del mismo modo, un oyente puede darse de baja de un grupo por medio de un
mensaje.
Cuando el último grupo se da de baja, el router elimina la dirección de ese link de su

lista de control.
En todos los mensajes MLD se usan direcciones de enlace local como origen y el
“hop limit” = 1. Así se limita el alcance al enlace local. También se usa la opción “Hop
By Hop” y se activa el flag Router Alert para garantizar de que el paquete será
procesado por el router aunque no sea miembro del grupo multicast.
Multicast Router Discovery (MRD)
Es un mecanismo basado en paquetes ICMPv6 que permite el descubrimiento de

routers capaces de propagar tráfico multicast.
Consta de tres mensajes, dos de los cuales, Multicast Router Advertisement (Tipo =
151) y Multicast Router Termination (Tipo = 153) permiten al router anunciar la
activación / desactivación de la difusión multicast.

El tercer mensaje, Multicast Router Solicitation (Tipo = 152), permite que cualquier
host pueda preguntar a todos los routers (FF02::2) si alguno trabaja con multicast.
Al igual que en MLD, todos estos mensajes se envían con “Hop Limit” = 1 y con la
opción “Router Alert” activa

3.2. Configuración stateless.

3.2.1. Introducción
La configuración automática comienza con la instalación de la dirección de interface

de enlace local que se carecteriza por comenzar por FE80. Esta dirección junto con los
mensajes de descubrimiento de vecinos ND es la que permite iniciar el proceso de
autoconfiguración de direcciones de red públicas
Se pueden dar tres tipos de configuración automática:
Stateless o sin estado: el host se configura mediante mensajes RA (Anuncio de Router)
que incluyen la información necesaria para configurar el enlace
Stateful o con estado: utilizan un servidor DHCPv6 de modo similar a la

configuración automática utiliza en IPv4. El proceso comienza cuando no hay mensajes
RA de ningún router o cuando el host se haya configurado para ello
Mixto: mediante mensajes RA configura la IPv6 del host y los datos referentes a las
direcciones de los servidores DNS y nombre dominio. En este caso se utiliza una
particularidad el servidor DHCPv6 configurado en modo "sin estado", de manera que no
da direcciones IPv6 y no controla el estado de los host que se conectan
En este apartado veremos la configuración stateless
3.2.2. Descripción
Autoconfiguración sin estado
RFC 4862: Stateless Address Autoconfiguration
En la configuración stateless la red se autoconfigura de manera automática. Esta es

una característica del protocolo IPv6 que no existía en el protocolo IPv4. Los datos más

importantes a configurar son los mismos que los que se obtendrían de un servidor
DHCP con estado :
IPv6 global, IP de la puerta de enlace e IP del servidor DNS ipv6
La configuración de direcciones se basa en la recepción de mensajes de anuncio de

enrutador RA. Estos mensajes contienen prefijos de direcciones sin estado, así como la
IPv6 de la puerta o Gateway. Los prefijos son los que definen la red a crear indicando la
parte fija de la dirección IPv6 de los host que formen parte de dicha red.
En el proceso de configuración de la red intervienen tanto el router como el host

definiendo de forma automática la IPv6 global de cada host perteneciente a la subred
que se haya definido.
En lo que respecta a la configuración de las direcciones de los servidores DNS, los

mensajes RA no incluyen esta información, pero incluyen una indicación de que hay
más información disponible en la red para que el host la busque.
3.2.3. Autoconfiguración de direcciones globales
La autoconfiguración a nivel de enlace local ya se ha visto previamente así que en

este tema veremos la autoconfiguración de direcciones de enlace global que son las que
van a permitir la conexión del host con el resto del mundo.
3.2.3.1. Autoconfiguración de la IPv6 Global y la dirección de la puerta de enlace en cada

host
El funcionamiento del protocolo IPv6 a la hora de crear una red stateless se puede
resumir como sigue:
El router recibe una configuración (manual o automática) sobre el pool de

direcciones IPv6 correspondiente a la subred a configurar, en forma de IPv6
global/máscara de manera que la máscara define la subred a la que pertenece el router.
Se define un prefijo para el pool de direcciones de la subred que va a colgar del

router en forma IPv6/máscara. Este prefijo debe pertenecer a la subred del router de
forma que se cree una jerarquía de direcciones.
Los datos configurados en el router se transmiten a todos los host conectados a él se

mediante la función RA (Router Advertisment) que se encarga de mandar paquetes a los
vecinos con los datos de la configuración de la red. En este paquete se indican
principalmente el valor del prefijo que define la red a crear y la dirección local de la
puerta de enlace. Para esto se utilizan direcciones multicast, en el caso del los paquetes
RA se mandan a la dirección multicast "Todos los nodos del enlace local" (FE02::1)
Por otro lado, un host puede solicitar los datos para autoconfiguración mediante el
envío de paquetes RS (Router Solicitation) que se envían a la dirección multicast

"Todos los routers del enlace local" (FE02::2) , a lo que los routers del enlace local
responden con paquetes RA enviados a su dirección local.
En la imagen siguiente podemos ver el flujo multicast generado por un host que
acaba de conectarse a la red. En este caso se trata de una red donde no se ha activado el
envío de paquetes RA, y por tanto intenta encontrar un servidor DHCP
Una vez activado el envío de paquetes RA por parte del router, el flujo queda
Desde el punto de vista del host podemos ver el estado inicial con las direcciones
auto-configuradas durante la instalación del protocolo IPv6
Sin prefijo, la información básica que ofrece el paquete RA es la de anuncio de la

dirección de la puerta de enlace
Al añadirle el prefijo al paquete RA (en la imagen 2001:5c0:1400:a::/64), la auto-

configuración de la conexión de red en el host crea 2 direcciones IP nuevas, una
anónima y otra a partir de algoritmo EUI-64 (termina en 96-A9-0A que son los últimos
dígitos de la MAC)
Finalmente tenemos configuradas las direcciones locales y globales así como la de la

puerta de enlace y los servidores DNS
3.2.4. Obtención de direcciones de autoconfiguración
Veamos en este apartado como consigue un host las direcciones IPv6 necesarias
para autoconfigurarse.
3.2.4.1. Obtención de las direcciones IPv6 globales
Mediante autoconfiguración stateless se generan 2 tipos de direcciones globales
Mediante algoritmo IEEE EUI-64
El prefijo se añade a las direcciones IPv6 de cada host mediante un algoritmo que
combina el prefijo con la MAC de la interface basado en IEEE EUI-64 visto
anteriormente para la autoconfiguración de la dirección de enlace local.
Esta dirección es pública y fija, ya que siempre es la misma para un mismo prefijo, por
lo que puede dar problemas de seguridad al poder ser rastreada fácilmente
Direcciones anónimas
Para resolver el problema anterior se genera otra dirección global. Esta dirección se
puede obtener mediante un algoritmo hash que utiliza MD5 (Mesage Digest 5) o
aleatoriamente, dependiendo de que el protocolo IPv6 implementado memorice las
direcciones generadas previamente o no.
3.2.4.2. Obtención de la IP del servidor DNS y del nombre del dominio
En los mensajes RA sólo se envían los parámetros de prefijos de red y la IPv6 de la

puerta de enlace así que hay recurrir a otros sistemas para obtener el resto de la
configuración.
En Windows XP, p.ej, durante el proceso de autoconfiguración stateless, al instalar el

protocolo IPv6 se instalan automáticamente 3 direcciones IPv6 para servidores DNS,
que utilizan como interface el de bucle invertido (looback).

FEC0:0:0:0:FFFF::1,FEC0:0:0:0:FFFF::2 y FEC0:0:0:0:FFFF::3
En el caso de utilizar una autoconfiguración mixta, el mensaje RA incluye una

indicación (flag O) de que hay más información disponible aparte de la enviada en el
mensaje y el host busca un servidor DNS utilizando para ello el servidor DHCPv6 en
"modo sin estado" que le da las direcciones así como el resto de información que pueda
necesitar.
Como ejemplo podemos ver la pantalla de configuración del servidor DHCPv6 de

Windows Server 2008 con la opción de configuración "Modo sin estado DHCPv6". Al
activar esta opción nos pide que introduzcamos las direcciones de los servidores DNS
3.2.5. Algoritmos de generación de direcciones globales
En modo stateless las direcciones se generan a partir de un prefijo común a todos los
host de la misma red y un sufijo generado por el propio host bien mediante algún
algoritmo o bien de forma aleatoria.
3.2.5.1. Creación de la Dirección Global de Unicast: basado en IEEE EUI-64
El procedimiento es el mismo que el utilizado para crear la dirección de enlace local,

con alguna modificaciones:
1. Partimos de la dirección IPv6 ponemos al final los 48 bits de la MAC de la

interface
2. Ponemos el séptimo bit, el bit U/L (universal/local) a 1, que indica una dirección
administrada de forma remota
3. Insertamos FFFE en medio de la MAC (bit 24 o Byte3º). El nº de 64 bits
obtenido se denomina Identificador de Interface
4. En la dirección IPv6 ponemos al final los 64 bits del Identificador de Interface
5. Cuando recibe el prefijo, este se coloca al inicio de la dirección y el resto se
rellena con ceros
Por ejemplo:
MAC: 00-0C-6E-6B-EB-0A Prefijo: 2000::/3
El proceso sería
1. 0000 00002 -0C-6E-6B-EB-0A

2. 0000 00102-0C-6E-6B-EB-0A
3. 02-0C-6E-6B-EB-0A
4. 02-0C-6E-FF-FE-6B-EB-0A
5. 2000::20C:6EFF:FE6B:EB0A
3.2.5.2. Creación de la Dirección Global de Unicast: basado en algoritmo hash
El protocolo IPv6 implementado debe memorizar en un historial las direcciones

generadas previamente.
La primera dirección se genera aleatoriamente. Cuando transcurre el tiempo de

caducidad, se inicia el proceso de generación de dirección anónima mediante el
algoritmo siguiente:
1. Se recupera el valor de historial almacenado y se anexa el identificador de

interfaz basado en la dirección EUI-64 del adaptador.
2. Se calcula el algoritmo hash de cifrado unidireccional MD5 (Message Digest-5)
con la cantidad del paso 1.
3. Se memorizan los últimos 64 bits del algoritmo hash MD5 calculado en el
paso anterior como valor de historial para el siguiente cálculo de dirección
anónima.
4. Se toman los primeros 64 bits del algoritmo hash MD5 calculado en el paso 2 y
se pone el séptimo bit (U/L) a 0, que indica una dirección administrada de forma
local. El resultado es el identificador de interfaz.
Este proceso se repite continuamente cada cierto tiempo. Los tiempos pueden ser
configurados
3.2.6. Router IPv6
El router adquiere una gran importancia en la configuración stateless ya que es el

que distribuye la información de autoconfiguración al resto de los host. Hay que decir
que no son compatibles con los router IPv4 ya que deben poder leer los paquetes IPv6 y
manejar el protocolo ICMPv6. En la práctica actualmente utilizan protocolos IPv6 de
pila dual, lo que viene a significar que pueden trabajar tanto en IPv4 como en IPv6 y a
menudo recurren a túneles para pasar de una red a otra.

Algunas de las principales características de un router IPv6 son:
• Manejo de direcciones IPv6 unicast, multicast y anycast

• Procesado de paquetes IPv6 y de cabeceras de extensión
• Descubrimiento de Vecinos (ND) IPv6
• Envío de mensajes de Aviso de Router (RA)
• ICMPv6
3.2.6.1. Configuración del router para stateless
Para que el router IPv6 pueda iniciar el proceso de autoconfiguración stateless debemos
configurar
• Mensaje RA
En los mensajes RA ajustaremos los flags y los tiempos del paquete
1. RA Managed flag: este flag indica si la autoconfiguración va ser stateless

(mediante los mensajes RA del router) o si va a ser stateful (mediante un
servidor DHCPv6)
2. RA Other flag: mediante este flag se indica a los host que además de las
direcciones generadas mediante los paquetes RA (stateless) en la red hay
disponible más información, como por ejemplo, las direcciones de los servidores
DNS (que serán proporcionadas por el DHCPv6 en modo sin estado)
3. Temporizaciones: Retransmisión time, Life time y Reachable time
Como ejemplo de parámetros a configurar se indican los solicitados por el switch L3

DGS-3627
RA Router Utilice este menú desplegable para activar o desactivar que el
Advertisement switch sea capaz de aceptar solicitud de un vecino (ND), y así
convertirse en un vecino de IPv6. Una vez activada, este switch es
capaz de producir mensajes de anuncio de enrutador (RA) para
ser devueltos a consulta de vecinos(RS)
RA Router Life Esta tiempo representa la validez de que esta interfaz sea el
Time (s) router por defecto para el enlace local de red. Un valor de 0
representa que este switch no debe ser reconocido como el router
predeterminado para este enlace de red local. El usuario puede
establecer un tiempo de entre 0 y 9.000 segundos con una
configuración predeterminada de 1800 segundos.
RA Reachable Este campo establece el tiempo en que un nodo IPv6 remoto
Time se considera alcanzable. En esencia, este es el campo Detección
de Vecino Inalcanzable una vez que la confirmación del acceso a
esta nodo se ha hecho. El usuario puede establecer un tiempo de
entre 0 y 3.600.000 milisegundos con de una configuración
predeterminada de 1200000 milisegundos. Un valor muy bajo, no
se recomienda.
RA Retransmit Se utiliza para ajustar un tiempo de intervalo entre 0 y
Time (ms) 4294967295 milisegundos para el envío de anuncios de enrutador
(RA) en esta interfaz en el enlace de red local, en respuesta a una
Mensaje de Solicitación de Vecino (RS). Este valor no debe
exceder el valor indicado en el campo el tiempo de vida se ha
mencionado anteriormente. Establecer este campo a cero, se
especifica que este cambio no se especifica el tiempo de
retransmisión para el enlace de red local. (y por lo tanto se
especificarán por otro router en la linklocal red. El valor
predeterminado es 0 milisegundos.
RA Managed Flag Utilice el menú desplegable para activar o desactivar la
bandera administrado. Cuando se activa, el mensaje RA indica
que hay que utilizar un proceso de configuración automática con
estado para obtener Direcciones IPv6 tanto a nivel global como
local. El valor predeterminado es Desactivado. Sería la
configuración statefull
RA Other Use el menú desplegable para activar o desactivar el flag
Configure Flag configurar otras. Cuando se activa, el mensaje RA indica que hay
que utilizar un proceso de configuración automática con estado
para obtener la información de configuración que no es la
dirección IP pero que, sin embargo, es importante para la
configuración de IPv6, como p.e los direcciones de los servidores
DNS. El valor predeterminado es Desactivado. Sería la
configuración mixta
RA Max Router Se utiliza para establecer el intervalo de tiempo máximo entre
AdvInterval (s) el envío de anuncios de enrutador (RA) por esta interfaz a través
del vínculo de red local. Esta entrada debe ser no menos de 4
segundos (4000 milisegundos) y no más de 1800 segundos. El
usuario puede configurar un tiempo de entre 4 y 1800 segundos,
con un valor predeterminado de 600 segundos.
RA Min Router Se utiliza para establecer el intervalo de tiempo mínimo entre
AdvInterval (s) el envío de anuncios de enrutador (RA) por esta interfaz a través
del vínculo de red local. Esta entrada debe ser no menos de 3
segundos y no más de 0’75 (3 / 4) de la MaxRtrAdvInterval. El
usuario puede configurar un tiempo entre 3 y 1350 segundos, con
un valor predeterminado de 198 segundos.
Configuración de RA
La siguiente imagen corresponde a una captura realizada con Wireshark del envío de
un mensaje RA (Type 134) donde se ven los flags Managed y Other desactivados y
demás datos de temporización.

• Prefijo
En este apartado configuraremos la información a enviar en el mensaje RA: el propio

prefijo, los flag correspondientes y los tiempos
1. Prefijo: en forma de IPv6/máscara, será el valor a enviar en los mensajes RA y el

que utilizarán los host que se vayan a autoconfigurar. Se pueden configurar
varios prefijos
2. On Link flag: si está activo indica que el prefijo a utilizar en la
autoconfiguración de la red local es el correspondiente a esta interface (el router
puede tener más interfaces)
3. Autonomous flag: indica que el prefijo configurado puede ser utilizado para
autoconfiguración de la red local
4. Temporizaciones: Valid life time y Preferred life time
Como ejemplo de parámetros a configurar se indican los solicitados por el switch

DGS-3627
Prefix Utilice este campo para configurar cada uno de los prefijo para
direcciones IPv6 Global Unicast que se asignarán a los otros nodos
en el enlace de red local. Estos prefijos se enviarán en el mensaje de
anuncio de enrutador RA para ser compartido en el enlace de red
local. El usuario debe primero tener al menos una Dirección Global
Unicast para el switch de la que se obtiene el prefijo.
Prefered Life Este campo establece el tiempo durante el que este prefijo se
Time anuncia como preferido en el vínculo local de la red, utilizando la
configuración de direcciones sin estado. El usuario puede configurar
un tiempo de de entre 0 y 4294967295 milisegundos, con un valor
predeterminado de 604800 milisegundos.
Valid Life Time Este campo establece el tiempo que este prefijo se anuncia como
válido en el enlace de red local, cuando se utiliza la configuración
de direcciones sin estado. El usuario puede configurar un tiempo de
entre 0 y 4294967295 milisegundos.
Flag On-link Habilitando esta opción se indica, en el paquete IPv6, que el
prefijo IPv6 configurado aquí se asigna a este vínculo de red local.
Una vez que el tráfico ha sido enviado a estos nodos con este prefijo
IPv6 específico, los nodos se considerarán accesibles en el enlace de
red local.

Flag Autónomo Habilitando este campo se indica que este prefijo puede ser
usado para autoconfigurar direcciones IPv6 en el enlace de red
local.
Configuración del prefijo
En la siguiente imagen podemos ver una captura realizada con Wireshark del envío
de un mensaje RA con un prefijo de 64 bits de longitud, con los flags Onlink y Auto
activados y demás datos de temporización.

3.3. DHCPv6.
Vamos a probar la configuración de direcciones IPv6 usando DHCPv6 para el
siguiente esquema de una LAN:
La LAN estará formada por:
• Un ordenador Ubuntu-Linux (9.10).
• Un ordenador Windows XP (SP3).
• Un ordenador Windows 7.
• Un servidor DHCPv6. (Analizaremos Ubuntu-Server 9.10 y Windows 2008

Server).
• Un switch compatible IPv6. En nuestro caso D-Link DGS-3627
Para instalar el servidor debemos elegir un sistema operativo. Nosotros

analizaremos DHCPv6 en Windows 2008 server y Ubuntu-Linux Server.
Servidor DHCPv6 en Ubuntu-Linux Server 9.10.
Servidor DHCPv6 en Windows 2008 Server.
Además analizaremos como se instala el cliente DHCPv6 en los siguientes sistemas

operativos:
Cliente DHCPv6 en Ubuntu-Linux.
Cliente DHCPv6 en Windows XP (SP3).
Cliente DHCPv6 en Windows 7.
Logicamente el ámbito de las direcciones a repartir deberá determinarse en el servidor

DHCPv6.

3.3.1. DHCPv6 Ubuntu 9.10 Server
El siguiente gráfico muestra la configuración a obtener:
En este apartado analizaremos la instalación del Servidor DHCPv6 en Ubuntu

Server 9.10. La instalación de los clientes DHCPv6 está en los siguientes apartados.
3.3.1.1. Instalación de DHCPv6 en Ubuntu Server 9.10:
Existen varios proyectos que desarrollan la instalación de servidores DHCPv6 en

linux. Algunos están estancados o con versiones que requieren ser mejoradas. Algunos
son:
• WIDE-DHCPv6 inicialmente desarrollado dentro del proyecto KAME para

BSD y Linux.
• El proyecto DHCPv6 para la distribución Fedora.
• Dibbler.
Puede obtenerse más información en internet por ejemplo consultando:
http://www.google.com/url?q=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDH
CPv6&sa=D&sntz=1&usg=AFrqEzfcpC1F1DqKZQvy_8PZr1fA1VqxGQ
En nuestro caso, para Ubuntu-Linux utilizaremos Dibbler. Dibbler fue desarrollado

inicialmente por Tomasz Mrugalski and Marek Senderski y actualmente funciona tanto
en plataformas linux como windows.
Una vez instalado Ubuntu Server (en nuestro caso la versión 9.10.) procederemos a
instalar el servidor dibbler:
iplaza@ubuntuserver:~$ sudo aptitude install dibbler-server

Nos preguntará si deseamos que el servidor DHCPv6 se inicie siempre que

encendamos el servidor. Nosotros le indicaremos que no, ya que para hacer pruebas
preferimos iniciar el servidor manualmente.
Automaticamente todos los ficheros de configuración se instalarán en /etc/dibbler.

Además debemos asegurarnos de que exista el directorio /var/lib/dibbler y tengamos
permisos de escritura en él.
Para observar el estado del servidor, podemos ejecutar:
iplaza@ubuntuserver:~$ sudo dibbler-server status
En principio el servidor estará detenido
3.3.1.2. Configuración de DHCPv6 en Ubuntu Server 9.10:
Una vez instalado el servidor para configurarlo debemos editar el fichero server.conf
en /etc/dibbler
iplaza@ubuntuserver:~$ sudo nano /etc/dibbler/server.conf
Obviamente podemos usar el editor de texto que queramos, vi, nano, gedit (si lo
hemos instalado).
Existen múltiples opciones de configuración. En esta introducción probaremos la

más sencilla. Posteriormente analizaremos configuraciones más avanzadas. En
cualquier caso, en la documentación de dibbler todas las opciones están documentadas
de forma clara y precisa.
Basicamente podemos asignar un rango de direcciones de dos maneras:
• pool minaddress-maxaddress (dirección inicial - dirección final)
• pool address/prefix (usando la dirección y el prefijo)
En nuestro /etc/dibbler/server.conf quedará:
# server.conf
iface eth0 {
class {
pool 2000::500-2000::600
}}
Donde eth0 determina la interfaz encargada de repartir las direcciones y mediante

class determinamos el inicio y fin del rango de direcciones a repartir. (Las hemos
elegido al azar, obiamente el rango podría ser cualquier otro).

Ahora solamente debemos iniciar el servidor dibbler y este comenzará el reparto de

direcciones.
iplaza@ubuntuserver:~$ sudo dibbler-server start
Debemos tener en cuenta que los clientes pueden configurarse de muchas formas.
Por ello en los siguientes apartados estudiaremos ls opciones de configuración de cada
cliente en cada sistema operativo.
3.3.2. DHCPv6 Windows 2008 Server
El siguiente gráfico muestra la configuración a obtener:
En este apartado analizaremos la instalación del Servidor DHCPv6 en Windows

2008 Server. La instalación de los clientes DHCPv6 está en los siguientes apartados.
3.3.2.1. Instalación de DHCPv6 en Windows 2008 Server:
Una vez instalado Windows 2008 server en el servidor, conviene también instalar un
controlador de dominio y un servidor DNS. Se puede realizar ejecutando dcpromo en la
interfaz de comandos. A continuación y para comenzar con las instalación de DHCP
deberemos dar los siguientes pasos:
Inicio --> Herramientas administrativas --> Administrador del servidor

A continuación Agregaremos una función:
Leemos las advertencias, nosotros hemos instalado en el servidor una IPv4 estática:
192.168.0.80
Agregamos el servidor DHCP:
Podemos leer la ayuda para produndizar:
Obtenemos la configuración IPv4 que hemos establecido anteriormente en el

servidor:
Vamos a definir un ambito IPv4:
Red: 192.168.0.x
Mascara: 255.255.255.0
La puerta de enlace es opcional, en nuestro caso representa un router que podremos

añadir posteriormente.

Observamos que el ámbito IPv4 es correcto:
Comenzamos a configurar el ámbito IPv6. Observar con Atención la siguiente

ventana. En nuestro caso debemos debemos Deshabilitar el modo sin estado para este
servidor.
Usamos las credenciales actuales del usuario Administrador:
Confirmamos si todo es correcto:
El servidor DHCPv4 se instalará:
La instalación ha sido satisfactoria:
En el Administrador del servidor vamos al Servidor DHCP:
O podemos hacerlo: Inicio-->Herramientas administrativas-->DHCP
Una vez IPv4 está activo y con su ámbito definido, nos situamos en IP6, botón
derecho Agregamos ámbito:
Se ejectuta el asistente de ámbito nuevo:
Damos un nombre y descripción al ámbito:
Debemos elegir el Prefijo de las direcciónes IPv6 que vamos a repartir. Por
ejemplo, elegimos un prefijo de direcciones locales unicas para nuestra organización
fd00:1::1 Podríamos por ejemplo definir un ámbito para direcciones globales que
empiecen por 2001:xxxx pero en este caso elegimos el prefijo fd00:1::1/64 En cada
caso el administrador del sistema elegirá el ámbito que más le interese.
La Preferencia determina el grado de prioridad que tiene el servidor DHCPv6.

Dentro de una red puede existir más de un servidor DHCPv6, en ese caso, se establece
la prioridad de cada uno, siendo el número 0 el que tiene mayor prioridad a la hora de
asignar las direcciones IPv6

Si queremos agregar exclusiones (direcciones que no nos interesa que distribuya el

servidor), este es el momento. Nosotros de momento no agregaremos exclusiones.
Por último, debemos indicar la vigencia de las concesiones:

El asistente muestra un resumen de la configuración y nos permite finalizar.
En el caso de IPv4 siempre que los sistemas operativos de los ordenadores cliente
indiquen en la configuración TCP/IP del adaptador de red que la dirección se obtenga de
forma automática para observar las concesiones basta ir a la opción Concesiones de
direcciones en el servidor DHCP IPv4. En nuestro caso, observamos los tres
ordenadores de la red.

En el caso de IPv6 para los clientes Windows XP y Ubuntu-Linux (de momento) es

necesario instalar un cliente DHCPv6 como veremos en los siguientes apartados. En el
caso de Windows 7 el cliente viene instalado en el propio sistema operativo. Lo único
que debemos tener en cuenta en Windows 7 es la configuración del Firewall que
incorpora el sistema que en algunos casos impide la asignación de una dirección por
parte del servidor.
Una vez instalados los clientes (como veremos más adelante), bastaría con ir a la
opción Concesiones de direcciones en el apartado IPv6 y obtendríamos la información
de cada cliente. En nuestro caso:
Para terminar, normalmente, además de repartir las direcciones IP el servidor se

encarga de asignar puertas de enlace predeterminadas o servidores DNS. Dichas
opciones pueden seleccionarse en Opciones de ámbito.

La configuración del servidor DHCPv6 para Windows Server 2008 se ha realizado

satisfactoriamente.
3.3.3. DHCPv6 Cliente Ubuntu 9.10
Al contrario que en Ubuntu 9.04, en Ubuntu 9.10, la configuración de IPv6 puede

hacerse en modo comando o desde el entorno gráfico. Observemos la opción en el
entorno gráfico:
Sin embargo, para obtener una dirección DHCPv6 a través de un servidor no basta
con indicar en el modo gráfico que deseamos obtener una dirección IPv6
automaticamente. Debemos instalar un cliente. En nuestro caso vamos a instalar y
probar dibbler.
Para instalar dibbler en Ubuntu 9.10 Desktop version vamos a utilizar aptitude:

Como alternativa, también podríamos descargar el fichero desde
http://www.google.com/url?q=http%3A%2F%2Fklub.com.pl%2Fdhcpv6&sa=D&sn
tz=1&usg=AFrqEzdiHchTKXvdz6GeCxyYvUXl_Q2p-g
o directamente:
http://www.google.com/url?q=http%3A%2F%2Fklub.com.pl%2Fdhcpv6%2Fdibble
r%2Fdibbler-0.7.3-
src.tar.gz&sa=D&sntz=1&usg=AFrqEzf6NInE1Oc_l5hVWJLkiOEwBZPWJw
en este caso descargaríamos la versión 0.7.3, descomprimimos con gzip y extraemos

con tar. Nosotros ya lo hemos instalado en el paso anterior con sudo aptitude
install.
Automaticamente todos los ficheros de configuración se habrán instalado en

/etc/dibbler. Además debemos asegurarnos de que exista el directorio /var/lib/dibbler y
tengamos permisos de escritura en él.
Para observar el estado del servidor, podemos ejecutar:
En principio el cliente estará detenido.
Vamos a realizar una sencilla configuración de nuestra interfaz editando el fichero

/var/dibbler/client.conf:
Descomentamos (quitamos #) para configurar nuestra interfaz:

Iniciamos dibbler-client:
y para no tener problemas reiniciamos todos los adaptadores de red:
Si el servidor instalado es Ubuntu-Server 9.10 observaremos la dirección IPv6 que

nos ha proporcionado:

En el caso de Windows 2008 Server la dirección será:
El cliente DHCPv6 para la estación de trabajo Ubuntu ya está instalado y

funcionando. La configuración del fichero client.conf determinará el grado de
complejidad y las diferentes opciones de la dirección obtenida.
3.3.4. DHCPv6 Cliente Windows XP
Como sabemos, la opción TCP/IPv6 en windows XP no puede configurarse de

forma gráfica en XP (SP3). El proceso es el mismo tanto si el servidor DHCPv6 es
Linux o Windows:
Para configurar el cliente de windows XP vamos a utilizar el cliente dibbler, que

podemos descargar desde:
http://www.google.com/url?q=http%3A%2F%2Fklub.com.pl%2Fdhcpv6&sa=D&sn
tz=1&usg=AFrqEzdiHchTKXvdz6GeCxyYvUXl_Q2p-g
o directamente:
http://www.google.com/url?q=http%3A%2F%2Fklub.com.pl%2Fdhcpv6%2Fdibbler%2Fdibbl
er-0.7.2-win32.exe&sa=D&sntz=1&usg=AFrqEzenYtanrH1fvC_tm80dbgagZc-bnQ
en este caso instalamos la versión 0.7.2
Una vez descargado el fichero la instalación es tan simple como otra cualquiera en
windows. Veamos las ventanas:
Ejecutamos el .exe:
Aceptamos la licencia GNU de dibbler:
Vamos a instalarlo en C:\dibbler

Personalizamos la instalación, ya que esta versión para Windows de dibbler permite

también instalar el servidor DHCPv6 en cualquier ordenador. En este caso, nosotros
desactivamos la opción DHCPv6 server porque para funciones de servidor vamos a usar
servidores específicos Ubuntu y/o Windows 2008 Server.
Elegimos icono y nombre del programa:

Pulsamos install y aceptamos las ventanas siguientes:
Al finalizar dibbler se instalará en windows XP como un servicio. Para consultarlo:

Inicio-->Panel de control-->Herramientas administrativas-->Servicios
Para la configuración de la interfaz de red usaremos cualquier editor de texto para

abrir el fichero de configuración c:\dibbler\client.conf
Descomentamos (quitamos #) en las lineas indicadas y sustituimos "Local Network

Adapter" por el nombre de nuestro adaptador de red. En nuestro caso "Conexión de
área local" (Se debe tener en cuenta las mayúsculas/minúsculas y las tildes). Está es la
configuración más básica. En fichero client.conf puede configurarse de muchas
maneras.
Una vez guardado el fichero la configuración ya ha terminado. Si por ejemplo el

servidor que utilizamos es el Ubuntu-Server 9.10 que hemos configurado en el apartado
anterior, la dirección otorgada podría observarse desde la interfaz de comandos de la
siguiente manera:

Utilizando el servidor Windows 2008 Server que hemos configurado el resultado

sería:
El hecho de que la dirección asignada por Ubuntu-Server sea global (2000::/3) y la

asignada por Windows 2008 Server privada dentro de una organización (FD00::/8) no
tiene ninguna relevancia. Lo hemos decidido para que exista mayor claridad a la hora
de entender las distintas posibilidades.

Para terminar, si tenemos algún problema al obtener la dirección desde el servidor,

podemos detener y volver a iniciar el servicio dibbler-client desde el entorno gráfico de
XP o ejecutando c:\dibbler\dibbler-client stop y a continuación c:\dibbler\dibbler-
client start desde la interfaz de comandos.
Además podemos reiniciar la obtención de direcciónes ejecutando: netsh interface

ipv6 renew también desde la interfaz de comandos.
3.3.5. DHCPv6 Cliente Windows 7
Windows 7 no necesita instalar ningún cliente para la obtención de direcciones IPv6

desde un servidor DHCPv6. Basta con indicar en la configuración del protocolo
TCP/IPv6 que la dirección se obtendrá automaticamente. Veamos:
Inicio-->Panel de control-->Redes e Internet-->Centro de redes y recursos

compartidos-->Conexión de área local-->Propiedades-->Protocolo de Internet versión
6(TCP/IPv6)
Si el servidor que poseemos en la red está configurado como nuestro Ubuntu-Server

9.10, el cliente windows 7 obtendrá la siguiente configuración automaticamente:

Sin embargo si el servidor de la red es el Windows 2008 Server, obtendríamos:
La obtención de la dirección por parte del cliente de windows 7 es automática.

3.4. Configuración manual.

Como indicamos anteriormente, un PC IPv6 típico no necesita configurar
manualmente su dirección IPv6. Este método está orientado a servidores y/o routers
IPv6. Sin embargo en caso necesario, la configuración manual es muy sencilla y como
es habitual en la mayoría de los sistemas operativos puede hacerse de forma gráfica o
mediante la interfaz de comandos.
Vamos a analizar la configuración manual de los PC en los siguientes sistemas

operativos
Ubuntu-Linux 9.10
Windows
3.4.1. Configuración manual en Ubuntu-Linux
Vamos a analizar los siguientes puntos:
Añadir direcciones IPv6 en Ubuntu-Linux.
Mediante el entorno gráfico.
Mediante comandos.
Más opciones de la configuración manual en Ubuntu-Linux.
Añadir direcciones IPv6 en Ubuntu-Linux:

3.4.1.1. Mediante el entorno gráfico:
SistemaPreferenciasConexiones de redMarcamos la interfaz deseada, en

nuestro caso Auto eth0 y pulsamos editar
Seleccionamos el metodo Manual

Y podemos escribir la direccón y el prefijo que deseamos introducir de forma

manual. En este punto es importante recalcar que el usuario que ejecuta el entorno
gráfico debe tener privilegios de administrador o root. Si es un usuario normal la
opción APLICAR permanecera inactiva.
Por ejemplo, supongamos que queremos introducir la siguiente dirección unicast:
2001:db8:290c:1291::3/64
Pulsamos Aplicar y probablemente nos pedirá una contraseña con privilegios para
realizar el cambio. Introducimos la contraseña. La dirección ha sido asignada tal y
como lo indica la ventana gráfica.

Para corroborar que la dirección ha sido asignada correctamente podemos abrir la

terminal y ejecutar el comando ip addr show. Como observamos en el gráfico, es
correcto.
3.4.1.2. Mediante comandos:
Por ejemplo, para configurar una dirección IPv6 unicast 2001:db8:290c:1291::3 en

la interfaz eth0:
ip addr add direccion_ipv6 dev nombre_interfaz
En nuestro caso:
ip addr add 2001:db8:290c:1291::3 dev eth0
Si lo hemos escrito correctamente veremos que la nueva dirección ha sido añadida

para la interfaz especificada. Como indicamos anteriormente, aunque podamos usar
ifconfig, este comando ha sido sustituido por el uso del comando ip. Veamos la
respuesta obtenida en ambos casos:

Para determinar el correcto funcionamiento podemos utilizar el comando ping6 a la

nueva dirección.
ping –c 4 2001:db8:290c:1291::3
Los resultados obtenidos son satisfactorios.
Más opciones de la configuración manual en Ubuntu-Linux:
En el caso anterior, hay que destacar que la configuración que hemos realizado
desaparecerá cuando reiniciamos el ordenador. Es decir, la dirección de ámbito
global 2001:db8:290c:1291::3 no será asignada. Solamente se configura

automáticamente la dirección de enlace local.
Para hacer permanente la asignación de la dirección global deberemos especificarlo

en el fichero /etc/network/interfaces de Ubuntu-Linux. Veamos como podemos hacerlo:
Vamos a editar el fichero usando gedit
Deberemos introducir la nueva dirección a continuación:
Para reiniciar el adaptador anteriormente usábamos ifdown y luego ifup
Sin embargo, actualmente se recomienda el uso del comando ip
sudo ip link set dev eth0 down
sudo ip link set dev eth0 up
Veamos la configuración y observaremos que la dirección es permanente.
Obviamente, si reiniciamos el ordenador, la dirección de ámbito global permanecerá

configurada:

Como vimos anteriormente el comando ip permite muchas más opciones de

configuración:
Para mostrar las interfaces bastaría con escribir:
sudo ip link show
Podríamos mostrar una interface concreta indicándolo:
sudo ip link show eth0
Si queremos eliminar la dirección que hemos introducido anteriormente, bastaria con

ejecutar:
sudo ip addr del 2001:db8:290c:1291::3 eth0
Como hemos indicado para modificar opciones de una interfaz ip link set posee las
siguientes opciones:
Para activar o desactivar una interface:
ip link set eth0 on
ip link set eth0 off
Por ejemplo para indicar la unidad máxima de transferencia de una interfaz:
ip link set eth0 mtu tamaño_en_bytes
Hemos utilizado eth0 para los ejemplos, pero logicamente la interfaz puede ser la
que cada uno desea dentro de las interfaces configuradas en el ordenador.

Mediante el uso de la ayuda en cada caso, el usuario interesado podría profundizar

más en el estudio de cada una de las opciones.
3.4.2. Configuración manual en Windows
Vamos a analizar los siguientes puntos:
Añadir direcciones IPv6 en Windows XP.
Mediante comandos.
Añadir direcciones IPv6 en Windows 7
Mediante comandos.
Más opciones de la configuración manual en Windows.
3.4.2.1. Añadir direcciones IPv6 en Windows XP:
Veamos que posibilidades existen tanto desde el entorno gráfico como desde la
interfaz de comandos:
a)Mediante el entorno gráfico:
En Windows XP de momento (es casi seguro que Microsoft no realizará los cambios
necesarios) la configuración de IPv6 no puede modificarse desde el interface gráfico.
Al contrario de lo que ocurre para IPv4, la opción Propiedades de cualquier interfaz de
red que seleccionemos ( InicioPanel de controlConexiones de red, seleccionar
interfaz y botón derecho ) permanece inactiva.

Por lo tanto para modificar las configuraciones usaremos la interfaz de comandos

con netsh.
b)Mediante la interfaz de comandos:
Por ejemplo, para configurar una dirección IPv6 unicast 2001:db8:290c:1291::1 en

la interfaz “Conexión de área Local” con un valor infinito para los parámetros “valid
lifetime” y “preferred lifetime” y hacer que este cambio sea persistente (no cambie cada
vez que se reinicia el sistema):
netsh interface ipv6 add address "Conexión de área local" 2001:db8:290c:1291::1
Se debe tener cuidado al escribir el nombre puesto que "Conexión de Area local" es
distinto de "Conexión de área local" tanto en la A mayúscula como en la tilde.
Cualquier error de sintaxis obtendra la siguiente respuesta:

para la interfaz especificada.

Una opción mucho más sencilla es indicar el índice de la interfaz (el número) en
lugar de su nombre, en nuestro caso, sería el 4, por tanto, podríamos hacer lo mismo
escribiendo:
netsh interface ipv6 add address 4 2001:db8:290c:1291::1
Para determinar el correcto funcionamiento podemos utilizar el comando ping a la

nueva dirección.
ping :2001:db8:290c:1291::1
Los resultados obtenidos son satisfactorios

3.4.2.2. Añadir direcciones IPv6 en Windows 7:
Veamos que posibilidades existen tanto desde el entorno gráfico como desde la
interfaz de comandos:
a) Mediante el entorno gráfico:
Usando el entorno gráfico:
Inicio--> Panel de control --> Redes e internet --> Centro de redes y recursos
compartidos:
Pulsamos Conexión de área local.
Aparece una ventana indicando el estado de la conexión, pinchamos sobre

Propiedades

Pulsamos Protocolo de Internet versión 6 (TCP/IPv6) y Propiedades
Basta con escribir la nueva dirección IPv6, la longitud del prefijo y la puerta de
enlace si es que existe.
b) Mediante la interfaz de comandos:
Desde la interfaz de comandos, utilizando netsh:
En Windows 7 al ejecutar la interfaz de comandos, a veces como en este caso es

necesario ejecutarla con privilegios de administrador (como ocurre con sudo en Linux).
Para ello, buscaremos el icono de la interfaz de comandos desde Inicio y pulsaremos
sobre el botón derecho:
A continuación clickaremos sobre la opción "Ejecutar como administrador".
Vamos a configurar una nueva dirección IPv6 2001:db8:290c:1291::2 en la interfaz

“Conexión de área local” con un valor infinito para los parámetros “valid lifetime” y

“preferred lifetime” y hacer que este cambio sea persistente (no cambie cada vez que se
reinicia el sistema):
netsh interface IPv6 add address "Conexión de área local" 2001:db8:290c:1291::2
Tal como indicamos en la instalación manual de XP se debe tener cuidado al escribir

el nombre puesto que "Conexión de Area local" es distinto de "Conexión de área local"
tanto en la A mayúscula como en la tilde.

para la interfaz especificada:

Una vez entendida la instalación de IPv6 y su resultado en W7 para determinar el

ping 2001:db8:290c:1291::2
Los resultados obtenidos son satisfactorios
c) Más opciones de la configuración manual en Windows:
El entorno netsh diseñado por Microsoft puede utilizarse en todas las versiones
modernas de Windows. Por ello, vamos a analizar algunas opciones más que podeis
probar desde Windows XP, Windows Vista, Windows 7, etc…
Obviamente, la configuración manual de IPv6 no consiste unicamente en añadir

direcciones IPv6. Existen muchas más opciones. En el entorno netsh in ipv6 aparecen:
Donde se especifica para que podemos utilizar cada opción. Por ejemplo, si
quisieramos eliminar la dirección añadida utilizaríamos la opción delete. Para ver sus
opciones:

Por tanto escribiríamos:
netsh in ipv6 delete address 2001:db8:290c:1291::2
Podemos eliminar una interfaz completa, una dirección concreta de una interfaz, etc.
Para reiniciar las direcciones IPv6:
netsh in ipv6 renew
Otra opción interesante para realizar modificaciones es set
Por ejemplo dentro de la opción: netsh in ipv6 set address

Podríamos indicar que nuestra dirección IPv6 es permanente o persistente, es decir

se mantiene aunque reiniciemos el ordenador, indicando:
netsh in ipv6 set address “Conexión de área local” 2001:db8:290c:1291::2

store=persistent
El usuario interesado podría profundizar más en el estudio de cada una de las

opciones.

3.5. Planificación de una red IPv6

La secuencia de pasos a dar para realizar la implementación de una red IPv6 sería la
indicada en la tabla siguiente
Tarea Descripción
1. Preparar el hardware para Comprobar que el hardware se pueda utilizar

admitir IPv6. con IPv6.
2. Disponer de un ISP que admita Buscar un ISP que admita IPv6. Se pueden
IPv6. utilizar dos ISP, uno para IPv6 y otro para IPv4.
3. Comprobar que las Verificar que las aplicaciones sean compatibles

aplicaciones estén preparadas con IPv6.
para funcionar con IPv6.
4. Disponer de prefijo de sitio Solicite al ISP un prefijo de sitio de 48 bits.
5. Crear un plan de direcciones de Se debe planificar la topología de red IPv6

subredes. global y el esquema de direcciones para poder
configurar IPv6 en los distintos nodos de la red.
6. Diseñar un plan para el uso de Establezca los routers que deben ejecutar
túneles. túneles a otras subredes o redes externas.
7. Crear un plan de direcciones Se debe planificar la dirección de servidores,

para entidades de la red. routers y hosts antes de configurar IPv6.
8.Desarrollar directrices de A la hora de desarrollar directrices de

seguridad de IPv6. seguridad de IPv6, consulte las funciones de filtro
IP, arquitectura de seguridad IP (IPsec), Internet
Key Exchange (IKE) y otras funciones de
seguridad
9. (Opcional) Configurar una Por motivos de seguridad, se precisa un plan de

DMZ. direcciones para la DMZ y sus entidades antes de
configurar IPv6.
10.Habilitar los nodos para que Configurar IPv6 en todos los hosts y routers.
admitan IPv6.
11. Activar los servicios de red Comprobar que los servidores puedan admitir
IPv6.
12. Actualizar los nombres de Comprobar que los servidores DNS, NIS y
servidor para la compatibilidad LDAP se actualicen con las nuevas direcciones

con IPv6. IPv6.
Más información en el documento original Guía de administración de sistema:

Servicios IP de Sun Microsystem

4. Mecanismos de trasición para conseguir conectividad.

En la transición buscamos la compatibilidad de los host y redes IPv6 con redes
IPv4 existentes.
El Mecanismo explica la forma de crear túneles.
El túnel es el camino virtual que se crea para atravesar redes IPv4.
El mecanismo se sirve de túneles para enviar datagramas IPv6 encapsulados en

paquetes IPv4 y además, emplea infraestructuras IPv4 para comunicación con redes
IPv6 y viceversa, ya que es necesaria la coexistencia de los dos protocolos durante un
tiempo indefinido.
Existen varios mecanismos para utilizar las infraestructuras IPv4 mientras la red
IPv6 está siendo implantada. Los mecanismos se clasifican en:
• IPv6 in IPv4
• IPv6 to IPv4
• Teredo
Mientras nuestro proveedor de Internet no nos ofrezca una dirección ipv6 para
nuestro ADSL no podremos tener una red IPv6 nativa en la Empresa.
EJEMPLO:
Supongamos un ordenador de la Red Empresa1 desea ver la página Web de otro

ordenador de la Red de la Empresa 2. Cada Empresa tiene un túnel configurado cuyo

extremo inicial es un nodo (Firewall, host de la Empresa) que conecta con un servidor
en Internet (extremo final). Los dos nodos tienen una dirección IPv4 asociada.
En el Navegador pondríamos http://[ipv6 de ord. Pagina web]
• El paquete que se genera en el ordenador es un paquete con formato IPv6.

Este paquete llega hasta el Firewall y se encuentra con el extremo inicial del
túnel. En este momento se encapsula en un paquete IPv4. Sale por el ADSL
hasta llegar al broker1 (mecanismo usado para crear el túnel).
10.10.10.50 216.66.80.26
IPv6 ori. IPv6 desti. Datos
• Una vez el paquete llegue al broker1 este vuelve a desencapsularse y se

convierte a un paquete con formato IPv6. Este paquete atraviesa la red IPv6
nativa hasta llegar al broker2 (broker con el que tiene el túnel la Empresa 2.
No necesariamente el mismo que el de la Empresa1).
• En este momento el paquete debe encapsularse en un paquete IPv4

nuevamente para llegar a la Empresa2 atravesando el túnel que tiene
configurado.
216.66.82.34 10.13.2.5
• Al final del túnel se vuelve a desencapsular convirtiéndose en un paquete

IPv6 llegando al ordenador final que tiene la página Web que se ha pedido.
La dirección del extremo final del túnel ha de ser determinada a través de

información de configuración en el nodo que realiza el túnel (extremo inicial del túnel),
“Túnel configurado” se denomina a aquel tipo de túnel donde el extremo final del
túnel es explícitamente configurado.
4.1. IPv6 in IPv4

Los proveedores de túneles (broker) que se ajusten a los principios de RFC 3053
describen un sistema con el cual los usuarios pueden solicitar la creación de un túnel
IPv6 en un host llamado Punto de Presencia (PoP) ofreciendo al usuario conectividad
IPv6.
Existen aplicaciones que permiten utilizar, de forma libre y gratuita, nuestras

direcciones Ipv4 actuales, sobre las infraestructuras IPv4, para acceder a redes y sitios
IPv6.
El “tunnel broker” es el lugar donde el usuario se conecta para registrar y activar

“su túnel”. El “broker” gestiona (crea, modifica, activa y desactiva) el túnel en nombre
del usuario. No requiere la configuración de un Router. Se trata de ISP’s IPv6
“virtuales”, proporcionando conectividad IPv6 a usuarios que ya tienen conectividad
IPv4.
El mecanismo para su configuración es tan sencillo como indicar en un formulario

Web, datos relativos al S.O., la dirección IPv4, un “apodo” para la máquina, y el país
donde está conectada. El servidor de túneles crea los registros DNS, el extremo final del
túnel, y genera un script para la configuración del cliente.
Un ejemplo de este sistema es http://www.tunnelbroker.net.
El “tunnel server” es un Router con pila doble (IPv4 e IPv6), conectado a Internet,
que siguiendo órdenes del “broker” crea, modifica o borra los servicios asociados a un
determinado túnel/usuario.
Pila doble: Consiste en usar los protocolos Ipv4 e Ipv6 simultáneamente en pilas
separadas. En cada pila tendrá una dirección IP de cada tipo, estas pueden estar o no
relacionadas. De esta forma, un dispositivo de este tipo puede comunicar enviando
tráfico con nodos que soportan uno de los dos protocolos.
http://lacnic.net/documentos/lacnicxi/presentaciones/Intro_Consulintel_Tutorial_IPv6_LACNIC_XI_v1_2.pdf
El túnel creado es un túnel directo entre un punto y otro punto. No se tiene acceso
directo a internet con IPv6. Se puede configurar el túnel manualmente (bien el usuario
mediante un comando o el sistema operativo porque lo tiene configurado) o
automáticamente (el broker).
Hay una variedad de proveedores de túneles que proporcionan sus propias

implementaciones basadas en los objetivos de negocio.

Vamos a mostrar una tabla con los distintos proveedores de Túnel broker existentes.
B
RD
Proveedor Cobertura Subred Protocolos Estático NS
G Registro Configuración Idioma
P
Estados
Unidos,
Canadá, / 64 y
Hurricane Requiere
Europa (6 /48 6in4 Sí Sí Sí Sitio web Inglés
Electric[4] registro
países), subred
Hong Kong,
Tokio
RIPE,
Estados ARIN,
/ 64 del
Unidos, APNIC,
túnel y TIC /AICCU,
Brasil, Europa 6in4, LACNIC,
SixXS de Sí Sí Manual, Inglés
(13 países), AYIYA AFRINIC,
subred / página web
Nueva O
48
Zelanda[5] directamen
te registro
Anónimo,
o un
Montreal, registro
6in4,
gogo6/Free Amsterdam, / 56 de (mediante TSP,
4in6, Sí Sí Inglés
net6[2] Taipei, subred el registro Sitio web
TSP
Sydney en
gogoNET]
)
En la tabla anterior se muestra la siguiente información:
Proveedor El nombre del proveedor de túneles.
Cobertura Lugares donde el proveedor de túneles tiene puntos de presencia.
Subredes Las máscaras de red que provee.
Protocolos Los protocolos de tunelado son provistos por el proveedor. Esto tiene
impacto para la posibilidad de usar los túneles en máquinas que se
encuentran detrás de NAT o en casos donde la IPv4 del usuario
cambia frecuentemente.
Estático Indica si el proveedor de túneles provee direcciones estáticas.
Reversos Si el proveedor entrega DNS inversos.
BGP Si el proveedor provee opcionalmente ruteo BGP sobre el túnel. BGP

significa Border Gateway Protocol. Este último es un protocolo

mediante el cual se intercambia información de encaminamiento entre

sistemas autónomos.
Registro Los métodos de registro disponibles, si se requirieran.
Configuración Métodos que están disponibles para configurar túneles y subredes

provistas por el proveedor.
Idiomas Idiomas que están soportados por las interfases web y otros canales de
comunicación de los proveedores.
Brokers Manuales: Hurricane Electric...
Brokers automáticos: SixXS, Freenet6, Hexago...
NOTA:
• Freenet es un bróker que se comunica muy bien con cualquier tipo de túnel
(6in4, 6to4).
• Hurricane se comunica bien hacia Freenet pero no hacia 6to4. Para que esta
comunicación sea posible hace falta un relay router.
4.2. IPv6 to IPv4

Este mecanismo fue diseñado para permitir conectividad IPv6 sin la cooperación de
los proveedores de internet.
• Este sistema puede funcionar en un Router (proveyendo conectividad a toda

una red) o en una máquina en particular. En ambos casos se necesita una
dirección IP pública para crear el túnel.
• Muchas máquinas están conectadas a Internet IPv4 a través de uno o varios

dispositivos NAT, por lo general a causa de la escasez de direcciones IPv4.
En tal situación, la única dirección IPv4 pública disponible se asigna al
dispositivo NAT, el extremo del túnel 6to4 debe aplicarse en el
dispositivo NAT.
• La clave del sistema consiste en la asignación de direcciones IPv6 que

contienen embebida la dirección IPv4 pública. No hace falta configuración,
ya que todas las IPv4 públicas son únicas y por lo tanto, tendremos también
una IPv6 equivalente única.
Estas direcciones tienen todas el prefijo 2002::/16. De esta manera, cuando es

necesario convertir un paquete IPv6 para que atraviese la red IPv4, el Router sabe la
dirección a la que debe estar dirigido el paquete IPv4 generado.

Ejemplo del resultado de una IPv6 a partir de una IPv4 pública:
IPv4: 1.2.3.4
IPv6: 2002:0102:0304::1
Vamos a ver un ejemplo de creación de un túnel 6to4 en una máquina Debian y

que tiene asignada una IPv4:
Para calcular una dirección IPv6 a partir de una IPv4 podemos usar las órdenes
ipv6calc y printf. Para usar la orden ipv6calc previamente deberemos instalarla.
#apt-get install ipv6calc
# ipv6calc --quiet --action conv6to4 1.2.3.4
#printf “2002:%02x%02x:%02x%02x::1\n” a b c d
El gateway es siempre una dirección especial anycast (192.88.99.1) que apunta al

Router 6to4 más cercano.
Vamos a usar la Interface sit0 que tiene el debían desactivada.
IP pública ADSL 79 148 113 222

DECIMAL
IP pública ADSL 4f 94 71 de
HAXADECIMAL
#nano /etc/network/interfaces
auto sit0
iface sit0 inet6 static
address 2002:4f94:71de::1 (4F94:71 de IP pública del ADSL en hexadecimal)
netmask 16
gateway ::192.88.99.1
endpoint any
local 79.148.113.222 (Ip pública del ADSL)

Este mecanismo funciona aún cuando la dirección IPv4 global (pública) es única y se
accede a la red mediante mecanismos NAT (Network Address Translation), que es el
caso más común en las redes actuales para el acceso a Internet a través de ISP’s.
• El mecanismo 6to4 está basado en la creación de túneles ipv6-in-ipv4. Su

filosofía es permitir a los nodos Ipv4 que implementen el mecanismo 6to4.
Obtener una dirección Ipv6 basada en la dirección Ipv4 pública del nodo y
poder contactar a través de Ipv6 bien con otros nodos 6to4, usando para ello
la red Ipv4 como transporte, o bien con otros nodos Ipv6 nativos usando para
ello relays 6to4.
http://www.ipv6tf.org/images/figure_6to4.jpg
En el caso en el que se conectan dos redes que utilizan 6to4 la relación

es simétrica. los Routers de ambos sistemas intercambian entre sí los
paquetes.
• Para enviar un paquete a una dirección IPv6 "nativa" es necesario, en

cambio, enviarlo a un Router que esté conectado a la red IPv6 real. Esto se
logra enviando el paquete a una dirección anycast: 192.88.99.1. El emisor no
necesita saber dónde está ese Router, y se espera que muchas de las distintas
redes que conforman internet provean Routers que respondan a esta
dirección. Asimismo, desde la red pura IPv6 cuando un paquete está
destinado a una red 6to4 debe ser dirigido a un Router que anuncie manejar
el prefijo 2002::/16.
• Cuando la dirección IPv4 utilizada es fija, el prefijo IPv6 que se genera en

base a ella es fijo también.

4.3. Teredo.
El objetivo de este mecanismo es dar conectividad IPv6 a aquellos usuarios que se
encuentran detrás de un NAT y que por lo tanto el host tiene una IP privada.
Su función es encapsular paquetes Ipv6 dentro de datagramas UDP-IPv4 para poder

atravesar dispositivos NAT y la red de Internet IPv4.
De forma similar a 6to4, este sistema se habilita de forma automática aportando una
dirección IPv6 a los nodos Windows Xp/ 2003/ Vista y Windows 7 finales del usuario
cuando se cumplen las siguientes condiciones:
• La pila IPv6 está habilitada
• No existe conectividad nativa IPv6 y no dispone de una dirección IPv4

pública.
Teredo desempeña múltiples funciones:
• Determina la conectividad UDP sobre IPv4 y descubre el tipo de nat presente

(DNAT, SNAT).
• Asigna una dirección IPv6 única global a cada host.
• Enruta tráfico entre host con Teredo y host IPv6 nativos (es decir, que no
usan Teredo)
Teredo aporta una dirección IPv6 con la siguiente forma a cada host:
Bits 0 - 31 32-63 64-79 80-95 96-127

Longitud 32 bits 32 bits 16 bits 16 bits 32 bits
Descripción Prefijo Teredo Server Flags puerto UDP IPv4 pública del cliente
IPv4
Ejemplo 2001:0000 4136:e378 8000 63bf c000:022d
65.54.227.120 código Nat 40000 192.0.2.45
http://en.wikipedia.org/wiki/Teredo_tunneling
• El mecanismo Teredo requiere de cierta infraestructura, como servidores y

relays Teredo. Los servidores usualmente no redireccionan paquetes de
datos. Su función principal es facilitar el direccionamiento entre clientes y
relays Teredo. Por lo tanto, Teredo Server debe estar en la red pública de
internet IPv4.
• Los host se conectan con los nodos Teredo Server y estos últimos detectan
detrás de qué tipo de nat se encuentra el cliente. El host (Teredo cliente)
mantiene un vínculo permanente con Teredo Server enviando cada cierto
tiempo paquetes UDP. Este sistema asegura que el servidor puede contactar
con cualquiera de sus clientes y que el túnel está activo.
• Los Relays Teredo son puertas de enlace entre internet IPv6 y los clientes
teredo. Su función principal es la transmisión y recepción real de los
paquetes de tráfico IPv6. Los relays deben estar en internet IPv4 e IPv6.
Estos relay pueden contactar con Servidores Teredo si lo necesitan para
redireccionar paquetes.
• En la práctica, cuándo un nodo Teredo Cliente quiere contactar con un nodo

IPv6 nativo, debe encontrar el Teredo relay que le corresponde (el cuál
pública los nº de puertos UDP y una dirección pública IPv4 para enviar
paquetes IPv6 encapsulados). Gracias a esta información el paquete se
encapsula en paquetes IPv4 y se transmiten a través de su túnel hasta el
Teredo relay. Este desencapsula el paquete y lo envía a Internet IPv6, de
modo que el paquete finalmente debe alcanzar el nodo IPv6.
• El servidor Teredo requiere poco ancho de banda debido a que no están

involucrados en la transmisión y recepción real de los paquetes de tráfico
IPv6. Además, no requiere de ningún acceso a los protocolos de
enrutamiento de Internet.
• Un Teredo Relay potencialmente requiere mucho ancho de banda de Red.

De esta forma, Teredo Relay recibirá el tráfico desde cualquier host IPv6
dirigido a cualquier cliente Teredo, y lo remitirá en formato UDP/IPv4.

Servidores de Teredo públicos:
• teredo.remlab.net / teredo-debian.remlab.net (Francia)
• teredo.autotrans.consulintel.com (España)
• teredo.ipv6.microsoft.com (por defecto para Windows XP/ 2003 / Vista /

2008 / 7)
• teredo.ngix.ne.kr (Sur de korea)
• teredo.managemydedi.com (USA, Chicago)
Teredo sólo puede proporcionar una dirección IPv6 única por el túnel a un punto
final. Como tal, no es posible utilizar un único túnel Teredo para conectar varios hosts.
Para que los túneles Teredo funcionen los Firewalls no deben filtrar los paquetes
UDP 3544 entrantes ni salientes.

5. EJEMPLOS de tuneles: Tunnel Broker y Teredo

En este apartado vamos a exponer diferentes ejercicios resueltos.
1. Creación de túnel en un host con Windows con freenet6
2. Creación de túnel de un firewall de Debian con hurricane
3. Creación de túnel Teredo
5.1. Creación de túnel en un host con Windows con Freenet6.

La red que tenemos es una LAN IPv4 detrás de un ADSL con su IP pública. Esta
vez no existe un Firewall entre el ADSL y la LAN.
Vamos a ver los pasos a seguir para crear un túnel con freenet6 en un host
(Windows) de la LAN (en este caso estamos detrás de NAT) y de esta manera conseguir
conectividad Ipv6 para este host teniendo Ipv4.
Antes de comenzar unas notas:
1. Nosotros vamos a configurar en el host la parte cliente (gogoCLIENT) del

túnel. El cliente deberá interactuar con el servidor (gogoSERVER).
2. El túnel utiliza el protocolo TSP que establece y mantiene el túnel de datos

estático. GogoCLIENT conecta con gogoSERVER y obtiene información
relativa al túnel usando el protocolo TSP. Si el host donde se va a crear el
túnel se encuentra detrás de un FIREWALL deberemos abrir el puerto 3653
en el mismo. En nuestro caso no estamos detrás de un FIREWALL por
lo tanto no abriremos ningún puerto.
3. El código fuente es la misma para casi todas las plataformas cliente.
4. Se puede configurar el cliente para conectarse a un único gogoSERVER o a

múltiples SERVIDORES. Esta flexibilidad tiene dos propósitos: Ofrecer
mejor calidad de servicio permitiendo a los usuarios conectarse al servidor
más cercano y mantener redundancia de forma que ante cualquier suceso en
el que un servidor no esté disponible el túnel seguirá funcionando.
5. Existe un interfaz gráfico para el sistema Operativo Microsoft Windows que

permite una fácil configuración del túnel y que ofrece un informe con el
estado del servicio.

COMENCEMOS:
• Crear una cuenta
Como primer paso, tenemos que ir a la web de gogo6:
http://www.gogo6.com
Haremos clic en el vínculo que pone Freenet6 y nos aparecerá la siguiente ventana
en la cual tendremos que elegir la opción Sign Up:
Rellenaremos el formulario que nos aparece completando así el registro.

Una vez registrados, podremos iniciar sesión introduciendo los datos del registro y
haciendo clic en Sign In.
• Descarga de software
Una vez iniciada la sesión, nos aparece una ventana en la que tendremos que hacer
clic en DOWNLOAD Latest gogoCLIENT .
Se nos abrirá una ventana con dos versiones diferentes, “Basic Version” y “Home
Access versión”. Descargamos la que nos convenga. Esta última se diferencia de la
primera porque dispone de una herramienta llamada HomeAccess que permite utilizar el
software como servicio web.

• Instalación de gogoCLIENT
Se nos descargará un fichero ejecutable en el que haremos doble clic y con una
rápida y sencilla instalación dispondremos del software de gogo instalado en nuestro
PC.
Ejecutamos gogoCLIENT utility. Debemos tener permisos de administrador. Esta

utilidad nos permite conectarnos Identificándonos o anónimamente al servidor freenet6
haciendo clic en el botón Connect de la pestaña Basic.

La conexión se realizará según el botón de opción seleccionado:
Seleccionando “Connect anonymously” en “Server Address” escribiremos

“anonymous.freenet6.net”. Esta será una conexión anónima. Tan sólo nos permitirá
navegar con IPv6 en Internet. No podrá nadie acceder a una página Web que tengamos
alojada en nuestra máquina. Además, no dará una dirección Ipv6 a ningún host de
nuestra LAN.
Seleccionando “Connect Using the Following Credentials” en Server Address

pondremos “authenticated.freenet6.net” y en user name y password el nombre de
usuario y la contraseña del registro realizado en freenet. En este caso tendremos todas
las opciones comentadas si las tenemos activas en la configuración avanzada que se
explica más adelante.
La opción “launch de gogoclient service system at startup” activada cada vez que
reiniciamos o encendemos el ordenador pondrá el túnel en marcha. De forma
predeterminada tendremos la red con IPv6. No es conveniente tenerla activada por
seguridad.
Para conectarnos con una identificación, previamente tendremos que registrarnos

desde la página web en la que nos aparecían las diferentes versiones de gogoCLIENT
haciendo clic en here.

Utilizaremos los datos del registro para conectarnos con nuestra identificación en la
pestaña Basic, con esta identificación, podremos utilizar la utilidad de servicio web en
la versión HomeAccess.
Si clicamos en la pestaña Status, veremos la información que freenet6 nos ha

asignado, observando que se trata de una configuración Ipv6 in UDP Ipv4. (Significa
que estamos detrás de nat).
La longitud del prefijo asignado es de 64 bits. En los túneles con conexión anónima
el prefijo cambia respecto a la conexión autenticada. En el primer caso, el prefijo tiene
la forma 2001:5c0:1400:a:: /64 (acaba con a) y la dirección IPv6 que tiene asociada
cambia con cada conexión del túnel mientras que en el segundo el prefijo tiene la
forma 2001:5c0:1400:b:: /64 (acaba con b) y la dirección IPv6 es asignada de forma

permanente al usuario y no cambia aunque el usuario se desplace a una dirección IPv4

nueva.
En el modo de autenticación, existen dos métodos disponibles para realizar la

autenticación: autenticación simple o autenticación encriptada. Con la autenticación
simple, la identificación de usuario y contraseña se envían como texto sin cifrar, con la
autenticación encriptada (MD5), SASL-DIGEST-MD5 se utiliza para cifrar la cuenta.
Para cada túnel autenticado se crea un registro AAAA en el servidor DNS de

Freenet6. El FQDN asociado con los túneles autenticados utiliza el formato
userid.broker.freenet6.net, donde userid es el nombre de la cuenta del usuario final.
Un usuario registrado como "increibleipv6" tendría la siguiente entrada DNS:
increibleipv6.broker.freenet6.net. Un usuario anónimo no tiene registro DNS.
Varios host simultáneamente no pueden autenticarse con el mismo usuario. De

forma anónima desde cualquier host de la LAN se puede crear un túnel.
Se puede conseguir diferentes cuentas en freenet siempre y cuando tenga direcciones

de correo diferentes.
El túnel expirará a los pocos minutos después de que el cliente se haya

desconectado.
Desde este momento, podemos comprobar la conexión Ipv6 haciendo un ping a la

dirección de google desde la consola cmd.
En el momento en el que ejecutamos el software, podremos comprobar que nos ha

creado una conexión virtual que funciona de túnel.

NOTA:
Para navegar bien con direcciones IPv6 es necesario que la versión del Navegador
Explorer sea 8 o posterior. Podemos personalizar la configuración. Para ello en el
software de gogo6client elegiremos la ficha Advanced:
• La primera opción “Tunnel Mode”: Nos permite elegir entre varias opciones.
IPv6-inIPv4 Tunnel, IPv6-inIPv4 Tunnel (Native), IPv6-in-UDP-IPv4
Tunnel (NAT Transversal), y IPv6-inIPv4 Tunnel (DSTM). Si dejamos
seleccionado el valor por defecto (se muestra en la imagen), gogoCLIENT
preguntará a gogoSERVER cuál es el tipo de túnel que más le conviene
crear. gogSERVER analizará a gogoCLIENT y determinará el tipo de túnel
que le conviene establecer (nativo o con NAT transversal). En la ficha Status
podremos consultar el tipo de túnel que finalmente ha creado.

• La opción “Tunnel Authenticaion Method” tiene por defecto

“Automatic(ANY)”. Significa que va unida a la opción seleccionada en la
ficha “Basic”. Esta ficha puede tener seleccionado “anonymous” o
“authenticated”. Si decidimos autentificarnos en “Server Address”
pondremos “authenticated.freenet6.net”. Además, añadiremos el usuario y
contraseña. De lo contrario, pondremos “anonymous.freenet6.net”.
• “Connect to Best Server”. gogoCLIENT enviará ping a todos los

gogoSERVER y se conectará con el gogoSERVER que devuelva en primer
lugar la respuesta. Si no consigue crear el túnel entonces lo intentará con el
gogoSERVER que haya respondido al ping en segundo lugar. Seguirá
intentándolo mientras no tenga éxito o no le queden más gogoSERVER con
quien intentarlo. Si fallasen todos los intentos dará error.
• “Connect Using Preferred gogoSERVER” se conectará al servidor

especificado. Si no consiguiese crear el túnel se limitará en notificar el error.
Entre las dos últimas opciones elegiremos una de ellas.
Hay varias razones por las cuales gogoCLIENT puede no conseguir

establecer el túnel:
1. Cada gogoSERVER tiene un nº máximo de usuarios que pueden

conectarse simultáneamente. En periodos de mucho tráfico podría
ocurrir que se supere el número.
2. gogoCLIENT puede estar intentando crear un tipo de túnel con un

gogoSERVER que no lo soporta.
• “Obtain Source IP Address Automatically” es la opción por defecto. Si el

host tiene varias tarjetas de red elegiremos “Specify Source IP Address”. En
este caso se escribirá en la caja la dirección IPv4 con la cual se quiere crear
el túnel.
• “Enable Keepalive Funcionally” indica cada cuánto tiempo debe enviar un

paquete ICMP a gogoSERVER para asegurarse que la sesión del túnel sigue
activa. El valor por defecto es 30 segundos.
• “Enable Routing Advertisements option” es usado para publicar la

disponibilidad de la conectividad IPv6 al grupo de interfaces de la red y
proporcionar el prefijo para que generen su propia dirección IPv6. Cuándo se
activa esta opción, gogoCLIENT espera que el servidor provea el prefijo
como parte de la negociación del túnel. Si esta opción está activada una vez
realizada la conexión, gogoSERVER le va a proveer de un prefijo al túnel y
este host publicará este prefijo a todas los host de la LAN. Cada host formará
su propia dirección IPv6 y tendrá acceso a las páginas con IPv6. De esta

manera podemos con un solo túnel dar direcciones IPv6 a cada host de la
LAN.
• Poner una página Web accesible desde Internet. Trabajaremos con las otras
dos pestañas que tiene nuestro aplicativo “HomeWeb” y “HomeAccess”. En
la primera ficha activaremos el cuadro “Enable Home Web” y en la caja de
texto pondremos la ruta donde tenemos nuestra página Web alojada en el
disco duro.
En la ficha “HomeAccess” activaremos la casilla “Enable Homeaccess” y

añadiremos una línea indicando la dirección Ipv6 que tenemos asignada en el host
y un nombre (el que queramos).

La página web estará accesible en la siguiente conexión que realicemos.
5.2. Creación de túnel de un firewall de Bebian con Hurricane.

La red que tenemos es una red LAN IPv4 detrás de un Firewall Debian que a su vez
este está conectado a un ADSL con su IP pública estática.
El objetivo es crear un túnel desde un firewall dotándole de una dirección ipv6 hacia
internet y que pueda llegar a ver páginas web ipv6.
Es suficiente con registrarse en la página web http://tunnelbroker.net .
Al pulsar en Register saldrá un formulario con la siguiente forma:

Rellenamos el formulario, lo enviamos y recibiremos por Email un mensaje con la

información del usuario con el que a continuación vamos a logearnos. Una vez hemos
entrado, elegimos “Create regular tunnel” se visualizará una ventana que nos pedirá la
IP pública que tiene nuestro ADSL. Al tener una IP estática y estar asociada a nuestro
usuario en el servidor del Broker no nos obliga a identificarnos constantemente. A
continuación saldrá una ventana mostrándonos la información de nuestro túnel.

Entre toda la información que hay observamos, la dirección IPv4 e IPv6 de los dos
extremos del túnel. Además, un prefijo IPv6 que tenemos asignado en exclusividad para
dar una dirección IPv6 a cada host de nuestra LAN que se encuentra detrás del Firewall.
Con la cuenta creada en el Broker, procedemos a realizar nuestra instalación en el

Debian.
Este Host es un ordenador con distribución Debian que tiene dos tarjetas de Red,
una de ellas unida a la red LAN (eth1) y la otra a la Red del ADSL (eth0).
Este Host además es un Firewall y un servidor Apache. Al Firewall le hemos puesto

políticas por defecto de Aceptar.
REQUISITOS:
1. La IPv4 pública del ADSL debe ser estática.
2. La dirección IPv4 de cada host de la LAN puede ser estática o dinámica.
3. El túnel que se crea es autenticado no existe anónimo como en Freenet6.
Desde la web de Hurrricane, por usuario solo se pueden crear 5 túneles, tiene esa
limitación.
Primeros pasos:
1. Probar que el kernel de debían admite IPv6. Este debe ser posterior a 2.6
#cat /proc/net/if_inet6 && echo 'IPv6 sistema preparado!' || echo 'No se

encuentra el soporte IPv6. Compile el Kernel!!'

2. Probar que el módulo IPv6 está cargado:
modprobe IPv6
lsmod | grep ipv6
Resultado:
ipv6 411425 18
Creamos un archivo que tiene las ordenes iptables que configura el Firewall. Al
archivo le damos el nombre de “permitir” y lo almacenamos en la ruta /etc/init.d
apacheaeg:/etc/init.d# cat permitir
#!/bin/bash
pt=/sbin/iptables
for TABLE in filter nat

do
$pt -t $TABLE -F
$pt -t $TABLE -X
$pt -t $TABLE -Z
done
echo 1 >/proc/sys/net/ipv4/ip_forward
echo 1 >/proc/sys/net/ipv6/conf/all/forwarding
iptables -t nat -A POSTROUTING --protocol ! 41 -o eth0 -j MASQUERADE
En este archivo además de poner las políticas por defecto Aceptar, se da la orden
de forwardear entre las tarjetas los paquetes IPv4 e IPv6. Además, se da la orden de
enmascarar únicamente los paquetes IPv4. Los paquetes IPv6 usan el protocolo 41 y se
le está indicando al Firewall que no enmascare estos paquetes. Este archivo tiene un
enlace creado en /etc/rc2.d para que se ejecute cada vez que se inicia el Host.
/etc/init.d# chmod 777 permitir
/etc/init.d# ln –s /etc/init.d/permitir /etc/rc2.d/S99_permitir
Ordenes para crear el túnel:
ip tunnel add he-ipv6 mode sit remote 216.66.80.26 local 10.10.10.50 ttl 255
Sintaxis:
ip tunnel [add|change|delete] nombre_tunel mode [ipip|sit|gre] remote [direci. Ipv4 b broker]

local [la ip de nuestro host] dev [periferico]
Los argumentos posibles son:

• name NOMBRE -- selecciona el nombre del túnel

• mode MODO -- hay 3 modos disponibles: ipip, sit y gre
El modo ipip corresponde a un simple túnel IP sobre IP. Se encapsulan los paquetes
sin más. El modo sit se usa para túneles IPv6. El modo gre corresponde a los túneles
GRE especificados por la compañía Cisco, que son túneles IP sobre IP cifrados.
• remote DIRECCION -- dirección de 'salida' del túnel

• local DIRECCION -- dirección local de 'entrada' del túnel
• dev PERIFERICO-- nombre del periférico a través del que se envían los paquetes
ip tun show – Esta orden muestra los túneles
ip link set he-ipv6 up
Esta orden sirve para levantar el túnel llamado he-ipv6
ip addr add 2001:470:1f08:744::2/64 dev he-ipv6
Permite asignar una dirección IPv6 al extremo local del túnel
ip route add ::/0 dev he-ipv6
Permite poner una ruta estática. Cualquier paquete que esté destinado a una
dirección IPv6 deberá salir por el túnel llamado he-ipv6.
ip -f inet6 addr
El -f significa family, y al poner inet6 hace referencia a la familia IPv6. Si no se

pone nada por defecto es IPv4. Esta orden tiene carácter informativo y muestra las
direcciones IPv6.
Todas las órdenes juntas forman el script para crear el túnel. Se puede usar cualquier
editor de texto (nano, vi,..) :
apacheaeg:/etc/init.d# nano tunel
ip tunnel add he-ipv6 mode sit remote 216.66.80.26 local 10.10.10.50 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f08:744::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr
/etc/init.d# chmod 777 tunel
/etc/init.d# ln –s /etc/init.d/tunel /etc/rc2.d/S99_tunel
A este archivo se le ha dado permisos de ejecución, se ha creado el enlace a rc2.d

para su ejecución en el arranque. La orden ifconfig me muestra:
apacheaeg:/home/apacheweb# ifconfig
Neighbor Discovery (ND) es un protocolo de IPv6, y es equivalente al protocolo

Address Resolution Protocol (ARP) en IPv4.
Consiste en un mecanismo con el cual un nodo que se acaba de incorporar a una red,
descubre la presencia de otros nodos en el mismo enlace. Este protocolo también se
ocupa de mantener limpios las caches donde se almacena la información relativa al
contexto de la red a la que está conectado un nodo. Así cuando una ruta hacia un cierto
nodo falla el enrutador correspondiente buscara rutas alternativas. Emplea los mensajes
de ICMPv6, y es la base para permitir el mecanismo de autoconfiguración en IPv6.
Ahora debemos configurar el radvd (router advertisement daemon) en el Firewall

para que publique el prefijo de nuestra subred a todos los nodos que se encuentran en la
LAN. Para esto, modificamos el archivo /etc/radvd.conf (sustituimos cualquier línea que
ya existiese en el archivo) añadiendo las siguientes líneas:
NOTA: Si radvd no está instalado a priori deberemos hacerlo.
#apt-get install radvd
apacheaeg:/etc/init.d# cat ../radvd.conf

interface eth1
{
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
prefix 2001:470:1f09:744::/64
{
AdvPreferredLifetime 120;
};
};

El valor de MaxRtrAdvInterval significa el valor máximo en segundos entre envíos

de paquetes "Router advertisement" y MinRtrAdvInterval tiempo mínimo en segundos
para el envío de un paquete "Router advertisement”. AdvSendAdvert on, establece que
se enviaran paquetes “Router advertisement" bajo solicitud por parte de uno de los
nodos o automáticamente cada cierto tiempo.
Para poner el demonio radvd en marcha damos la orden:
apacheaeg:/etc/init.d# /etc/radvd restart
Stopping radvd: radvd.
Starting radvd: radvd.
Para que se ejecute de forma automática el radvd deberemos en el archivo rc.local

que se encuentra en /etc añadir la línea /etc/radvd.conf restart. Este archivo tiene un
enlace a rc2.d llamado S99rc.local.
/etc# nano rc.local
Añadir la línea: /etc/radvd.conf restart
NOTA: La última acción ha sido necesaria ya que el enlace que tiene el demonio
radvd en rc2.d llamado S50radvd no se ejecuta.
Después de dar esta orden cada interface de la LAN tendrá una dirección IPv6
formada con el prefijo que le ha dado el demonio más la Mac de la tarjeta de Red. En
este instante tenemos una Red IPv6. La Red IPv4 se mantiene y está funcionando. Tan
sólo falta darle una dirección IPv6 a la interface eth1 perteneciente al prefijo que nos
han dado: 2001:470:1f09:744::1. Para ello, editamos en archivo /etc/network /interfaces
y añadimos las siguientes órdenes:
iface eth1 inet6 static

address 2001:470:1f09:744::1
netmask 64
El archivo quedaría de la siguiente forma:

En este instante desde cualquier host de nuestra red tenemos posibilidad de consultar
Páginas web IPv6 en Internet. Además, podemos ver nuestra página web en el Firewall
desde cualquier host que tenga una dirección IPv6.
Consultando la información de la interface del host que está detrás de la LAN

observamos:
La puerta de enlace que está detrás de la LAN es la dirección IPv6 (fe80:---) local
de la interface del Firewall. No utiliza la dirección global IPv6. El servidor DNS no
coge una dirección IPv6 utiliza una dirección IPv4. El servidor DNS IPv4 resuelve
direcciones IPv4 e IPv6.
Un paquete que debe salir a Internet desde un host de la LAN, inicialmente será
enviado a la interface del Firewall local (fe80), una vez el paquete ha llegado al router
este consulta en su tabla de enrutamiento la dirección Ipv6 por la que debe salir para
llegar a internet.
Vamos a ver la tabla de enrutamiento de direcciones Ipv6.
#route –A inet6
La línea resaltada indica que para ir a cualquier dirección IPv6 (::/0) se saldrá por el
túnel he-ipv6.
5.3. Creación de túnel Teredo

Este sistema tan sólo permite salir hacia fuera (ver páginas web) desde el host y
nadie puede entrar en él. Es lógico ya que es una dirección IPv6 formada a partir de una
IPv4. Este sistema crea un túnel para cada host. No obtiene un prefijo y no permite dar
direcciones IPv6 a las máquinas.
El protocolo IPv6 y Teredo está habilitado por defecto tanto en Windows Vista,
Windows 7 como en Windows XP SP3.
Vamos a ver un ejemplo:
Deberemos tener un host con Windows 7 detrás de una ADSL. Antes de dar las
órdenes deberemos entrar en la ventana CMD con permisos de Administrador. Sobre el
“Símbolo del sistema” pulsamos botón derecho del ratón y elegimos “Ejecutar como
Administrador”.

Podemos comprobar nuestro host a que servidor Teredo accede dando la orden:
Netsh interface ipv6 show teredo
Observamos que en tipo pone client. Este parámetro indica que nuestro host utiliza
Teredo cliente. El servidor al que va a acceder nuestro host es
“teredo.ipv6.microsoft.com”. El Intervalo de actualización del cliente tiene como valor
60 y su objetivo es la comprobación del estado del túnel enviando un paquete. El
puerto se ha especificado con el valor 34567 y su estado es dormat. El hecho de que
tenga este valor significa que ha conectado con un servidor teredo. Si no lo consigue
(porque el Router ADSL no se lo permite) tendrá el valor offline.
Si deseamos acceder a otro servidor teredo tenemos que dar la orden:
Netsh interface ipv6 set teredo client teredo.remlab.net 60 34567

Vamos a comprobar los valores que tiene nuestra tarjeta de red:
Usando la orden ipconfig veremos:

Comprobamos que la interface “teredo Tunneling Pseudo-Interface” tiene una

dirección IPv6 que comienza en 2001: ………………. Ahora probamos a navegar a
páginas IPv6:
Vamos a acceder a la página Web creada en un host que se encuentra detrás de un

Firewall y que obtiene una dirección IPv6 creando un túnel con la aplicación gogo6
usando el Broker Freenet6.
Vamos a acceder a la página Web creada en un host Debian que tiene un túnel
creado con el bróker Hurricane. Su dirección IPv6 es : http://[2001:470:1f08:744::2]/
Este host con Windows 7 nos permite ver páginas Web en otros host con IPv6 pero
tan sólo se puede salir de él y nadie podrá llegar al mismo a ver su página web si la
tuviera ni haciendo ping.

6. Inyección y captura de paquetes.

6.1. WireShark
OBJETIVO: Capturar paquetes Ivp6 con el programa Wireshark.
Como primer paso, hemos instalado Wireshark en un PC con Debian.
Para instalarlo hay que escribir el siguiente comando en el terminal:
apt-get install wireshark
Después, hemos ejecutado el programa como root (Wireshark as root), se nos abre la
pantalla principal y hay que hacer una pequeña configuración.
Hacemos clic en el icono de la imagen y se abrirá otra ventana en la que tenemos

que elegir la interface a utilizar. En ella elegimos “he-ipv6”. Se trata del nombre que le
hemos dado al túnel.

El círculo rojo de mayor tamaño, es para elegir algún tipo de filtro si deseamos
filtrar los paquetes capturados.
Si hacemos clic en el botón de los filtros, nos aparece la siguiente ventana donde
podremos elegir el protocolo a filtrar o alguna de las opciones que nos aparecen en la
lista. Nosotros no vamos a elegir ningún filtro.
Aceptamos la ventana de los filtros si hemos elegido algún filtro y sino cancelamos
y una vez realizados estos pasos, clicamos en el botón Start y el programa iniciará la
captura de paquetes en modo promiscuo.

La siguiente imagen, muestra los paquetes capturados navegando desde el mismo

equipo con Ipv6.
Como podemos ver, por cada captura nos muestra los siguientes apartados.
• Nº de Paquete.
• Tiempo tardado.
• IP Origen.
• IP Destino.
• Protocolo.
• Información acerca del paquete (puerto que se ha utilizado, acción que se ha
realizado, tardanza de la acción...)
En el siguiente ejemplo, muestra los paquetes capturados accediendo al Debian

mediante ssh desde un Windows Vista. En el debian, tendremos que instalar el ssh con
el comando:
apt-get install ssh
Cuando finalice ya tendremos instalado y funcionando a la perfección el demonio de

ssh.
Es necesario reiniciar el demonio de red, lo haremos con: /etc/init.d/ssh restart.
Para acceder mediante ssh desde un Windows Vista, hay que usar el software Putty
que lo descargamos desde:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Ejecutaremos el programa y nos pedirá la IP del host destino (IPv6 en nuestro caso).
Clicando en el botón Open se nos abrirá una ventana parecida a CMD donde
tendremos que introducir un usuario y contraseña del otro host destino.

Supongamos que la máquina TK1 con IPv6 2001:5c0:1400:b::6895 conecta usando

ssh con otra máquina TK2 con IPv6 2001:470:1f08:744::2.
La máquina TK1 hace una petición (Request) de conexión hacia la máquina TK2.
Esta segunda máquina acepta la petición (Response). Observamos que el tráfico está
encriptado.
Esta otra imagen, muestra los paquetes capturados accediendo a la web que el
Debian tiene alojada con el navegador desde otro PC con conectividad Ipv6.
Una máquina TK1 con IPv6 2001:5c0:1400:b::70db consulta la página web de otra
máquina TK2 con IPv6 2001:470:1f08:744::2
Han abierto una conexión segura TCP entre los puertos 49769 y 80 para la
señalización de la petición de la página Web. Para esto utilizan el proceso de saludo a
tres vías de establecimiento de conexión TCP (Fijándonos en las tramas 3,4 y 5).
• TK1 → TK2. Envía un numero de secuencia y SYN para establecer conexión.

• TK2 ← TK1. Responde con ACK (aceptar) y envía SYN para establecer la conexión
en el otro sentido.
• TK1 → TK2. Responde con ACK (aceptar).

7. Nuevas amenazas con Ipv6

El uso de IPv6 puede ser aprovechado de forma maliciosa para llevar a cabo
actividades fraudulentas, no solo cuando se disfruta de una red IPv6 nativa, sino
también cuando se utilizan mecanismos de transición.
7.1. Comunicaciones a través de IPv6

Con IPv6 no se utiliza NAT sino que las direcciones IPv6 globales son alcanzables
desde cualquier punto de Internet. Esto permite la proliferación de sistemas p2p (peer to
peer) donde los dispositivos finales envían y reciben contenidos de forma independiente
a un servidor.
• Por tanto se hace imprescindible la existencia de al menos un firewall

perimetral con soporte IPv6 en la red en la que se encuentra el usuario como
medida básica de protección.
• Además es recomendable que cada nodo IPv6 tenga un firewall local

instalado en el propio nodo que filtre las comunicaciones indeseadas. En
realidad las vulnerabilidades que pueden ser aprovechadas de forma maligna
para ganar el control de una máquina o con otros fines no las proporciona el
protocolo de red (en este caso IPv6) sino las propias aplicaciones o el
sistema operativo que tiene instalados la máquina.
• Las mismas medidas de protección que se usan en la actualidad para IPv4

son igualmente válidas para IPv6.
7.2. Ataques contra la autoconfiguración IPv6

Los nodos IPv6 se autoconfiguran usando el protocolo NDP (Neighbor Discovery
Protocol). Además NDP permite descubrir a otros nodos IPv6 en el mismo enlace,
determinar su dirección de nivel de red, encontrar otros Routers IPv6 en su mismo
enlace y mantener información de la ruta IPv6 hacia otros nodos activos. NDP es
similar en muchos aspectos al protocolo ARP en IPv4 y funciona básicamente enviando
paquetes ICMPv6 a la LAN (u otro enlace) para encontrar otros nodos IPv6 vecinos con
los que poder contactar.
Sin embargo NDP también posee una nueva función en relación a su homólogo
ARP, que es la autoconfiguración de la dirección IPv6 por medio del envío de
paquetes Router Advertisement (RA).
Como se puede deducir, el proceso de autoconfiguración es básico para que los

nodos IPv6 puedan obtener conectividad IPv6 global. Sin embargo NDP tal y como
está definido es vulnerable a varios ataques si no se utilizan las herramientas de
seguridad adecuadas.

• En particular, es relativamente fácil poder realizar un bloqueo a todos los

nodos IPv6 conectados en un segmento de red (denegación de servicio) sin
más que un nodo IPv6 inyecte paquetes RA con un prefijo erróneo de forma
intencionada o por descuido. En este caso, todos los nodos del segmento de
red configurarán una dirección IPv6 basada en el prefijo erróneo y por tanto
nunca serán alcanzables por un nodo IPv6 externo.
• Según las especificaciones de IPv6, los mensajes de ND (Neighbor

Discovery) se pueden proteger con la cabecera de autenticación (AH -
Authentication Header) de IPsec con el fin de establecer una relación de
confianza con el supuesto router que envía los paquetes RA. Sin embargo
existen limitaciones prácticas en el uso de la gestión automática y dinámica
de claves.
• Con el fin de minimizar este tipo de ataque en entornos no controlados, se ha

definido un mecanismo llamado SEND (Secure Neighbor Discovery) que
proporciona seguridad a los mensajes de NDP. SEND define una serie de
extensiones y mejoras de NDP que posibilita a los nodos IPv6 estar
seguros de que el nodo que envía paquetes RA es adecuado y que el
prefijo que anuncia es correcto. De esta manera los administradores de un
domino IPv6 tienen una herramienta que garantiza que su red no va a ser
contaminada (intencionadamente o por descuido) con el envío de paquetes
RA erróneos, garantizando por tanto la seguridad de la autoconfiguración de
los equipos IPv6 en ambientes donde la seguridad en el nivel físico está
comprometida, como por ejemplo en las redes públicas inalámbricas.
7.3. Vulnerabilidades con Teredo

7.3.1. Puerta abierta a Internet
El objetivo principal de Teredo es proporcionar una dirección IPv6 global al nodo

cliente situado detrás de un NAT por lo que lo primero que hay que tener en cuenta al
usar Teredo es que el nodo cliente está puenteando las medidas de seguridad perimetral
instaladas habitualmente en la red IPv4 y está abriendo las puertas a la Internet IPv6
global. Con el fin de evitar que el nodo cliente sufra algún tipo de ataque que aproveche
la vulnerabilidad de una determinada aplicación servidora que se esté ejecutando es
conveniente configurar alguna Suplantación de identidades regla en el firewall local
de la máquina para que solo responda a peticiones provenientes de entornos
controlados, por ejemplo la red local u otros. Alternativamente se podría utilizar un
firewall perimetral con capacidad de inspeccionar tráfico encapsulado en túneles
Teredo, el cual sigue un patrón bien conocido por el tipo de protocolo de transporte
(UDP) y número de puerto (3544).

7.3.2. Suplantación de identidades
Debido a las características intrínsecas de Teredo, el cliente Teredo debe contactar

con un servidor y con un relay con el fin de cursar tráfico IPv6 de forma efectiva. Esto
hace que ambos agentes, que por lo general están ubicados fuera del dominio del cliente
Teredo, sean objeto de ataques externos por dos motivos: provocar un ataque de
denegación de servicio (DoS) y interceptar tráfico de un cliente Teredo con diversos
fines.
Existen diversas formas de conseguir el primero de ellos pero el segundo es el que

tiene peores consecuencias puesto que un ataque de denegación de servicio, si bien no
deja de ser un inconveniente al impedir que el cliente tenga conectividad IPv6, no
compromete la seguridad de las comunicaciones del cliente.
La suplantación de dirección más comprometedora es la del agente relay puesto que

este componente se encarga de retransmitir tráfico IPv6 desde/hacia la Internet IPv6
hacia/desde clientes Teredo. Por tanto está manejando tráfico de datos, mientras que con
la suplantación del servidor Teredo solo se intercepta tráfico de señalización del cliente
Teredo.
La única manera de estar seguro de que las comunicaciones IPv6 a través de Teredo
no son vulnerables a un ataque de suplantación de la identidad es protegerlas
adecuadamente por medio de IPsec ya que proporciona seguridad de extremo-a-
extremo impidiendo que en el caso de que existan servidores/relays que interceptan
tráfico, estos puedan ver su contenido.
7.3.3. Ataques de denegación de Servicios
Por definición un ataque de denegación de servicio es aquel que impide el

funcionamiento normal de un servicio de red. Existen diversas formas documentadas
para conseguir este tipo de ataques que principalmente se basan en el envío masivo de
tráfico a una determinada víctima (el nodo que presta el servicio bajo ataque) con el fin
de saturarle hasta el punto de que no pueda contestar todas las peticiones que le lleguen
o incluso se quede bloqueado por un desbordamiento de memoria.
Como se apuntaba en la sección anterior, este tipo de ataques no comprometen

directamente la seguridad en las comunicaciones en el sentido de que los datos no son
interceptados ni modificados, pero sí causan perjuicios puesto que impiden que la
comunicación IPv6 en un cliente Teredo se lleve a cabo.
Debido a la complejidad de Teredo y a la diversidad de nodos que pueden llegar a

intervenir en una comunicación entre un cliente Teredo y otro nodo IPv6, Teredo es un
campo abonado para llevar a cabo ataques de tipo DoS y/o para magnificarlos.
Existen ciertos procedimientos paliativos para la mayoría de ellas, aunque son

medidas que se llevan a cabo en la propia implementación o en el administrador que

despliega los agentes Teredo, por lo que el usuario final no tiene muchos recursos para
luchar contra ellos.
7.4. Vulnerabilidades con 6to4

Gracias a 6to4 los nodos que se encuentran en una red que sólo es IPv4 pueden
obtener conectividad IPv6 de una forma sencilla sin ningún despliegue especial en la
red en la que se encuentra. Al igual que ocurre con Teredo, este mecanismo no es
inseguro en sí mismo. Tan solo ofrece nuevas posibilidades de realizar ataques a gente
sin escrúpulos, por lo que es conveniente conocer sus posibles vulnerabilidades con el
fin de que los administradores de red puedan poner los medios adecuados para evitar se
atacados o ser utilizados como fuente de ataque en el caso de utilizar este servicio en su
red.
Los tipos de ataque que se pueden llevar a cabo con 6to4 se fundamentan en las
características del mecanismo: los nodos 6to4 deben aceptar tráfico IPv4/IPv6 enviado
desde cualquier lugar, sin comprobar identidades y sin una relación de confianza previa.
Con esta premisa es fácil entender que 6to4 se pueda usar para llevar a cabo ataques
de tipo DoS y de suplantación de la identidad posibilitando ataques de tipo man-in-the-
middle. Pero también existen otras vulnerabilidades como se describirá a continuación.
7.4.1. Puerta abierta a Internet
Al igual que ocurre con Teredo, al usar 6to4 el nodo cliente se conecta a la Internet
IPv6 global de forma directa, puenteando las posibles medidas de seguridad perimetral
instaladas habitualmente en la red para IPv4. Por tanto se pueden aplicar en este caso
las mismas consideraciones que con Teredo en cuanto a las medidas de seguridad en las
comunicaciones extremo-a-extremo.
7.4.2. Suplantación de identidades
Puesto que un nodo 6to4 necesita de un relay 6to4 para conectar con un nodo IPv6
nativo, un atacante podría hacerse pasar por un relay 6to4con el fin de espiar el tráfico
intercambiado entre ambos.
La única forma de hacer esto es conseguir que el relay 6to4 haga pensar al nodo
6to4 que él es el relay adecuado (bien porque tenga la dirección anycast 192.88.99.1
asignada a este servicio o bien porque se use una dirección unicast y se haga pasar por
un relay confiable) y además sea capaz de anunciar por BGP el prefijo IPv6
correspondiente a 6to4: 2002::/16 .
Sin embargo este ataque es más difícil de llevar a cabo que en el caso de Teredo
debido a la asimetría en las rutas que sigue el tráfico intercambio entre ambos nodos: el
relay 6to4 que usa el nodo 6to4 y el nodo IPv6 nativo puede ser diferente en la
comunicación llevada a cabo entre ambos.

7.4.3. Ataques de denegación de Servicios
Este ataque es muy similar al descrito para Teredo.
7.5. Usos de IPv6 con fines maliciosos

Los mecanismos de transición IPv6 basados en túneles podrían ser usados para
puentear las medidas de seguridad perimetrales (firewalls, proxies, etc.) instaladas en
cualquier dominio puesto que tienen la facilidad de ocultar el tráfico TCP/UDP
transportado a través de IPv6 dentro del túnel IPv4.
Esta característica podría ser aprovechada para llevar a cabo actividades ilícitas
como:
• Visitas web a sitios no autorizados por el administrador de la red.
• Comunicación o coordinación entre grupos delictivos.
• Ataques coordinados de DoS.
• Compartición ilegal de material informático como software, libros, videos,

música, etc.
Todo ello con la novedad de que ser indetectables en la Internet actual en el caso de
que las medidas de control de tráfico solo controlen paquetes TCP/UDP transportados
sobre paquetes IPv4.
Un ejemplo de esto podría ser el uso de servidores de túneles IPv6, también

llamados Tunnel Brokers (TB), los cuales los usuarios lícitos usan para obtener
lícitamente conectividad IPv6 y que los usuarios fraudulentos pueden utilizar para
construir una red "virtual" distribuida mundialmente sobre la actual Internet IPv4 que
les posibilita la comunicación entre ellos sin que sea detectable por sistemas que no
soportan comunicaciones IPv6.

8. Aspectos de seguridad mejorados con Ipv6.

A pesar de lo que pueda parecer por lo descrito en las secciones anteriores, IPv6 no
es más inseguro que su predecesor IPv4, en realidad es todo lo contrario puesto que
desde el comienzo de su estandarización la seguridad ha sido una pieza fundamental. De
hecho, existen algunos aspectos de la seguridad con IPv6 que han mejorado con
respecto a IPv4 como se describen a continuación:
• El escaneo de Red es más complicada. Escanear por fuerza bruta una red de
área local IPv6 puede llevar, con la tecnología actual, más de 5.000 millones
de años, lo cual evidentemente es impensable. También los ataques
automatizados, por ejemplo gusanos que seleccionan direcciones aleatorias
para propagarse, se ven dificultados.
• IPsec. La especificación de IPv6 dice que toda pila IPv6 debe llevar IPsec
incorporada. Esto es una ventaja ya que IPsec está disponible si se quiere
usar. En la práctica el uso de IPsec es escaso debido sobre todo a la falta de
un mecanismo generalizado y global de intercambio de claves.
• Ataques broadcast (smurf). Este problema desaparece. En IPv4 se generan

enviando un paquete ICMP echo request a la dirección de broadcast de la
red con la dirección origen del nodo atacado. En IPv6 no existe el concepto
de broadcast. IPv6 especifica que no se debe responder con un mensaje
ICMP a ningún paquete que tenga dirección destino de nivel tres
multicast o direcciones de nivel dos multicast o broadcast.
• Fragmentación de paquetes. En IPv6 la fragmentación de paquetes sólo se

puede realizar en los extremos de la comunicación, por lo que se reducen
los riesgos por ataques con fragmentos superpuestos o de pequeño tamaño.
Las consideraciones sobre fragmentos fuera de secuencia serán las mismas
que para IPv4, pero en el nodo final. Los firewalls no deberán filtrar los
fragmentos de paquetes.

IPv 6 AEGFinal

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

IPv 6 AEGFinal

Cargado por

Copyright:

Formatos disponibles

IPV6

Centro de Estudios A.E.G.

1.1. DISTRIBUCIÓN DE DIRECCIONES IPV4 1

2. CABECERA, DIRECCIONAMIENTO Y CONFIGURACIÓN BÁSICA. 9

2.1. LA NUEVA CABECERA 10

Paseo de Heríz, 82 DONOSTIA GIPUZKOA TEL: 943313907 1

3.3.2. DHCPV6 WINDOWS 2008 SERVER 97

4. MECANISMOS DE TRASICIÓN PARA CONSEGUIR CONECTIVIDAD. 132

4.1. IPV6 IN IPV4 133

5. EJEMPLOS DE TUNELES: TUNNEL BROKER Y TEREDO 142

5.1. CREACIÓN DE TÚNEL EN UN HOST CON WINDOWS CON FREENET6. 142

6. INYECCIÓN Y CAPTURA DE PAQUETES. 164

6.1. WIRESHARK 164

7. NUEVAS AMENAZAS CON IPV6 170

7.1. COMUNICACIONES A TRAVÉS DE IPV6 170

8. ASPECTOS DE SEGURIDAD MEJORADOS CON IPV6. 175

Paseo de Heríz, 82 DONOSTIA GIPUZKOA TEL: 943313907 2

Todos los protocolos empleados conviven en la llamada pila de protocolos TCP/IP.

El IP (Internet Protocol) que aparece en el nombre de la pila hace referencia al

1.1. Distribución de direcciones IPv4

Estas direcciones se representan en 4 grupos de 8 bits, con notación decimal y

10.0.0.0 a 10.255.255.255 (10.0.0.0/8)

172.16.0.0 a 172.31.255.255 (172.16.0.0/12)

192.168.0.0 a 192.168.255.255 (192.168.0.0/16)

Paseo de Heríz, 82 DONOSTIA GIPUZKOA TEL: 943313907 1

La jerarquía para el reparto se ilustra en la siguiente figura:

El total de las direcciones disponibles se organiza en 256 bloques de 16.777.216

En este enlace se pueden ver estadísticas diarias de la progresión del reparto de

Un problema adicional al agotamiento de las direcciones es lo descompensado que

1.2. Evolución de la necesidad de direcciones

Por un lado, como se ha comentado en el punto anterior, las economías emergentes

Todo esto nos lleva a un escenario "Always-on" en el que el usuario no solo

1.3. Inconvenientes técnicos de IPv4

Paseo de Heríz, 82 DONOSTIA GIPUZKOA TEL: 943313907 3

Los problemas de rendimiento vienen ocasionados por:

El mal uso de los medios disponibles.

La manipulación a que son sometidos los datos.

El resultado final es la acumulación de retardos que producen fallos en aplicaciones

Otra situación que desemboca en retardos es el procesamiento a que son sometidos

Problemas de IPv4 relacionados con seguridad

En el diseño de IPv4 se pensó en garantizar la conectividad. El tema de la seguridad

Actualmente la seguridad en IPv4 se garantiza por medio de dos parches: SSL

Paseo de Heríz, 82 DONOSTIA GIPUZKOA TEL: 943313907 4

Problemas de la utilización de NAT (Network Address Translation)

Ante la necesidad de dosificar las direcciones IP públicas disponibles se ha ideado el

Algunas de las consecuencias de la utilización de NAT son las siguientes:

Rompe el modelo end-to-end.

Debido a NAT se pierde la "transparencia" original de Internet, cuando había un

Afecta a protocolos y aplicaciones.

Proporciona una falsa sensación de seguridad.

RFC 2775 "Internet transparency"

RFC 3027 "Protocol Complication with the IP Network Address Translator"

RFC 2993 "Architectural Implications of NAT"

1.4. La solución: IPv6

En relación a la escasez de direcciones:

En IPv6 el número de bits para direccionamiento pasa de los 32 de IPv4 a 128.

Para hacernos a la idea de la cantidad de direcciones disponibles en IPv6 se suele

En relación a los retardos:

En IPv6 el formato de las cabeceras de los paquetes se ha simplificado. Tienen un

Paseo de Heríz, 82 DONOSTIA GIPUZKOA TEL: 943313907 5

En IPv6 no existe tráfico de broadcast. Cada paquete de información tiene un origen

No hay reconstrucción de tramas en cada salto. Esa reconstrucción la hará

Todo esto hace que mejore el rendimiento de la red.