IPv4

La versión actual de la página aún no ha sido revisada por colaboradores experimentados y puede diferir significativamente de la versión revisada el 23 de diciembre de 2021; las comprobaciones requieren 7 ediciones .
IPv4
Nombre Protocolo de Internet versión 4
Nivel (según el modelo OSI ) la red
Familia TCP/IP
Creado en 1981
Propósito del protocolo Direccionamiento
Especificación RFC 791
Implementaciones principales (clientes) Implementaciones de pila TCP/IP en Windows , Linux y BSD , Mac OS
Implementaciones principales ( servidores ) implementaciones de la pila TCP/IP en Windows , Linux y BSD
 Archivos multimedia en Wikimedia Commons

IPv4 ( English  Internet Protocol version 4 ) es la cuarta versión del Protocolo de Internet ( IP ). Primera versión ampliamente utilizada. El protocolo se describe en RFC 791 (septiembre de 1981), que reemplaza a RFC 760 (enero de 1980).

Representación de direcciones

IPv4 utiliza direcciones de 32 bits ( cuatro bytes ), lo que limita el espacio de direcciones a 4294967296 (232 ) posibles direcciones únicas.

La forma tradicional de una dirección IPv4 es cuatro números decimales (0 a 255) separados por puntos. La fracción indica la longitud de la máscara de subred .

Formulario de entrada Ejemplo Convertir de notación decimal con puntos
Punto decimal 192.0.2.235
Hexadecimal punteado 0xC0.0x00.0x02.0xEB Cada octeto se convierte a hexadecimal.
octal punteado 0300.0000.0002.0353 Cada octeto se convierte a octal.
hexadecimal 0xC00002EB Concatenación de octetos a partir de notación hexadecimal con puntos
Decimal 3221226219 número de 32 bits en forma decimal
octales 030000001353 número de 32 bits en forma octal

Direccionamiento: hosts y subredes

Una versión anterior del estándar IP, según RFC 760  ( enero de 1980), describía una división rígida del espacio de direcciones en subredes y hosts. El primer octeto era la dirección de la red, seguido de la dirección del host local en los tres octetos restantes. Así, el estándar permitía la existencia de 2^8=256 redes con 2^24=16.777.216 hosts cada una.

El tamaño de la subred es fijo.

Direccionamiento con clase

Sin embargo, pronto quedó claro que las redes eran demasiado pocas, demasiado grandes y que el direccionamiento carecía de flexibilidad. Por lo tanto, ya en septiembre de 1981, se lanzó el RFC 791  (inglés) , que introdujo el llamado direccionamiento con clase. La idea es esta: por flexibilidad en la asignación de direcciones de red y la capacidad de usar una gran cantidad de redes pequeñas y medianas, el espacio de direcciones se dividió en varios grupos lógicos y cada grupo tenía una proporción diferente de hosts y subredes. Estos grupos reciben el nombre de clases de red y están numerados en letras latinas: A, B, C, D y E. La división se basa en los bits más significativos de la dirección. El direccionamiento se cubre en detalle en RFC 790  .

Clase A : 0.XXX.XXX.XXX - 127.XXX.XXX.XXX

El primer bit de la dirección es cero, por lo que la clase A ocupa la mitad de todo el espacio de direcciones. La dirección de red es de 7 bits, la dirección del host es de 24 bits, por lo que la clase A contiene 128 subredes con 16 777 216 direcciones cada una.

Por ejemplo, la subred 10.0.0.0 (clase A, contiene más de 16,7 millones de direcciones desde 10.0.0.0 hasta 10.255.255.255). Reservado de forma predeterminada, no enrutable en Internet y utilizado para construir redes locales y corporativas.

SS B : 128.0.XXX.XXX - 191.255.XXX.XXX

Nuestra dirección también comienza con los bits 1,0, por lo que la clase B ocupa una cuarta parte de todo el espacio de direcciones. La dirección de red es de 14 bits, la dirección del host es de 16 bits, por lo que la clase B contiene 16 384 subredes de 65 536 direcciones cada una.

