IPv4

Todas las secciones que aparecen en color ROJO son

elementos que se eliminaron del encabezado de IPv6. Lo
que está en AZUL, cambió de nombre y posición. Lo que
está en AMARILLO se mantiene igual.

Veamos qué secciones se eliminaron:

· IHL (IP Header Length - 4 bits). En IPv4 el tamaño del
encabezado es variable. Este valor combinado con el Total
Length del paquete le permite al equipo saber cuántos bytes hay de carga útil o payload
(Payload = Total Length - IHL). Con un tamaño de encabezado variable, se requiere de alguna
rutina o algoritmo para que los equipos determinen en dónde empieza la información dentro del
paquete lo que hace un poco más complejo el manejo y proceso de paquetes.
· Identification/Flags/Fragment Offset (32 bits). Estos elementos se utilizan para el manejo de
fragmentación de paquetes.
· Header Checksum (16 bits). Utiliza un algoritmo para determinar si el encabezado no está
corrupto o ha sido modificado incorrectamente. Tecnologías como NAT que modifican
parámetros del encabezado también deben modificar esta sección de manera adecuada. IPv6
elimina el uso de esta sección y deja la revisión de la integridad de los paquetes a CRC en capa
2 y checksums de capa 4.
· Options. Es una sección de tamaño variable y contiene datos sobre la información del paquete
que no se pudieron integrar en otros campos del encabezado. Es esta sección la que hace que
el encabezado de IPv4 sea de tamaño variable.
· Padding. Es una serie de bits con un valor de '0' que sirve para alinear el encabezado a un
múltiplo de palabras de 32 bits.

IPv6
Como se puede observar, las secciones de Versión (4 bits)
y Direcciones de Origen y Destino (128 bits) permanecen igual.
Además existe una sección nueva de 20 bits, Flow Label, que es
para un uso futuro basado en el RFC 3697. Esta sección servirá
para identificar un flujo específico y hacerle un tratamiento (QoS)
idéntico a todos los paquetes que pertenezcan al flujo (aún no
está implementado).

Veamos ahora las secciones modificadas:

· Traffic Class (8 bits). Tiene la misma funcionalidad que el Type
of Service, sirve para almacenar la información de precedencia,
DSCP o clase de servicio dependiendo de la implementación de QoS.
· Payload Length (16 bits). En IPv6 tenemos un encabezado fijo de 40 bytes por lo que solo
necesitamos saber el tamaño de la información útil del paquete. Esto también nos quita la
necesidad de implementar rutinas de búsqueda como en IPv4. Ya estamos utilizando 4 veces el
tamaño de buffers para el manejo de direcciones de 128 bits, cualquier cosa que disminuya el
procesamiento extensivo de los paquetes es preferible.
· Next Header (8 bits). Esta sección nos puede indicar el protocolo al que pertenece la
información que estamos acarreando (TCP, UDP, ICMPv6, etc.). También se utiliza para
indicarnos si existe información de opciones para los datos que se transportan. En lugar de
manejar Opciones en el encabezado como IPv4, éstas las integramos dentro de la carga útil de
los paquetes para mantener el encabezado en un tamaño fijo. Esta sección nos indicaría si hay
opciones que revisar dentro del paquete.
· Hop Limit (8 bits). Sirve exactamente la misma función que el TTL de IPv4. Solo se cambió el
nombre ya que este parámetro es un contador de saltos (equipos capa 3) y no un contador de
tiempo como parece indicar el nombre en IPv4.
6to4
6to4 es un sistema que permite enviar paquetes IPv6 sobre redes IPv4 obviando la necesidad
de configurar túneles manualmente. Fue diseñado para permitir conectividad IPv6 sin la
cooperación de los proveedores de Internet.

Características
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. La clave del
sistema consiste en la asignación de direcciones IPv6 que contienen embebida la dirección IPv4
pública del router. 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.
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 sobre la base de ella es
fijo también. En este caso es posible pedir a Number Resource Organization una delegación
del DNS reverso para ese prefijo particular, bajo la zona 2.0.0.2.ip6.arpa. Esto se hace en el
sitio http://6to4.nro.net/ y el proceso es completamente automático.
Otro protocolo para la coexistencia de IPv6 e IPv4 es Teredo. La diferencia con 6to4 es que
Teredo no necesita una dirección IPv4 pública, y tiene mecanismos para crear "agujeros" en los
routers NAT detrás de los que se utiliza.

