IPv4
El Protocolo de Internet versión 4 o 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 especiales de red.
Historia
El Protocolo de Internet versión 4 se describe en la publicación IETF RFC 791 (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.
Objetivo
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 el 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 previsto en otra red.
IPv4 es un protocolo sin conexión y funciona con un modelo de entrega de mejor esfuerzo, en el sentido de 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
IPv4 utiliza direcciones de 32 bits, lo que limita el espacio de direcciones a 4 294 967 296 (2) direcciones.
IPv4 reserva bloques de direcciones especiales para redes privadas (~18 millones de direcciones) y direcciones de multidifusión (~270 millones de direcciones).
Representaciones de dirección
Las direcciones IPv4 pueden representarse 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 un carácter de 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 de bucle invertido 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 host. 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 fue llamado el 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 luego 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, sobre la base de este trabajo, RFC 1517 introdujo el enrutamiento entre dominios sin clases (CIDR), que expresaba el número 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.
| Bloque de direcciones | Rango de direcciones | Número de direcciones | Alcance | Descripción |
|---|---|---|---|---|
| 0.0.0.0/8 | 0.0.0.0–0.255.255.255 | 16 777 216 | Software | Red actual |
| 10.0.0.0/8 | 10.0.0.0–10.255.255.255 | 16 777 216 | 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 | 4 194 304 | Red privada | Espacio de direcciones compartido para las comunicaciones entre un proveedor de servicios y sus suscriptores cuando se utiliza un NAT de nivel de operador. |
| 127.0.0.0/8 | 127.0.0.0–127.255.255.255 | 16 777 216 | Anfitrión | Se utiliza para direcciones de loopback al host local. |
| 169.254.0.0/16 | 169.254.0.0–169.254.255.255 | 65 536 | subred | Se utiliza para direcciones locales de enlace entre dos hosts en un solo enlace cuando no se especifica ninguna dirección IP, como la que normalmente se habría obtenido de un servidor DHCP. |
| 172.16.0.0/12 | 172.16.0.0–172.31.255.255 | 1 048 576 | 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 de protocolo IETF. |
| 192.0.2.0/24 | 192.0.2.0–192.0.2.255 | 256 | Documentación | Asignado como TEST-NET-1, documentación y ejemplos. |
| 192.88.99.0/24 | 192.88.99.0–192.88.99.255 | 256 | Internet | Reservado. Anteriormente utilizado para la retransmisión de IPv6 a IPv4 (incluido el bloque de direcciones IPv6 2002::/16). |
| 192.168.0.0/16 | 192.168.0.0–192.168.255.255 | 65 536 | Red privada | Se utiliza para comunicaciones locales dentro de una red privada. |
| 198.18.0.0/15 | 198.18.0.0–198.19.255.255 | 131 072 | Red privada | Se utiliza para pruebas comparativas de comunicaciones entre redes entre dos subredes separadas. |
| 198.51.100.0/24 | 198.51.100.0–198.51.100.255 | 256 | Documentación | Asignado como TEST-NET-2, documentación y ejemplos. |
| 203.0.113.0/24 | 203.0.113.0–203.0.113.255 | 256 | Documentación | Asignado como TEST-NET-3, documentación y ejemplos. |
| 224.0.0.0/4 | 224.0.0.0–239.255.255.255 | 268 435 456 | Internet | En uso para multidifusión IP. (Antigua red Clase D). |
| 233.252.0.0/24 | 233.252.0.0-233.252.0.255 | 256 | Documentación | Asignado como MCAST-TEST-NET, documentación y ejemplos. |
| 240.0.0.0/4 | 240.0.0.0–255.255.255.254 | 268 435 455 | Internet | Reservado para utilización futura. (Antigua red Clase E). |
| 255.255.255.255/32 | 255.255.255.255 | 1 | subred | Reservado para la dirección de destino de "difusión limitada". |
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 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.
| Nombre | bloque CIDR | Rango de direcciones | Número de direcciones | Descripción con clase |
|---|---|---|---|---|
| bloque de 24 bits | 10.0.0.0/8 | 10.0.0.0 – 10.255.255.255 | 16 777 216 | Clase única A. |
| bloque de 20 bits | 172.16.0.0/12 | 172.16.0.0 – 172.31.255.255 | 1 048 576 | Gama contigua de 16 bloques Clase B. |
| bloque de 16 bits | 192.168.0.0/16 | 192.168.0.0 – 192.168.255.255 | 65 536 | 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 la 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 mayores, 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.
| forma binaria | Notación punto-decimal | |
|---|---|---|
| espacio de red | 11000000.10101000.00000101.00000000 | 192.168.5.0 |
| Dirección de Difusión | 11000000.10101000.00000101.11111111 | 192.168.5.255 |
| En rojo, se muestra la parte del host de la dirección IP; la otra parte es el prefijo de red. El host se invierte (NO lógico), pero el prefijo de red permanece intacto. |
Sin embargo, esto no significa que todas las direcciones que terminen en 0 o 255 no puedan usarse 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 las direcciones de red y las direcciones de transmisión porque algunos programas usaban direcciones de transmisión no estándar con ceros en lugar de unos.
En redes menores a /24, las direcciones de transmisión no terminan necesariamente en 255. Por ejemplo, una subred CIDR 203.0.113.16/28 tiene la dirección de transmisión 203.0.113.31.
| forma binaria | Notación punto-decimal | |
|---|---|---|
| espacio de red | 11001011.00000000.01110001.00010000 | 203.0.113.16 |
| Dirección de Difusión | 11001011.00000000.01110001.00011111 | 203.0.113.31 |
| En rojo, se muestra la parte del host de la dirección IP; la otra parte es el prefijo de red. El host se invierte (NO lógico), pero el prefijo de red permanece intacto. |
Como caso especial, una red /31 tiene capacidad para solo dos hosts. 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 resolverlos, 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 se realiza mediante 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 sin numerar
Un enlace punto a punto (PtP) no numerado, también llamado enlace de tránsito, es un enlace que no tiene ninguna red IP o número de subred asociado, pero aún tiene una dirección IP. Introducido por primera vez en 1993. El único propósito de un enlace de tránsito es enrutar datagramas.
El enlace no numerado se utiliza para liberar direcciones IP, cuando se tiene un espacio de direcciones IP escaso, o reducir la gestión de asignación de IP y configuración de interfaces. Antes, cada enlace necesita una subred /30 o /31 dedicada que use de 2 a 4 direcciones IP por enlace punto a punto. Cuando un enlace no está numerado, se usa una identificación de enrutador, la identificación del enrutador es una dirección IP /32 prestada de una interfaz definida (normalmente un bucle invertido). El mismo ID de enrutador se puede usar en varias interfaces.
Una de las desventajas de la interfaz no numerada es que es más difícil realizar pruebas y administración remotas.
Phil Karn de Qualcomm es acreditado como diseñador original.
Agotamiento del espacio de direcciones
Desde la década de 1980, era 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 las 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:
- Enrutamiento entre dominios sin clase (CIDR), para asignaciones de ISP más pequeñas
- Interfaz no numerada, eliminó la necesidad de enlaces de tránsito.
- traducción de direcciones de red, eliminó la necesidad del principio de extremo a extremo.
A mediados de la década de 1990, el uso generalizado de la traducción de direcciones de red (NAT) en los sistemas de proveedores de acceso a la red y las 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 subred 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.
Encabezamiento
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 (big endian), 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.
| Compensaciones | Octeto | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octeto | Un poco | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Versión | DIH | DSCP | ECN | Largo total | |||||||||||||||||||||||||||
| 4 | 32 | Identificación | Banderas | Desplazamiento de fragmentos | |||||||||||||||||||||||||||||
| 8 | 64 | Tiempo para vivir | Protocolo | Suma de comprobación del encabezado | |||||||||||||||||||||||||||||
| 12 | 96 | Dirección IP origen | |||||||||||||||||||||||||||||||
| dieciséis | 128 | Dirección IP de destino | |||||||||||||||||||||||||||||||
| 20 | 160 | Opciones (si DIH > 5) | |||||||||||||||||||||||||||||||
| ⋮ | ⋮ | ||||||||||||||||||||||||||||||||
| 56 | 448 |
VersiónEl primer campo de encabezado en un paquete IP es el campo de versión de cuatro bits. Para IPv4, siempre es igual a 4.Longitud del encabezado de Internet (IHL)El encabezado de IPv4 tiene un tamaño variable debido al campo 14 opcional (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 de 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 15; esto significa que el tamaño máximo del encabezado IPv4 es de 15 × 32 bits = 480 bits = 60 bytes.Punto de código de servicios diferenciados (DSCP)Definido originalmente como el tipo de servicio (ToS), este campo especifica servicios diferenciados (DiffServ) según RFC 2474. La transmisión de datos en tiempo real utiliza el campo DSCP. Un ejemplo es Voice over IP (VoIP), que se utiliza para servicios de voz interactivos.Notificación de congestión explícita (ECN)Este campo se define en RFC 3168 y permite la notificación de congestión de red de extremo a extremo sin descartar paquetes. ECN es una función opcional disponible cuando ambos extremos la admiten y es efectiva cuando también la admite la red subyacente.Largo totalEste campo de 16 bits define el tamaño completo del paquete en bytes, incluidos el encabezado y los datos. El tamaño mínimo es de 20 bytes (cabecera sin datos) y el máximo de 65.535 bytes. Se requiere que todos los hosts puedan volver a ensamblar datagramas de un tamaño de hasta 576 bytes, pero la mayoría de los hosts modernos manejan paquetes mucho más grandes. Los enlaces pueden imponer más restricciones en el tamaño del paquete, en cuyo caso los datagramas deben fragmentarse. La fragmentación en IPv4 se realiza en el host de envío o en los enrutadores. El reensamblado se realiza en el host receptor.IdentificaciónEste campo es un campo de identificación y se utiliza principalmente para identificar de forma única el grupo de fragmentos de un solo datagrama IP. Algunos trabajos experimentales sugirieron usar el campo ID para otros fines, como agregar información de seguimiento de paquetes para ayudar a rastrear datagramas con direcciones de origen falsificadas, pero RFC 6864 ahora prohíbe tal uso.BanderasSigue un campo de tres bits y se utiliza para controlar o identificar fragmentos. Son (en orden, de más significativo a menos significativo):
- bit 0: Reservado; debe ser cero.
- bit 1: No fragmentar (DF)
- bit 2: Más Fragmentos (MF)
Si se establece el indicador DF y se requiere fragmentación para enrutar el paquete, entonces el paquete se descarta. Esto se puede usar cuando se envían paquetes a un host que no tiene recursos para realizar el reensamblado de fragmentos. También se puede utilizar para el descubrimiento de MTU de ruta, ya sea automáticamente mediante el software IP del host o manualmente mediante herramientas de diagnóstico como ping o traceroute.Para paquetes no fragmentados, se borra el indicador MF. Para paquetes fragmentados, todos los fragmentos excepto el último tienen el indicador MF establecido. El último fragmento tiene un campo Fragment Offset distinto de cero, lo que lo diferencia de un paquete no fragmentado.Desplazamiento de fragmentosEste campo especifica el desplazamiento de un fragmento particular en relación con el comienzo del datagrama IP original no fragmentado en unidades de bloques de ocho bytes. El primer fragmento tiene un desplazamiento de cero. El campo de 13 bits permite un desplazamiento máximo de (2 – 1) × 8 = 65 528 bytes que, con la longitud del encabezado incluida (65 528 + 20 = 65 548 bytes), admite la fragmentación de paquetes que superan la longitud máxima de IP de 65 535 bytes.Tiempo de vida (TTL)Un campo de tiempo de vida de ocho bits limita la vida útil de un datagrama para evitar fallas en la red en caso de un bucle de enrutamiento. Se especifica en segundos, pero los intervalos de tiempo inferiores a 1 segundo se redondean a 1. En la práctica, el campo se utiliza como conteo de saltos: cuando el datagrama llega a un enrutador, el enrutador reduce el campo TTL en uno. Cuando el campo TTL llega a cero, el enrutador descarta el paquete y normalmente envía un mensaje ICMP de tiempo excedido al remitente.El programa traceroute envía mensajes con valores TTL ajustados y utiliza estos mensajes ICMP de tiempo excedido para identificar los enrutadores atravesados por paquetes desde el origen hasta el destino.ProtocoloEste campo define el protocolo utilizado en la porción de datos del datagrama IP. IANA mantiene una lista de números de protocolo IP según lo indica RFC 790.Suma de comprobación del encabezadoEl campo de suma de comprobación del encabezado IPv4 de 16 bits se utiliza para la comprobación de errores del encabezado. Cuando un paquete llega a un enrutador, el enrutador calcula la suma de verificación del encabezado y la compara con el campo de suma de verificación. Si los valores no coinciden, el enrutador descarta el paquete. Los errores en el campo de datos deben ser manejados por el protocolo encapsulado. Tanto UDP como TCP tienen sumas de verificación separadas que se aplican a sus datos.Cuando un paquete llega a un enrutador, el enrutador reduce el campo TTL en el encabezado. En consecuencia, el enrutador debe calcular una nueva suma de verificación de encabezado.Dirección de la fuenteEste campo es la dirección IPv4 del remitente del paquete. Tenga en cuenta que esta dirección puede cambiarse en tránsito por un dispositivo de traducción de direcciones de red.Dirección de destinoEste campo es la dirección IPv4 del receptor del paquete. Al igual que con la dirección de origen, esto puede cambiarse en tránsito por un dispositivo de traducción de direcciones de red.OpcionesEl campo de opciones no se usa con frecuencia. Los paquetes que contienen algunas opciones pueden ser considerados peligrosos por algunos enrutadores y ser bloqueados. Tenga en cuenta que el valor en el campo IHL debe incluir suficientes palabras adicionales de 32 bits para contener todas las opciones más cualquier relleno necesario para garantizar que el encabezado contenga un número entero de palabras de 32 bits. Si IHL es mayor a 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 terminar con una opción EOOL (Fin de la lista de opciones, 0x00); esto solo es necesario si el final de las opciones no coincidiría con el final del encabezado. Las posibles opciones que se pueden poner en la cabecera son las siguientes:
| Campo | Tamaño (bits) | Descripción |
|---|---|---|
| copiado | 1 | Establézcalo en 1 si es necesario copiar las opciones en todos los fragmentos de un paquete fragmentado. |
| Clase de opción | 2 | Una categoría de opciones generales. 0 es para opciones de control y 2 es para depuración y medición. 1 y 3 están reservados. |
| Número de opción | 5 | Especifica una opción. |
| Longitud de la opción | 8 | Indica el tamaño de toda la opción (incluido este campo). Este campo puede no existir para opciones simples. |
| Datos de opción | Variable | Datos específicos de la opción. Este campo puede no existir para opciones simples. |
La siguiente tabla muestra las opciones definidas para IPv4. La columna Tipo de opción se deriva de los bits Copiado, Clase de opción y Número de opción como se definió anteriormente.
| Tipo de opción (decimal/hexadecimal) | Nombre de la opción | Descripción |
|---|---|---|
| 0 / 0x00 | EOOL | Fin de la lista de opciones |
| 1 / 0x01 | NOP | No operacion |
| 2 / 0x02 | SEGUNDO | Seguridad (desaparecido) |
| 7 / 0x07 | RR | Grabar ruta |
| 10 / 0x0A | ZSU | Medición Experimental |
| 11 / 0x0B | MTUP | Sonda MTU |
| 12 / 0x0C | MTUR | Respuesta de MTU |
| 15 / 0x0F | CODIFICAR | CODIFICAR |
| 25 / 0x19 | QS | Inicio rápido |
| 30 / 0x1E | Exp | Experimento de estilo RFC3692 |
| 68 / 0x44 | TS | Marca de tiempo |
| 82 / 0x52 | TR | trazarruta |
| 94 / 0x5E | Exp | Experimento de estilo RFC3692 |
| 130 / 0x82 | SEGUNDO | Seguridad (RIPSO) |
| 131 / 0x83 | LSR | Ruta de fuente suelta |
| 133 / 0x85 | ESEC | Seguridad extendida (RIPSO) |
| 134 / 0x86 | CIPSO | Opción de seguridad IP comercial |
| 136 / 0x88 | S.I.D. | Id. de transmisión |
| 137 / 0x89 | RSS | Ruta de origen estricta |
| 142 / 0x8E | VISA | Control de acceso experimental |
| 144 / 0x90 | IMITADO | Descriptor de tráfico IMI |
| 145 / 0x91 | EIP | Protocolo de Internet extendido |
| 147 / 0x93 | AÑADIR | Extensión de dirección |
| 148 / 0x94 | ALT.RT | Alerta de enrutador |
| 149 / 0x95 | SDB | Difusión dirigida selectiva |
| 151 / 0x97 | DPD | Estado de paquete dinámico |
| 152 / 0x98 | UMP | Paquete de multidifusión ascendente. |
| 158 / 0x9E | Exp | Experimento de estilo RFC3692 |
| 205 / 0x CD | FINLANDÉS | 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:
| Número de protocolo | Nombre del protocolo | Abreviatura |
|---|---|---|
| 1 | Protocolo de mensajes de control de Internet | ICMP |
| 2 | Protocolo de gestión de grupos de Internet | IGMP |
| 6 | Protocolo de Control de Transmisión | TCP |
| 17 | Protocolo de datagramas de usuario | UDP |
| 41 | Encapsulación IPv6 | ENCAP |
| 89 | Abrir primero la ruta más corta | OSPF |
| 132 | Protocolo de transmisión de control de flujo | SCTP |
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 a 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 campo de longitud total es el tamaño del fragmento.
- El indicador de más fragmentos (MF) se establece para todos los fragmentos excepto el último, que se establece en 0.
- El campo de desplazamiento del fragmento se establece en función del desplazamiento del fragmento en la carga útil de datos original. Esto se mide en unidades de bloques de 8 bytes.
- Se vuelve a calcular el campo de suma de comprobación del encabezado.
Por ejemplo, para una MTU de 1500 bytes y un tamaño de encabezado de 20 bytes, los desplazamientos de fragmentos serían múltiplos de 
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:
| Fragmento | Tamaño(bytes) | Tamaño del encabezado(bytes) | Tamaño de datos(bytes) | MarcarMás fragmentos | Desplazamiento de fragmentos(bloques de 8 bytes) |
|---|---|---|---|---|---|
| 1 | 2,500 | 20 | 2,480 | 1 | 0 |
| 2 | 2,040 | 20 | 2,020 | 0 | 310 |
Se conserva el tamaño total de los datos: 2480 bytes + 2020 bytes = 4500 bytes. Las compensaciones son 
Cuando se reenvía a un enlace con una MTU de 1500 bytes, cada fragmento se fragmenta en dos fragmentos:
| Fragmento | Tamaño(bytes) | Tamaño del encabezado(bytes) | Tamaño de datos(bytes) | MarcarMás fragmentos | Desplazamiento de fragmentos(bloques de 8 bytes) |
|---|---|---|---|---|---|
| 1 | 1,500 | 20 | 1,480 | 1 | 0 |
| 2 | 1,020 | 20 | 1,000 | 1 | 185 |
| 3 | 1,500 | 20 | 1,480 | 1 | 310 |
| 4 | 560 | 20 | 540 | 0 | 495 |
Una vez más, se conserva el tamaño de los datos: 1480 + 1000 = 2480 y 1480 + 540 = 2020.
También en este caso, el bit More Fragments permanece en 1 para todos los fragmentos que vinieron con 1 en ellos y para el último fragmento que llega, funciona como de costumbre, es decir, el bit MF se establece en 0 solo 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 desplazamiento y el último tamaño de datos se utilizan para calcular el tamaño total de los datos: 
Reensamblaje
Un receptor sabe que un paquete es un fragmento, si al menos una de las siguientes condiciones es verdadera:
- Se establece el indicador más fragmentos, que es cierto para todos los fragmentos excepto el último.
- El desplazamiento del fragmento de campo es distinto de cero, lo cual es cierto para todos los fragmentos excepto el primero.
El receptor identifica los fragmentos coincidentes utilizando las direcciones de origen y destino, la ID del protocolo y el campo de identificación. El receptor vuelve a ensamblar los datos de los fragmentos con el mismo ID utilizando tanto el desplazamiento de fragmentos como el indicador de más fragmentos. Cuando el receptor recibe el último fragmento, que tiene el indicador de más fragmentos establecido en 0, puede calcular el tamaño de la carga útil de datos original, multiplicando el desplazamiento del último fragmento por ocho y sumando el tamaño de datos del último fragmento. En el ejemplo dado, este cálculo fue 
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 hacer una asociación entre la dirección de hardwarede interfaces de red y 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.