Por ejemplo, red clase B 169.254.XX con 65536 direcciones. Reservado para direcciones de "canal".

Clase C : 192.0.0.XXX - 223.255.255.XXX

La dirección comienza con los bits 1,1,0, por lo que la clase C ocupa 1/8 del espacio de direcciones. Una dirección de red tiene 21 bits, una dirección de host tiene 8 bits, por lo que la clase C contiene 2 097 152 redes de 256 direcciones cada una.

Por ejemplo, la red 192.0.2.X tiene las direcciones 192.0.2.0 a 192.0.2.255, reservadas para ejemplos de documentación.

En 1990, RFC 1166  describió dos clases más.

Clase D : 224.XXX.XXX.XXX - 239.XXX.XXX.XXX

La dirección comienza con los bits 1,1,1,0. La clase D ocupa 1/16 del espacio de direcciones. Se utiliza para multidifusión.

Clase E : 240.XXX.XXX.XXX - 255.XXX.XXX.XXX.

La dirección comienza con los bits 1,1,1,1. Tales direcciones están prohibidas. Reservado para utilización futura.

Comparativamente, los tamaños de las clases de subred se ven así:

clases: A B C D mi

Con el direccionamiento con clase, el tamaño de la subred se calcula a partir de la dirección IP.

Direccionamiento sin clases

Con el crecimiento de Internet, este sistema demostró ser ineficiente y se complementó con el direccionamiento sin clase (CIDR). Se introdujo una métrica adicional: la máscara de subred, que determina cuántos bits de la dirección se asignan a la dirección de red y cuántos a la dirección del host.

Asignaciones de subredes

Algunas direcciones IPv4 están reservadas para fines especiales y no están destinadas al enrutamiento global [1] . La lista de subredes de propósito especial está definida por RFC 6890 . La siguiente tabla muestra los principales (la lista no está completa).

subred Objetivo Enrutamiento
0.0.0.0/8[2 ] Direcciones de fuentes de paquetes de "esta" ("propia") red [1] [3] . prohibido
0.0.0.0/32 En los sockets con el estado de "escucha", significa cualquier IP de origen o cualquier red de destino en el host actual. Solo se puede enviar a la red como una dirección de origen si aún no se ha asignado una dirección IP al host (generalmente a través de DHCP ). No se puede utilizar como destino de red.

En los enrutadores Cisco, si intenta enviar un paquete a la dirección 0.0.0.0, se enviará a la dirección de transmisión de la subred conectada más pequeña (conectada en la tabla de enrutamiento).

