Protocolo de Internet versión 4

Protocolo de Internet versión 4 (IPv4) es la cuarta versión del Protocolo de Internet (IP). Es uno de los protocolos centrales de los métodos de interconexión de redes basados en estándares en Internet y otras redes de conmutación de paquetes. IPv4 fue la primera versión implementada para producción en SATNET en 1982 y en ARPANET en enero de 1983. Todavía se usa para enrutar la mayor parte del tráfico de Internet en la actualidad, incluso con la implementación en curso del Protocolo de Internet versión 6 (IPv6), su sucesor.

IPv4 utiliza un espacio de direcciones de 32 bits que proporciona 4 294 967 296 (2³²) direcciones únicas, pero los bloques grandes se reservan para fines de red especiales.

Historia

La versión 4 del Protocolo de Internet se describe en la publicación RFC 791 de IETF (septiembre de 1981), reemplazando una definición anterior de enero de 1980 (RFC 760). En marzo de 1982, el Departamento de Defensa de EE. UU. decidió que el conjunto de protocolos de Internet (TCP/IP) sería el estándar para todas las redes informáticas militares.

Propósito

El Protocolo de Internet es el protocolo que define y permite la interconexión de redes en la capa de Internet del conjunto de protocolos de Internet. En esencia, forma Internet. Utiliza un sistema de direccionamiento lógico y realiza enrutamiento, que es el reenvío de paquetes desde un host de origen al siguiente enrutador que está un paso más cerca del host de destino deseado en otra red.

IPv4 es un protocolo sin conexión y funciona con un modelo de entrega de mejor esfuerzo, ya que no garantiza la entrega, ni asegura la secuencia adecuada ni evita la entrega duplicada. Estos aspectos, incluida la integridad de los datos, se abordan mediante un protocolo de transporte de capa superior, como el Protocolo de control de transmisión (TCP).

Direccionamiento

Descomposición de la representación de dirección IPv4 de cuatro puntos a su valor binario

IPv4 usa direcciones de 32 bits que limitan el espacio de direcciones a 4294967296 (2³²) direcciones.

IPv4 reserva bloques de direcciones especiales para redes privadas (~18 millones de direcciones) y direcciones de multidifusión (~270 millones de direcciones).

Dirección de representaciones

Las direcciones IPv4 se pueden representar en cualquier notación que exprese un valor entero de 32 bits. La mayoría de las veces se escriben en notación decimal de punto, que consta de cuatro octetos de la dirección expresados individualmente en números decimales y separados por puntos.

Por ejemplo, la dirección IP de cuatro puntos 192.0.2.235 representa el número decimal de 32 bits 3221226219, que en formato hexadecimal es 0xC00002EB.

La notación CIDR combina la dirección con su prefijo de enrutamiento en un formato compacto, en el que la dirección va seguida de una barra inclinada (/) y el recuento de 1 bits consecutivos iniciales en el prefijo de enrutamiento (máscara de subred).

Otras representaciones de direcciones eran de uso común cuando se practicaba la creación de redes con clase. Por ejemplo, la dirección loopback 127.0.0.1 se suele escribir como 127.1, dado que pertenece a una red de clase A con ocho bits para la máscara de red y 24 bits para el número de anfitrión. Cuando se especifican menos de cuatro números en la dirección en notación punteada, el último valor se trata como un número entero de tantos bytes como sean necesarios para completar la dirección hasta los cuatro octetos. Así, la dirección 127.65530 equivale a 127.0.255.250.

Asignación

En el diseño original de IPv4, una dirección IP se dividía en dos partes: el identificador de red era el octeto más significativo de la dirección y el identificador de host era el resto de la dirección. Este último también se llamaba campo de descanso. Esta estructura permitía un máximo de 256 identificadores de red, lo que rápidamente se consideró inadecuado.

Para superar este límite, el octeto de dirección más importante se redefinió en 1981 para crear clases de red, en un sistema que más tarde se conoció como redes con clase. El sistema revisado definía cinco clases. Las clases A, B y C tenían diferentes longitudes de bits para la identificación de la red. El resto de la dirección se usó como antes para identificar un host dentro de una red. Debido a los diferentes tamaños de campos en diferentes clases, cada clase de red tenía una capacidad diferente para direccionar hosts. Además de las tres clases para el direccionamiento de hosts, la Clase D se definió para el direccionamiento de multidifusión y la Clase E se reservó para futuras aplicaciones.

