IPv4

A finales de 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. ^{[ 7 ]} Las principales fuerzas del mercado que aceleraron el agotamiento de las direcciones a partir de la década de 1990 incluyeron el rápido crecimiento del número de usuarios de Internet, que utilizaban cada vez más dispositivos informáticos móviles, como ordenadores 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 conectados. La amenaza de agotamiento motivó la introducción de varias tecnologías correctivas, tales como:

• Enrutamiento entre dominios sin clases (CIDR), para asignaciones de ISP más pequeñas.
• Las interfaces sin numerar 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, la NAT se utilizaba de forma generalizada en los sistemas de los proveedores de acceso a la red, junto con estrictas políticas de asignación basadas en el uso en los registros regionales y locales de Internet.

El grupo principal de direcciones de Internet, mantenido por IANA, se agotó el 3 de febrero de 2011, cuando los últimos cinco bloques se asignaron a los cinco RIR . ^{[ 8 ] [ 9 ]} 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. ^{[ 10 ]}

La solución a largo plazo para el agotamiento de direcciones fue la especificación de 1998 de una nueva versión del Protocolo de Internet, IPv6 . ^{[ 11 ]} Proporciona un espacio de direcciones enormemente mayor, pero también permite una agregación de rutas mejorada en Internet y ofrece grandes asignaciones de subredes de un mínimo de 2 ⁶⁴ direcciones de host a los usuarios finales. Sin embargo, IPv4 no es directamente interoperable con IPv6, por lo que los hosts que solo usan IPv4 no pueden comunicarse directamente con los que solo usan IPv6. Con la eliminación gradual de la red experimental 6bone a partir de 2004, el despliegue formal permanente de IPv6 comenzó en 2006. ^{[ 12 ]} Se espera que la finalización del despliegue de IPv6 tome un tiempo considerable, ^{[ 13 ]} por lo que son necesarias tecnologías de transición intermedias para permitir que los hosts participen en Internet usando ambas versiones del protocolo.

Las direcciones IPv4 pueden representarse en cualquier notación que exprese un valor entero de 32 bits. Lo más frecuente es que se escriban en notación decimal con puntos , que consiste en cuatro octetos de la dirección expresados ​​individualmente en números decimales (sin ceros iniciales adicionales) 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 va seguida de una barra inclinada (/) y el número de bits consecutivos iniciales de 1 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 de puntos, el último valor se trataba como un entero de tantos bytes como se requirieran para completar la dirección a 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 de resto . Esta estructura permitía un máximo de 256 identificadores de red, lo que pronto se consideró insuficiente.

Para superar esta limitación, en 1981 se redefinió el octeto de dirección más significativo para crear clases de red , en un sistema que posteriormente se conoció 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 red. El resto de la dirección se utilizaba, como antes, para identificar un host dentro de una red. Debido a los diferentes tamaños de los campos en las distintas clases, cada clase de red tenía una capacidad diferente para direccionar hosts. Además de las tres clases para direccionar hosts, se definió la Clase D para el direccionamiento multicast y la Clase E se reservó para futuras aplicaciones.

La división de las redes con clases existentes en subredes comenzó en 1985 con la publicación del RFC 950. Esta división se hizo más flexible con la introducción de las máscaras de subred de longitud variable (VLSM) en el RFC 1109 en 1987. En 1993, basándose en este trabajo, el RFC 1517 introdujo el enrutamiento entre dominios sin clases (CIDR), ^{[ 14 ]} que expresaba el número de bits (desde el más significativo ) como, por ejemplo, /24 , y el esquema basado en clases se denominó , por contraste, con clases . CIDR se diseñó 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. ^{[ 3 ] [ 4 ]} Cabe destacar que estas direcciones se utilizan para tráfico multicast y para proporcionar espacio de direcciones para usos sin restricciones en redes privadas.