prohibido
10.0.0.0/8[4 ] Para uso en redes privadas . RFC 1918 . La mayoría de las direcciones IPv4 en la red Gwangmyeong (RPDC) [5] . El enrutamiento global está deshabilitado.
100.64.0.0/10 Espacio de direcciones compartido. RFC 6598 . Para uso en redes de proveedores de servicios. ER-Telecom , Beeline , etc. utilizan la mayoría de las direcciones IPv4 para los suscriptores de NAT . El enrutamiento global está prohibido.
127.0.0.0/8[2 ] La subred para las comunicaciones dentro del host (consulte localhost ). Se utiliza el subsistema de red, pero estos paquetes en realidad no pasan a través de la tarjeta de red. Si se recibió un paquete con la misma dirección de destino de la red, DEBE descartarse. prohibido
169.254.0.0/16 [6] direcciones de canales La subred se utiliza para la asignación automática de IP por parte del sistema operativo en caso de que DHCP esté configurado, pero ningún servidor responda. solo en redes privadas
172.16.0.0/12 [4] Para uso en redes privadas . RFC 1918 . parte de las direcciones IPv4 en la red Gwangmyeon (RPDC) [5] . El enrutamiento global está deshabilitado.
192.0.0.0/24[7 ] Asignaciones de protocolo IETF
192.0.0.0/29 Dual-Stack Lite (DS-Lite). RFC6333 . de transición de IPv6
192.0.0.170/32 NAT64
192.0.0.171/32 DNS64
192.0.2.0/24[8 ] Para ejemplos en la documentación. prohibido
192.88.99.0/24 [1] Se utiliza para enviar al nodo más cercano . RFC 3068 permitido globalmente
192.88.99.1/32 Se utiliza como retransmisión para la encapsulación de IPv6 a IPv4 ( 6to4 ) [9] . En otras palabras, esta IP no es única. Muchas empresas lo anuncian. Un paquete a esta dirección irá al host más cercano con esta IP, que desempaquetará el paquete y lo enviará a lo largo del enrutamiento IPv6. permitido globalmente
192.168.0.0/16 [4] Para uso en redes privadas. RFC 1918 . parte de las direcciones IPv4 en la red Gwangmyeon (RPDC) [5] . El enrutamiento global está deshabilitado.
198.51.100.0/24 [8] Para ejemplos en la documentación. prohibido
198.18.0.0/15 [10] Para bancos de pruebas de rendimiento. solo para pruebas
203.0.113.0/24 [8] Para ejemplos en la documentación. prohibido
224.0.0.0/4 [11] Se utiliza para multidifusión . Para obtener una lista actualizada completa de los bloques reservados, consulte el sitio web de la IANA [1] . Subredes de multidifusión reservadas RFC 5771 aclaradas . permitido globalmente solo para las subredes 233.0.0.0/8 y 234.0.0.0/8.
240.0.0.0/4[2 ] Reservado para utilización futura. Existe la opinión de que esta subred nunca se volverá a utilizar, ya que hay muchos equipos que no pueden enviar paquetes a esta red. prohibido
255.255.255.255/32 [12] Dirección de difusión limitada . Se usa más comúnmente como dirección de destino al buscar servidores DHCP. prohibido
otro Distribuido por registradores regionales de Internet . Puede ser independiente del proveedor . permitido globalmente

Estructura del encabezado del paquete

El encabezado del paquete IP contiene 14 campos, de los cuales 13 son obligatorios. El decimocuarto campo es para opciones opcionales. Los campos usan el orden de bytes de mayor a menor, con los bits más significativos primero. El primer bit tiene el número 0. Así, por ejemplo, el campo de versión está en los cuatro bits más significativos del primer byte. Cuando se transmiten valores de múltiples octetos, el octeto más significativo se transmite primero.

Formato de encabezado IPv4
Sangrar Octeto 0 una 2 3
Octeto Un poco 0 una 2 3 cuatro 5 6 7 0 una 2 3 cuatro 5 6 7 0 una 2 3 cuatro 5 6 7 0 una 2 3 cuatro 5 6 7
0 0 Versión Tamaño del encabezado Punto de código de servicios diferenciados Notificación de congestión explícita Tamaño del paquete (completo)
cuatro 32 identificador Banderas Desplazamiento de fragmentos
ocho 64 Toda la vida Protocolo Suma de comprobación del encabezado
12 96 Dirección IP origen
dieciséis 128 Dirección IP de destino
veinte 160 Opciones (si el tamaño del encabezado es > 5)
20 o 24+ 160 o 192+ Datos
Versión El primer campo del encabezado del paquete es la versión del protocolo, que tiene una longitud de cuatro bits. Para IPv4 es 4. Tamaño del encabezado (longitud del encabezado de Internet) Los siguientes cuatro bits contienen el tamaño del encabezado del paquete en palabras de 32 bits . Dado que el número de opciones no es constante, es importante especificar el tamaño para separar el encabezado de los datos. El valor mínimo es 5 (5×32=160 bits, 20 bytes), el máximo es 15 (60 bytes). Punto de código de servicios diferenciados (DSCP) Originalmente llamado "Tipo de servicio" ( ToS), ahora definido por RFC 2474 como "Servicios diferenciados". Se utiliza para dividir el tráfico en clases de servicio, por ejemplo, para dar mayor prioridad al tráfico sensible a los retrasos, como VoIP . Puntero de congestión (Notificación de congestión explícita, ECN) Advertencia de congestión de red sin pérdida de paquetes. Esta es una función opcional y solo se usa si ambos hosts la admiten. Tamaño del paquete El tamaño total del paquete de 16 bits en bytes, incluidos el encabezado y los datos. El tamaño mínimo es de 20 bytes (cabecera sin datos), el máximo es de 65535 bytes. Los hosts deben admitir la transmisión de paquetes de hasta 576 bytes, pero las implementaciones modernas suelen admitir tamaños mucho más grandes. Los paquetes más grandes que los que admite el canal de comunicación se fragmentan. identificador Se utiliza principalmente para identificar fragmentos de un paquete si se ha fragmentado. Hay experimentos para usarlo para otros fines, como agregar información de rastreo de paquetes para que sea más fácil rastrear la ruta de un paquete con una dirección de origen falsificada [13] . Banderas Un campo de tres bits que contiene banderas de control de fragmentación. Los bits, de mayor a menor, significan:
  • 0: Reservado, debe ser 0 [14] .
  • 1: No fragmentar
  • 2: El paquete todavía tiene fragmentos
