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 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 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 32 ) direcciones únicas, pero los bloques grandes se reservan para fines especiales de conexión en red. [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 del IETF (septiembre de 1981), que reemplaza una definición anterior de enero de 1980 (RFC 760). En marzo de 1982, el Departamento de Defensa de EE. UU. decidió utilizar el Internet Protocol Suite (TCP/IP) como estándar para todas las redes informáticas militares . [6]
El Protocolo de Internet es el protocolo que define y permite la interconexión en red en la capa de Internet del Conjunto de Protocolos de Internet. En esencia forma Internet. Utiliza un sistema de direccionamiento lógico y realiza enrutamiento , que es el reenvío de paquetes desde un host de origen al siguiente enrutador que está un salto más cerca del host de destino previsto en otra red.
IPv4 es un protocolo sin conexión y opera según un modelo de entrega de mejor esfuerzo , ya que no garantiza la entrega, ni asegura una secuenciación 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 32 ) direcciones.
IPv4 reserva bloques de direcciones especiales para redes privadas (2 24 + 2 20 + 2 16 ≈ 18 millones de direcciones) y direcciones multicast (2 28 ≈ 268 millones de direcciones).
Las direcciones IPv4 pueden representarse en cualquier notación que exprese un valor entero de 32 bits. Generalmente se escriben en notación decimal con puntos , 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 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 un carácter de barra (/) 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 loopback 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 número entero de tantos bytes como fueran necesarios para completar la dirección en cuatro octetos. Así, la dirección 127.65530 equivale 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 llamaba campo de descanso . Esta estructura permitía un máximo de 256 identificadores de red, lo que rápidamente resultó insuficiente.
Para superar este límite, el octeto de dirección más significativo se redefinió en 1981 para crear clases de red , en un sistema que más tarde 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 la red. El resto de la dirección se utilizó como anteriormente 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 direccionar hosts, se definió la Clase D para direccionamiento de multidifusión y la Clase E se reservó para aplicaciones futuras.
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, basado en este trabajo, RFC 1517 introdujo el enrutamiento entre dominios sin clases (CIDR), [7] que expresaba el número de bits (desde los más significativos ) 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 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 con capacidad 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.
De los aproximadamente cuatro mil millones de direcciones definidas en IPv4, alrededor de 18 millones de direcciones en tres rangos están reservadas para su uso en redes privadas. Las direcciones de paquetes en estos rangos no se pueden enrutar en la Internet pública; Todos los enrutadores públicos los 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.
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 el 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.
RFC 3927 define el bloque de direcciones especial 169.254.0.0/16 para direccionamiento de enlace local. Estas direcciones sólo 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 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 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 Direccionamiento IP privado automático (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 .
La red 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.
La primera dirección de una subred se utiliza para identificar la propia subred. En esta dirección todos los bits del 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 del host establecidos en 1 . Se utiliza como dirección de transmisió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 hacer referencia a toda la subred. La dirección de transmisión de la red es 192.168.5.255 .
Sin embargo, esto no significa que todas las direcciones que terminan 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 equivale 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 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. [19] : 31 Se podrán asignar las direcciones 192.168.1.0 , 192.168.2.0 , etc., aunque terminen en 0.
En el pasado, el conflicto entre las direcciones de red y las direcciones de transmisión surgía porque algún software usaba direcciones de transmisión no estándar con ceros en lugar de unos. [19] : 66
En redes menores que / 24 , las direcciones de transmisión no necesariamente terminan en 255. Por ejemplo, una subred CIDR 203.0.113.16 / 28 tiene la dirección de transmisión 203.0.113.31 .
Como caso especial, una red / 31 tiene capacidad para sólo dos hosts. Estas redes se utilizan normalmente para conexiones punto a punto. No existe un identificador de red ni una dirección de transmisión para estas redes. [20]
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 el enrutamiento y la identificación de la interfaz de red. El uso de nombres de dominio requiere traducirlos, llamado 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 distribuido y jerárquico 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 una red IP o un número de subred asociado, pero aún tiene una dirección IP. Presentado por primera vez en 1993, [21] [22] [23] [24] Phil Karn de Qualcomm es acreditado como el diseñador original.
El propósito de un enlace de tránsito es enrutar datagramas . Se utilizan para liberar direcciones IP de un escaso espacio de direcciones IP o para reducir la gestión de asignación de IP y configuración de interfaces. Anteriormente, cada enlace necesitaba dedicar una subred / 31 o / 30 usando 2 o 4 direcciones IP por enlace punto a punto. Cuando un enlace no está numerado, se utiliza una identificación de enrutador , una única dirección IP tomada prestada de una interfaz definida (normalmente un loopback ). La misma ID de enrutador se puede utilizar en múltiples 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 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 basó en dispositivos siempre activos. La amenaza de agotamiento motivó la introducción de una serie de tecnologías correctivas, tales como:
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 la IANA, se agotó el 3 de febrero de 2011, cuando los últimos cinco bloques se asignaron a los cinco RIR . [26] [27] 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á según una política restringida. [28]
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 . [29] 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 264 direcciones de host a los usuarios finales. Sin embargo, IPv4 no es interoperable directamente con IPv6, por lo que los hosts que solo utilizan IPv4 no pueden comunicarse directamente con hosts que solo 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 completar la implementación de IPv6 lleve un tiempo considerable, [31] por lo que se necesitan tecnologías de transición intermedias para permitir a los hosts participar 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 verificació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 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. [32]
El encabezado del paquete IPv4 consta de 14 campos, de los cuales 13 son obligatorios. El campo 14 es opcional y se llama apropiadamente: opciones. Los campos del encabezado se empaquetan con el byte más significativo primero ( orden de bytes de la red ) y, para el diagrama y la discusión, se considera que los bits más significativos aparecen 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 realidad en los cuatro bits más significativos del primer byte, por ejemplo.
La carga útil del paquete no está incluida en la suma de comprobación. Su contenido se interpreta en función del valor del campo de encabezado Protocolo.
La lista de números de protocolo IP contiene una lista completa de los tipos de protocolos de carga útil. Algunos de los protocolos de carga útil comunes incluyen:
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 diferente hardware suelen variar no sólo 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 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 MTU de ruta antes de enviar datagramas.
Cuando un enrutador recibe un paquete, examina la dirección de destino y determina la interfaz saliente 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 20 bytes; máximo 60 bytes). El enrutador coloca cada fragmento en su propio paquete y cada paquete de fragmentos tiene los siguientes cambios:
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 (0, 185, 370, 555, 740, etc.).
Es posible que un paquete esté fragmentado 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. Las compensaciones son y .
Cuando se reenvía a un enlace con una MTU de 1500 bytes, cada fragmento se fragmenta en dos fragmentos:
Nuevamente, se conserva el tamaño de los datos: 1480 + 1000 = 2480 y 1480 + 540 = 2020.
También en este caso, el bit Más Fragmentos permanece en 1 para todos los fragmentos que vinieron con 1 y para el último fragmento que llega, funciona como de costumbre, es decir, el bit MF 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: .
Un receptor sabe que un paquete es un fragmento, si al menos una de las siguientes condiciones es verdadera:
El receptor identifica 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 fue de bytes. Cuando el receptor tiene todos los fragmentos, se pueden volver a ensamblar en la secuencia correcta de acuerdo con las compensaciones para formar el datagrama original.
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 varias 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, a menudo es necesaria la correlación inversa. Por ejemplo, a menos que un administrador preconfigure 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, ARP inverso .
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.
Direcciones especiales: en ciertos contextos, es útil tener direcciones fijas con significado funcional en lugar de identificadores de hosts específicos. Cuando se requiere tal uso, la dirección cero debe interpretarse en el sentido de "esto", como en "esta red".