IPv4
| Pila de protocolos | |
 Paquete IPv4 | |
| Objetivo | protocolo de internetworking |
|---|---|
| Desarrollador (es) | DARPA |
| Introducido | 1981 |
| Capa OSI | Capa de red |
| RFC (s) | RFC 791 |
| Conjunto de protocolos de internet |
|---|
| Capa de aplicación |
| Capa de transporte |
| Capa de internet |
| Capa de enlace |
|
La versión 4 del Protocolo de Internet ( IPv4 ) es la cuarta versión del Protocolo de Internet (IP). Es uno de los protocolos centrales de la basada en estándares de conexión en red métodos en la Internet y otras de conmutación de paquetes redes. IPv4 fue la primera versión implementada para producción en SATNET en 1982 y en ARPANET en enero de 1983. Todavía se usa para enrutar la mayor parte del tráfico de Internet en la actualidad, [1] a pesar del despliegue continuo de un protocolo sucesor, IPv6 .
IPv4 utiliza un espacio de direcciones de 32 bits que proporciona 4,294,967,296 (2 32 ) direcciones únicas, pero los bloques grandes están reservados para métodos de red especiales.
Historia
Esta sección necesita expansión . Puede ayudar añadiéndole . ( Agosto de 2020 ) |
La capa IP se separó originalmente en la versión 3 del TCP para mejorar el diseño y se estabilizó en la versión 4. [2] IPv4 se describe en la publicación del IETF RFC 791 (septiembre de 1981), reemplazando una definición anterior (RFC 760, enero de 1980). En marzo de 1982, el Departamento de Defensa de EE. UU. Declaró TCP / IP como el estándar para todas las redes de computadoras militares. [3]
Objetivo
El Protocolo de Internet es el protocolo que define y habilita la interconexión en red en la capa de Internet de Internet Protocol Suite . 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 está un salto más cerca del host de destino previsto en otra red.
IPv4 es un protocolo sin conexión y funciona con un modelo de entrega de mejor esfuerzo , ya que no garantiza la entrega, ni asegura la secuenciación adecuada ni evita la entrega duplicada. Estos aspectos, incluida la integridad de los datos, se tratan mediante un protocolo de transporte de capa superior , como el Protocolo de control de transmisión (TCP).
Direccionamiento
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 se pueden representar en cualquier notación que exprese un valor entero de 32 bits. Por lo general, 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 192.0.2.235 representa el número decimal de 32 bits 3221226219, que en formato hexadecimal es 0xC00002EB. Esto también se puede expresar en formato hexadecimal punteado como 0xC0.0x00.0x02.0xEB, o con valores de bytes octales como 0300.0000.0002.0353.
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 escribe 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 especifican menos de cuatro números en la dirección en notación con puntos, el último valor se trata como un número entero de tantos bytes como sean necesarios para completar la dirección hasta cuatro octetos. Por 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 llamó campo de descanso . Esta estructura permitió un máximo de 256 identificadores de red, lo que rápidamente se descubrió que era inadecuado.
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 clase . 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 direccionamiento de 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 classful 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 Classless Inter-Domain Routing (CIDR), [4] que expresaba el número de bits (del más significativo ) como, por ejemplo, / 24, y el esquema basado en clases se denominó con clase , por el contrario. CIDR se diseñó para permitir la repartición de cualquier espacio de direcciones de modo que se pudieran asignar bloques de direcciones más pequeños o más grandes a los usuarios. La estructura jerárquica creada por CIDR es administrada por la Autoridad de Números Asignados de Internet (IANA) y los registros regionales de Internet (RIR). Cada RIR mantiene una base de datos de 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 propósitos especiales. [5] En particular, estas direcciones se utilizan para tráfico de multidifusión y para proporcionar espacio de direccionamiento para usos sin restricciones en redes privadas.
Bloques de direcciones especiales Bloque de direcciones Rango de direcciones Numero de direcciones Alcance Descripción 0.0.0.0/8 0.0.0.0–0.255.255.255 16 777 216 Software Red actual [6] (solo válida como dirección de origen). 10.0.0.0/8 10.0.0.0–10.255.255.255 16 777 216 Red privada Se utiliza para comunicaciones locales dentro de una red privada . [7] 100.64.0.0/10 100.64.0.0–100.127.255.255 4 194 304 Red privada Espacio de direcciones compartido [8] para las comunicaciones entre un proveedor de servicios y sus abonados cuando se utiliza un NAT de nivel de operador . 127.0.0.0/8 127.0.0.0–127.255.255.255 16 777 216 Anfitrión Se utiliza para direcciones de bucle de retorno al host local. [6] 169.254.0.0/16 169.254.0.0–169.254.255.255 65 536 Subred Se utiliza para direcciones de enlace local [9] entre dos hosts en un solo enlace cuando no se especifica ninguna dirección IP, como la que normalmente se obtendría de un servidor DHCP . 172.16.0.0/12 172.16.0.0–172.31.255.255 1 048 576 Red privada Se utiliza para comunicaciones locales dentro de una red privada. [7] 192.0.0.0/24 192.0.0.0–192.0.0.255 256 Red privada Asignaciones de protocolo IETF. [6] 192.0.2.0/24 192.0.2.0–192.0.2.255 256 Documentación Asignado como TEST-NET-1, documentación y ejemplos. [10] 192.88.99.0/24 192.88.99.0–192.88.99.255 256 Internet Reservado. [11] Anteriormente utilizado para retransmisiones de IPv6 a IPv4 [12] (incluido el bloque de direcciones IPv6 2002 :: / 16 ). 192.168.0.0/16 192.168.0.0–192.168.255.255 65 536 Red privada Se utiliza para comunicaciones locales dentro de una red privada. [7] 198.18.0.0/15 198.18.0.0–198.19.255.255 131 072 Red privada Se utiliza para pruebas comparativas de comunicaciones entre redes entre dos subredes separadas. [13] 198.51.100.0/24 198.51.100.0–198.51.100.255 256 Documentación Asignado como TEST-NET-2, documentación y ejemplos. [10] 203.0.113.0/24 203.0.113.0–203.0.113.255 256 Documentación Asignado como TEST-NET-3, documentación y ejemplos. [10] 224.0.0.0/4 224.0.0.0–239.255.255.255 268 435 456 Internet En uso para multidifusión IP . [14] (Antigua red de clase D). 233.252.0.0/24 233.252.0.0-233.252.0.255 256 Documentación Asignado como MCAST-TEST-NET, documentación y ejemplos. [14] [15] 240.0.0.0/4 240.0.0.0–255.255.255.254 268 435 455 Internet Reservado para uso futuro. [16] (Antigua red de Clase E). 255.255.255.255/32 255.255.255.255 1 Subred Reservado para la dirección de destino de " difusión limitada ". [6] [17]
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; son ignorados por todos los enrutadores públicos. Por lo tanto, los hosts privados no pueden comunicarse directamente con las redes públicas, pero requieren la traducción de la dirección de red en una puerta de enlace de enrutamiento para este propósito.
Intervalos de red IPv4 privados reservados [7] Nombre Bloque CIDR Rango de direcciones Numero de direcciones Descripción con clase Bloque de 24 bits 10.0.0.0/8 10.0.0.0 - 10.255.255.255 16 777 216 Clase única A. Bloque de 20 bits 172.16.0.0/12 172.16.0.0 - 172.31.255.255 1 048 576 Gama contigua de 16 bloques Clase B. Bloque de 16 bits 192.168.0.0/16 192.168.0.0 - 192.168.255.255 65 536 Rango contiguo de 256 bloques Clase C.
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 en puente 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 local de enlace
RFC 3927 define el bloque de direcciones especiales 169.254.0.0/16 para 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) directamente conectado a un host que las usa. Estas direcciones no se pueden enrutar. 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 se reservó el bloque de direcciones, 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 IPv4 Link-Local .
Loopback
La red clase A 127.0.0.0 (red sin clase 127.0.0.0/8) está reservada para bucle invertido . 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 fuente de bucle invertido o una dirección de destino 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 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 transmisión local para enviar mensajes a todos los dispositivos de la subred simultáneamente. Para redes de tamaño / 24 o más grandes, 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), el identificador 192.168.5.0 se utiliza para hacer referencia a toda la subred. La dirección de transmisión de la red es 192.168.5.255.
| Forma binaria | Notación decimal de puntos | |
|---|---|---|
| Espacio de red | 11000000.10101000.00000101.00000000 | 192.168.5.0 |
| Dirección de Difusión | 11000000.10101000.00000101.11111111 | 192.168.5.255 |
| En rojo, se muestra la parte del host de la dirección IP; la otra parte es el prefijo de red. El host se invierte (NOT lógico), pero el prefijo de red permanece intacto. | ||
Sin embargo, esto no significa que todas las direcciones que terminan en 0 o 255 no se puedan utilizar como dirección de host. 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 transmisión es 192.168.255.255. Se pueden usar las siguientes direcciones para los 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] Las direcciones 192.168.1.0, 192.168.2.0, etc., pueden asignarse, a pesar de terminar en 0.
En el pasado, el conflicto entre las direcciones de red y las direcciones de transmisión surgía porque algunos software usaban direcciones de transmisión no estándar con ceros en lugar de unos. [20]
En redes menores que / 24, las direcciones de transmisión no terminan necesariamente en 255. Por ejemplo, una subred CIDR 203.0.113.16/28 tiene la dirección de transmisión 203.0.113.31.
| Forma binaria | Notación decimal de puntos | |
|---|---|---|
| Espacio de red | 11001011.00000000.01110001.00010000 | 203.0.113.16 |
| Dirección de Difusión | 11001011.00000000.01110001.00011111 | 203.0.113.31 |
| En rojo, se muestra la parte del host de la dirección IP; la otra parte es el prefijo de red. El host se invierte (NOT lógico), pero el prefijo de red permanece intacto. | ||
Como caso especial, una red / 31 tiene capacidad para solo dos hosts. Estas redes se utilizan normalmente para conexiones punto a punto. No hay un identificador de red ni una dirección de transmisión para estas redes. [21]
Resolución de direcciones
Los hosts en Internet generalmente se conocen por sus 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, lo que se denomina resolverlos , a direcciones y viceversa. Esto es análogo a buscar un número de teléfono en una guía telefónica usando 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 jerárquico que permite la subdelegación de espacios de nombres a otros servidores DNS.
Agotamiento del espacio de direcciones
Desde la década de 1980, era 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. [22] Las principales fuerzas del mercado que aceleraron el agotamiento de las direcciones incluyeron el número cada vez mayor 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, como los métodos Classless Inter-Domain Routing (CIDR) a mediados de la década de 1990, el uso generalizado detraducción de direcciones de red (NAT) en los sistemas de proveedores de acceso a la red y estrictas políticas de asignación basadas en el uso en los registros regionales y locales de Internet.
El grupo principal de direcciones de Internet, mantenido por IANA, se agotó el 3 de febrero de 2011, cuando los últimos cinco bloques se asignaron a los cinco RIR . [23] [24] APNIC fue el primer RIR en agotar su grupo regional el 15 de abril de 2011, excepto por una pequeña cantidad de espacio de direcciones reservado para las tecnologías de transición a IPv6, que se asignará bajo una política restringida. [25]
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 . [26] 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 subredes de un mínimo de 2 64 direcciones de host a los usuarios finales. Sin embargo, IPv4 no es directamente interoperable con IPv6, por lo que los hosts solo con IPv4 no pueden comunicarse directamente con los hosts solo con IPv6. Con la eliminación de la red experimental 6bone a partir de 2004, la implementación formal permanente de IPv6 comenzó en 2006. [27] Se espera que la implementación de IPv6 lleve un tiempo considerable, [28]de modo que las tecnologías de transición intermedia son necesarias 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 transportados por IP también tienen su propia verificación de errores. [29]
Encabezamiento
El encabezado del paquete IPv4 consta de 14 campos, de los cuales 13 son obligatorios. El decimocuarto campo es opcional y se llama acertadamente: opciones. Los campos del encabezado están empaquetados con el byte más significativo primero ( big endian ), y para el diagrama y la discusión, se considera que los bits más significativos vienen 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 los cuatro bits más significativos del primer byte, por ejemplo.
| Compensaciones | Octeto | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octeto | Poco | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Versión | DIH | DSCP | ECN | Largo total | |||||||||||||||||||||||||||
| 4 | 32 | Identificación | Banderas | Desplazamiento de fragmento | |||||||||||||||||||||||||||||
| 8 | 64 | Tiempo para vivir | Protocolo | Suma de comprobación del encabezado | |||||||||||||||||||||||||||||
| 12 | 96 | Dirección IP origen | |||||||||||||||||||||||||||||||
| dieciséis | 128 | Dirección IP de destino | |||||||||||||||||||||||||||||||
| 20 | 160 | Opciones (si DIH> 5) | |||||||||||||||||||||||||||||||
| ⋮ | ⋮ | ||||||||||||||||||||||||||||||||
| 56 | 448 | ||||||||||||||||||||||||||||||||
- 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 es de tamaño variable debido al campo 14 opcional (opciones). El campo IHL contiene el tamaño del encabezado IPv4, tiene 4 bits que especifican el número de palabras de 32 bits en el encabezado. El valor mínimo para este campo es 5, [30] 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) según RFC 2474. [a] La transmisión de datos en tiempo real hace uso del campo DSCP. Un ejemplo es Voice over IP (VoIP), que se utiliza para servicios de voz interactivos.
- Notificación de congestión explícita (ECN )
- Este campo está definido en RFC 3168 y permite la notificación de un extremo a otro de la congestión de la red sin perder paquetes . ECN es una función opcional disponible cuando ambos extremos la admiten y efectiva cuando también es compatible con 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 (encabezado sin datos) y el máximo es de 65.535 bytes. Se requiere que todos los hosts puedan volver a ensamblar datagramas de un tamaño de hasta 576 bytes, pero la mayoría de los hosts modernos manejan paquetes mucho más grandes. Los enlaces pueden imponer restricciones adicionales sobre el tamaño del paquete, en cuyo caso los datagramas deben estar fragmentados . 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 usar el campo ID para otros propósitos, como agregar información de rastreo de paquetes para ayudar a rastrear datagramas con direcciones de origen falsificadas, [31] pero RFC 6864 ahora prohíbe tal uso.
- Banderas
- A continuación, aparece un campo de tres bits que se utiliza para controlar o identificar fragmentos. Son (en orden, del más significativo al menos significativo):
- bit 0: reservado; debe ser cero. [B]
- 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, el paquete se descarta. Esto se puede usar 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 rutas MTU , ya sea automáticamente por el software de IP del host o manualmente utilizando herramientas de diagnóstico como ping o traceroute .
- Para paquetes no fragmentados, se borra el indicador MF. Para los paquetes fragmentados, todos los fragmentos excepto el último tienen la bandera MF activada. El último fragmento tiene un campo de desplazamiento de fragmentos 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 no fragmentado original en unidades de bloques de ocho bytes. El primer fragmento tiene un desplazamiento de cero. El campo de 13 bits permite un desplazamiento máximo de (2 13 - 1) × 8 = 65,528 bytes, que, con la longitud del encabezado incluida (65,528 + 20 = 65,548 bytes), admite la fragmentación de paquetes que exceden la longitud máxima de IP de 65,535 bytes.
- Tiempo de vida (TTL)
- Un niño de ocho bits Tiempo de Vida de campo limita la vida de un datagrama para evitar el fracaso de 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 un recuento de saltos: cuando el datagrama llega a un enrutador , el enrutador reduce 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 excedido ICMP 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 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 según lo indicado por RFC 790.
- Suma de comprobación del encabezado
- El campo de suma de comprobación del encabezado IPv4 de 16 bits se utiliza para verificar los errores del encabezado. Cuando un paquete llega a un enrutador, el enrutador calcula la suma de verificación del encabezado y la compara con el campo de suma de verificación. Si los valores no coinciden, el enrutador descarta el paquete. Los errores en el campo de datos deben ser manejados por el protocolo encapsulado. Tanto UDP como TCP tienen sumas de comprobació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 de encabezado.
- Dirección de la fuente
- Este campo es la dirección IPv4 del remitente del paquete. Tenga en cuenta que esta dirección puede ser cambiada en tránsito por un dispositivo de traducción de direcciones de red .
- Dirección de destino
- Este campo es la dirección IPv4 del receptor del paquete. Al igual que con la dirección de origen, un dispositivo de traducción de direcciones de red puede modificarla en tránsito.
- Opciones
- El campo de opciones no se usa a menudo. Los paquetes que contienen algunas opciones pueden ser considerados peligrosos por algunos enrutadores y bloqueados. [32] Tenga en cuenta que el valor en el campo DIH debe incluir suficientes palabras adicionales de 32 bits para contener todas las opciones más cualquier relleno necesario para garantizar que el encabezado contenga un número entero de palabras de 32 bits. Si el DIH es mayor que 5 (es decir, de 6 a 15) significa que el campo de opciones está presente y debe ser considerado. La lista de opciones puede terminarse con una opción EOOL (Fin de la lista de opciones, 0x00); esto solo 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:
Campo Tamaño (bits) Descripción Copiado 1 Establézcalo en 1 si es necesario copiar las opciones en todos los fragmentos de un paquete fragmentado. Clase de opción 2 Una categoría de opciones generales. 0 es para opciones de control y 2 es para depuración y medición . 1 y 3 están reservados. Número de opción 5 Especifica una opción. Longitud de la opción 8 Indica el tamaño de toda la opción (incluido este campo). Es posible que este campo no exista para opciones simples. Datos de opciones Variable Datos específicos de la opción. Es posible que este campo no exista para opciones simples.
- 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. [33]
Tipo de opción (decimal / hexadecimal) Nombre de la opción Descripción 0 / 0x00 EOOL Fin de la lista de opciones 1 / 0x01 NOP No operacion 2 / 0x02 SEGUNDO Seguridad (desaparecida) 7 / 0x07 RR Ruta de registro 10 / 0x0A ZSU Medición experimental 11 / 0x0B MTUP Sonda MTU 12 / 0x0C MTUR Respuesta de MTU 15 / 0x0F CODIFICAR CODIFICAR 25 / 0x19 QS Inicio rápido 30 / 0x1E Exp Experimento de estilo RFC3692 68 / 0x44 TS Sello de tiempo 82 / 0x52 TR Traceroute 94 / 0x5E Exp Experimento de estilo RFC3692 130 / 0x82 SEGUNDO Seguridad (RIPSO) 131 / 0x83 LSR Ruta de origen suelta 133 / 0x85 E-SEC Seguridad extendida (RIPSO) 134 / 0x86 CIPSO Opción de seguridad IP comercial 136 / 0x88 SID ID de secuencia 137 / 0x89 SSR Ruta de origen estricta 142 / 0x8E VISA Control de acceso experimental 144 / 0x90 IMITD Descriptor de tráfico IMI 145 / 0x91 EIP Protocolo de Internet extendido 147 / 0x93 AÑADIR Extensión de dirección 148 / 0x94 RTRALT Alerta de enrutador 149 / 0x95 SDB Difusión dirigida selectiva 151 / 0x97 DPS Estado de paquete dinámico 152 / 0x98 UMP Pkt de multidifusión ascendente. 158 / 0x9E Exp Experimento de estilo RFC3692 205 / 0xCD FINLANDÉS Control de flujo experimental 222 / 0xDE Exp Experimento de estilo RFC3692
Datos
La carga útil del paquete no se incluye en la suma de comprobación. Su contenido se interpreta en función del valor del campo de encabezado del Protocolo.
La lista de números de protocolo IP contiene una lista completa de tipos de protocolo de carga útil. Algunos de los protocolos de carga útil más comunes incluyen:
| Número de protocolo | Nombre del protocolo | Abreviatura |
|---|---|---|
| 1 | Protocolo de mensajes de control de Internet | ICMP |
| 2 | Protocolo de administración de grupos de Internet | IGMP |
| 6 | Protocolo de Control de Transmisión | TCP |
| 17 | Protocolo de datagramas de usuario | UDP |
| 41 | Encapsulación IPv6 | ENCAP |
| 89 | Abra primero el camino más corto | OSPF |
| 132 | Protocolo de transmisión de control de flujo | SCTP |
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 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, que por lo tanto no requieren la implementación de capas superiores para la función de enrutamiento de paquetes IP.
Por el contrario, IPv6 , la próxima generación del Protocolo de Internet, no permite que los enrutadores realicen la fragmentación; los hosts deben determinar la ruta MTU 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 se establece 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 menos el tamaño del encabezado IP (20 bytes como mínimo; 60 bytes como máximo). El enrutador coloca cada fragmento en su propio paquete, y cada paquete de fragmentos tiene los siguientes cambios:
- El campo de longitud total es el tamaño del fragmento.
- El indicador de más fragmentos (MF) se establece para todos los fragmentos excepto el último, que se establece en 0.
- El campo de desplazamiento del fragmento se establece en función del desplazamiento del fragmento en la carga útil de datos original. Esto se mide en unidades de bloques de 8 bytes.
- El campo de suma de comprobación del encabezado se vuelve a calcular.
Por ejemplo, para una MTU de 1500 bytes y un tamaño de encabezado de 20 bytes, las compensaciones de los fragmentos serían múltiplos de . Estos múltiplos son 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, incluidos los 20 bytes del encabezado IP (sin opciones), se fragmenta en dos paquetes en un enlace con una MTU de 2500 bytes:
| Fragmento | Tamaño (bytes) | Tamaño del encabezado (bytes) | Tamaño de datos (bytes) | Marcar más fragmentos | Desplazamiento de fragmento (bloques de 8 bytes) |
|---|---|---|---|---|---|
| 1 | 2500 | 20 | 2,480 | 1 | 0 |
| 2 | 2.040 | 20 | 2.020 | 0 | 310 |
Se conserva el tamaño total de los datos: 2480 bytes + 2020 bytes = 4500 bytes. Las compensaciones son y .
En un enlace con una MTU de 1500 bytes, cada fragmento da como resultado dos fragmentos:
| Fragmento | Tamaño (bytes) | Tamaño del encabezado (bytes) | Tamaño de datos (bytes) | Marcar más fragmentos | Desplazamiento de fragmento (bloques de 8 bytes) |
|---|---|---|---|---|---|
| 1 | 1500 | 20 | 1,480 | 1 | 0 |
| 2 | 1.020 | 20 | 1.000 | 1 | 185 |
| 3 | 1500 | 20 | 1,480 | 1 | 310 |
| 4 | 560 | 20 | 540 | 0 | 495 |
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 1 para todos los fragmentos que vinieron con 1 en ellos y para el último fragmento que llega, funciona como de costumbre, es decir, el bit MF se pone a 0 solo en el último. Y, por supuesto, el campo Identificación sigue teniendo el mismo valor en todos los fragmentos re-fragmentados. 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 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:
- Se establece la bandera "más fragmentos", que es válida para todos los fragmentos excepto el último.
- El campo "desplazamiento de fragmento" es distinto de cero, lo cual es cierto para todos los fragmentos excepto el primero.
El receptor identifica los fragmentos coincidentes utilizando la dirección local y extranjera, el ID de 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 de fragmentos como el indicador de más fragmentos. Cuando el receptor recibe el último fragmento, que tiene el indicador "más fragmentos" establecido en 0, puede calcular el tamaño de la carga de datos original, multiplicando el desplazamiento del último fragmento por ocho y agregando el tamaño de los datos del último fragmento. En el ejemplo dado, este cálculo fue 495 * 8 + 540 = 4500 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 a las identificaciones de hardware y, de hecho, una interfaz de red puede tener varias direcciones IP en los sistemas operativos modernos. Los hosts y los enrutadores necesitan mecanismos adicionales para identificar la relación entre las interfaces del dispositivo y las direcciones IP, a fin de entregar correctamente un paquete IP al host de destino en un enlace. El Protocolo de resolución de direcciones (ARP) realiza esta traducción de dirección IP a dirección de hardware para IPv4. (Una dirección de hardware también se denomina dirección MAC ). Además, la correlación inversa a menudo es necesaria. Por ejemplo, cuando un host IP se inicia o se conecta a una red, necesita determinar su dirección IP, a menos que un administrador preconfigure una dirección. Existen protocolos para tales correlaciones inversas en elSuite de protocolo de Internet . Los métodos que se utilizan actualmente son el Protocolo de configuración dinámica de host (DHCP), el Protocolo Bootstrap (BOOTP) y, con poca frecuencia, ARP inverso .
Ver también
- Historia de Internet
- Lista de bloques de direcciones IPv4 asignados / 8
- Lista de números de protocolo IP
Notas
- ^ Actualizado porRFC 3168 yRFC 3260
- ^ Como una broma de April Fools , propuesto para su uso en RFC 3514 como el " bit Evil "
Referencias
- ^ "Informes de análisis de BGP" . Consultado el 9 de enero de 2013 .
- ^ "¿Dónde está IPv1, 2, 3 y 5?" . blog.alertlogic.com . Consultado el 12 de agosto de 2020 .
- ^ "Una breve historia de IPv4" . Grupo de mercado IPv4 . Consultado el 19 de agosto de 2020 .
- ^ "Comprensión del direccionamiento IP: todo lo que siempre quiso saber" (PDF) . 3Com. Archivado desde el original (PDF) el 16 de junio de 2001.
- ^ Algodón, M .; Vegoda, L. (enero de 2010). Direcciones IPv4 de uso especial . doi : 10.17487 / RFC5735 . RFC 5735 .
- ^ a b c d M. Algodón; L. Vegoda; R. Bonica; B. Haberman (abril de 2013). Registros de direcciones IP para fines especiales . Grupo de trabajo de ingeniería de Internet . doi : 10.17487 / RFC6890 . BCP 153. RFC 6890 . Actualizado por RFC 8190 .
- ^ a b c d Y. Rekhter; B. Moskowitz; D. Karrenberg; GJ de Groot; E. Lear (febrero de 1996). Asignación de direcciones para Internet privado . Grupo de trabajo en red. doi : 10.17487 / RFC1918 . BCP 5. RFC 1918 . Actualizado por RFC 6761 .
- ^ 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 (IETF). doi : 10.17487 / RFC6598 . ISSN 2070-1721 . BCP 153. RFC 6598 .
- ^ S. Cheshire; B. Aboba; E. Guttman (mayo de 2005). Configuración dinámica de direcciones locales de enlace IPv4 . Grupo de trabajo en red. doi : 10.17487 / RFC3927 . RFC 3927 .
- ^ a b c 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 .
- ^ O. Troan (mayo de 2015). B. Carpenter (ed.). Desactivación 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 .
- ^ C. Huitema (junio de 2001). Un prefijo Anycast para enrutadores de retransmisión 6to4 . Grupo de trabajo en red. doi : 10.17487 / RFC3068 . RFC 3068 . Obsoleto por RFC 7526 .
- ^ S. Bradner; J. McQuaid (marzo de 1999). Metodología de evaluación comparativa para dispositivos de interconexión de red . Grupo de trabajo en red. doi : 10.17487 / RFC2544 . RFC 2544 . Actualizado por: RFC 6201 y RFC 6815 .
- ^ a b M. Algodón; L. Vegoda; D. Meyer (marzo de 2010). Directrices de la IANA para asignaciones de direcciones de multidifusión IPv4 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487 / RFC5771 . BCP 51. RFC 5771 .
- ^ 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 . RFC 6676 .
- ^ J. Reynolds, ed. (Enero de 2002). Números asignados: RFC 1700 es reemplazado por una base de datos en línea . Grupo de trabajo en red. doi : 10.17487 / RFC3232 . RFC 3232 . Desactiva RFC 1700 .
- ^ Jeffrey Mogul (octubre de 1984). Difusión de datagramas de Internet . Grupo de trabajo en red. doi : 10.17487 / RFC0919 . RFC 919 .
- ^ "RFC 923" . IETF . Junio de 1984 . Consultado el 15 de noviembre de 2019 .
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 "esta", como en "esta red".
- ^ Robert Braden (octubre de 1989). "Requisitos para hosts de Internet - Capas de comunicación" . IETF . pag. 31. RFC 1122 .
- ^ Robert Braden (octubre de 1989). "Requisitos para hosts de Internet - Capas de comunicación" . IETF . pag. 66. RFC 1122 .
- ^ RFC 3021
- ^ "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 .
- ^ Smith, Lucie; Lipner, Ian (3 de febrero de 2011). "Grupo libre de espacio de direcciones IPv4 agotado" . Organización de recursos numéricos . Consultado el 3 de febrero de 2011 .
- ^ ICANN, lista de distribución de nanog. "Cinco / 8 asignados a RIR - no quedan IPv4 unicast / 8 sin asignar" .
- ^ Centro de información de la red de Asia y el Pacífico (15 de abril de 2011). "El grupo de direcciones IPv4 de APNIC alcanza la final / 8" . Archivado desde el original el 7 de agosto de 2011 . Consultado el 15 de abril de 2011 .
- ^ "Protocolo de Internet, especificación de la versión 6 (IPv6)" . tools.ietf.org . Consultado el 13 de diciembre de 2019 .
- ^ Fink, R .; HInden, R. (marzo de 2004). Eliminación gradual de 6bone (asignación de direcciones de prueba IPv6) . doi : 10.17487 / RFC3701 . RFC 3701 .
- ^ 2016 IEEE International Conference on Emerging Technologies and Innovative Business Practices for the Transformation of Societies (EmergiTech): fecha, 3-6 de agosto de 2016 . Universidad de Tecnología, Mauricio, Instituto de Ingenieros Eléctricos y Electrónicos. Piscataway, Nueva Jersey. 2016. ISBN 9781509007066. OCLC 972636788 .CS1 maint: otros ( enlace )
- ^ Perdiz, C .; Kastenholz, F. (diciembre de 1994). "6.2 Suma de comprobación del encabezado IP" . Criterios técnicos para elegir IP de próxima generación (IPng) . pag. 26. seg. 6.2. doi : 10.17487 / RFC1726 . RFC 1726 .
- ^ Postel, J. Protocolo de Internet . doi : 10.17487 / RFC0791 . RFC 791 .
- ^ Savage, Stefan (2000). "Práctico soporte de red para rastreo IP" . Revisión de comunicación informática ACM SIGCOMM . 30 (4): 295-306. doi : 10.1145 / 347057.347560 . Consultado el 6 de septiembre de 2010 .
- ^ "Preguntas frecuentes no oficiales de Cisco" . Consultado el 10 de mayo de 2012 .
- ^ "Parámetros del Protocolo de Internet versión 4 (IPv4)" .
enlaces externos
Definiciones de Wikcionario- Medios de Wikimedia Commons
- Recursos de Wikiversity
- Autoridad de números asignados de Internet (IANA)
- IP, Protocolo de Internet : desglose de encabezados IP, incluidas opciones específicas
- RFC 3344 - Movilidad IPv4
- IPv6 frente a NAT de grado de operador / sacar más provecho de IPv4
- Informe RIPE sobre consumo de direcciones a octubre de 2003
- Estado actual oficial de las asignaciones de IPv4 / 8, según lo mantiene IANA
- Gráficos generados dinámicamente del consumo de direcciones IPv4 con predicciones de fechas de agotamiento: Geoff Huston
- El direccionamiento IP en China y el mito de la escasez de direcciones
- Cuenta atrás de las direcciones IPv4 disponibles restantes (estimado)
- IPv4
- Estándares de Internet
- Protocolos de capa de Internet
- Protocolos de capa de red