Si se establece el indicador "no fragmentar", entonces, si la fragmentación es necesaria, dicho paquete se destruirá. Puede usarse para enviar datos a hosts que no tienen suficientes recursos para manejar paquetes fragmentados. El indicador "tiene fragmentos" debe establecerse en 1 para todos los fragmentos del paquete excepto el último. Establézcalo en 0 para paquetes no fragmentados: dicho paquete se considera su propio último fragmento. Desplazamiento de fragmentos El campo de 13 bits indica el desplazamiento del campo de datos del fragmento actual con respecto al comienzo del campo de datos del primer paquete fragmentado en bloques de 8 bytes. Le permite configurar hasta (2 13 −1)×8=65528 bytes de compensación. Al considerar el tamaño del encabezado, el desplazamiento resultante puede exceder el tamaño máximo del paquete (65528 + 20 = 65548 bytes). El primer fragmento de la secuencia tiene un desplazamiento de cero. Paquete "Time to Live" ( Tiempo de vida , TTL) Especifica el número máximo de enrutadores a lo largo de la ruta del paquete. La presencia de este parámetro no permite que el paquete atraviese la red sin fin. Cada enrutador debe disminuir el valor TTL en uno al procesar un paquete. Los paquetes cuya duración se ha convertido en cero se descartan y se envía un mensaje ICMP Time Exceeded al remitente . El rastreo de su ruta de viaje ( traceroute ) se basa en el envío de paquetes con diferentes tiempos de vida . El valor máximo TTL=255. Valor inicial normal TTL=64 (depende del sistema operativo). Protocolo Especifica qué información de protocolo IP contiene el paquete (por ejemplo, TCP o ICMP). Los números de protocolo asignados se pueden encontrar en el sitio web de la IANA [15] . Suma de comprobación del encabezado Suma de comprobación de 16 bits utilizada para comprobar la integridad del encabezado. Cada host o enrutador compara la suma de verificación del encabezado con el valor de este campo y descarta el paquete si no coinciden. IP no verifica la integridad de los datos: lo verifican los protocolos de capa superior (como TCP o UDP ) que también usan sumas de verificación. Dado que el TTL se reduce en cada salto del paquete, la suma también debe calcularse en cada salto. El método de recálculo de la suma de comprobación se define en RFC 1071 [16] . Dirección de la fuente La dirección de 32 bits del remitente del paquete. Puede que no coincida con la dirección real del remitente debido a la traducción de la dirección . Dirección de destino La dirección de 32 bits del destinatario del paquete. También puede cambiar durante la traducción de direcciones. Opciones La dirección de destino puede ir seguida de un campo de opciones adicionales, pero rara vez se usa. El tamaño del encabezado en este caso debe ser lo suficientemente grande para acomodar todas las opciones (sujeto al relleno a un número entero de palabras de 32 bits). Los números de opción asignados se publican en el sitio web de la IANA. [17] Si la lista de opciones no es el final de un encabezado, debe terminar con la opción 0x00. Las opciones tienen el siguiente formato:
Campo Tamaño de bit Descripción
Copiar una Establézcalo en 1 si las opciones se van a copiar en los encabezados de todos los fragmentos.
Clase de opción 2 0 para las opciones de "control" y 2 para las opciones de "medir y depurar". 1 y 3 están reservados.
Número de opción 5 Especifica una opción.
Tamaño de la opción ocho Especifica el tamaño de la opción (incluido este campo). Puede omitirse para opciones sin argumentos.
Argumentos de opción Variable Datos adicionales utilizados por la opción.
  • Nota: La longitud del título superior a 5 palabras indica la presencia de opciones y la necesidad de procesarlas.
  • Nota: Los campos "copia", "clase de opción" y "número de opción" a veces se denominan un solo campo de "tipo de opción" de ocho bits.