Teredo
Teredo es una tecnología de transición que proporciona conectividad IPv6 a hosts que soportan
IPv6 pero que se encuentran conectados a Internet mediante una red IPv4. Comparado con
otros protocolos similares, la característica que lo distingue es que es capaz de realizar su
función incluso detrás de dispositivos NAT, como los routers domésticos.
Teredo opera usando un protocolo de túneles independiente de la plataforma diseñado para
proporcionar conectividad IPv6 encapsulando los datagramas IPv6 dentro de
datagramas UDP IPv4. Estos datagramas pueden ser encaminados en Internet IPv4 y a través
de dispositivos NAT. Otros nodos Teredo, también llamados Teredo relays, que tienen acceso a
la red IPv6, reciben los paquetes, los desencapsulan y los encaminan.
Teredo está diseñado como una tecnología de transición con el objetivo de ser una medida
temporal. En el largo plazo, todos los hosts IPv6 deberían usar la conectividad IPv6 nativa y
desactivar Teredo cuando la conectividad IPv6 esté disponible.
Teredo fue desarrollado por Christian Huitema en Microsoft y fue estandarizado por
la IETF como RFC 4380. El servidor teredo escucha en el puerto UDP 3544.
Objetivo
El protocolo de túneles IPv6 sobre IPv4 más común, 6to4, requiere que el final del túnel tenga
una dirección IPv4 pública. Sin embargo, actualmente muchos hosts se conectan a Internet
IPv4 a través de uno o varios dispositivos NAT, por lo general por el agotamiento de las
direcciones IPv4. En esta situación, la única dirección IPv4 pública se asigna al dispositivo NAT
y es necesario que el protocolo 6to4 esté implementado en este dispositivo. Muchos de los
dispositivos NAT usados actualmente no pueden ser actualizados para implementar 6to4 por
razones técnicas o económicas.
Teredo soluciona este problema encapsulando paquetes IPv6 dentro de datagramas UDP IPv4,
los cuales pueden ser reenviados correctamente por NATs. Por lo tanto los hosts IPv6 que se
encuentran detrás de dispositivos NAT pueden usar los túneles Teredo incluso si no disponen de
una dirección IPv4 pública. Un host que implemente Teredo puede tener conectividad IPv6 sin
cooperación por parte de la red local o del dispositivo NAT.
ACERCA DE IPV6 → RFC 2460
IPv6 es una versión mejorada que Internet Engineering Task Force (IETF) diseñó para resolver
muchos problemas de IPv4, como el agotamiento de las direcciones, el rendimiento (mediante
la eliminación de la fragmentación en la capa de red), la complejidad de cabecera (confinando
todas las cabeceras en un formato común), la autoconfiguración (permitiendo la configuración
sin estados), la movilidad y la seguridad (exigiendo soporte IPsec).

El cambio más visible en IPv6 es el formato de la dirección. Mientras que las direcciones IPv4
tienen cuatro octetos de longitud (un total de 32 bits), las direcciones IPv6 tienen 16 octetos de
longitud (128 bits). Las configuraciones expresan las direcciones IPv6 en ocho palabras de 16
bits en formato hexadecimal, con dos puntos que separan las palabras de 16 bits (por ejemplo,
2001:0db8:85a3:0000:0000:8a2E: 0370:7334)

En IPv6, las direcciones se clasifican en tres categorías: Unicast (identifica un único interfaz de
red), Multicast (identifica un grupo de interfaces, por lo que cualquier paquete enviado a la
dirección será entregado a todas esas interfaces) y Anycast (también identifica un grupo de
interfaces, pero el paquete solo será enviado al de menor coste según la métrica que tiene).

Además, existen diferentes tipos de direcciones. Las del tipo Link Local Unicast están pensadas
para enlaces locales y suelen usarse para los mecanismos de autoconfiguración de direcciones o
para el protocolo Neighbour Discovery, entre otros. Por otro lado, tenemos las direcciones
Unique Local Unicast, también de ámbito local como su nombre indica y solo enrutables dentro
de un ámbito corporativo. Sin embargo, estas direcciones son únicas a nivel global.
Hay algunas direcciones Unicast que son especiales debido a sus características y usos. Una de
ellas es la dirección no especificada (0:0:0:0:0:0:0:0), la dirección de loopback
(0:0:0:0:0:0:0:1), que se utiliza para enviar un paquete sin que salga a la red, únicamente
atraviesa la pila del sistema u otro tipo de direcciones usadas para realizar túneles para poder
utilizar la red IPv6 con la red IPv4, con mecanismos como 6to4 o Teredo.
Para que un equipo pueda funcionar con IPv6, necesita tener configuradas las siguientes
direcciones IPv6 para identificarse:
• Dirección Link Local en cada interfaz
• Dirección de Loopback
• Dirección Multicast del grupo al que pertenece la interfaz
• Alguna dirección de tipo Unicast o Anycast asignada

En la siguiente lista se muestra la distribución actual del espacio de direcciones IPv6. Incluye el
espacio de direcciones reservado para redes enrutables a nivel mundial, además de los bloques
de direcciones que la IETF ha reservado para fines específicos de protocolos.
• 2000::/3 -> Global Unicast
• FC00::/7 -> Unique Local Unicast
• FE80::/10 -> Link Local Unicast
• FF00::/8 -> Multicast
• Resto -> Reservado

CABECERA FIJA DEL PAQUETE