La división de las redes con clase existentes en subredes comenzó en 1985 con la publicación de RFC 950. Esta división se hizo más flexible con la introducción de máscaras de subred de longitud variable (VLSM) en RFC 1109 en 1987. En 1993, según este trabajo, RFC 1517 introdujo el enrutamiento entre dominios sin clase (CIDR), que expresaba la cantidad de bits (desde el más significativo) como, por ejemplo, /24, y el esquema basado en clases se denominó classful, por el contrario. CIDR fue diseñado para permitir el reparticionamiento de cualquier espacio de direcciones para poder asignar bloques de direcciones más pequeños o más grandes a los usuarios. La estructura jerárquica creada por CIDR es administrada por la Autoridad de Números Asignados de Internet (IANA) y los registros regionales de Internet (RIR). Cada RIR mantiene una base de datos WHOIS de búsqueda pública que proporciona información sobre las asignaciones de direcciones IP.

Direcciones de uso especial

El Grupo de trabajo de ingeniería de Internet (IETF) y la IANA han restringido el uso general de varias direcciones IP reservadas para fines especiales. En particular, estas direcciones se utilizan para el tráfico de multidifusión y para proporcionar espacio de direccionamiento para usos sin restricciones en redes privadas.

Bloques de dirección especiales

Bloque de dirección	Catálogo	Número de direcciones	Ámbito	Descripción
0,00,0/8	0,00,0–0,255,255	16777216	Software	Red actual
10.0.0.0/8	10.0.0.0–10.255.255	16777216	Red privada	Se utiliza para comunicaciones locales dentro de una red privada.
100.64.0.0/10	100.64.0.0–100.127.255.255	4194304	Red privada	Espacio de dirección compartido para las comunicaciones entre un proveedor de servicios y sus suscriptores al utilizar un NAT de grado portador.
127.0.0.0/8	127.0.0.0–127.255.255	16777216	Host	Se utiliza para direcciones de vuelta al host local.
169.254.0.0/16	169.254.0.0–169.254.255.255	65536	Subnet	Se utiliza para direcciones locales entre dos hosts en un solo enlace cuando no se especifica la dirección IP, como se habría recuperado normalmente de un servidor DHCP.
172.16.0.0/12	172.16.0.0–172.31.255.255	1048576	Red privada	Se utiliza para comunicaciones locales dentro de una red privada.
192.0.0.0/24	192.0.0.0–192.0.0.255	256	Red privada	Asignaciones del Protocolo de la IETF.
192.0.2.0/24	192.0.2.0–192.0.255	256	Documentación	Assigned as TEST-NET-1, documentation and examples.
192.88.99.0/24	192.88.99.0-192.88.99.255	256	Internet	Reservado. Anteriormente utilizado para IPv6 a IPv4 relay (incluido IPv6 bloque de dirección 2002::/16).
192.168.0.0/16	192.168.0.0–192.168.255.255	65536	Red privada	Se utiliza para comunicaciones locales dentro de una red privada.
198.18,0/15	198.18.0.0–198.19.255.255	131072	Red privada	Se utiliza para realizar pruebas de referencia de comunicaciones entre redes entre dos subredes separados.
198.51.100.0/24	198.51.100.0–198.51.100.255	256	Documentación	Assigned as TEST-NET-2, documentation and examples.
203.0.113.0/24	203.0.113.0–203.0.113.255	256	Documentación	Assigned as TEST-NET-3, documentation and examples.
224.0.0.0/4	224.0.0.0–239.255.255	268435456	Internet	En uso para IP multicast. (Red de Clase D Former.)
233.252.0.0/24	233.252.0.0-233.252.0.255	256	Documentación	Assigned as MCAST-TEST-NET, documentation and examples.
240.0.0.0/4	240.0.0.0–255.255.254	268435455	Internet	Reservado para uso futuro. (Former Class E network.)
255.255.255/32	255.255.255	1	Subnet	Reservado para la dirección de destino "limited broadcast".

Redes privadas