Copiar clase número valor Nombre referencia
0 0 0 0 EOOL - Fin de la lista de opciones RFC791 [18]
0 0 una una NOP—Sin operación RFC791 [18]
una 0 2 130 SEC - Seguridad [RFC1108]
una 0 3 131 LSR - Ruta de fuente suelta RFC791 [18]
0 2 cuatro 68 Marca de tiempo TS RFC791 [18]
una 0 5 133 E-SEC - Seguridad ampliada [RFC1108]
una 0 6 134 CIPSO-Seguridad Comercial [borrador-ietf-cipso-ipsecurity-01]
0 0 7 7 RR—Registrar ruta RFC791 [18]
una 0 ocho 136 SID - ID de transmisión RFC791 [18] [RFC6814][1]
una 0 9 137 SSR - Ruta de origen estricta RFC791 [18]
0 0 diez diez ZSU—Medición experimental [ZSu]
0 0 once once MTUP - Sonda MTU [RFC1063][RFC1191][1]
0 0 12 12 MTUR-MTU Responder [RFC1063][RFC1191][1]
una 2 13 205 FINN - Control de flujo experimental [Greg_Finn]
una 0 catorce 142 VISA - Control de Acceso Experimental [Deborah_Estrin][RFC6814][1]
0 0 quince quince CODIFICAR - ??? [VerSteeg][RFC6814][1]
una 0 dieciséis 144 IMITD - Descriptor de tráfico IMI [Sotavento]
una 0 17 145 EIP - Protocolo de Internet extendido [RFC1385][RFC6814][1]
0 2 Dieciocho 82 TR - Trazado de ruta [RFC1393][RFC6814][1]
una 0 19 147 ADDEXT-Extensión de dirección [Ullmann IPv7][RFC6814][1]
una 0 veinte 148 Alerta de enrutador RTRALT [RFC2113]
una 0 21 149 SDB - Transmisión Dirigida Selectiva [Charles_Bud_Graff][RFC6814][1]
una 0 22 150 В В В В В В В В — Sin asignar (Publicado el 18 de octubre de 2005)
una 0 23 151 DPS - Estado de paquete dinámico [Andy_Malis][RFC6814][1]
una 0 24 152 UMP: paquete de multidifusión ascendente. [Dino_Farinacci][RFC6814][1]
0 0 25 25 QS-Inicio rápido [RFC4782]
0 0 treinta treinta EXP - Experimento estilo RFC3692 [2] [RFC4727]
0 2 treinta 94 EXP - Experimento estilo RFC3692 [2] [RFC4727]
una 0 treinta 158 EXP - Experimento estilo RFC3692 [2] [RFC4727]
una 2 treinta 222 EXP - Experimento estilo RFC3692 [2] [RFC4727]

Agotamiento del espacio de direcciones

Ya en la década de 1980, se hizo evidente que la distribución del espacio de direcciones estaba ocurriendo a un ritmo mucho más rápido que el que estaba integrado en la arquitectura IPv4. Esto condujo primero al direccionamiento con clase , luego al direccionamiento sin clase y, finalmente, al desarrollo del nuevo protocolo IPv6 .

