IPv4
El Protocolo de Internet versión 4 (en inglés, Internet Protocol version 4, IPv4) es la cuarta versión del Internet Protocol (IP), un protocolo de interconexión de redes basados en Internet, y que fue la primera versión implementada en 1983 para la producción de ARPANET. Definida en el RFC 791, el IPv4 usa direcciones de 32 bits, limitadas a = 4 294 967 296 direcciones únicas, muchas de ellas LAN.[1] Por el crecimiento enorme que ha tenido la seguridad electrónica y la automatización, combinado con el hecho de que hay desperdicio de direcciones en muchos casos (consultar las secciones que siguen), ya hace varios años se observó que escaseaban las direcciones IPv4.
Esta limitación ayudó a estimular el estudio sobre la factibilidad de implantación de un nuevo protocolo IPv6, que en el año 2016 ya estaba en las primeras fases de pruebas, y que terminaría reemplazando al protocolo IPv4.
Las direcciones disponibles en la reserva global de IANA pertenecientes al protocolo IPv4 se agotaron oficialmente el lunes 31 de enero de 2011.[2] Los Registros Regionales de Internet deberieron manejarse, desde ese momento, con sus propias reservas, que se estimaba alcanzarían hasta el año 2020 y no por mucho más tiempo.
Direccionamiento
El IPv4 utiliza direcciones de 32 bits que limitan el espacio de direcciones a 4 294 967 296 (232) direcciones posibles.
El IPv4 (Protocolo de Internet versión 4) reserva bloques de direcciones especiales para redes privadas (en total 16 777 216 direcciones, o sea, (224), así como direcciones de multidifusión (268 435 456 direcciones, o sea, 228).
Representaciones de direcciones
Las direcciones IPv4 pueden representarse en cualquier notación que exprese un valor entero de 32 bits. La mayoría de las veces se escriben en la notación decimal, la que consta de cuatro octetos de la dirección expresada individualmente en números decimales, y separados uno del siguiente 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 de puntos como 0xC0.0x00.0x02.0xEB, o con valores en formato octal 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 a la dirección le sigue un carácter de barra (/) y el conteo de 1 bits consecutivos en el prefijo de enrutamiento (máscara de subred).
Asignación
En el diseño original de IPv4, una dirección IP se dividió en dos partes: el identificador de red era el octeto más significativo de la dirección, y por su parte, el identificador de host (anfitrión o huésped) era el resto de la dirección. Este último también fue llamado el campo de descanso. Esta estructura permitía un máximo de 256 identificadores de red, que rápidamente se encontró que eran inadecuados.
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 usó 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 a sus huéspedes. Además de las tres clases para direccionar hosts, la Clase D se definió para el direccionamiento de multidifusión, y la Clase E se reservó para aplicaciones futuras.
La división de las redes con clase existentes en subredes comenzó en 1985 con la publicación del RFC 950. Esta división se hizo más flexible con la introducción de máscaras de subred de longitud variable (VLSM) en el RFC 1109 en 1987. En 1993, basado en este trabajo, el RFC 1517 introdujo el Classless Inter-Domain Routing (CIDR),[3] que expresa el número de bits (de los más significativos) como, por ejemplo, /24, y el esquema basado en clases se denominaba con clase, en contraste. El CIDR fue diseñado para permitir la repartición de cualquier espacio de direcciones, de modo que se pudieran asignar bloques de direcciones más pequeños o más grandes a los distintos usuarios. La estructura jerárquica creada por el CIDR fue administrada por la Autoridad de Números Asignados de Internet (IANA) y los registros regionales de Internet (RIR). Cada RIR mantiene una base de datos WHOIS de búsqueda pública, la 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 Autoridad de Números Asignados de Internet (IANA) han restringido el uso general de varias direcciones IP reservadas para fines especiales. En particular, estas direcciones se utilizan para el tráfico de multidifusión y para proporcionar espacio de direccionamiento para usos no restringidos en redes privadas.
| Bloque de direcciones | Rango | Número de direcciones | Alcance | Descripción |
|---|---|---|---|---|
| 0.0.0.0/8 | 0.0.0.0–0.255.255.255 | 16.777.216 | Software | Red actual[4] (solo válido como dirección de origen). |
| 10.0.0.0/8 | 10.0.0.0–10.255.255.255 | 16.777.216 | Red privada | Utilizado para las comunicaciones locales dentro de una red privada.[5] |
| 100.64.0.0/10 | 100.64.0.0–100.127.255.255 | 4.194.304 | Red privada | Espacio de direcciones compartido[6] para las comunicaciones entre un proveedor de servicios y sus suscriptores 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 | Host | Se utiliza para las direcciones de loopback.[4] |
| 169.254.0.0/16 | 169.254.0.0–169.254.255.255 | 65.536 | Subred | Se utiliza para las direcciones de enlace local[7]l entre dos hosts en un solo enlace cuando de otra manera no se especifica una dirección IP, como normalmente se habría recuperado de un servidor DHCP. |
| 172.16.0.0/12 | 172.16.0.0–172.31.255.255 | 1.048.576 | Red privada | Utilizado para las comunicaciones locales dentro de una red privada.[5] |
| 192.0.0.0/24 | 192.0.0.0–192.0.0.255 | 256 | Red privada | IETF Protocol Assignments.[4] |
| 192.0.2.0/24 | 192.0.2.0–192.0.2.255 | 256 | Documentación | Asignada como TEST-NET-1, para documentación y ejemplos.[8] |
| 192.88.99.0/24 | 192.88.99.0–192.88.99.255 | 256 | Internet | Reservada.[9] Previamente usado para relay IPv6 a IPv4.[10] (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 | Utilizado para las comunicaciones locales dentro de una red privada.[5] |
| 198.18.0.0/15 | 198.18.0.0–198.19.255.255 | 131.072 | Red privada | Se utiliza para pruebas de referencia de comunicaciones entre dos subredes separadas.[11] |
| 198.51.100.0/24 | 198.51.100.0–198.51.100.255 | 256 | Documentación | Asignado como TEST-NET-2, para documentación y ejemplos.[8] |
| 203.0.113.0/24 | 203.0.113.0–203.0.113.255 | 256 | Documentación | Asignado como TEST-NET-3, para documentación y ejemplos.[8] |
| 224.0.0.0/4 | 224.0.0.0–239.255.255.255 | 268.435.456 | Internet | Usado para Multicast IP.[12] (previamente una red clase D). (Experimental) |
| 240.0.0.0/4 | 240.0.0.0–255.255.255.254 | 268.435.456 | Internet | Reservada para usos futuros.[13] (anteriormente una red clase E). (Experimental) |
| 255.255.255.255/32 | 255.255.255.255 | 1 | Subred | Reservada para destinos multidifusión.[4][14] |
Redes privadas
De los aproximadamente cuatro mil millones de direcciones definidas en IPv4, cerca de 18 millones de direcciones en tres rangos están reservadas para su uso en redes privadas. Las direcciones de paquetes en estos rangos no son enrutables en la Internet pública; son ignorados por todos los enrutadores públicos. Por lo tanto, los hosts privados no pueden comunicarse directamente con las redes públicas y requieren la traducción de direcciones de red en una puerta de enlace de enrutamiento para este propósito.
| Nombre | Bloque CIDR | Rango de direcciones | Número de direcciones | Clase |
|---|---|---|---|---|
| bloque de 24-bit | 10.0.0.0/8 | 10.0.0.0 – 10.255.255.255 | 16 777 216 | Clase A. |
| bloque de 20-bit | 172.16.0.0/12 | 172.16.0.0 – 172.31.255.255 | 1 048 576 | Rango contiguo de 16 bloques de clase B. |
| bloque de 16-bit | 192.168.0.0/16 | 192.168.0.0 – 192.168.255.255 | 65 536 | Rango contiguo de 256 bloques de 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 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 se pueden cifrar para que la transmisión a través de redes públicas asegure los datos.
Direcciones de enlace-local
La RFC 3927 define el bloque de dirección especial 169.254.0.0/16 para el direccionamiento de enlace-local. Estas direcciones solo son válidas en enlaces (como un segmento de red local o conexión punto a punto) conectados a un host. Estas direcciones no son enrutables. Al igual que las direcciones privadas, estas direcciones no pueden ser el origen o 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 de enlace local IPv4.
Loopback
La red de clase A 127.0.0.0 (red sin clase 127.0.0.0/8) está reservada para loopback. Los paquetes IP cuyas direcciones de origen pertenecen a esta red nunca deben aparecer fuera de un host. El modus operandi de esta red se expande sobre el de una interfaz de loopback:
- Los paquetes IP cuyas direcciones de origen y destino pertenecen a la red (o subred) de la misma interfaz de loopback se devuelven a esa interfaz;
- Los paquetes IP cuyas direcciones de origen y destino pertenecen a redes (o subredes) de diferentes interfaces del mismo host, uno de los cuales es una interfaz de loopback, se reenvían regularmente.
Direcciones terminadas en 0 o 255
Es posible que las redes con máscaras de subred de al menos 24 bits, es decir, redes Clase C en redes con clase, y redes con sufijos CIDR /24 a /30 (255.255.255.0–255.255.255.252) no tengan una dirección que termine en 0 o 255.
El direccionamiento con clase prescribió solo tres posibles máscaras de subred: Clase A, 255.0.0.0 o /8; Clase B, 255.255.0.0 o /16; y Clase C, 255.255.255.0 o /24. Por ejemplo, en la subred 192.168.5.0/255.255.255.0 (192.168.5.0/24) el identificador 192.168.5.0 se usa comúnmente para referirse a la subred completa. Para evitar la ambigüedad en la representación, la dirección que termina en el octeto 0 está reservada.
Una dirección multidifusión es una dirección que permite que la información se envíe a todas las interfaces en una subred determinada, en lugar de a una máquina específica. En general, la dirección de difusión se encuentra obteniendo el complemento de bits de la máscara de subred y realizando una operación OR a nivel de bits con el identificador de red. En otras palabras, la dirección de transmisión es la última dirección en el rango de direcciones de la subred. Por ejemplo, la dirección de transmisión para la red 192.168.5.0 es 192.168.5.255. Para redes de tamaño /24 o más, la dirección de transmisión siempre termina en 255.
| Forma binaria | Notación decimal | |
|---|---|---|
| Espacio de red | 11000000.10101000.00000101.00000000 | 192.168.5.0 |
| Direcciones de difusión | 11000000.10101000.00000101.11111111 | 192.168.5.255 |
| En negrita, se muestra la parte del host de la IP; La otra parte es el prefijo de red. El host se invierte (NO lógico), pero el prefijo de red permanece intacto. | ||
Sin embargo, esto no significa que todas las direcciones que terminen en 0 o 255 no puedan usarse como una 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 con 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.[15] Las direcciones 192.168.1.0, 192.168.2.0, etc., pueden asignarse, a pesar de terminar con 0.
En el pasado, surgía un conflicto entre las direcciones de red y las direcciones de difusión porque algunos programas utilizaban direcciones de difusión no estándar con ceros en lugar de unos.[16]
En redes más pequeñas que /24, las direcciones de difusión no terminan necesariamente con 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 | |
|---|---|---|
| Espacio de red | 11001011.00000000.01110001.00010000 | 203.0.113.16 |
| Direcciones de difusión | 11001011.00000000.01110001.00011111 | 203.0.113.31 |
| En negrita, se muestra la parte del host de la IP; La otra parte es el prefijo de red. El host se invierte (NO lógico), pero el prefijo de red permanece intacto. | ||
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 usa para el enrutamiento y la identificación de la interfaz de red. El uso de nombres de dominio requiere la traducción, llamada resolución, a direcciones y viceversa. Esto es análogo a buscar un número de teléfono en una guía telefónica con el nombre del destinatario.
La traducción entre las direcciones y los nombres de dominio se realiza mediante el Sistema de nombres de dominio (DNS), un sistema de nombres jerárquico y distribuido que permite la subdelegación de espacios de nombres a otros servidores DNS.
Fragmentación y Reensamblaje
El Protocolo de Internet (IP) permite a las redes comunicarse unas con otras. El diseño acomoda redes de naturalezas físicas diversas; es independiente de la tecnología usada en la capa inmediatamente inferior, la Capa de Enlace. Las redes con diferente hardware difieren usualmente no solo en velocidad de transmisión, sino que también en su Unidad Máxima de Transmisión (MTU). Cuando una red quiere transmitir datagramas a una red con un MTU inferior, debe fragmentar sus datagramas. En IPv4, esta función es realizada en la capa de Intenet, y es llevada a cabo en routers IPv4, los cuales solo requieren esta capa como la más alta implementada en su diseño.
En contraposición, IPv6, la nueva generación del Protocolo de Internet, no permite a los routers a llevar a cabo dicha fragmentación; los hosts son los que determinan el MTU antes de enviar datagramas.
Fragmentación
Cuando un enrutador recibe un paquete, este examina la dirección de destino y determina la interfaz de salida a utilizar y el MTU de ella. Si el tamaño del paquete es mayor que el MTU y el bit de No Fragmentación (DF) es 0 en la cabecera del paquete, el enrutador tendrá que fragmentar dicho paquete.
El enrutador divide el paquete en fragmentos. El tamaño máximo de cada fragmento es el MTU menos el tamaño de la cabecera IP (entre 20 y 60 bytes). El enrutador pone cada fragmento dentro de su paquete. Estos fragmentos reciben los siguientes cambios:
- El campo de total size es el tamaño de fragmento.
- La bandera de more fragments (MF) es igual a 1 en todos los paquetes excepto en el último.
- El campo fragment offset está activado, basado en el offset del fragmento en la carga de datos original. Es medido en unidades de bloques de 8 bytes.
- El campo header checksum es recomputado.
Por ejemplo, para un MTU de 1500 bytes y un tamaño de cabecera de 20 bytes, los offsets del fragmentos serían múltiplos de (1500-20)/8 = 185. Estos múltiplos son 0,370,555,740…
Es posible que un paquete sea fragmentado en un enrutador y estos a su vez sean fragmentados en otro enrutador. Por ejemplo, supongamos una Capa de Transporte con un tamaño de 4500 bytes, sin opciones, y un tamaño de cabecera IP de 20 bytes. Así, el tamaño de paquete sería de 4520 bytes.
Asumiendo que el paquete viaja en un enlace con un MTU de 2500 bytes, quedaría algo talque así:
| Fragmento | Tamaño en Bytes | Bytes de la cabecera | Bytes de datos | Bandera “Más Fragmentos” | Offset del fragmentos (bloques de 8 bytes) |
|---|---|---|---|---|---|
| 1 | 2500 | 20 | 2480 | 1 | 0 |
| 2 | 2040 | 20 | 2020 | 0 | 310 |
Observar que los fragmentos conservan el tamaño de datos: 2480 + 2020 = 4500 Bytes.
Observar también cómo averiguar los offsets del tamaño de datos:
- 0
- 0 + 2480/8 = 310.
Asumiendo que estos fragmentos alcanzan un enlace con un MTU de 1500 bytes. Cada fragmento se convertiría en dos fragmentos:
| Fragmento | Tamaño en Bytes | Bytes de la cabecera | Bytes de datos | Bandera “Más Fragmentos” | Offset del fragmentos (bloques de 8 bytes) |
|---|---|---|---|---|---|
| 1 | 1500 | 20 | 1480 | 1 | 0 |
| 2 | 1020 | 20 | 1000 | 1 | 185 |
| 3 | 1500 | 20 | 1480 | 1 | 310 |
| 4 | 560 | 20 | 540 | 0 | 495 |
Observar que los fragmentos conservan el tamaño de datos:
- 1480 + 1000 = 2480 Bytes
- 1480+540 = 2020 Bytes
Observar también que el bit de “Más Fragmentos” permanece a 1 para todos los fragmentos que vinieron con dicho 1 y que al llegar al último fragmento, dicho bit se establecerá a 0. Por supuesto, el campo de Identificación continúa con el mismo valor en todos los fragmentos refragmentados. De esta forma, incluso si los fragmentos son re-fragmentados, el receptor sabe que inicialmente todos empezaron en el mismo paquete.
Observar cómo conseguimos los offsets de los tamaños de datos:
- 0.
- 0 + 1480/8 = 185.
- 185 + 1000/8 = 310.
- 310 + 1480/8 = 495.
Podemos utilizar el último offset y el último tamaño de datos para calcular el tamaño total: 495*8 + 540 = 4500
3960 + 540 = 4500.
Reensamblaje
Un receptor sabe que un paquete es un fragmento si se cumple al menos una de las siguientes condiciones:
- La bandera de “Más Fragmentos” está activada (= 1). (Esto se cumple para todos los fragmentos excepto para el último).
- El offset del fragmento es distinto de 0. (Esto se cumple para todos los fragmentos menos para el primero).
El receptor identifica fragmentos coincidentes utilizando direcciones locales y foráneas, el protocolo ID y el campo Identificación. El receptor reensamblará los datos de fragmentos con el mismo ID utilizando tanto el offset del fragmento como la bandera de “Más Fragmentos”. Cuando el receptor recibe el último fragmento (que tiene la bandera de “Más Fragmentos” a 0), puede calcular la longitud de la carga útil de datos, multiplicando el offset del último fragmento por 8 y añadiendo su tamaño de datos también. En el ejemplo superior, este cálculo es de 495 x 8 + 540 = 4500 Bytes.
Cuando el receptor tiene todos los fragmentos, puede colocarlos de nuevo en el orden correcto utilizando los offsets para ello.
Será entonces cuando puede pasar sus datos a la pila para su posterior proceso.
Representación de direcciones
Las direcciones IPv4 se pueden escribir de forma que expresen un entero de 32 bits, aunque normalmente se escriben con decimales separados por puntos. A estos números decimales de 3 dígitos se les llama "octetos", porque en binario requieren de 8 dígitos (8 bits) para ser representados. La siguiente tabla muestra varias formas de representación de direcciones IPv4:
| Notación | Valor | Conversión desde decimal separado por puntos |
|---|---|---|
| Decimal separada por puntos | 192.0.2.235 | - |
| Hexadecimal separada por puntos | 0xC0.0x00.0x02.0xEB | Cada octeto se convierte individualmente a la forma hexadecimal |
| Octal separada por puntos | 0301.1680.0002.0353 | Cada octeto se convierte de individualmente en octal |
| Hexadecimal | 0xC00002EB | Concatenación de octetos de la forma hexadecimal separada por puntos |
| Decimal | 3221226219 | El número hexadecimal expresado en decimal |
| Octal | 030000001353 | El número hexadecimal expresado en octal |
Desperdicio de direcciones
El desperdicio de direcciones IPv4 se debe a varios factores.
Uno de los principales es que inicialmente no se consideró el enorme crecimiento que iba a tener Internet; se asignaron bloques de direcciones grandes (de 16 271 millones de direcciones) a países, e incluso a empresas.
Otro motivo de desperdicio es que en la mayoría de las redes, exceptuando las más pequeñas, resulta conveniente dividir la red en subredes. Dentro de cada subred, la primera y la última dirección no son utilizables; de todos modos no siempre se utilizan todas las direcciones restantes. Por ejemplo, si en una subred se quieren acomodar 80 hosts, se necesita una subred de 128 direcciones (se debe redondear a la siguiente potencia en base 2), en este ejemplo, las 48 direcciones IP restantes ya no se utilizan.
Referencias
- http://tools.ietf.org/html/rfc1918
- http://www.enterprisenetworkingplanet.com/news/article.php/3923391/IPv4+Officially+Depleted,+Eyes+on+IPv6.htm
- . 3Com. Archivado desde el original el 16 de junio de 2001.
- ↑ Special-Purpose IP Address Registries, doi:10.17487/RFC6890, BCP 153. RFC 6890. Updated by RFC 8190.
- ↑ Address Allocation for Private Internets, doi:10.17487/RFC1918, BCP 5. RFC 1918. Updated by RFC 6761.
- IANA-Reserved IPv4 Prefix for Shared Address Space, doi:10.17487/RFC6598, BCP 153. RFC 6598.
- Dynamic Configuration of IPv4 Link-Local Addresses, doi:10.17487/RFC3927, RFC 3927.
- ↑ IPv4 Address Blocks Reserved for Documentation, doi:10.17487/RFC5737, RFC 5737.
- Deprecating the Anycast Prefix for 6to4 Relay Routers, doi:10.17487/RFC7526, BCP 196. RFC 7526.
- An Anycast Prefix for 6to4 Relay Routers, doi:10.17487/RFC3068, RFC 3068. Obsoleted by RFC 7526.
- Benchmarking Methodology for Network Interconnect Devices, doi:10.17487/RFC2544, RFC 2544. Updated by: RFC 6201 and RFC 6815.
- IANA Guidelines for IPv4 Multicast Address Assignments, doi:10.17487/RFC5771, BCP 51. RFC 5771.
- Assigned Numbers: RFC 1700 is Replaced by an On-line Database, doi:10.17487/RFC3232, RFC 3232. Obsoletes RFC 1700.
- Broadcasting Internet Datagrams, doi:10.17487/RFC0919, RFC 919.
- Robert Braden (October 1989). «Requirements for Internet Hosts – Communication Layers». IETF. p. 31. RFC 1122.
- Robert Braden (October 1989). «Requirements for Internet Hosts – Communication Layers». IETF. p. 66. RFC 1122.