stringtranslate.com

IPv4

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 32 ) direcciones únicas, pero se reservan bloques grandes para fines de red especiales. [3] [4]

Historia

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]

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 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).

Direccionamiento

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

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 de multidifusión (2 28  ≈ 268 millones de direcciones).

Representaciones de dirección

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 .

Asignación

En el diseño original de IPv4, una dirección IP se dividía en dos partes: el identificador de red era el octeto más significativo de la dirección y el identificador de host era el resto de la dirección. Este último también se 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.

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. [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.

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

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.

Direccionamiento de enlace local

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 .

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

Primera y última dirección de subred

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]

Resolución de direcciones

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.

Interfaz sin numerar

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.

Agotamiento del espacio de direcciones

Cronología del agotamiento de direcciones IPv4

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:

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.

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 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 

Encabezamiento

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 0 – 1) a (2 13  – 1)). Por lo tanto, permite un desplazamiento máximo de fragmento de (2 13  – 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:
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.

Fragmentación y reensamblaje

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.

Fragmentación

Cuando un enrutador recibe un paquete, examina la dirección de destino y determina la interfaz de salida que se utilizará y la MTU de esa interfaz. Si el tamaño del paquete es mayor que la MTU y el bit No fragmentar (DF) en el encabezado del paquete está 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:

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.).

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 .

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: .

Reensamblaje

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

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.

Protocolos de asistencia

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 .

Véase también

Notas

  1. ^ Como broma del Día de los Inocentes , se propuso su uso en el RFC 3514 como el " bit malvado " [38]
  2. ^ Para las tecnologías de red IEEE 802 , incluida Ethernet , la dirección de hardware es una dirección MAC .