En febrero de 2011, IANA asignó los últimos 5 bloques de direcciones a los RIR . Los bloques de direcciones IP gratuitas comenzaron a agotarse en los registradores regionales desde 2011 [19] .

El 25 de noviembre de 2019 se distribuyeron las últimas direcciones IPv4 gratuitas en Europa, los países de la antigua URSS y Oriente Medio [20] . Ahora será posible obtener una dirección IPv4 solo si el propietario actual la libera; por ejemplo, una empresa cierra o una red libera un recurso de dirección que no necesita.

Véase también

Notas

  1. 1 2 3 RFC3330: Direcciones IPv4 de uso especial Archivado el 14 de diciembre de 2011 en Wayback Machine  ; reemplazado por RFC5735 : direcciones IPv4 de uso especial Archivado el 15 de mayo de 2013 en Wayback Machine . 
  2. 1 2 3 RFC1700: Números asignados Archivado el 1 de enero de 2012 en Wayback Machine . 
  3. RFC1122: Requisitos para hosts de Internet - Capas de comunicación [sección 3.2.1.3] Archivado el 15 de septiembre de 2008 en Wayback Machine . 
  4. 1 2 3 RFC1918: Asignación de direcciones para Internet privadas . Archivado el 2 de diciembre de 2011 en Wayback Machine . 
  5. 1 2 3 Un vistazo a la intranet de Corea del Norte . Consultado el 20 de octubre de 2021. Archivado desde el original el 20 de octubre de 2021.
  6. RFC3927: Configuración dinámica de direcciones locales de enlace IPv4. Archivado el 19 de enero de 2012 en Wayback Machine . 
  7. RFC 6890: Registro de direcciones de propósito especial IPv4 de la IANA. Archivado el 17 de octubre de 2012 en Wayback Machine . 
  8. 1 2 3 RFC5737: bloques de direcciones IPv4 reservados para documentación Archivado el 9 de noviembre de 2011 en Wayback Machine . 
  9. RFC3068: An anycast prefix for 6to4 relay routers Archivado el 21 de enero de 2012 en Wayback Machine . 
  10. RFC2544: Metodología de evaluación comparativa para dispositivos de interconexión de red. Archivado el 9 de noviembre de 2011 en Wayback Machine . 
  11. RFC3171: Pautas de la IANA para asignaciones de direcciones de multidifusión IPv4 . Archivado el 15 de mayo de 2012 en Wayback Machine . 
  12. RFC919: Difusión de datagramas de Internet . Archivado el 26 de noviembre de 2011 en Wayback Machine . 
  13. Stefan Savage. Práctico soporte de red para rastreo de IP . Consultado: 6 de septiembre de 2010.
  14. Como broma de April Fool , se propone que signifique la intención maliciosa del paquete (parte malvada)
  15. Números de protocolo de Internet asignados Archivado el 13 de junio de 2018 en Wayback Machine . 
  16. Computing the Internet Checksum Archivado el 9 de junio de 2011 en Wayback Machine . 
  17. NÚMEROS DE OPCIÓN DE IP . IANA. Consultado el 17 de junio de 2018. Archivado desde el original el 25 de octubre de 2018.
  18. 1 2 3 4 5 6 7 RFC791: Protocolo de Internet Archivado el 30 de julio de 2019 en Wayback Machine . 
  19. Informe de direcciones IPv4 . Consultado el 16 de febrero de 2011. Archivado desde el original el 1 de abril de 2009.
  20. Fecha de publicación: 25 de noviembre de 2019- noticias, ipv4, Agotamiento de Ipv4, ipv6, Comunicado de prensa. El RIPE NCC se quedó sin direcciones IPv4 . Centro de Coordinación de la Red RIPE. Consultado el 27 de noviembre de 2019. Archivado desde el original el 25 de noviembre de 2019.