IPv6

Una de las principales motivaciones fue la constatación de que el espacio de direcciones IPv4 de 32 bits comenzaba a agotarse, con nuevas subredes y nodos IP conectándose a Internet (y asignándoseles direcciones IP únicas) a un ritmo vertiginoso. El momento en que las direcciones IPv4 estarían completamente asignadas (y, por lo tanto, ninguna red nueva podría conectarse a Internet) fue objeto de un considerable debate.

IPv6 Datagram Format

• Capacidad de direcciones expandida IPv6 aumenta el tamaño de las direcciones IP de 32 a 128 bits. Además de las direcciones unicast y multicast, IPv6 ha introducido un nuevo tipo de dirección, denominada dirección anycast, que permite entregar un datagrama a cualquier host de un grupo de hosts.
• Un encabezado optimizado de 40 bytes Se han eliminado o hecho opcionales varios campos IPv4. El encabezado resultante, con una longitud fija de 40 bytes, permite un procesamiento más rápido del datagrama IP por parte de un enrutador. Una nueva codificación de opciones permite un procesamiento más flexible.
• Etiquetado de flujo IPv6 tiene una definición de flujo difícil de definir. La RFC 2460 establece que esto permite el etiquetado de paquetes pertenecientes a flujos específicos para los cuales el remitente solicita un manejo especial, como una calidad de servicio no predeterminada o un servicio en tiempo real. Por ejemplo, la transmisión de audio y video probablemente se considere un flujo. Por otro lado, las aplicaciones más tradicionales, como la transferencia de archivos y el correo electrónico, podrían no considerarse flujos. Es posible que el tráfico transportado por un usuario prioritario (por ejemplo, alguien que paga por un mejor servicio para su tráfico) también se considere un flujo.

Los siguientes campos se definieron en este protocolo:

• Versión Este campo de 4 bits identifica el número de versión de IP. Como era de esperar, IPv6 tiene un valor de 6 en este campo. Tenga en cuenta que escribir un 4 en este campo no crea un datagrama IPv4 válido.
• Clase de tráfico El campo de clase de tráfico de 8 bits, al igual que el campo TOS en IPv4, se puede utilizar para dar prioridad a ciertos datagramas dentro de un flujo, o se puede utilizar para dar prioridad a los datagramas de ciertas aplicaciones (por ejemplo, voz sobre IP) sobre los datagramas de otras (por ejemplo, correo electrónico SMTP).
• Etiqueta de flujo Este campo de 20 bits se utiliza para identificar un flujo de datagramas.
• Largo de los datos Este valor de 16 bits se trata como un entero sin signo que proporciona la cantidad de bytes del datagrama IPv6 que sigue al encabezado del datagrama de longitud fija de 40 bytes.
• Siguiente encabezado Este campo identifica el protocolo al que se entregará el contenido (campo de datos) de este datagrama (por ejemplo, TCP o UDP). Este campo utiliza los mismos valores que el campo de protocolo del encabezado IPv4.
• Límite de saltos El contenido de este campo se reduce en uno por cada enrutador que reenvía el datagrama. Si el límite de saltos llega a cero, el enrutador debe descartar el datagrama.
• Direcciones de origen y destino
• Datos Esta es la parte de carga útil del datagrama IPv6. Cuando el datagrama llega a su destino, la carga útil se elimina del datagrama IP y se transfiere al protocolo especificado en el siguiente campo de encabezado.

Observamos que varios campos que aparecen en el datagrama IPv4 ya no están presentes:

• Fragmentación/reensamblado IPv6 no permite la fragmentación ni el reensamblado en enrutadores intermedios; estas operaciones solo pueden ser realizadas por el origen y el destino. Si un datagrama IPv6 recibido por un enrutador es demasiado grande para ser reenviado por el enlace de salida, el enrutador simplemente lo descarta y envía un mensaje de error ICMP "Paquete demasiado grande" al remitente. Este puede entonces reenviar los datos, utilizando un datagrama IP de menor tamaño. La fragmentación y el reensamblado son operaciones que requieren mucho tiempo; eliminar esta funcionalidad de los enrutadores e implementarla directamente en los sistemas finales acelera considerablemente el reenvío IP dentro de la red.
• Checksum del encabezado Dado que los protocolos de la capa de transporte y de la capa de enlace en las capas de Internet realizan sumas de comprobación, los diseñadores de IP probablemente consideraron que esta funcionalidad era lo suficientemente redundante en la capa de red como para eliminarla. Una vez más, el procesamiento rápido de los paquetes IP fue una preocupación fundamental. Recordemos que, como la cabecera IPv4 contiene un campo TTL, la suma de comprobación de la cabecera IPv4 debía recalcularse en cada enrutador. Al igual que la fragmentación y el reensamblado, esta también era una operación costosa en IPv4.
• Options Ya no forma parte del encabezado IP estándar. Sin embargo, no ha desaparecido. En su lugar, es uno de los posibles encabezados siguientes a los que se apunta desde el encabezado IPv6. Es decir, al igual que los encabezados de los protocolos TCP o UDP pueden ser el siguiente encabezado dentro de un paquete IP, también lo puede ser un campo de opciones. La eliminación del campo de opciones da como resultado un encabezado IP de longitud fija de 40 bytes.