De los aproximadamente cuatro mil millones de direcciones definidas en IPv4, alrededor de 18 millones de direcciones en tres rangos están reservadas para su uso en redes privadas. Las direcciones de paquetes en estos rangos no se pueden enrutar en la Internet pública; son ignorados por todos los enrutadores públicos. Por lo tanto, los hosts privados no pueden comunicarse directamente con las redes públicas, pero requieren la traducción de direcciones de red en una puerta de enlace de enrutamiento para este propósito.

Rangos de red IPv4 reservados

Nombre	Bloque CIDR	Catálogo	Número de direcciones	Clasificado descripción
Bloque de 24 bits	10.0.0.0/8	10.0.0.0 – 10.255.255	16777216	Clase única A.
Bloque de 20 bits	172.16.0.0/12	172.16.0.0 – 172.31.255.255	1048576	Rango contiguo de 16 bloques Clase B.
Bloque de 16 bits	192.168.0.0/16	192.168.0.0 – 192.168.255.255	65536	Rango contiguo de 256 Bloques Clase C.

Dado que dos redes privadas, por ejemplo, dos sucursales, no pueden interoperar directamente a través de la Internet pública, las dos redes deben conectarse a través de Internet a través de una red privada virtual (VPN) o un túnel IP, que encapsula los paquetes, incluidos sus encabezados que contienen las direcciones privadas, en una capa de protocolo durante la transmisión a través de la red pública. Además, los paquetes encapsulados pueden cifrarse para su transmisión a través de redes públicas para proteger los datos.

Direccionamiento local de enlace

RFC 3927 define el bloque de dirección especial 169.254.0.0/16 para el direccionamiento local de enlace. Estas direcciones solo son válidas en el enlace (como un segmento de red local o una conexión punto a punto) conectado directamente a un host que las utiliza. Estas direcciones no son enrutables. Al igual que las direcciones privadas, estas direcciones no pueden ser el origen ni el destino de los paquetes que atraviesan Internet. Estas direcciones se utilizan principalmente para la configuración automática de direcciones (Zeroconf) cuando un host no puede obtener una dirección IP de un servidor DHCP u otros métodos de configuración internos.

Cuando se reservó el bloque de direcciones, no existían estándares para la configuración automática de direcciones. Microsoft creó una implementación llamada Automatic Private IP Addressing (APIPA), que se implementó en millones de máquinas y se convirtió en un estándar de facto. Muchos años después, en mayo de 2005, el IETF definió un estándar formal en RFC 3927, titulado Configuración dinámica de direcciones locales de enlace IPv4.

Bucle invertido

La red de clase A 127.0.0.0 (red sin clase 127.0.0.0/8) está reservada para loopback. Los paquetes IP cuyas direcciones de origen pertenecen a esta red nunca deben aparecer fuera de un host. Los paquetes recibidos en una interfaz sin bucle invertido con una dirección de origen o destino de bucle invertido deben descartarse.

Primera y última dirección de subred

La primera dirección de una subred se utiliza para identificar la propia subred. En esta dirección, todos los bits de host son 0. Para evitar ambigüedades en la representación, esta dirección está reservada. La última dirección tiene todos los bits de host establecidos en 1. Se utiliza como dirección de difusión local para enviar mensajes a todos los dispositivos de la subred simultáneamente. Para redes de tamaño 24 o más grandes, la dirección de transmisión siempre termina en 255.

Por ejemplo, en la subred 192.168.5.0/24 (máscara de subred 255.255.255.0) se utiliza el identificador 192.168.5.0 para referirse a toda la subred. La dirección de difusión de la red es 192.168.5.255.

Sin embargo, esto no significa que todas las direcciones que terminen en 0 o 255 no se puedan usar como direcciones de host. Por ejemplo, en la subred/16 192.168.0.0/255.255.0.0, que es equivalente al rango de direcciones 192.168.0.0–192.168.255.255, la dirección de transmisión es 192.168.255.255. Se pueden utilizar las siguientes direcciones para hosts, aunque terminen en 255: 192.168.1.255, 192.168.2.255, etc. Además, 192.168.0.0 es el identificador de red y no debe asignarse a una interfaz. Se pueden asignar las direcciones 192.168.1.0, 192.168.2.0, etc., aunque terminen en 0.