IPv6 especifica dos cabeceras: una cabecera fija de 40 octetos que el emisor debe incluir en
todos los paquetes y cabeceras de extensión de longitud variable que el remitente podría incluir
si fuera necesario en un paquete o flujo concreto. Cada cabecera de extensión sólo puede
aparecer una vez en un paquete IPv6 y debe aparecer en un orden determinado. Dado que la
longitud de la cabecera es una constante, en IPv6 se elimina el campo “Internet Header
Length” (longitud de la cabecera de Internet) de la estructura del datagrama. Por lo tanto, el
datagrama general de IPv6 consiste en una cabecera principal, cabeceras de extensión y un
área de datos. Restringir el tamaño de la cabecera principal a 40 bytes y permitir el
encadenamiento ilimitado de las cabeceras de extensión permite una alta flexibilidad y ofrece
un espacio ilimitado para la modificación y expansión
CONFIGURACIÓN AUTOMÁTICA SIN ESTADO
La configuración automática de direcciones sin estado (SLAAC, Stateless Address Auto
Configuration), definida por la RFC 2462, permite que un dispositivo de red IPv6 genere
automáticamente una dirección IP sin necesidad de comunicarse con un servidor DHCP.
Cuando un host IPv6 que utiliza SLAAC para la configuración automática de direcciones se
conecta por primera vez a una red, genera una dirección de enlace local mediante la
combinación de una dirección local MAC con el prefijo de enlace local FE80::0 comentado
anteriormente. El dispositivo realiza una consulta a la subred local para determinar si otro host
está utilizando la misma dirección. Si no, el dispositivo consulta a un enrutador local para
localizar el prefijo real del enlace local y utiliza este prefijo para crear una dirección única a
nivel mundial. Una dirección de host local única combinada con un prefijo único a nivel mundial
se traducirá en una dirección única a nivel mundial. Estas son las ventajas de SLAAC:
• No se requiere infraestructura DHCP para utilizar IPv6.
• Los nuevos dispositivos no requieren ninguna configuración manual inicial.

Por otro lado, tenemos el protocolo DHCP (Dynamic Host Configuration Protocol). Este protocolo
se utiliza para la configuración de direcciones de red en IPv4. Con el mecanismo de
autoconfiguración aparecido en IPv6, no hay necesidad de ello. Sin embargo, en algunas
ocasiones sí que es necesario usarlo. En IPv6 se implementa como DHCPv6. La configuración de
equipos mediante este protocolo se llama Stateful Configuration y puede ser útil para la
asignación dinámica de servidores DNS, configurar una dirección IPv6 que no provenga de la
dirección MAC o para la utilización de un esquema específico de direcciones IPv6.

PROTOCOLO NEIGHBOUR DISCOVERY

El protocolo Neighbour Discovery es una mejora de IPv6. Su funcionalidad viene dada por el
protocolo ICMPv6. Tiene muchas funciones, como descubrimiento de routers, determinación de
prefijos de red, protocolo SLAAC o detección de direcciones duplicadas, entre otros.

CAMBIOS DE SEGURIDAD RESPECTO A IPV4

La seguridad en IPv6 ha sido mejorada de forma notable con varios cambios, pero el principal
ha sido IPSec (Internet Protocol security) → es un conjunto de protocolos cuya función es
asegurar las comunicaciones sobre el Protocolo de Internet (IP) autenticando y/o cifrando cada
paquete IP en un flujo de datos, a la vez que incluye protocolos para el establecimiento de
claves de cifrado entre los extremos de la comunicación. Tiene como fin proporcionar seguridad
en las comunicaciones de la capa de red del modelo OSI (a la que pertenece el protocolo IPv6),
y de ese modo, a todos los protocolos de capas superiores.
unque en IPv4 se puede hacer uso de IPSec, su implementación se define en una especificación
diferente a la del propio protocolo, por lo que la inclusión se hace con mecanismos definidos
fuera del mismo, mientras que en IPv6 la propia arquitectura "extensible" del protocolo permite
implementar IPsec de forma natural. Hay dos modos o tipos de transferencia: el modo
transporte y el modo túnel.
En el modo transporte se cifra y/o autentica la carga útil del paquete, es decir, la información a
transmitir, pero las cabeceras no. Por consiguiente, la información de las cabeceras, como la
dirección IP de origen y destino, es visible, aunque tiene como principal ventaja que se puede
utilizar de extremo a extremo. Por otro lado, en el modo túnel se encapsula el paquete original
en otro paquete. Con ello se cifra y/o autentica el paquete original completo, pero se necesita
que algún tipo de plataforma realice este túnel.
En cuanto a tipos o niveles de seguridad, IPSec implementa dos opciones, que a su vez pueden
funcionar en modo transporte o en modo túnel: AH (Authentication Header), que proporciona
autenticación, integridad y servicio de anti-repetición, mientras que el otro modo, ESP
(Encapsulating Security Payload), añade confidencialidad a todas las características anteriores.
Otras mejoras en cuanto a seguridad es la mayor fortaleza de la red, debido, por ejemplo, a no
tener que fragmentar los paquetes en nodos intermedios o el uso de cabeceras simplificadas.
Además, el escaneo de direcciones se vuelve mucho más complicado debido al alto número de
direcciones IPv6 que se pueden encontrar, que imposibilita realizar un ataque de fuerza bruta.
También se puede prescindir del uso de NAT, debido también al gran espacio de direcciones
disponible. Por último, se elimina la opción de realizar ataques de tipo broadcast al desaparecer
este tipo de direccionamiento.