stringtranslate.com

Protocolo de Internet versión 4

El Protocolo de Internet versión 4 ( IPv4 ) es la cuarta versión del Protocolo de Internet (IP). Es uno de los protocolos centrales de los métodos de interconexión de redes basados ​​en estándares en Internet y otras redes de conmutación de paquetes . IPv4 fue la primera versión implementada para producción en SATNET en 1982 y en ARPANET en enero de 1983. Todavía se 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]

Historia

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

Objetivo

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

Direccionamiento

Descomposición de la representación de la dirección IPv4 de 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 (~18 millones de direcciones) y direcciones de multidifusión (~270 millones de direcciones).

Representaciones 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 diagonal (/) 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 .

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 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), [6] 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.

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

Direccionamiento de enlace local

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 .

Bucle invertido

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.

Primera y última dirección de subred

La primera dirección de una subred se utiliza para identificar la propia subred. En esta dirección todos los bits del host son 0 . Para evitar ambigüedades en la representación, esta dirección está reservada. [17] 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.0192.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. [18] : 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. [18] : 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. [19]

Resolución de direcciones

Los hosts en Internet generalmente se conocen por nombres, por ejemplo, www.example.com, no principalmente por su dirección IP, que se utiliza para 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.

Interfaz sin numerar

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, [20] [21] [22] [23] 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.

Agotamiento del espacio de direcciones

Cronología del agotamiento de las 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. [24] 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 del 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 . [25] [26] 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. [27]

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 . [28] 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. [29] Se espera que completar la implementación de IPv6 lleve un tiempo considerable, [30] por lo que se necesitan tecnologías de transición intermedias para permitir a los hosts participar en Internet utilizando ambas versiones del protocolo.

Estructura del paquete

Un paquete IP consta de una sección de encabezado y una sección de datos. Un paquete IP no tiene suma de verificación de datos ni ningún otro pie de página después de la sección de datos. 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. [31]

Encabezamiento

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.

Versión
El primer campo de encabezado de un paquete IP es el campo de versión de cuatro bits. Para IPv4, esto siempre es igual a 4.
Longitud del encabezado de Internet (DIH)
El encabezado IPv4 tiene un tamaño variable debido al campo 14 opcional (opciones). El campo DIH 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, [32] 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 )
Originalmente definido como el tipo de servicio (ToS), este campo especifica servicios diferenciados (DiffServ). [33] 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 )
Este campo permite la notificación de un extremo a otro de la congestión de la red sin perder paquetes . [34] ECN es una característica opcional disponible cuando ambos puntos finales la admiten y efectiva cuando también la admite la red subyacente.
Largo total
Este campo de 16 bits define el tamaño completo del paquete en bytes, incluidos el encabezado y los datos. El tamaño mínimo es de 20 bytes (cabecera sin datos) y el máximo 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 en el tamaño del paquete, en cuyo caso los datagramas deben fragmentarse . La fragmentación en IPv4 se realiza en el host de envío o en los enrutadores. El reensamblaje se realiza en el host receptor.
Identificación
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 agregar información de seguimiento de paquetes para ayudar a rastrear datagramas con direcciones de origen falsificadas, [35] pero dicho uso ahora está prohibido. [36]
Banderas
Le sigue un campo de tres bits que se utiliza para controlar o identificar fragmentos. Son (en orden, de más significativo a menos significativo):
  • bit 0: reservado; debe ser cero. [a]
  • bit 1: No fragmentar (DF)
  • bit 2: Más fragmentos (MF)
