1.20. Header IPv6


Nota: Lastimosamente el contenido completo solo está disponible para miembros… por favor suscríbete
CCNA 200-301 Módulo 1 — Fundamentos de las redes Header IPv6: estructura, campos y extension headers

Header IPv6: estructura de campos, comparación con IPv4 y extension headers

⏱️ 18 min lectura 📊 Nivel: Intermedio

Por qué IPv6 necesitaba un nuevo header

Continuemos con la discusión de IPv6, y ahora hablemos sobre su Header. Aunque el agotamiento de direcciones IPv4 fue el detonante principal para el desarrollo de IPv6, la transición fue también una oportunidad para rediseñar el protocolo desde cero e incorporar características que IPv4 no podía ofrecer de forma nativa. Entre las más importantes se encuentran:

  • Mejor soporte para tráfico multicast
  • Un diseño de protocolo más eficiente para el enrutamiento, con un header de tamaño fijo que los routers pueden procesar más rápido
  • Mejor soporte para seguridad, con IPsec (Protección de datos) integrado como parte del protocolo en lugar de ser opcional como en IPv4. Hablamos de IPSec más adelante
  • Mejor soporte para dispositivos móviles
  • Mejor soporte para calidad de servicio (QoS), con los campos Traffic Class y Flow Label en el header principal
  • La posibilidad de que los dispositivos puedan autoconfigurar sus propias direcciones IPv6 sin necesidad de un servidor DHCP, mediante el mecanismo SLAAC

Para incorporar todas estas características era necesario construir un nuevo header. No era posible agregar todos estos campos al header IPv4 sin aumentar drásticamente su complejidad y el tiempo de procesamiento en cada router. La solución fue diseñar un header principal fijo y simple, y delegar las funcionalidades opcionales a lo que se conoce como extension headers, que se agregan solo cuando son necesarios.

Encapsulación de datos en IPv6

El proceso de encapsulación de datos en IPv6 sigue exactamente el mismo modelo que en IPv4.



Los datos se generan en la capa de aplicación, son entregados a la capa de transporte, la capa de transporte genera los segmentos y los entrega a la capa de red. En ese punto, el protocolo IPv6 agrega su header al segmento y forma el paquete IPv6. Ese paquete es entregado a la capa de enlace de datos, que lo encapsula en una trama, y la trama se transmite por el medio físico hacia el siguiente salto.

Lo que cambia respecto a IPv4 es la estructura del header que IPv6 agrega en la capa de red. Y una diferencia importante: a diferencia de IPv4, donde todas las opciones van dentro del header principal, IPv6 implementa un sistema de multiheader. Existe un header principal de tamaño fijo, y si se necesitan funcionalidades adicionales, se agregan extension headers entre el header principal y el header de la capa de transporte, esto lo veremos a continuación. Esta estructura en cadena permite que el header principal se mantenga simple y eficiente, sin importar qué funcionalidades opcionales se estén utilizando.

Estructura del header IPv6

El header IPv6 es un header más simple, no más pequeño. Con 128 bits para la dirección de origen y otros 128 bits para la dirección de destino, es imposible que sea más pequeño que el de IPv4. Lo que sí es más simple es su estructura: tiene un número menor de campos, todos de tamaño fijo, sin opciones variables que obliguen a los routers a hacer procesamiento adicional en cada salto.

El header IPv6 tiene siempre un tamaño fijo de 40 bytes — 320 bits — distribuidos en 8 campos. El header IPv4 mínimo tiene 20 bytes pero puede crecer hasta 60 bytes si se utilizan los campos de opciones, lo que obliga a los routers a verificar el campo Header Length en cada paquete para saber dónde termina el header y dónde empieza el payload. En IPv6 ese problema no existe: el header siempre tiene exactamente 40 bytes.



A continuación analizamos cada campo del header IPv6 y su relación con el header IPv4. Para facilitar la comparación, los campos se agrupan según su equivalencia entre ambos protocolos.

Campos del header IPv6 y comparación con IPv4

Version

El campo Version como lo vemos en la anterior imagen, tiene un tamaño de 4 bits en ambos headers y cumple exactamente la misma función: indica la versión del protocolo IP al que pertenece el header. En IPv4 el valor de este campo es 0100 (el número 4 en binario) y en IPv6 es 0110 (el número 6 en binario). Es el mismo campo con el mismo nombre y la misma función — solo cambia el valor.

 
logo
SI QUIERES DISFRUTAR DE ESTE CONTENIDO, TE INVITAMOS A QUE TE SUSCRIBAS.