RFC 3927 define el bloque de direcciones especiales 169.254.0.0/16 para el direccionamiento de enlace local. 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, no pueden ser el origen ni el destino de los paquetes que atraviesan Internet. Se utilizan principalmente para la autoconfiguración 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 se reservó el bloque de direcciones, no existían estándares para la autoconfiguración de direcciones. Microsoft creó una implementación llamada Automatización de Direcciones IP Privadas (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 el RFC 3927, titulado Configuración Dinámica de Direcciones Locales de Enlace IPv4 .

La red de clase A 127.0.0.0 (red sin clase 127.0.0.0 / 8 ) está reservada para la interfaz 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 loopback deben descartarse.

En cada subred, tanto las direcciones de host con todos los bits a cero como las que tienen todos los bits a uno están reservadas. ^{[ 29 ] [ 30 ]} La dirección de host con todos los bits a cero se utiliza para identificar una subred determinada. La dirección más alta de cada subred, con todos los bits de host establecidos en 1 , es la 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 en notación decimal con puntos siempre termina en 255 .

Por ejemplo, en la subred 192.168.5.0 / 24 (máscara de subred 255.255.255.0 ) el identificador 192.168.5.0 se utiliza 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 usar como dirección de host cualquier 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 usar 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. ^{[ 31 ] : 31} Las direcciones 192.168.1.0 , 192.168.2.0 , etc., pueden asignarse, a pesar de terminar con 0.

En el pasado, surgieron conflictos entre las direcciones de red y las direcciones de difusión debido a que algunos programas utilizaban direcciones de difusión no estándar con ceros en lugar de unos. ^{[ 31 ] : 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. ^{[ 32 ]}

Los servidores en Internet suelen conocerse por nombres, por ejemplo, www.example.com, y 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 su traducción, denominada resolución , a direcciones y viceversa. Esto es similar 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) sin numerar, también llamado enlace de tránsito, es un enlace que no tiene un número de red o subred IP asociado, pero sí tiene una dirección IP. Introducido por primera vez en 1993, ^{[ 33 ] [ 34 ] [ 35 ] [ 36 ]} se le atribuye a Phil Karn de Qualcomm ser 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 limitado o para reducir la gestión de la asignación de IP y la configuración de interfaces. Anteriormente, cada enlace requería 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 ID de enrutador , una única dirección IP tomada de una interfaz definida (normalmente una interfaz de bucle invertido ). El mismo ID de enrutador puede utilizarse en varias interfaces.

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

La cabecera del paquete IPv4 consta de 14 campos, de los cuales 13 son obligatorios. El decimocuarto campo es opcional y se denomina, como su nombre indica, opciones. Los campos de la cabecera se organizan de mayor a menor byte ( orden de bytes de red ), y para el diagrama y la explicación, se considera que los bits más significativos van primero ( numeración del bit más significativo 0 ). El bit más significativo se numera como 0, por lo que el campo de versión se encuentra, por ejemplo, en los cuatro bits más significativos del primer byte.

Versión : 4 bits

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

Longitud de la cabecera de Internet  (IHL) : 4 bits

El tamaño de la cabecera IPv4 es variable debido al campo opcional número 14 ( Opciones ). El campo IHL contiene el tamaño de la cabecera IPv4; tiene 4 bits que especifican el número de palabras de 32 bits en la cabecera. El valor mínimo para este campo es 5, ^{[ 38 ]} 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 de la cabecera IPv4 es de 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 los servicios diferenciados (DiffServ). ^{[ 39 ]} 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 extremo a extremo de la congestión de la red sin perder paquetes . ^{[ 40 ]} 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, incluyendo la cabecera y los datos. El tamaño mínimo es de 20 bytes (cabecera sin datos) y el máximo es de 65 535 bytes. Todos los hosts deben ser capaces de reensamblar datagramas de hasta 576 bytes, pero la mayoría de los hosts modernos manejan paquetes mucho mayores. 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 reensamblaje 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 único datagrama IP. Algunos trabajos experimentales han sugerido utilizar el campo ID para otros fines, como añadir información de rastreo de paquetes para ayudar a rastrear datagramas con direcciones de origen falsificadas, ^{[ 41 ]} pero cualquier uso de este tipo está ahora prohibido. ^{[ 42 ]}

Banderas : 3 bits

En este campo se definen tres indicadores.

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 usar al enviar paquetes a un host que no tiene recursos para reensamblar los fragmentos. También se puede usar para el descubrimiento de la MTU de la ruta , ya sea automáticamente mediante el software IP del host o manualmente con herramientas de diagnóstico como ping o traceroute . Si el indicador DF está activado y se requiere fragmentación para enrutar el paquete, este se descarta.

Más fragmentos  (MF) : 1 bit

Para paquetes no fragmentados, el indicador MF se desactiva. Para 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 inicio del datagrama IP original sin fragmentar. Los fragmentos se especifican en unidades de 8 bytes, por lo que las longitudes de los fragmentos siempre son un múltiplo de 8; excepto el último, que puede ser menor. ^{[ 44 ]} 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, incluyendo la longitud de la cabecera (65 528 + 20 = 65 548 bytes), lo que admite la fragmentación de paquetes que superan la longitud IP máxima de 65 535 bytes.

Es hora de vivir  (TTL ) : 8 bits

El campo de tiempo de vida ( TTL) limita la duración de un datagrama para evitar fallos de red en caso de bucle de enrutamiento . Se especifica en segundos, pero los intervalos de tiempo inferiores a 1 segundo se redondean a 1. En la práctica, este campo se utiliza como contador de saltos : cuando el datagrama llega a un enrutador , este decrementa 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 por los que pasan los paquetes desde el origen hasta el destino.

Protocolo : 8 bits

Este campo define el protocolo de siguiente nivel utilizado en la porción de datos del datagrama IP. ^{[ 45 ]} La lista de números de protocolo IP es mantenida por la Autoridad de Números Asignados de Internet (IANA). ^{[ 24 ]}

Algunos de los protocolos de carga útil comunes incluyen:

Suma de verificación del encabezado : 16 bits

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

Cuando un paquete llega a un enrutador, este disminuye el valor TTL del encabezado. Por consiguiente, el enrutador debe calcular una nueva suma de verificación del encabezado antes de volver a enviarlo.

Los errores en la parte de datos del paquete son gestionados por separado por el protocolo encapsulado. Tanto UDP como TCP tienen sumas de verificació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 la transmisión mediante la traducción de direcciones de red (NAT).

Dirección de destino : 32 bits

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

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

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

El campo Opciones no se usa con frecuencia. Algunos enrutadores pueden considerar peligrosos los paquetes que contienen ciertas opciones y bloquearlos. ^{[ 46 ]} El valor en el campo IHL debe incluir suficientes palabras adicionales de 32 bits para almacenar todas las opciones y cualquier relleno necesario para asegurar que el encabezado contenga un número entero de palabras de 32 bits. Si IHL es mayor que 5 (es decir, está entre 6 y 15), significa que el campo de opciones está presente y debe considerarse. La lista de opciones puede terminarse 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 otro modo con el final del encabezado.

Dado que la mayoría de las opciones IP incluyen especificaciones sobre cuántos o qué 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, ^{[ 47 ] : §3.13} ya que pueden exponer la topología de la red o los detalles de la red.

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

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

• El campo de longitud total es el tamaño del fragmento + la longitud del encabezado.
• El indicador more fragments (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. Este se mide en bloques de 8 bytes.
• El campo de suma de verificación del encabezado se vuelve a calcular.

Por ejemplo, para una MTU de 1500 bytes y un tamaño de encabezado de 20 bytes, los desplazamientos de fragmento serían múltiplos de${\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 esos fragmentos se fragmenten aún más en otro enrutador. Por ejemplo, un paquete de 4520 bytes, que incluye una cabecera 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${\displaystyle 0}$y${\displaystyle {\frac {0+2{,}480}{8}}=310}$.

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

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

En este caso, el bit de Más Fragmentos permanece en 1 para todos los fragmentos que contenían un 1, 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 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 provenían del mismo paquete.

El último desplazamiento y el último tamaño de 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 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, el ID de protocolo y el campo de identificación. El receptor recompone los datos a partir de 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 fue${\displaystyle 495\times 8+540=4{,}500}$bytes. Cuando el receptor tiene todos los fragmentos, estos se pueden volver a ensamblar en la secuencia correcta según los desplazamientos para formar el datagrama original.