Si se establece el indicador DF y se requiere fragmentación para enrutar el paquete, entonces el paquete se descarta. Esto se puede utilizar al enviar paquetes a un host que no tiene recursos para realizar el reensamblaje de fragmentos. También se puede utilizar para el descubrimiento de MTU de ruta , ya sea automáticamente mediante el software de IP del host o manualmente mediante herramientas de diagnóstico como ping o traceroute .
Para paquetes no fragmentados, el indicador MF se borra. Para paquetes fragmentados, todos los fragmentos excepto el último tienen configurado el indicador MF. El último fragmento tiene un campo Desplazamiento de fragmento distinto de cero, lo que lo diferencia de un paquete no fragmentado.
Desplazamiento de fragmento
Este campo especifica el desplazamiento de un fragmento particular con respecto al comienzo del datagrama IP original no fragmentado. El valor de desplazamiento de fragmentación para el primer fragmento es siempre 0. El campo tiene 13 bits de ancho, por lo que el desplazamiento puede ser de 0 a 8191 (de (2 0  – 1) a (2 13  – 1)). Los fragmentos se especifican en unidades de 8 bytes, por lo que la longitud del fragmento debe ser múltiplo de 8. [37] Por lo tanto, el campo de 13 bits permite un desplazamiento máximo de (2 13  – 1) × 8 = 65 528 bytes, con el longitud del encabezado incluida (65,528 + 20 = 65,548 bytes), lo que admite la fragmentación de paquetes que exceden la longitud máxima de IP de 65,535 bytes.
Tiempo de vivir (TTL)
Un campo de tiempo de vida de ocho bits limita la vida útil de un datagrama para evitar fallas en la red en caso de un bucle de enrutamiento . Se especifica en segundos, pero los intervalos de tiempo inferiores a 1 segundo se redondean a 1. En la práctica, el campo se utiliza como recuento 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 normalmente envía un mensaje de tiempo ICMP excedido al remitente.
El programa traceroute envía mensajes con valores TTL ajustados y utiliza estos mensajes de tiempo excedido ICMP para identificar los enrutadores atravesados ​​por los paquetes desde el origen hasta el destino.
Protocolo
Este campo define el protocolo utilizado en la porción de datos del datagrama IP. IANA mantiene una lista de números de protocolo IP . [38]
Suma de comprobación del encabezado
El campo de suma de comprobación del encabezado IPv4 de 16 bits se utiliza para comprobar errores del encabezado. Cuando un paquete llega a un enrutador o a su destino, el dispositivo de red calcula la suma de verificación del encabezado, incluido el campo de suma de verificación. Se espera un valor de 0xFFFF. Si se obtiene un resultado diferente, el dispositivo descarta el paquete. Los errores en la porción de datos del paquete se manejan por separado mediante el protocolo encapsulado. Tanto UDP como TCP tienen sumas de verificación independientes que se aplican a sus datos.
Cuando un paquete llega a un enrutador, el enrutador reduce el campo TTL en el encabezado. En consecuencia, el enrutador debe calcular una nueva suma de comprobación del encabezado.
El campo de suma de comprobación es el complemento a unos de 16 bits de la suma en complemento a unos de todas las palabras de 16 bits del encabezado. Para calcular la suma de verificación, el valor del campo de suma de verificación es cero.
Dirección de la fuente
Este campo de 32 bits es la dirección IPv4 del remitente del paquete. Puede cambiarse en tránsito mediante la traducción de direcciones de red (NAT).
Dirección de destino
Este campo de 32 bits es la dirección IPv4 del receptor del paquete. Puede verse afectado por NAT.
Opciones
El campo de opciones no se utiliza con frecuencia. Algunos enrutadores pueden considerar peligrosos los paquetes que contienen algunas opciones y bloquearlos. [39] El valor en el campo DIH 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 ser considerado. La lista de opciones puede terminar con la opción EOOL (Fin de la lista de opciones, 0x00); esto sólo es necesario si el final de las opciones no coincidiría con el final del encabezado. Las posibles opciones que se pueden poner en el encabezado son las siguientes:
La siguiente tabla muestra las opciones definidas para IPv4. La columna Tipo de opción se deriva de los bits Copiado, Clase de opción y Número de opción como se definió anteriormente. [40]

Datos

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:

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

Fragmentación

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

Reensamblaje

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.

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

Ver también

