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 .
Pila de protocolos | |
Propósito | protocolo de internetworking |
---|---|
Desarrollador (es) | DARPA |
Introducido | 1981 |
Capa OSI | Capa de red |
RFC (s) | RFC 791 |
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 métodos de red especiales.
Historia
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 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 los Estados Unidos declaró TCP / IP como el estándar para todas las redes de computadoras militares. [3]
Propósito
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. La mayoría de las veces 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 puede expresarse 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 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, sobre la base de 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ó classful , 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 fines 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 único 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 realizar pruebas comparativas de comunicaciones entre redes entre dos subredes independientes. [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 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 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 difusión no terminan necesariamente en 255. Por ejemplo, una subred CIDR 203.0.113.16/28 tiene la dirección de difusió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 existe 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 de la traducción de direcciones de red (NAT) en los sistemas de proveedores de acceso a la red y el uso estricto. políticas de asignación basadas 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] por lo que las tecnologías de transición intermedias son necesarias 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 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 | Un 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) | |||||||||||||||||||||||||||||||
⋮ | ⋮ | ||||||||||||||||||||||||||||||||
60 | 480 |
- 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 se define 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 de 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 fuente 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 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 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 campo de tiempo de vida de ocho bits ayuda a evitar que los datagramas persistan (por ejemplo, dando vueltas) en Internet. Este campo limita la vida útil de un datagrama. Se especifica en segundos, pero los intervalos de tiempo inferiores a 1 segundo se redondean a 1. En la práctica, el campo se ha convertido en 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 ICMP Tiempo excedido al remitente.
- El programa traceroute usa estos mensajes ICMP Time Exceeded para imprimir los enrutadores usados por los paquetes para ir del origen al 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 campos de suma de comprobación.
- Cuando un paquete llega a un enrutador, el enrutador reduce el campo TTL. En consecuencia, el enrutador debe calcular una nueva suma de comprobación.
- 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. 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). La lista de opciones puede terminar con una opción EOL (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.
- Nota: Si la longitud del encabezado es superior a 5 (es decir, de 6 a 15), significa que el campo de opciones está presente y debe tenerse en cuenta.
- Nota: Copiado, Clase de opción y Número de opción a veces se denominan un solo campo de ocho bits, el Tipo de opción .
- Los paquetes que contienen algunas opciones pueden ser considerados peligrosos por algunos enrutadores y bloqueados. [32]
- La siguiente tabla muestra las opciones definidas para IPv4. Estrictamente hablando, la columna denominada "Número de opción" es en realidad el "Valor de opción" que se deriva de los bits Copiado, Clase de opción y Número de opción como se definió anteriormente. Sin embargo, dado que la mayoría de la gente se refiere hoy en día a este conjunto de bits combinado como el "número de opción", esta tabla muestra ese uso común. La tabla muestra los números de opción decimal y hexadecimal. [33]
Número de opción 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 Circuito 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.
Algunos de los protocolos de carga útil más comunes son:
Número de protocolo | Nombre de 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 |
Consulte Lista de números de protocolo IP para obtener una lista completa.
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 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:
- 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. Los protocolos para tales correlaciones inversas existen en Internet Protocol Suite . 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 por RFC 3168 y RFC 3260
- ^ Como una broma de April Fools , propuesto para su uso en RFC 3514 como el " Bit Evil "
Referencias
- ^ "Informes de análisis 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.
- ^ RFC 5735
- ^ a b c d M. Cotton; 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. Cotton; 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 correo 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 .
- ^ RFC 3701, R. Fink, R. HInden, Eliminación gradual de 6bone (asignación de direcciones de prueba de IPv6) (marzo de 2004)
- ^ 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. ISBN 9781509007066. OCLC 972636788 .CS1 maint: otros ( enlace )
- ^ RFC 1726 sección 6.2
- ^ Postel, J. Protocolo de Internet . doi : 10.17487 / RFC0791 . RFC 791 .
- ^ Salvaje, Stefan. "Práctico soporte de red para rastreo IP" . Consultado el 6 de septiembre de 2010 .
- ^ "Preguntas frecuentes no oficiales de Cisco" . Consultado el 10 de mayo de 2012 .
- ^ https://www.iana.org/assignments/ip-parameters/ip-parameters.xhtml#ip-parameters-1
enlaces externos
- 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 restantes disponibles (estimado)