Referencias

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.

  1. ^ "Informes de análisis de BGP". Informes de BGP . Consultado el 9 de enero de 2013 .
  2. ^ "IPv6 – Google". www.google.com . Consultado el 28 de enero de 2022 .
  3. ^ "Registro de direcciones IPv4 de propósito especial de la IANA". www.iana.org . Consultado el 28 de enero de 2022 .
  4. ^ abcdef M. Cotton; L. Vegoda; B. Haberman (abril de 2013). R. Bonica (ed.). Registros de direcciones IP para fines especiales. IETF . doi : 10.17487/RFC6890 . ISSN  2070-1721. BCP 153. RFC 6890. Mejor práctica actual 153. Deja obsoletos los RFC 4773, 5156, 5735 y 5736. Actualizado por el RFC 8190.
  5. ^ Davis, Lidija. "Vint Cerf: todavía nos queda el 80 por ciento del mundo por conectar". The New York Times . Consultado el 10 de mayo de 2024 .
  6. ^ "Una breve historia de IPv4". IPv4 Market Group . Consultado el 19 de agosto de 2020 .
  7. ^ "Comprensión del direccionamiento IP: todo lo que siempre quiso saber" (PDF) . 3Com. Archivado desde el original (PDF) el 16 de junio de 2001.
  8. ^ abcd Y. Rekhter ; B. Moskowitz; D. Karrenberg; GJ de Groot; E. Lear (febrero de 1996). Asignación de direcciones para Internet privadas. Grupo de trabajo de redes. doi : 10.17487/RFC1918 . BCP 5. RFC 1918. Mejor práctica actual 5. Deja obsoletos los RFC 1627 y 1597. Actualizado por el RFC 6761.
  9. ^ J. Weil; V. Kuarsingh; C. Donley; C. Liljenstolpe; M. Azinger (abril de 2012). Prefijo IPv4 reservado por la IANA para el espacio de direcciones compartidas. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6598 . ISSN  2070-1721. BCP 153. RFC 6598. Mejores prácticas comunes. Actualizaciones RFC 5735.
  10. ^ S. Cheshire ; B. Aboba; E. Guttman (mayo de 2005). Configuración dinámica de direcciones locales de enlace IPv4. Grupo de trabajo de redes. doi : 10.17487/RFC3927 . RFC 3927. Norma propuesta.
  11. ^ abc J. Arkko; M. Cotton; L. Vegoda (enero de 2010). Bloques de direcciones IPv4 reservados para documentación. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC5737 . ISSN  2070-1721. RFC 5737. Informativo. Actualizaciones RFC 1166.
  12. ^ O. Troan (mayo de 2015). B. Carpenter (ed.). Desuso del prefijo Anycast para enrutadores de retransmisión 6to4. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7526 . BCP 196. RFC 7526. Mejores prácticas actuales. RFC 3068 y 6732 obsoletos .
  13. ^ C. Huitema (junio de 2001). Un prefijo Anycast para enrutadores de retransmisión 6to4. Grupo de trabajo de redes. doi : 10.17487/RFC3068 . RFC 3068. Informativo. Obsoleto por RFC 7526.
  14. ^ S. Bradner; J. McQuaid (marzo de 1999). Metodología de evaluación comparativa para dispositivos de interconexión de redes. Grupo de trabajo de redes. doi : 10.17487/RFC2544 . RFC 2544. Informativo. Actualizado por: RFC 6201 y RFC 6815.
  15. ^ ab M. Cotton; L. Vegoda; D. Meyer (marzo de 2010). Directrices de la IANA para asignaciones de direcciones de multidifusión IPv4. IETF . doi : 10.17487/RFC5771 . ISSN  2070-1721. BCP 51. RFC 5771. Mejor práctica actual 51. Deja obsoletos los RFC 3138 y 3171. Actualiza el RFC 2780.
  16. ^ S. Venaas; R. Parekh; G. Van de Velde; T. Chown; M. Eubanks (agosto de 2012). Direcciones de multidifusión para documentación. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6676 . ISSN  2070-1721. RFC 6676. Informativo.
  17. ^ ab J. Reynolds , ed. (enero de 2002). Números asignados: RFC 1700 se reemplaza por una base de datos en línea. Grupo de trabajo de redes. doi : 10.17487/RFC3232 . RFC 3232. Informativo. RFC 1700 obsoleto .
  18. ^ J. Reynolds ; J. Postel (octubre de 1984). NÚMEROS ASIGNADOS. Grupo de trabajo de redes. doi : 10.17487/RFC0923 . RFC 923. Obsoleto. Obsoleto por RFC 943. Obsoleto por RFC 900. Direcciones especiales: En ciertos contextos, es útil tener direcciones fijas con significado funcional en lugar de ser identificadores de hosts específicos. Cuando se requiere dicho uso, la dirección cero debe interpretarse como que significa "esto", como en "esta red".
  19. ^ ab R. Braden , ed. (octubre de 1989). Requisitos para hosts de Internet: capas de comunicación. Grupo de trabajo de redes. doi : 10.17487/RFC1122 . STD 3. RFC 1122. Estándar de Internet 3. Actualizado por RFC 1349, 4379, 5884, 6093, 6298, 6633, 6864, 8029 y 9293.
  20. ^ A. Retana; R. White; V. Fuller; D. McPherson (diciembre de 2000). Uso de prefijos de 31 bits en enlaces punto a punto IPv4. Grupo de trabajo de redes. doi : 10.17487/RFC3021 . RFC 3021. Norma propuesta.
  21. ^ Almquist, Philip; Kastenholz, Frank (diciembre de 1993). "Hacia los requisitos para los enrutadores IP". Grupo de trabajo de ingeniería de Internet .
  22. ^ P. Almquist (noviembre de 1994). F. Kastenholz (ed.). Hacia los requisitos para enrutadores IP. Grupo de trabajo de redes. doi : 10.17487/RFC1716 . RFC 1716. Obsoleto. Quedó obsoleto según RFC 1812.
  23. ^ F. Baker , ed. (junio de 1995). Requisitos para enrutadores IP versión 4. Grupo de trabajo de redes. doi : 10.17487/RFC1812 . RFC 1812. Norma propuesta. Deja obsoletas las RFC 1716 y 1009. Actualizada por las RFC 2644 y 6633.
  24. ^ "Comprensión y configuración del comando ip unnumbered". Cisco . Consultado el 25 de noviembre de 2021 .
  25. ^ "El mundo 'se está quedando sin direcciones de Internet'". Archivado desde el original el 25 de enero de 2011. Consultado el 23 de enero de 2011 .
  26. ^ Smith, Lucie; Lipner, Ian (3 de febrero de 2011). "Libre reserva de espacio de direcciones IPv4 agotado". Organización de recursos numéricos . Consultado el 3 de febrero de 2011 .
  27. ^ ICANN, lista de correo nanog. "Cinco /8 asignados a los RIR; no quedan /8 unicast IPv4 sin asignar".
  28. ^ Asia-Pacific Network Information Centre (15 de abril de 2011). «APNIC IPv4 Address Pool Reachs Final /8». Archivado desde el original el 7 de agosto de 2011. Consultado el 15 de abril de 2011 .
  29. ^ S. Deering ; R. Hinden (diciembre de 1998). Especificación del Protocolo de Internet, versión 6 (IPv6). Grupo de trabajo de redes. doi : 10.17487/RFC2460 . RFC 2460. Obsoleto. Quedó obsoleto según RFC 8200. Quedó obsoleto según RFC 1883. Actualizado según RFC 5095, 5722, 5871, 6437, 6564, 6935, 6946, 7045 y 7112.
  30. ^ R. Fink; R. Hinden (marzo de 2004). Eliminación gradual de 6bone (asignación de direcciones de prueba IPv6). Grupo de trabajo de redes. doi : 10.17487/RFC3701 . RFC 3701. Informativo. RFC 2471 obsoleto .
  31. ^ Conferencia internacional IEEE de 2016 sobre tecnologías emergentes y prácticas empresariales innovadoras para la transformación de las sociedades (EmergiTech) . Piscataway, Nueva Jersey: Universidad de Tecnología, Mauricio, Instituto de Ingenieros Eléctricos y Electrónicos. Agosto de 2016. ISBN 9781509007066.OCLC 972636788  .
  32. ^ C. Partridge; F. Kastenholz (diciembre de 1994). Criterios técnicos para elegir IP The Next Generation (IPng). Grupo de trabajo de redes. doi : 10.17487/RFC1726 . RFC 1726. Informativo.
  33. ^ J. Postel , ed. (septiembre de 1981). PROTOCOLO DE INTERNET - ESPECIFICACIÓN DEL PROTOCOLO DE PROGRAMA DE INTERNET DE DARPA. IETF . doi : 10.17487/RFC0791 . STD 5. RFC 791. IEN 128, 123, 111, 80, 54, 44, 41, 28, 26. Estándar de Internet 5. Obsoleto RFC 760. Actualizado por RFC 1349, 2474 y 6864.
  34. ^ K. Nichols; S. Blake; F. Baker ; D. Black (diciembre de 1998). Definición del campo de servicios diferenciados (campo DS) en los encabezados de IPv4 e IPv6. Grupo de trabajo de redes. doi : 10.17487/RFC2474 . RFC 2474. Norma propuesta. Deja obsoletas las RFC 1455 y 1349. Actualizada por las RFC 3168, 3260 y 8436.
  35. ^ K. Ramakrishnan; S. Floyd; D. Black (septiembre de 2001). La incorporación de la notificación explícita de congestión (ECN) a IP. Grupo de trabajo de redes. doi : 10.17487/RFC3168 . RFC 3168. Norma propuesta. Deja obsoleta la RFC 2481. Actualiza las RFC 2474, 2401 y 793. Actualizada por las RFC 4301, 6040 y 8311.
  36. ^ Savage, Stefan (2000). "Soporte práctico de red para rastreo de IP". ACM SIGCOMM Computer Communication Review . 30 (4): 295–306. doi : 10.1145/347057.347560 .
  37. ^ J. Touch (febrero de 2013). Especificación actualizada del campo ID de IPv4. IETF . doi : 10.17487/RFC6864 . ISSN  2070-1721. RFC 6864. Norma propuesta. Actualizaciones RFC 791, 1122 y 2003.
  38. ^ S. Bellovin (1 de abril de 2003). El indicador de seguridad en el encabezado IPv4. Grupo de trabajo de redes. doi : 10.17487/RFC3514 . RFC 3514. Informativo. Esta es una solicitud de comentarios por el Día de los Inocentes .
  39. ^ Bhardwaj, Rashmi (4 de junio de 2020). "Desplazamiento de fragmentos: IP con facilidad". ipwithease.com . Consultado el 21 de noviembre de 2022 .
  40. ^ "Preguntas frecuentes no oficiales de Cisco" . Consultado el 10 de mayo de 2012 .
  41. ^ F. Gont (julio de 2011). Evaluación de seguridad del protocolo de Internet versión 4. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6274 . ISSN  2070-1721. RFC 6274. Informativo.

Enlaces externos

Wikidata tiene la propiedad:
  • Prefijo de enrutamiento IPv4 (P3761) (ver usos )