Notas

  1. ^ Como broma del Día de los Inocentes , propuesto para su uso en RFC 3514 como la " parte malvada "
  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 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 de propósito especial IPv4 de IANA". www.iana.org . Consultado el 28 de enero de 2022 .
  4. ^ abcdef M. Algodón; L.Vegoda; B. Haberman (abril de 2013). R. Bonica (ed.). Registros de direcciones IP de propósito especial. IETF . doi : 10.17487/RFC6890 . ISSN  2070-1721. BCP 153. RFC 6890. Mejores prácticas comunes. Obsoletos RFC 4773, 5156, 5735 y 5736. Actualizado por RFC 8190.
  5. ^ "Una breve historia de IPv4". Grupo de Mercado IPv4 . Consultado el 19 de agosto de 2020 .
  6. ^ "Comprensión de las direcciones IP: todo lo que siempre quiso saber" (PDF) . 3Com. Archivado desde el original (PDF) el 16 de junio de 2001.
  7. ^ 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 Red. doi : 10.17487/RFC1918 . BCP 5. RFC 1918. Mejores prácticas comunes. Obsoletos RFC 1627 y 1597. Actualizado por RFC 6761.
  8. ^ J. Weil; V. Kuarsingh; C. Donley; C. Liljenstolpe; M. Azinger (abril de 2012). Prefijo IPv4 reservado por IANA para espacio de direcciones compartido. Grupo de Trabajo de Ingeniería de Internet . doi : 10.17487/RFC6598 . ISSN  2070-1721. BCP 153. RFC 6598. Mejores prácticas comunes. Actualiza RFC 5735.
  9. ^ S. Cheshire; B. Aboba; E. Guttman (mayo de 2005). Configuración dinámica de direcciones IPv4 Link-Local. Grupo de Trabajo de Red. doi : 10.17487/RFC3927 . RFC 3927. Norma propuesta.
  10. ^ abc J. Arkko; M. Algodón; 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. Actualiza RFC 1166.
  11. ^ O. Troan (mayo de 2015). B. Carpintero (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. Obsoletos RFC 3068 y 6732.
  12. ^ C. Huitema (junio de 2001). Un prefijo Anycast para enrutadores de retransmisión 6to4. Grupo de Trabajo de Red. doi : 10.17487/RFC3068 . RFC 3068. Informativo. Obsoleto por RFC 7526.
  13. ^ S. Bradner; J. McQuaid (marzo de 1999). Metodología de Benchmarking para Dispositivos de Interconexión de Redes. Grupo de Trabajo de Red. doi : 10.17487/RFC2544 . RFC 2544. Informativo. Actualizado por: RFC 6201 y RFC 6815.
  14. ^ ab M. Algodón; 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. Mejores prácticas comunes. Obsoletos RFC 3138 y 3171. Actualizaciones RFC 2780.
  15. ^ S. Venaas; R. Parej; 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.
  16. ^ 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 Red. doi : 10.17487/RFC3232 . RFC 3232. Informativo. Obsoleto RFC 1700.
  17. ^ J. Reynolds ; J. Postel (octubre de 1984). NÚMEROS ASIGNADOS. Grupo de Trabajo de Red. doi : 10.17487/RFC0923 . RFC 923. Obsoleto. Obsoleto por RFC 943. Obsoleto RFC 900. 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".
  18. ^ ab R. Braden , ed. (octubre de 1989). Requisitos para servidores de Internet: capas de comunicación. Grupo de Trabajo de Red. doi : 10.17487/RFC1122 . ETS 3. RFC 1122. Estándar de Internet 3. Actualizado por RFC 1349, 4379, 5884, 6093, 6298, 6633, 6864, 8029 y 9293.
  19. ^ A.Retana; R. Blanco; V. más completo; D. McPherson (diciembre de 2000). Uso de prefijos de 31 bits en enlaces punto a punto IPv4. Grupo de Trabajo de Red. doi : 10.17487/RFC3021 . RFC 3021. Norma propuesta.
  20. ^ Almquist, Felipe; Kastenholz, Frank (diciembre de 1993). "Hacia los requisitos para enrutadores IP". Grupo de Trabajo de Ingeniería de Internet .
  21. ^ P. Almquist (noviembre de 1994). F. Kastenholz (ed.). Hacia los requisitos para los enrutadores IP. Grupo de Trabajo de Red. doi : 10.17487/RFC1716 . RFC 1716. Obsoleto. Obsoleto por RFC 1812.
  22. ^ F. panadero , ed. (junio de 1995). Requisitos para enrutadores IP versión 4. Grupo de Trabajo de Red. doi : 10.17487/RFC1812 . RFC 1812. Norma propuesta. Obsoletos RFC 1716 y 1009. Actualizado por RFC 2644 y 6633.
  23. ^ "Comprensión y configuración del comando ip unnumbered". Cisco . Consultado el 25 de noviembre de 2021 .
  24. ^ "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 .
  25. ^ Smith, Lucie; Lipner, Ian (3 de febrero de 2011). "Se ha agotado el espacio libre de direcciones IPv4". Organización de recursos numéricos . Consultado el 3 de febrero de 2011 .
  26. ^ ICANN, lista de correo nanog. "Cinco /8 asignados a RIR; no quedan /8 de unidifusión IPv4 sin asignar".
  27. ^ Centro de información de la red Asia-Pacífico (15 de abril de 2011). "El grupo de direcciones IPv4 de APNIC alcanza el /8 final". Archivado desde el original el 7 de agosto de 2011 . Consultado el 15 de abril de 2011 .
  28. ^ S. Deering ; R. Hinden (diciembre de 1998). Especificación del Protocolo de Internet, versión 6 (IPv6). Grupo de Trabajo de Red. doi : 10.17487/RFC2460 . RFC 2460. Obsoleto. Obsoleto por RFC 8200. Obsoleto por RFC 1883. Actualizado por RFC 5095, 5722, 5871, 6437, 6564, 6935, 6946, 7045 y 7112.
  29. ^ R. Fink; R. Hinden (marzo de 2004). Eliminación progresiva de 6bone (asignación de direcciones de prueba IPv6). Grupo de Trabajo de Red. doi : 10.17487/RFC3701 . RFC 3701. Informativo. Obsoleto RFC 2471.
  30. ^ Conferencia internacional IEEE 2016 sobre tecnologías emergentes y prácticas comerciales innovadoras para la transformación de 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.
  31. ^ Perdiz, C.; Kastenholz, F. (diciembre de 1994). "6.2 Suma de comprobación del encabezado IP". Criterios técnicos para la elección de IP La Próxima Generación (IPng). pag. 26. seg. 6.2. doi : 10.17487/RFC1726 . RFC 1726.
  32. ^ J. Postel , ed. (Septiembre de 1981). PROTOCOLO DE INTERNET - ESPECIFICACIÓN DEL PROTOCOLO DEL PROGRAMA DE INTERNET DARPA. IETF . doi : 10.17487/RFC0791 . ETS 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.
  33. ^ K. Nichols; S. Blake; F. panadero ; D. Negro (diciembre de 1998). Definición del Campo de Servicios Diferenciados (Campo DS) en los Encabezados IPv4 e IPv6. Grupo de Trabajo de Red. doi : 10.17487/RFC2474 . RFC 2474. Norma propuesta. Obsoletos RFC 1455 y 1349. Actualizado por RFC 3168, 3260 y 8436.
  34. ^ K. Ramakrishnan; S. Floyd; D. Negro (septiembre de 2001). La adición de notificación explícita de congestión (ECN) a IP. Grupo de Trabajo de Red. doi : 10.17487/RFC3168 . RFC 3168. Norma propuesta. Obsoletos RFC 2481. Actualizaciones RFC 2474, 2401 y 793. Actualizado por RFC 4301, 6040 y 8311.
  35. ^ Salvaje, Stefan (2000). "Soporte de red práctico para rastreo de IP". Revisión de comunicación por computadora ACM SIGCOMM . 30 (4): 295–306. doi : 10.1145/347057.347560 .
  36. ^ 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.
  37. ^ Bhardwaj, Rashmi (4 de junio de 2020). "Compensación de fragmentos: IP con facilidad". ipwithease.com . Consultado el 21 de noviembre de 2022 .
  38. ^ J. Postel (septiembre de 1981). NÚMEROS ASIGNADOS. Grupo de Trabajo de Red. doi : 10.17487/RFC0790 . RFC 790. Obsoleto. Obsoleto por RFC 820. Obsoleto RFC 776, 770, 762, 758, 755, 750, 739, 604, 503, 433 y 349. Obsoleto IEN: 127, 117, 93.
  39. ^ "Preguntas frecuentes no oficiales de Cisco" . Consultado el 10 de mayo de 2012 .
  40. ^ "Parámetros del protocolo de Internet versión 4 (IPv4)".

enlaces externos