❓ Preguntas Frecuentes

¿Cuántos bytes tiene el header IPv6 y por qué es siempre fijo?

El header IPv6 tiene siempre exactamente 40 bytes. Es fijo porque IPv6 eliminó los campos opcionales que en IPv4 hacían variable el tamaño del header (los campos Options y Padding). En IPv6, las funcionalidades opcionales se implementan mediante extension headers separados que se agregan únicamente cuando son necesarios. Al tener un tamaño de header siempre constante, los routers no necesitan calcular dónde termina el header en cada paquete, lo que acelera el procesamiento.

¿Cuál es la diferencia entre el campo Protocol de IPv4 y el campo Next Header de IPv6?

Ambos indican qué protocolo viene a continuación del header IP, pero Next Header tiene una función adicional en IPv6: cuando se utilizan extension headers, Next Header apunta al primer extension header de la cadena en lugar de apuntar directamente al protocolo de capa de transporte. Cada extension header tiene a su vez su propio campo Next Header que apunta al siguiente header en la cadena. Los valores numéricos que usan ambos campos son los mismos, ya que comparten la tabla de números de protocolo de IANA.

¿Qué son los extension headers de IPv6 y cuándo se usan?

Los extension headers son headers opcionales que se insertan entre el header principal de IPv6 y el header de la capa de transporte cuando se necesita alguna funcionalidad adicional — seguridad (IPsec), enrutamiento de origen, fragmentación, opciones para routers intermedios, etc. En un paquete IPv6 típico no hay ningún extension header: el campo Next Header del header principal apunta directamente a TCP o UDP. Los extension headers se encadenan mediante el campo Next Header de cada uno, formando una cadena que termina cuando se apunta al protocolo de capa de transporte.

 
logo
SI QUIERES DISFRUTAR DE ESTE CONTENIDO, TE INVITAMOS A QUE TE SUSCRIBAS.

PREGUNTAS!

Las preguntas que encontraras en esta sección, son similares a las que te encontraras en el examen de certificación.

Paso 1 de 2

  • Este campo está oculto cuando se visualiza el formulario

¡PARTICIPEMOS!

Si te quedaron dudas de la lección, escríbela a continuación y así todos podemos participar y ayudarte.
¿Quieres participar en los debates?… por favor suscríbete

NUESTROS CURSOS Foros Header IPv6

