IPv4

Protocolo de Internet versión 4

Pila de protocolos
Paquete IPv4
Abreviatura	IPv4
Objetivo	Protocolo de interconexión de redes
Desarrollador(es)	Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA)
Introducción	1981 ; hace 43 años ( 1981 )
Influenciado	IPv6
Capa OSI	Capa de red
RFC(s)	791

El Protocolo de Internet versión 4 ( IPv4 ) es la primera versión del Protocolo de Internet (IP) como especificación independiente. Es uno de los protocolos básicos 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 utiliza para enrutar la mayor parte del tráfico de Internet en la actualidad, ^[1] incluso con la implementación en curso del Protocolo de Internet versión 6 (IPv6), ^[2] su sucesor.

IPv4 utiliza un espacio de direcciones de 32 bits que proporciona 4.294.967.296 (2 ³² ) direcciones únicas, pero se reservan bloques grandes para fines de red especiales. ^{[3] [4]}

Las versiones anteriores de TCP/IP eran una especificación combinada a través de TCP/IPv3. Con IPv4, el Protocolo de Internet se convirtió en una especificación independiente. ^[5]

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

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 se encuentra un salto más cerca del host de destino previsto en otra red.

IPv4 es un protocolo sin conexión y funciona según un modelo de entrega de máximo esfuerzo , en el sentido de que no garantiza la entrega ni asegura una 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).

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 (2 ²⁴  + 2 ²⁰  + 2 ¹⁶  ≈ 18 millones de direcciones) y direcciones de multidifusión (2 ²⁸  ≈ 268 millones de direcciones).

Las direcciones IPv4 pueden representarse en cualquier notación que exprese un valor entero de 32 bits. Por lo general, se escriben en notación decimal con 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 con cuatro puntos en la ilustración ( 172.16.254.1 ) representa el número decimal de 32 bits 2886794753, que en formato hexadecimal es 0xAC10FE01.

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

Otras representaciones de direcciones eran de uso común cuando se practicaba la red con clases . Por ejemplo, la dirección de bucle invertido 127.0.0.1 se escribía comúnmente 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 especificaban menos de cuatro números en la dirección en notación con puntos, el último valor se trataba como un entero de tantos bytes como se requieren para completar la dirección hasta cuatro octetos. Por lo tanto, la dirección 127.65530 es equivalente a 127.0.255.250 .

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 denominaba campo resto . Esta estructura permitía un máximo de 256 identificadores de red, lo que rápidamente se demostró que era insuficiente.

Para superar este límite, en 1981 se redefinió el octeto de dirección más significativo para crear clases de red , en un sistema que más tarde se conocería como redes con clases . El sistema revisado definió 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 utilizó como antes para identificar un host dentro de una red. Debido a los diferentes tamaños de los campos en las diferentes clases, cada clase de red tenía una capacidad diferente para direccionar hosts. Además de las tres clases para direccionar hosts, la clase D se definió para el direccionamiento de multidifusión y la clase E se reservó para aplicaciones futuras.

La división de las redes con clases 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, basándose en este trabajo, RFC  1517 introdujo el enrutamiento entre dominios sin clases (CIDR), ^[7] 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 la repartición de cualquier espacio de direcciones de modo que se pudieran 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.

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. ^[4] En particular, estas direcciones se utilizan para tráfico de multidifusión y para proporcionar espacio de direcciones para usos sin restricciones en redes privadas.

Bloques de direcciones especiales