En el pasado, surgían conflictos entre direcciones de red y direcciones de transmisión porque algunos programas usaban direcciones de transmisión no estándar con ceros en lugar de unos.

En redes más pequeñas que /24, las direcciones de difusión no termina necesariamente en 255. Por ejemplo, una subred CIDR 203.0.113.16/28 tiene la dirección de transmisión 203.0.113.31.

Como caso especial, una red /31 tiene capacidad para solo dos anfitriones. Estas redes se utilizan normalmente para conexiones punto a punto. No hay identificador de red o dirección de transmisión para estas redes.

Resolución de direcciones

Los hosts en Internet generalmente se conocen por nombres, por ejemplo, www.example.com, no principalmente por su dirección IP, que se utiliza para enrutamiento e identificación de interfaz de red. El uso de nombres de dominio requiere traducirlos, lo que se denomina resolver, a direcciones y viceversa. Esto es similar a buscar un número de teléfono en una guía telefónica usando el nombre del destinatario.

La traducción entre direcciones y nombres de dominio la realiza el Sistema de nombres de dominio (DNS), un sistema de nombres jerárquico y distribuido que permite la subdelegación de espacios de nombres a otros servidores DNS.

Interfaz no numerada

Un enlace punto a punto (PtP) no numerado, también llamado enlace de tránsito, es un enlace que no tiene una red IP o un número de subred asociado, pero aún tiene una dirección IP. Presentado por primera vez en 1993, se acredita a Phil Karn de Qualcomm como el diseñador original.

El propósito de un enlace de tránsito es enrutar datagramas. Se utilizan para liberar direcciones IP de un escaso espacio de direcciones IP o para reducir la gestión de asignación de IP y configuración de interfaces. Anteriormente, cada enlace necesitaba una subred dedicada/30 o/31 usando de 2 a 4 direcciones IP por enlace punto a punto. Cuando un enlace no está numerado, se usa un router-id, una única dirección IP prestada de una interfaz definida (normalmente un loopback). El mismo router-id se puede usar en varias interfaces.

Una de las desventajas de las interfaces no numeradas es que es más difícil realizar pruebas y administración remotas.

Agotamiento del espacio de direcciones

Plazo de agotamiento de la dirección IPv4

En la década de 1980, se hizo evidente que el conjunto de direcciones IPv4 disponibles se estaba agotando a un ritmo que inicialmente no se anticipó en el diseño original de la red. Las principales fuerzas del mercado que aceleraron el agotamiento de direcciones incluyeron el rápido crecimiento del número de usuarios de Internet, que usaban cada vez más dispositivos informáticos móviles, como computadoras portátiles, asistentes digitales personales (PDA) y teléfonos inteligentes con servicios de datos IP. Además, el acceso a Internet de alta velocidad se basó en dispositivos siempre activos. La amenaza del agotamiento motivó la introducción de una serie de tecnologías correctivas, tales como:

• Routing Inter-Domain Routing (CIDR), para asignaciones más pequeñas del ISP
• Interfaz sin numerar, eliminó la necesidad de enlaces de tránsito.
• traducción de dirección de red, elimina la necesidad de principio final a extremo.

A mediados de la década de 1990, la traducción de direcciones de red (NAT) se usaba de manera generalizada en los sistemas de proveedores de acceso a la red, junto con estrictas políticas de asignación basadas en el uso en los registros de Internet regionales y locales.

El grupo principal de direcciones de Internet, mantenido por la IANA, se agotó el 3 de febrero de 2011, cuando se asignaron los últimos cinco bloques a los cinco RIR. APNIC fue el primer RIR en agotar su grupo regional el 15 de abril de 2011, excepto por una pequeña cantidad de espacio de direcciones reservado para las tecnologías de transición a IPv6, que se asignará bajo una política restringida.