Viendo 11 entradas - de la 1 a la 11 (de un total de 11)
  • Autor
    Entradas
  • #11034
    AdminNG
    Superadministrador
    #16941
    Nicolás Madrid
    Participante

    Hola

    En la pregunta 2, el campo version tiene 4 bits. No seria en binario 0100?

    Gracias

    #16969
    AlvaroM
    Superadministrador

    Hola Nicolás!

    La pregunta indica que identifiquemos el VALOR BINARIO que encontraríamos en el campo versión de un header IPv6… nos está preguntando por EL VALOR de ese campo, no nos pregunta por el TAMAÑO de ese campo. Si tú capturas una trama con un paquete IPv6… el campo versión del header IPv6 tendría el valor decimal de «6» indicando que efectivamente se trata de un paquete IPv6… 6 en valor binario es equivalente a 0110 y por ello esta es la respuesta correcta.

    Espero que con esta explicación quede más claro! =)

    • Esta respuesta fue modificada hace 5 años, 11 meses por AlvaroM.
    #17178
    Chrisstopher1893
    Participante

    Hola Alvaro!
    Tengo estas dudas en las siguientes preguntas:

    2. ¿Qué valor binario encontraríamos en el campo versión del header IPv6?
    (Vi la solucion en los comentarios, pero me gustaria saber que diferencia existe entre VALOR y TAMAÑO)

    5. Si tenemos un tamaño del paquete IPv6 de 1500 bytes, ¿Cuál es el tamaño del payload (extensión headers + datos de transporte + datos de aplicación)
    (Como seria el proceso de solucion correcta de esta pregunta)

    #17187
    AlvaroM
    Superadministrador

    Hola Chris!

    Respeto a tu primera pregunta, el valor es el CONTENIDO que encontramos DENTRO del campo que se encuentra en el header… tú tienes muchos campos dentro de 1 header no es cierto? y cada uno de ellos alberga un VALOR que tiene un significado en particular. El tamaño es simplemente el espacio físico en bits/bytes que dispones para albergar el valor.

    El campo versión del header IPv6 tiene un TAMAÑO de 4 bits… tu puedes utilizar esos 4 bits para generar un VALOR que tenga un significado en particular… en este caso si encontramos el valor de 0110 (decimal 6) en ese campo, esto tiene un significado, significa que ese header representa a un header del protocolo IPv6… si encontrarías en el campo versión el valor de 0100 (decimal), esto también tiene un significado, significa que ese header representa a un header del protocolo IPv4.

    Respecto a tu segunda pregunta, acá tienes que tener claros los conceptos de encapsulación… cuando hablamos del PAYLOAD, estamos hablando de algo que es encapsulado detrás de un header… por ejemplo, en una trama Ethernet, el header es donde se encuentran las direcciones MAC de origen, destino, el tipo de la trama, etc etc… y el Payload llega a ser lo que se encuentra DESPUÉS del header, es decir estaríamos hablando del header IP, del header del protocolo de la capa de Transporte y de los datos de Aplicación. Otro ejemplo… en un segmento TCP, el PAYLOAD es lo que se encuentra después del header TCP… el payload en este caso llegaría a ser los datos de Aplicación.

    Volviendo a la pregunta, en un paquete IPv6 el Payload es lo que se encuentra DESPUÉS del header IPv6… es decir el Payload en este caso está conformado por los extensión headers, por el segmento TCP o el datagrama UDP y por los datos de Aplicación… la pregunta ya te indica que el paquete tiene un tamaño de 1500 bytes, es decir esos 1500 bytes están conformados por el tamaño del header IPv6 + los extension header IPv6 + el header del protocolo de Transporte (UDP o TCP) + los datos de Aplicación. El tamaño del header IPv6 es de 40 bytes sin contar los extension headers… entonces para obtener al Payload, simplemente tienes que agarrar los 1500 bytes y restarle el tamaño del header IPv6 (40 bytes), esto da como resultado 1460 bytes que es la respuesta correcta.

    Espero que ahora quede más claro.

    Saludos cordiales!

    • Esta respuesta fue modificada hace 5 años, 10 meses por AlvaroM.
    • Esta respuesta fue modificada hace 5 años, 10 meses por AlvaroM.
    #20193
    edson4888
    Participante

    Alvaro:
    unas consultas
    1.- el playload es de un tamaño de 16 bits pero en la respuesta del ejercicio 5 indicas que el tamaño u o valor sera de 1460 bytes… no entiendo muy bien eso, o esque es el valor que iria en el playload y ese valor estaria representado en bytes???

    2.- el header ipv6 tiene un tamaño de 40 bytes y su nextheader de 8 bits, mi cunsulta es cada extencsion header tambien sera de 40 bytes??

    #20199
    AlvaroM
    Superadministrador

    Hola Edson!

    1. El campo «Payload lenght» es diferente al «Payload». Cuando nosotros hablamos de «Payload» hablamos sobre TODO lo que se está encapsulando a continuación de un header, ya sea un header capa 2, capa 3 o capa 4. El «Payload» en IPv6 está conformado por los Extension headers, por el header de la Capa de Transporte y por los datos de Aplicación (no incluye al header IPv6). Por el otro lado, el campo Payload Lenght, te indica el «TAMAÑO» que va tener tu Payload.

    En la pregunta te indican que el tamaño DEL PAQUETE es de 1500 bytes. Si recuerdas las clases de encapsulación, ya sabes que el paquete IPv6 está conformado por: Header de capa 3 + Extension Headers + Header de capa 4 + Datos de Aplicación. En la pregunta te están pidiendo el tamaño de Payload, ya sabemos que Payload NO incluye al header de capa 3. Por lo tanto: Payload = Tamaño del paquete – Header de capa 3 -> Payload = 1500 – 40 -> Payload: 1460 bytes.

    2. El «Extension Header» no tiene un tamaño fijo. Por el otro lado, el campo Next-header te indica el tipo de Extension header que estarás utilizando. Dependiendo del valor encontrado en ese campo Next-header tendrás el tamaño del Extension header. Los Extension Headers siempre tendrán un tamaño múltiplo de 8 bytes (8, 16, 32, 40 bytes).

    Por ejemplo, si ves en el campo Next-Header el valor decimal de 44, esto significa que el Extension Header es un «Fragment Header», este «Fragment Header» tendrá un tamaño de 8 bytes.

    Espero que ahora quede claro el panorama!

    Estoy atento a tus comentarios.

    Saludos cordiales.

    #33013
    richchri
    Participante

    en la imagen por ejemplo en el minuto 0:27

    tengo la duda porque en el caso del paquete IP4 es de 32 bits horizontalmente y de 40-60 bytes verticalmente si el header es de 32 bits entonces los bytes son el peso del paquete ?

    En la imagen de IPv6 horizontalmente 32 bits y verticalmente va de 40bytes entonces si ipv6 se dice que es de 128 bits porque en la imagen aparece q son 32 y si los 40 bytes representan su tamaño?

    #33019
    AlvaroM
    Superadministrador

    Hola Richchri!

    Si hablamos del header IPv4, está conformado (sin los campos Opciones y Padding) por 5 bloques de 32 bits que equivalen a los 20 bytes. Supongamos que solo trabajamos desde el campo Version hasta el campo Destination address; los campos Version, IHL, DSCP ECN y Packet Lenght son 32 bits en TOTAL, a continuación tenemos el campo Identification, Flags y Fragment offset que son otros 32 bits en TOTAL, después tenemos el campo Time to Live, Protocol y Header Checksum que son nuevamente OTROS 32 bits en total, a continuación tenemos el campo Source Address que son otros 32 bits, y finalmente el campo Destination Address que son OTROS 32 bits en total. Si tú haces la sumatoria de todos esos bits, te da un total de 160 bits lo que es equivalente a 20 BYTES. Por lo tanto es lo mismo hablar en bits o bytes.

    En IPv6 ocurre lo mismo, los campos Version, Traffic Class y Flow Label, equivalen a 32 bits; los campos PayLoad Lenght, Next Header y Hop Limit son otros 32 bits, el campo Source address es equivalente a 4 bloques de 32 bits (de ahí los 128 bits de tamaño); ocurre lo mismo con el campo Destination address que es equivalente a 4 bloques de 32 bits (de ahí los 128 bits de tamaño). Haciendo la sumatoria tenemos: 32 bits + 32 bits, + (32 + 32 + 32 + 32) + (32 + 32 + 32 + 32) = 320 bits, si lo dividimos entre 8, esto es equivalente a los 40 bytes que tú ves en la imagen.

    Espero que ahora quede más claro.

    Estoy atento a tus comentarios! =)

    #41884
    Joel Rodriguez
    Participante

    buenas profe me puede explicar la primera pregunta, que no entiendo el porque de la respuesta. Gracias de antemano!

    • Esta respuesta fue modificada hace 1 año, 9 meses por Joel Rodriguez.
    #41887
    AlvaroM
    Superadministrador

    Hola Joel, estos son conceptos de encapsulación y desencapsulación que los aprendes en las primeras clases del curso. Vamos descartando las opciones, «La computadora elimina el header y el trailer Ethernet y entrega el segmento a la capa de red», esta opción es incorrecta, ya que la denominación al PDU de la capa de red/Internet es «Paquete» y no «Segmento», además que estamos haciendo una desencapsulación y no una encapsulación. La opción «La computadora elimina el header del segmento para analizar el Header IPv6» es incorrecta debido a que, si recibes una trama, lo primero que haces es eliminar el header y el trailer de la trama Ethernet, y no así el header del segmento de la capa de Transporte. La opción «La computadora elimina el header y el trailer Ethernet y entrega el paquete a la capa de Transporte», esta opción es incorrecta, debido a que después del proceso de des encapsulación en la capa de Enlace de datos, se entregan los datos a la capa de Red/Internet y no así a la capa de Transporte. La opción «La computadora elimina el header y el trailer Ethernet y analiza el header IPv4 para después analizar el header IPv6» es incorrecta ya que no estamos hablando de IPv4, solo de IPv6. Lo que deja como opción correcta «La computadora elimina el header y el trailer Ethernet y analiza el header IPv6». En el proceso de desencapsulación, primero se elimina el header y el trailer Ethernet, después el header IP, después el header de la capa de transporte, y finalmente nos quedan los datos.

    Espero que ahora quede claro.

    Saludos! =)

Viendo 11 entradas - de la 1 a la 11 (de un total de 11)
  • Debes estar registrado para responder a este debate.