Vous êtes sur la page 1sur 7

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 fue la primera versión implementada para la producción
de ARPANET, en 1983. Definida en el RFC 791. IPv4 usa direcciones de 32 bits,
limitándola a {\displaystyle 2^{32}} 2^{{32}} = 4 294 967 296 direcciones únicas,
muchas de las cuales están dedicadas a redes locales (LAN).1 Por el crecimiento
enorme que ha tenido Internet (mucho más de lo que esperaba, cuando se diseñó
IPv4), combinado con el hecho de que hay desperdicio de direcciones en muchos casos
(ver abajo), ya hace varios años se vio que escaseaban las direcciones IPv4.

Esta limitación ayudó a estimular el impulso hacia IPv6, que a 2016 está en las
primeras fases de implantación, y se espera que termine reemplazando a 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 deben, desde ahora, manejarse con sus propias
reservas, que se estima, alcanzaran hasta el 2020.
Direccionamiento

Descomposición de la representación de la dirección IPv4 de cuatro puntos a su


valor binario.
IPv4 utiliza direcciones de 32 bits que limitan el espacio de direcciones a
42.934.967.296 (232) direcciones.

IPv4 reserva bloques de direcciones especiales para redes privadas (~18 millones de
direcciones) y direcciones de multidifusión (~270 millones de direcciones).

Representaciones de direcciones
Las direcciones IPv4 pueden representarse en cualquier notación que exprese un
valor entero de 32 bits. La mayoría de las veces se escriben en la notación decimal
de puntos, que consta de cuatro octetos de la dirección expresada 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 de puntos como 0xC0.0x00.0x02.0xEB,
o con valores de octal 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 el
identificador de host 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 hosts. 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.
CIDR fue diseñado para permitir la repartición de cualquier espacio de direcciones,
de modo que se puedan asignar bloques de direcciones más pequeños o más grandes a
los usuarios. La estructura jerárquica creada por CIDR es administrada por la
Autoridad de Números Asignados de Internet (IANA) y los registros regionales de
Internet (RIR). Cada RIR mantiene una base de datos WHOIS 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 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.

Bloques de direcciones especiales


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 actual4 (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 compartido6 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 local7l 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 Used for
local communications within a private network.5
192.0.0.0/24 192.0.0.0–192.0.0.255 1.048.576 Red privada IETF Protocol
Assignments.4
192.0.2.0/24 192.0.2.0–192.0.2.255 256 Documentación Assigned as TEST-
NET-1, documentation and examples.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, 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, 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).
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).
255.255.255.255/32 255.255.255.255 1 Subred Resevada para destinos
multidifusión.414
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, pero
requieren la traducción de direcciones de red en una puerta de enlace de
enrutamiento para este propósito.

Reserved private IPv4 network ranges5


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 16777216 Single Class
A.
bloque de 20-bit 172.16.0.0/12 172.16.0.0 – 172.31.255.255 1048576
Contiguous range of 16 Class B blocks.
bloque de 16-bit 192.168.0.0/16 192.168.0.0 – 192.168.255.255 65536 Contiguous
range of 256 Class C blocks.
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
Artículo principal: Automatic Private Internet Protocol Addressing
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
Artículo principal: 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
Artículo principal: Domain Name System
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 sólo 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 sólo 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 router recibe un paquete, éste 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 router tendrá que fragmentar dicho paquete.

El router 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 router 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. Éstos múltiplos son
0,370,555,740…

Es posible que un paquete sea fragmentado en un router y éstos a su vez sean


fragmentados en otro router. 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

Detalle de una dirección IPv4, expresada en notación decimal separada por puntos.
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
«Understanding IP Addressing: Everything You Ever Wanted To Know». 3Com. Archivado
desde el original el |urlarchivo= requiere |fechaarchivo= (ayuda).
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.