La solución a largo plazo para abordar el agotamiento fue la especificación de 1998 de una nueva versión del Protocolo de Internet, IPv6. Proporciona un espacio de direcciones mucho mayor, pero también permite una mejor agregación de rutas a través de Internet y ofrece grandes asignaciones de subredes de un mínimo de 2⁶⁴ direcciones de host para los usuarios finales. Sin embargo, IPv4 no es interoperable directamente con IPv6, por lo que los hosts solo de IPv4 no pueden comunicarse directamente con hosts solo de IPv6. Con la eliminación gradual de la red experimental 6bone a partir de 2004, la implementación formal permanente de IPv6 comenzó en 2006. Se espera que la finalización de la implementación de IPv6 tome un tiempo considerable, por lo que se necesitan tecnologías de transición intermedias para permitir que los hosts participen en Internet utilizando ambas versiones del protocolo.

Estructura del paquete

Un paquete IP consta de una sección de encabezado y una sección de datos. Un paquete IP no tiene suma de verificación de datos ni ningún otro pie de página después de la sección de datos. Por lo general, la capa de enlace encapsula los paquetes IP en tramas con un pie de página CRC que detecta la mayoría de los errores; muchos protocolos de la capa de transporte transportados por IP también tienen su propia verificación de errores.

Encabezado

El encabezado del paquete IPv4 consta de 14 campos, de los cuales 13 son obligatorios. El campo 14 es opcional y se llama acertadamente: opciones. Los campos en el encabezado se empaquetan con el byte más significativo primero (orden de bytes de red), y para el diagrama y la discusión, los bits más significativos se consideran primero (numeración de bits MSB 0). El bit más significativo tiene el número 0, por lo que el campo de versión se encuentra en los cuatro bits más significativos del primer byte, por ejemplo.

Versión

El primer campo de cabecera en un paquete IP es el campo de versión de cuatro bits. Para IPv4, esto es siempre igual a 4.

Longitud del encabezado de Internet (IHL)

El encabezado IPv4 es variable en tamaño debido al campo opcional 14 (opciones). El campo IHL contiene el tamaño del encabezado IPv4; tiene 4 bits que especifican el número de palabras de 32 bits en el encabezado. El valor mínimo para este campo es 5, lo que indica una longitud de 5 × 32 bits = 160 bits = 20 bytes. Como campo de 4 bits, el valor máximo es de 15; esto significa que el tamaño máximo de la cabecera IPv4 es de 15 × 32 bits = 480 bits = 60 bytes.

Punto de Código de Servicios Diferentes (DSCP)

Originalmente definido como el tipo de servicio (ToS), este campo especifica servicios diferenciados (DiffServ) por RFC 2474. La transmisión de datos en tiempo real hace uso del campo DSCP. Un ejemplo es Voice over IP (VoIP), que se utiliza para servicios de voz interactivos.

Notificación de Congestión de ExplícitosECN)

Este campo se define en RFC 3168 y permite la notificación de extremo a extremo de la congestión de red sin soltar paquetes. ECN es una característica opcional disponible cuando ambos puntos finales lo apoyan y son eficaces cuando también cuentan con el apoyo de la red subyacente.

Duración total

Este campo de 16 bits define todo el tamaño del paquete en bytes, incluyendo encabezado y datos. El tamaño mínimo es de 20 bytes (cabeza sin datos) y el máximo es de 65.535 bytes. Todos los anfitriones deben ser capaces de reensamblar datagramas de tamaño hasta 576 bytes, pero la mayoría de los anfitriones modernos manejan paquetes mucho más grandes. Los enlaces pueden imponer restricciones adicionales al tamaño del paquete, en cuyo caso los datagramas deben ser fragmentados. La fragmentación en IPv4 se realiza en el host de envío o en los routers. Reassembly se realiza en el host receptor.

Identificación

Este campo es un campo de identificación y se utiliza principalmente para identificar el grupo de fragmentos de un único datagram IP. Algunos trabajos experimentales han sugerido utilizar el campo de identificación para otros fines, como la adición de información de rastreo de paquetes para ayudar a rastrear los datagramas con direcciones de fuentes esponjosas, pero RFC 6864 ahora prohíbe cualquier uso de este tipo.

Banderas

Un campo de tres bits sigue y se utiliza para controlar o identificar fragmentos. Son (en orden, de lo más significativo a lo menos significativo):

• bit 0: Reservado; debe ser cero.
• bit 1: No Fragment (DF)
• bit 2: Más fragmentos (MF)