Bloque de dirección	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 (local, "esta") [4]
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 [8]
100.64.0.0/10	100.64.0.0–100.127.255.255	4 194 304	Red privada	Espacio de direcciones compartido [9] para 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 bucle invertido al host local [4]
169.254.0.0/16	169.254.0.0–169.254.255.255	65 536	Subred	Se utiliza para direcciones de enlace local [10] 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 [8]
192.0.0.0/24	192.0.0.0–192.0.0.255	256	Red privada	Asignaciones de protocolos IETF, DS-Lite (/29) [4]
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 [11]
192.88.99.0/24	192.88.99.0–192.88.99.255	256	Internet	Reservado. [12] Anteriormente utilizado para retransmisión de IPv6 a IPv4 [13] (incluido el bloque de dirección 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 [8]
198.18.0.0/15	198.18.0.0–198.19.255.255	131 072	Red privada	Se utiliza para realizar pruebas comparativas de comunicaciones entre redes entre dos subredes separadas [14]
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 [11]
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 [11]
224.0.0.0/4	224.0.0.0–239.255.255.255	268 435 456	Internet	En uso para multidifusión [15] (antigua red de 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 (Tenga en cuenta que esto es parte del espacio de multidifusión anterior). [15] [16]
240.0.0.0/4	240.0.0.0–255.255.255.254	268 435 455	Internet	Reservado para uso futuro [17] (antigua red de clase E)
255.255.255.255/32	255.255.255.255	1	Subred	Reservado para la dirección de destino de " difusión limitada" [4]

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 son enrutables en la Internet pública; todos los enrutadores públicos las ignoran. Por lo tanto, los hosts privados no pueden comunicarse directamente con las redes públicas, sino que requieren la traducción de direcciones de red en una puerta de enlace de enrutamiento para este propósito.

Rangos de redes IPv4 privadas reservadas ^[8]

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 A individual
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 de clase B
Bloque de 16 bits	192.168.0.0/16	192.168.0.0 – 192.168.255.255	65 536	Gama contigua de 256 bloques de clase C

Dado que dos redes privadas, por ejemplo, dos sucursales, no pueden interoperar directamente a través de Internet pública, las dos redes deben estar conectadas a través de Internet mediante 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 estar cifrados para su transmisión a través de redes públicas a fin de proteger los datos.

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 o 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 interna.

Cuando el bloque de direcciones estaba reservado, 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 Dynamic Configuration of IPv4 Link-Local Addresses .

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 que no sea loopback con una dirección de origen o destino de loopback deben descartarse.

La primera dirección de una subred se utiliza para identificar la subred en sí. En esta dirección, todos los bits de host son 0. Para evitar ambigüedades en la representación, esta dirección está reservada. ^[18] La última dirección tiene todos los bits de host establecidos en 1. Se utiliza como una 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 mayor, la dirección de difusió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 no se pueda utilizar como dirección de host toda dirección que termine en 0 o 255. 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 difusió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 se debe asignar a una interfaz. ^{[19] : 31} Las direcciones 192.168.1.0 , 192.168.2.0 , etc., pueden asignarse, a pesar de terminar en 0.

En el pasado, los conflictos entre direcciones de red y direcciones de difusión surgían porque algunos programas usaban direcciones de difusión no estándar con ceros en lugar de unos. ^{[19] : 66}

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

Como caso especial, una red / 31 ​​tiene capacidad para solo dos hosts. Estas redes se utilizan normalmente para conexiones punto a punto. No existe un identificador de red ni una dirección de difusión para estas redes. ^[20]

Los hosts de Internet suelen conocerse por sus nombres, p. ej., www.example.com, no principalmente por su dirección IP, que se utiliza para el enrutamiento y la identificación de la interfaz de red. El uso de nombres de dominio requiere traducirlos, lo que se denomina resolución , a direcciones y viceversa. Esto es análogo a buscar un número de teléfono en una guía telefónica utilizando 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.

Un enlace punto a punto (PtP) no numerado, también llamado enlace de tránsito, es un enlace que no tiene un número de red o subred IP asociado, pero que aún tiene una dirección IP. Presentado por primera vez en 1993, ^{[21] [22] [23] [24]} Phil Karn de Qualcomm es reconocido 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 espacio de direcciones IP escaso o para reducir la gestión de la asignación de IP y la configuración de interfaces. Anteriormente, cada enlace necesitaba dedicar una subred / 31 ​​o / 30 utilizando 2 o 4 direcciones IP por enlace punto a punto. Cuando un enlace no está numerado, se utiliza un router-id , una única dirección IP prestada de una interfaz definida (normalmente un loopback ). El mismo router-id se puede utilizar en varias interfaces.

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

En la década de 1980, se hizo evidente que el conjunto de direcciones IPv4 disponibles se estaba agotando a un ritmo que no se había previsto inicialmente en el diseño original de la red. ^[25] Las principales fuerzas del mercado que aceleraron el agotamiento de las direcciones incluyeron el número rápidamente creciente de usuarios de Internet, que utilizaban 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 basaba en dispositivos siempre activos. La amenaza del agotamiento motivó la introducción de una serie de tecnologías correctivas, como:

• Enrutamiento entre dominios sin clases (CIDR), para asignaciones de ISP más pequeñas
• Las interfaces no numeradas eliminaron la necesidad de direcciones en los enlaces de tránsito.
• La traducción de direcciones de red (NAT) eliminó la necesidad del principio de extremo a extremo .

A mediados de la década de 1990, NAT se utilizaba de forma 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 de direcciones principal de Internet, mantenido por IANA, se agotó el 3 de febrero de 2011, cuando se asignaron los últimos cinco bloques a los cinco RIR . ^{[26] [27]} APNIC fue el primer RIR en agotar su grupo regional el 15 de abril de 2011, a excepción de 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. ^[28]

La solución a largo plazo para abordar el agotamiento fue la especificación en 1998 de una nueva versión del Protocolo de Internet, IPv6 . ^[29] Proporciona un espacio de direcciones enormemente mayor, pero también permite una agregación de rutas mejorada a través de Internet y ofrece grandes asignaciones de subredes de un mínimo de 264 ^direcciones de host a los usuarios finales. Sin embargo, IPv4 no es directamente interoperable con IPv6, de modo que los hosts que sólo utilizan IPv4 no pueden comunicarse directamente con los hosts que sólo utilizan 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. ^[30] Se espera que la finalización de la implementación de IPv6 tome un tiempo considerable, ^{[31] de modo que son necesarias} tecnologías de transición intermedias para permitir que los hosts participen en Internet utilizando ambas versiones del protocolo.

Un paquete IP consta de una sección de encabezado y una sección de datos. Un paquete IP no tiene suma de comprobación de datos ni ningún otro pie de página después de la sección de datos. Normalmente, 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 que lleva IP también tienen su propia comprobación de errores. ^{[32] : §6.2}

El encabezado del paquete IPv4 consta de 14 campos, de los cuales 13 son obligatorios. El campo 14 es opcional y su nombre es muy apropiado: opciones. Los campos del encabezado se empaquetan con el byte más significativo primero ( orden de bytes de red ) y, para el diagrama y la discusión, se considera que los bits más significativos van primero ( numeración de bits MSB 0 ). El bit más significativo está numerado como 0, por lo que el campo de versión se encuentra en realidad en los cuatro bits más significativos del primer byte, por ejemplo.

Versión : 4 bits

El primer campo de encabezado de un paquete IP es el campo Versión . Para IPv4, este campo siempre es igual a 4 .

Longitud del encabezado de Internet  (IHL): 4 bits

El tamaño del encabezado IPv4 es variable debido al campo 14 opcional ( Opciones ). El campo IHL contiene el tamaño del encabezado IPv4; tiene 4 bits que especifican la cantidad de palabras de 32 bits en el encabezado. El valor mínimo para este campo es 5, ^[33] 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 15 × 32 bits = 480 bits = 60 bytes.

Punto de Código de Servicios Diferenciados  (DSCP ): 6 bits

Originalmente definido como el tipo de servicio (ToS), este campo especifica servicios diferenciados (DiffServ). ^[34] La transmisión de datos en tiempo real utiliza el campo DSCP. Un ejemplo es la voz sobre IP (VoIP), que se utiliza para servicios de voz interactivos.

Notificación explícita de congestión  (ECN ): 2 bits

Este campo permite la notificación de congestión de red de extremo a extremo sin perder paquetes . ^[35] ECN es una característica opcional disponible cuando ambos puntos finales la admiten y es efectiva cuando también la admite la red subyacente.

Longitud total : 16 bits

Este campo de 16 bits define el tamaño total del paquete en bytes, incluidos el encabezado y los datos. El tamaño mínimo es de 20 bytes (encabezado sin datos) y el máximo es de 65.535 bytes. Todos los hosts deben poder reensamblar datagramas de hasta 576 bytes, pero la mayoría de los hosts modernos manejan paquetes mucho más grandes. Los enlaces pueden imponer restricciones adicionales al tamaño del paquete, en cuyo caso los datagramas deben fragmentarse . La fragmentación en IPv4 se realiza en el host emisor o en los enrutadores. El reensamblado se realiza en el host receptor.

Identificación : 16 bits

Este campo es un campo de identificación y se utiliza principalmente para identificar de forma única el grupo de fragmentos de un datagrama IP único. Algunos trabajos experimentales han sugerido utilizar el campo de identificación para otros fines, como por ejemplo para añadir información de seguimiento de paquetes para ayudar a rastrear datagramas con direcciones de origen falsificadas, ^[36] pero dicho uso está prohibido en la actualidad. ^[37]

Banderas: 3 bits

Hay tres banderas definidas dentro de este campo.

Reservado  (R): 1 bit

Reservado. Debe establecerse en 0. ^[a]

No fragmentar  (DF): 1 bit

Este campo especifica si el datagrama se puede fragmentar o no. Esto se puede utilizar al enviar paquetes a un host que no tiene recursos para realizar el reensamblado de fragmentos. También se puede utilizar para el descubrimiento de la MTU de la ruta , ya sea automáticamente por el software de IP del host o manualmente utilizando herramientas de diagnóstico como ping o traceroute . Si se establece el indicador DF y se requiere fragmentación para enrutar el paquete, entonces el paquete se descarta.

Más fragmentos  (MF): 1 bit

En el caso de los paquetes no fragmentados, el indicador MF se borra. En el caso de los paquetes fragmentados, todos los fragmentos, excepto el último, tienen el indicador MF activado. El último fragmento tiene un campo de Desplazamiento de fragmento distinto de cero , por lo que aún se puede diferenciar de un paquete no fragmentado.

Desplazamiento del fragmento : 13 bits

Este campo especifica el desplazamiento de un fragmento particular con respecto al comienzo del datagrama IP original no fragmentado. Los fragmentos se especifican en unidades de 8 bytes, por lo que las longitudes de los fragmentos siempre son múltiplos de 8; excepto el último, que puede ser menor. ^[39]
El valor de desplazamiento de fragmentación para el primer fragmento siempre es 0. El campo tiene 13 bits de ancho, por lo que el valor de desplazamiento varía de 0 a 8191 (de (2 ⁰ – 1) a (2 ¹³  – 1)). Por lo tanto, permite un desplazamiento máximo de fragmento de (2 ¹³  – 1) × 8 = 65.528 bytes, con la longitud del encabezado incluida (65.528 + 20 = 65.548 bytes), lo que permite la fragmentación de paquetes que excedan la longitud IP máxima de 65.535 bytes.

Tiempo de vivir  (TTL ): 8 bits

El campo de tiempo de vida limita la duración de un datagrama para evitar una falla de la red en caso de un bucle de enrutamiento . Se especifica en segundos, pero los intervalos de tiempo menores a 1 segundo se redondean a 1. En la práctica, el campo se utiliza como un conteo de saltos : cuando el datagrama llega a un enrutador , el enrutador disminuye el campo TTL en uno. Cuando el campo TTL llega a cero, el enrutador descarta el paquete y, por lo general, 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 los paquetes desde el origen hasta el destino.

Protocolo : 8 bits

Este campo define el protocolo de la capa de transporte utilizado en la parte de datos del datagrama IP. La lista de números de protocolo IP la mantiene la Autoridad de Números Asignados de Internet (IANA). ^[17]

Algunos de los protocolos de carga útil más 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	Protocolo de control de tráfico
17	Protocolo de datagramas de usuario	Unión Popular de Palestina
41	Encapsulación IPv6	ENCAPSULAR
89	Abrir primero el camino más corto	OSPF
132	Protocolo de transmisión de control de flujo	PTC

Suma de comprobación del encabezado : 16 bits

El campo de suma de comprobación del encabezado de IPv4 se utiliza para comprobar si hay errores en el encabezado. Antes de enviar un paquete, la suma de comprobación se calcula como el complemento a uno de 16 bits de la suma del complemento a uno de todas las palabras de 16 bits del encabezado. Esto incluye el propio campo de suma de comprobación del encabezado , que se establece en cero durante el cálculo. El paquete se envía con la suma de comprobación del encabezado que contiene el valor resultante. Cuando un paquete llega a un enrutador o a su destino, el dispositivo de red vuelve a calcular el valor de la suma de comprobación del encabezado, que ahora incluye el campo de suma de comprobación del encabezado . El resultado debe ser cero; si se obtiene un resultado diferente, el dispositivo descarta el paquete.

Cuando un paquete llega a un enrutador, este reduce el campo TTL en el encabezado. En consecuencia, el enrutador debe calcular una nueva suma de comprobación del encabezado antes de volver a enviarlo.

Los errores en la parte de datos del paquete se gestionan por separado mediante el protocolo encapsulado. Tanto UDP como TCP tienen sumas de comprobación independientes que se aplican a sus datos.

Dirección de origen : 32 bits

Este campo contiene la dirección IPv4 del remitente del paquete. Puede modificarse durante el tránsito mediante la traducción de direcciones de red (NAT).

Dirección de destino : 32 bits

Este campo contiene la dirección IPv4 del destinatario del paquete. También puede verse afectado por NAT.

Si se puede llegar al destino directamente, el paquete será entregado por la capa de enlace subyacente , con la ayuda de ARP . De lo contrario, el paquete necesita enrutamiento y será entregado a la dirección de puerta de enlace .

Opciones : 0 - 320 bits, rellenados con múltiplos de 32 bits

El campo Opciones no se utiliza con frecuencia. Los paquetes que contienen algunas opciones pueden ser considerados peligrosos por algunos enrutadores y ser bloqueados. ^[40] El valor en el campo IHL debe incluir suficientes palabras adicionales de 32 bits para contener todas las opciones y cualquier relleno necesario para garantizar que el encabezado contenga un número entero de palabras de 32 bits. Si IHL es mayor que 5 (es decir, es de 6 a 15), significa que el campo de opciones está presente y debe considerarse. La lista de opciones puede terminar con la opción EOOL (Fin de la lista de opciones, 0x00); esto solo es necesario si el final de las opciones no coincidiría de otra manera con el final del encabezado.

Dado que la mayoría de las opciones IP incluyen especificaciones sobre cuántos o cuáles dispositivos intermedios debe pasar el paquete, las opciones IP no se utilizan para la comunicación a través de Internet y los paquetes IP que incluyen algunas de las opciones IP deben descartarse, ^{[41] : §3.13} ya que pueden exponer la topología de la red o los detalles de la red.

El Protocolo de Internet permite el tráfico entre redes. El diseño se adapta 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 hardware diferente 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 desea transmitir datagramas a una red con una MTU menor, 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 de los hosts a estos problemas.

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 el descubrimiento de ruta MTU antes de enviar datagramas.

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á configurado 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 de salida menos el tamaño del encabezado IP (20 bytes mínimo; 60 bytes máximo). El enrutador coloca cada fragmento en su propio paquete, y cada paquete de fragmento tiene los siguientes cambios:

• El campo de longitud total es el tamaño del fragmento.
• La bandera 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 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 los fragmentos serían múltiplos de (0, 185, 370, 555, 740, etc.).${\displaystyle {\frac {1{,}500-20}{8}}=185}$

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:

Se conserva el tamaño total de los datos: 2480 bytes + 2020 bytes = 4500 bytes. Los desplazamientos son y .${\displaystyle 0}$${\displaystyle {\frac {0+2{,}480}{8}}=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: 1.480 + 1.000 = 2.480 y 1.480 + 540 = 2.020.

También en este caso, el bit de Más Fragmentos permanece en 1 para todos los fragmentos que venían con 1 en ellos y para el último fragmento que llega, funciona como siempre, es decir, el bit MF se establece en 0 solo en el último. Y, por supuesto, el campo de Identificación continúa teniendo el mismo valor en todos los fragmentos refragmentados. De esta manera, incluso si los fragmentos se refragmentan, el receptor sabe que inicialmente todos comenzaron a partir del mismo paquete.

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

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

• Se establece la bandera más fragmentos , lo cual es verdadero para todos los fragmentos excepto el último.
• El desplazamiento del fragmento de campo no es cero, lo que es cierto para todos los fragmentos excepto el primero.

El receptor identifica los fragmentos coincidentes utilizando las direcciones de origen y destino, el 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 del fragmento 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 los datos del último fragmento. En el ejemplo dado, este cálculo se realizó en bytes. Cuando el receptor tiene todos los fragmentos, se pueden volver a ensamblar en la secuencia correcta según los desplazamientos para formar el datagrama original.${\displaystyle 495\times 8+540=4{,}500}$

Las direcciones IP no están vinculadas de manera permanente al hardware de red y, de hecho, en los sistemas operativos modernos , una interfaz de red puede tener múltiples direcciones IP. Para entregar correctamente un paquete IP al host de destino en un enlace, los hosts y enrutadores necesitan mecanismos adicionales para realizar una asociación entre la dirección de hardware ^[b] 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, la correlación inversa suele ser necesaria. 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 tales correlaciones inversas incluyen el Protocolo de configuración dinámica de host (DHCP), el Protocolo Bootstrap (BOOTP) y, con poca frecuencia, el ARP inverso .

• Historia de Internet
• Lista de bloques de direcciones IPv4 /8 asignados

Este artículo fue adaptado de la siguiente fuente bajo licencia CC BY 4.0 (2022): Michel Bakni; Sandra Hanbo (9 de diciembre de 2022). "Una encuesta sobre el protocolo de Internet versión 4 (IPv4)" (PDF) . WikiRevista científica . doi : 10.15347/WJS/2022.002 . ISSN  2470-6345. OCLC  9708517136. S2CID  254665961. Wikidata  Q104661268.

Wikidata tiene la propiedad:

• Prefijo de enrutamiento IPv4 (P3761) (ver usos )

• Autoridad de Números Asignados en Internet (IANA)
• IP, Protocolo de Internet Archivado el 14 de mayo de 2011 en Wayback Machine — Desglose del encabezado IP, incluidas opciones específicas
• C. Perkins, ed. (noviembre de 2010). Compatibilidad de movilidad IP para IPv4, revisada. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC5944 . ISSN  2070-1721. RFC 5944. Norma propuesta. Deja obsoleta la RFC 3344.
• Estado actual oficial de las asignaciones IPv4/8, según lo mantiene la IANA