Si la bandera DF está fijada, y la fragmentación es necesaria para la ruta del paquete, entonces el paquete se deja caer. Esto se puede utilizar al enviar paquetes a un host que no tiene recursos para realizar reassembly de fragmentos. También se puede utilizar para el descubrimiento de MTU, ya sea automáticamente por el software IP host, o manualmente utilizando herramientas de diagnóstico como ping o traceroute.

Para paquetes infragmentados, la bandera MF está despejada. Para paquetes fragmentados, todos los fragmentos excepto los últimos tienen el conjunto de la bandera MF. El último fragmento tiene un campo Fragment Offset no cero, diferenciandolo de un paquete sinfragmentar.

Fragmento

Este campo especifica la compensación de un fragmento particular relativo al comienzo del datagrama IP original no fragmentado. El valor offset de fragmentación para el primer fragmento es siempre 0. El campo es de 13 bits de ancho, por lo que el offset puede ser de 0 a 8191 (de (2⁰ –1) a (2¹³– 1)). Los fragmentos se especifican en unidades de 8 bytes, por lo que la longitud de fragmento debe ser múltiples de 8. Por lo tanto, el campo de 13 bits permite una compensación máxima de (2¹³– 1) × 8 = 65.528 bytes, con la longitud de la cabecera incluida (65.528 + 20 = 65.548 bytes), soportando la fragmentación de paquetes superiores a la longitud IP máxima de 65.535 bytes.

Hora de vivir (TTL)

Un tiempo de ocho bits para vivir limita la vida de un datagram para prevenir la falla de la red en caso de un bucle de enrutamiento. Se especifica en segundos, pero intervalos de tiempo menos de 1 segundo se redondean hasta 1. En la práctica, el campo se utiliza como recuento de hop, cuando el datagrama llega a un router, el router decree el campo TTL por uno. Cuando el campo TTL llega a cero, el router descarta el paquete y normalmente envía un mensaje excedido del tiempo ICMP al remitente.

El programa traceroute envía mensajes con valores ajustados de TTL y utiliza estos mensajes superados de tiempo ICMP para identificar los routers atravesados por paquetes de la fuente al destino.

Protocolo

Este campo define el protocolo utilizado en la porción de datos del datagrama IP. IANA mantiene una lista de números de protocolos IP dirigidos por RFC 790.

Título del examen

El campo de prueba de cabecera IPv4 de 16 bits se utiliza para el control de errores del encabezado. Cuando un paquete llega a un router, el router calcula la suma de comprobación de la cabecera y lo compara con el campo de la suma de comprobación. Si los valores no coinciden, el router descarta el paquete. Los errores en el campo de datos deben ser manejados por el protocolo encapsulado. Tanto UDP como TCP tienen cheques separados que se aplican a sus datos.

Cuando un paquete llega a un router, el router disminuye el campo TTL en el encabezado. En consecuencia, el router debe calcular una nueva suma de comprobación de cabecera.

El campo checksum es el complemento de 16 bits de la suma completa de las 16 bits en el encabezado. Para fines de cálculo de la suma de comprobación, el valor del campo de la suma de comprobación es cero.

Dirección de fuentes

Este campo de 32 bits es la dirección IPv4 del remitente del paquete. Tenga en cuenta que esta dirección puede ser cambiada en tránsito por un dispositivo de traducción de dirección de red.

Dirección de destino

Este campo de 32 bits es la dirección IPv4 del receptor del paquete. Al igual que con la dirección fuente, esto puede ser cambiado en tránsito por un dispositivo de traducción de dirección de red.

Opciones

El campo de opciones no se utiliza a menudo. Los paquetes que contienen algunas opciones pueden ser considerados como peligrosos por algunos routers y ser bloqueados. Tenga en cuenta que el valor en el campo IHL debe incluir suficientes palabras extra de 32 bits para mantener todas las opciones más cualquier relleno necesario para asegurar que el encabezado contiene un número entero de palabras de 32 bits. Si IHL es mayor de 5 (es decir, es de 6 a 15) significa que el campo de opciones está presente y debe ser considerado. La lista de opciones puede terminarse con una opción EOOL (End of Options List, 0x00); esto sólo es necesario si el final de las opciones no coincidiría de otra manera con el final del encabezado. Las posibles opciones que se pueden poner en el encabezado son las siguientes:

Campo	Tamaño (bits)	Descripción
Copiado	1	Se establece a 1 si las opciones necesitan ser copiadas en todos los fragmentos de un paquete fragmentado.
Clase de opción	2	Una categoría de opciones generales. 0 es para control opciones, y 2 es para depuración y medición. 1 y 3 están reservados.
Número de opciones	5	Especifica una opción.
Duración de la opción	8	Indica el tamaño de toda la opción (incluyendo este campo). Este campo puede no existir para opciones simples.
Datos de opción	Variable	Datos específicos para la opción. Este campo puede no existir para opciones simples.

La tabla siguiente muestra las opciones definidas para IPv4. El Tipo de opción columna se deriva de los bits Copied, Option Class y Option Number como se definen anteriormente.

Tipo de opción (decimal/hexadecimal)	Nombre de opción	Descripción
0x00	EOOL	Fin de la lista de opciones
1/0x01	NOP	No hay operación
2/0x02	SEC	Seguridad (defunción)
7/0x07	RR	Ruta de grabación
10/0x0A	ZSU	Medición experimental
11/0x0B	MTUP	MTU Probe
12/0x0C	MTUR	MTU Respuesta
15/0x0F	ENCODE	ENCODE
25/0x19	QS	Inicio rápido
30/0x1E	EXP	Experimento de estilo RFC3692
68/0x44	TS	Time Stamp
82/0x52	TR	Traceroute
94/0x5E	EXP	Experimento de estilo RFC3692
130/0x82	SEC	Seguridad (RIPSO)
131/0x83	LSR	Ruta de la Fuente
133/0x85	E-SEC	Seguridad ampliada (RIPSO)
134/0x86	CIPSO	Opción de Seguridad IP comercial
136/0x88	SID	ID de transmisión
137/0x89	SSR	Ruta de la Fuente
142/0x8E	VISA	Control de acceso experimental
144/0x90	IMITD	IMI Traffic Descriptor
145/0x91	EIP	Protocolo ampliado de Internet
147/0x93	ADDEXT	Address Extension
148/0x94	RTRALT	Router Alert
149/0x95	SDB	Difusión selectiva dirigida
151/0x97	DPS	Estado de paquete dinámico
152/0x98	UMP	Paquete multicast
158/0x9E	EXP	Experimento de estilo RFC3692
205/0xCD	FINN	Control de flujo experimental
222/0xDE	EXP	Experimento de estilo RFC3692

Datos

La carga útil del paquete no se incluye en la suma de comprobación. Su contenido se interpreta en función del valor del campo de encabezado del protocolo.

La lista de números de protocolo IP contiene una lista completa de los tipos de protocolo de carga útil. Algunos de los protocolos de carga útil comunes incluyen:

Fragmentación y reensamblaje

El Protocolo de Internet permite el tráfico entre redes. El diseño da cabida a redes de diversa naturaleza física; es independiente de la tecnología de transmisión subyacente utilizada en la capa de enlace. Las redes con diferente hardware suelen variar no solo en la velocidad de transmisión, sino también en la unidad máxima de transmisión (MTU). Cuando una red quiere transmitir datagramas a una red con una MTU más pequeña, puede fragmentar sus datagramas. En IPv4, esta función se colocó en la capa de Internet y se realiza en enrutadores IPv4, lo que limita la exposición a estos problemas por parte de los hosts.

Por el contrario, IPv6, la próxima generación del Protocolo de Internet, no permite que los enrutadores realicen fragmentación; los hosts deben realizar Path MTU Discovery antes de enviar datagramas.

Fragmentación

Cuando un enrutador recibe un paquete, examina la dirección de destino y determina la interfaz de salida que se utilizará y la MTU de esa interfaz. Si el tamaño del paquete es mayor que la MTU y el bit No fragmentar (DF) en el encabezado del paquete está establecido en 0, entonces el enrutador puede fragmentar el paquete.

El enrutador divide el paquete en fragmentos. El tamaño máximo de cada fragmento es la MTU saliente menos el tamaño del encabezado IP (mínimo de 20 bytes; máximo de 60 bytes). El enrutador coloca cada fragmento en su propio paquete, cada paquete de fragmento tiene los siguientes cambios:

• El longitud total campo es el tamaño del fragmento.
• El más fragmentos (MF) bandera se establece para todos los fragmentos excepto el último, que se establece a 0.
• El fragmento offset campo se establece, basado en la compensación del fragmento en la carga útil de datos original. Esto se mide en unidades de bloques de 8 bytes.
• El Header checksum campo se recompone.

Por ejemplo, para un MTU de 1.500 bytes y un tamaño de cabeza de 20 bytes, los offsets de fragmentos serían múltiples de 1.500− − 208=185{displaystyle {frac {1{,}500-20}{8}=185} (0, 185, 370, 555, 740, etc.).

Es posible que un paquete se fragmente en un enrutador y que los fragmentos se fragmenten aún más en otro enrutador. Por ejemplo, un paquete de 4520 bytes, incluido un encabezado IP de 20 bytes, se fragmenta en dos paquetes en un enlace con una MTU de 2500 bytes:

El tamaño total de los datos se conserva: 2.480 bytes + 2.020 bytes = 4.500 bytes. Las compensaciones son 0{displaystyle 0} y 0+2.4808=310{displaystyle {frac {0+2{}480}=310}.

Cuando se reenvía a un enlace con una MTU de 1500 bytes, cada fragmento se fragmenta en dos fragmentos:

Nuevamente, se conserva el tamaño de los datos: 1480 + 1000 = 2480 y 1480 + 540 = 2020.

También en este caso, el bit Más fragmentos sigue siendo 1 para todos los fragmentos que vinieron con 1 y para el último fragmento que llega, funciona como de costumbre, es decir, el bit MF es puesto a 0 sólo en el último. Y por supuesto, el campo Identificación sigue teniendo el mismo valor en todos los fragmentos refragmentados. De esta manera, incluso si los fragmentos se vuelven a fragmentar, el receptor sabe que inicialmente todos comenzaron desde el mismo paquete.

El último offset y el último tamaño de los datos se utilizan para calcular el tamaño total de los datos: 495× × 8+540=3.960+540=4.500{displaystyle 495times 8+540=3{,}960+540=4{,}500}.

Reensamblaje

Un receptor sabe que un paquete es un fragmento si se cumple al menos una de las siguientes condiciones:

• La bandera más fragmentos se establece, que es cierto para todos los fragmentos excepto el último.
• El campo fragmento offset es nonzero, que es cierto para todos los fragmentos excepto el primero.

El receptor identifica fragmentos coincidentes utilizando las direcciones de origen y destino, el ID de protocolo y el campo de identificación. El receptor reensambla los datos de fragmentos con el mismo ID utilizando tanto el offset de fragmentos como la bandera de más fragmentos. Cuando el receptor recibe el último fragmento, que tiene el más fragmentos bandera fijada a 0, puede calcular el tamaño de la carga útil original de datos, multiplicando el último fragmento de compensación por ocho y añadiendo el tamaño de los datos del último fragmento. En el ejemplo dado, este cálculo fue 495× × 8+540=4.500{displaystyle 495times 8+540=4{,}500} bytes. Cuando el receptor tiene todos los fragmentos, se pueden reensamblar en la secuencia correcta según los offsets para formar el datagrama original.

Protocolos de asistencia

Las direcciones IP no están vinculadas de forma permanente al hardware de red y, de hecho, en los sistemas operativos modernos, una interfaz de red puede tener varias direcciones IP. Para entregar correctamente un paquete IP al host de destino en un enlace, los hosts y los enrutadores necesitan mecanismos adicionales para establecer una asociación entre la dirección de hardware de las interfaces de red y las direcciones IP. El Protocolo de resolución de direcciones (ARP) realiza esta traducción de dirección IP a dirección de hardware para IPv4. Además, a menudo es necesaria la correlación inversa. Por ejemplo, a menos que un administrador configure previamente una dirección, cuando un host IP se inicia o se conecta a una red, necesita determinar su dirección IP. Los protocolos para dichas correlaciones inversas incluyen el Protocolo de configuración dinámica de host (DHCP), el Protocolo de arranque (BOOTP) y, con poca frecuencia, el ARP inverso.