Ver el código de «IPv4»

El '''Protocolo de Internet versión 4''' ({{lang-en|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 [[bit]]s, limitadas a <math>2^{32}</math> = 4&nbsp;294&nbsp;967&nbsp;296 direcciones únicas, muchas de ellas [[Red de área local|LAN]].<ref>http://tools.ietf.org/html/rfc1918</ref> 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 [[Agotamiento de las direcciones IPv4|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 jueves 3 de febrero de 2011.<ref name="noticia1">{{Cita web|url=https://www.arin.net/vault/announcements/20110203/|título=El fondo libre de direcciones IPv4 de la IANA se ha agotado|fechaacceso=2025-02-02|apellido=ARIN|fecha=2011-02-03|sitioweb=www.arin.net|idioma=en-us}}</ref> Los Registros Regionales de Internet debieron 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 ==

[[Archivo:IPv4 address structure and writing systems-en.svg|derecha |300px |thumb |Descomposición de la representación de la dirección IPv4 de cuatro valores, a su equivalente [[Sistema binario|binario]].]]

El IPv4 utiliza direcciones de 32 bits que limitan el [[espacio de direcciones]] a {{formatnum|4294967296}} (2<sup>32</sup>) direcciones posibles. 

El IPv4 (Protocolo de Internet versión 4) reserva bloques de direcciones especiales para [[Red privada|redes privadas]] (en total {{formatnum|16777216}} direcciones, o sea, (2<sup>24</sup>), así como direcciones de [[Multidifusión IP|multidifusión]] ({{formatnum|268435456}} direcciones, o sea, 2<sup>28</sup>).

=== 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 [[Sistema de numeración decimal|notación decimal]], la que consta de cuatro [[Byte|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 [[Classless Inter-Domain Routing|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 [[Request for Comments|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),<ref>{{cite web|url=http://www.3com.com/other/pdfs/infra/corpinfo/en_US/501302.pdf|title=Understanding IP Addressing: Everything You Ever Wanted To Know|publisher=3Com|archive-url=https://web.archive.org/web/20010616012053/http://www.3com.com/other/pdfs/infra/corpinfo/en_US/501302.pdf|fechaarchivo=2001-06-16|dead-url=yes}}</ref> 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 [[Internet Assigned Numbers Authority|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.<section begin="Direcciones de uso especial" /><!-- This table is transcluded to other pages, such as [[Reserved IP addresses]]. (see: [[Wikipedia:Transclusion]]) -->

{| class="wikitable"
|+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
| align="right" |16.777.216
|Software
|Red actual<ref name="rfc6890">{{Cite IETF|rfc=6890|bcp=153|title=Special-Purpose IP Address Registries|author1=M. Cotton|author2=L. Vegoda|author3=R. Bonica|author4=B. Haberman|date=April 2013|publisher=[[Internet Engineering Task Force]]}} Updated by RFC 8190.</ref> (solo válido como dirección de origen).
|-
|10.0.0.0/8
|10.0.0.0–10.255.255.255
| align="right" |16.777.216
|Red privada
|Utilizado para las comunicaciones locales dentro de una [[red privada]].<ref name="rfc1918">{{Cite IETF|rfc=1918|bcp=5|title=Address Allocation for Private Internets|author1=Y. Rekhter|author2=B. Moskowitz|author3=D. Karrenberg|author4=G. J. de Groot|author5=E. Lear|date=February 1996|publisher=Network Working Group}} Updated by RFC 6761.</ref>
|-
<!-- Note: 14.0.0.0/8, 24.0.0.0/8 and 39.0.0.0/8 are outdated and irrelevant. Do not add them. {{Citation needed}}-->
|100.64.0.0/10
|100.64.0.0–100.127.255.255
| align="right" |4.194.304
|Red privada
|Espacio de direcciones compartido<ref name="rfc6598">{{Cite IETF|rfc=6598|bcp=153|title=IANA-Reserved IPv4 Prefix for Shared Address Space|author1=J. Weil|author2=V. Kuarsingh|author3=C. Donley|author4=C. Liljenstolpe|author5=M. Azinger|date=April 2012|publisher=[[Internet Engineering Task Force]] (IETF)|issn=2070-1721}}</ref> 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
| align="right" |16.777.216
|Host
|Se utiliza para las [[Loopback|direcciones de loopback]].<ref name="rfc6890"/>
|-
<!-- Note: 128.0.0.0/16 is "no longer needed" and "subject to future allocation" so it is not relevant here. {{Citation needed}}-->
<!-- "Note that 128.66.0.0/24 has been used for some examples in the past. However, this block did not appear in the list of special prefixes in RFC 3330 or its successors, and the block is therefore not reserved for any special purpose. The block can be used for regular address assignments with caution." excerpt from RFC 5737. -->
|169.254.0.0/16
|169.254.0.0–169.254.255.255
| align="right" |65.536
|Subred
|Se utiliza para las [[Dirección de Enlace-Local|direcciones de enlace loca]]<nowiki/>[[Dirección de Enlace-Local|l]]<ref name="rfc3927">{{Cite IETF|rfc=3927|title=Dynamic Configuration of IPv4 Link-Local Addresses|author1=S. Cheshire|author2=B. Aboba|author3=E. Guttman|publisher=Network Working Group|date=May 2005}}</ref> 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 [[Protocolo de configuración dinámica de host|DHCP]].<br />
|-
|172.16.0.0/12
|172.16.0.0–172.31.255.255
| align="right" |1.048.576
|Red privada
|Utilizado para las comunicaciones locales dentro de una red privada.<ref name="rfc1918" />
|-
<!-- Note: 191.255.0.0/16 and 192.0.0.0/24 is "no longer needed" and "subject to future allocation" so it is not relevant here. -->
|-
|192.0.0.0/24
|192.0.0.0–192.0.0.255
| align="right" |256
|Red privada
|IETF Protocol Assignments.<ref name="rfc6890"/>
|-
|192.0.2.0/24
|192.0.2.0–192.0.2.255
| align="right" |256
|Documentación
|Asignada como TEST-NET-1, para documentación y ejemplos.<ref name="rfc5737">{{Cite IETF|rfc=5737|title=IPv4 Address Blocks Reserved for Documentation|author1=J. Arkko|author2=M. Cotton|author3=L. Vegoda|publisher=[[Internet Engineering Task Force]]|date=January 2010|issn=2070-1721}}</ref>
|-
|192.88.99.0/24
|192.88.99.0–192.88.99.255
| align="right" |256
|Internet
|Reservada.<ref name="rfc7526">{{Cite IETF|rfc=7526|bcp=196|title=Deprecating the Anycast Prefix for 6to4 Relay Routers|author1=O. Troan|editor=B. Carpenter|publisher=[[Internet Engineering Task Force]]|date=May 2015}}</ref> Previamente usado para ''relay'' [[6to4|IPv6 a IPv4]].<ref name="rfc3068">{{Cite IETF|rfc=3068|title=An Anycast Prefix for 6to4 Relay Routers|author=C. Huitema|publisher=Network Working Group|date=June 2001}} Obsoleted by RFC 7526.</ref> (incluido el bloque de direcciones [[IPv6]] [[IPv6 Address#Special addresses|2002::/16]]).
|-
|192.168.0.0/16
|192.168.0.0–192.168.255.255
| align="right" |65.536
|Red privada
|Utilizado para las comunicaciones locales dentro de una red privada.<ref name="rfc1918" />
|-
|198.18.0.0/15
|198.18.0.0–198.19.255.255
| align="right" |131.072
|Red privada
|Se utiliza para pruebas de referencia de comunicaciones entre dos subredes separadas.<ref name="rfc2544">{{Cite IETF|rfc=2544|title=Benchmarking Methodology for Network Interconnect Devices|author1=S. Bradner|author2=J. McQuaid|date=March 1999|publisher=Network Working Group}} Updated by: RFC 6201 and RFC 6815.</ref>
|-
|198.51.100.0/24
|198.51.100.0–198.51.100.255
| align="right" |256
|Documentación
|Asignado como TEST-NET-2, para documentación y ejemplos.<ref name="rfc5737"/>
|-
|203.0.113.0/24
|203.0.113.0–203.0.113.255
| align="right" |256
|Documentación
|Asignado como TEST-NET-3, para documentación y ejemplos.<ref name="rfc5737"/>
|-
<!-- 223.255.255.0/24 presently unused, but subject to future allocation -->
|224.0.0.0/4
|224.0.0.0–239.255.255.255
| align="right" |268.435.456
|Internet
|Usado para [[Multidifusión|Multicast IP]].<ref name="rfc5771">{{Cite IETF|rfc=5771|bcp=51|title=IANA Guidelines for IPv4 Multicast Address Assignments|author1=M. Cotton|author2=L. Vegoda|author3=D. Meyer|date=March 2010|publisher=[[Internet Engineering Task Force]]}}</ref> (previamente una red clase D). (Experimental)
|-
|240.0.0.0/4
|240.0.0.0–255.255.255.254
| align="right" |268.435.456
|Internet
|Reservada para usos futuros.<ref name="rfc3232">{{Cite IETF|rfc=3232|title=Assigned Numbers: RFC 1700 is Replaced by an On-line Database|editor=J. Reynolds|date=January 2002|publisher=Network Working Group}} Obsoletes RFC 1700.</ref> (anteriormente una red clase E). (Experimental)
|-
|255.255.255.255/32
|255.255.255.255
| align="right" |1
|Subred
|Reservada para destinos multidifusión.<ref name="rfc6890" /><ref name="rfc919">{{Cite IETF|rfc=919|title=Broadcasting Internet Datagrams|author=Jeffrey Mogul|date=Octobprer 1984|publisher=Network Working Group}}</ref>
|}<section end="Direcciones de uso especial" />

====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.
<section begin="RedesPrivadasIPv4" />
{| class="wikitable col4der"
|+ Rangos de red IPv4 reservados para redes privadas<ref name=rfc1918/>
!Nombre
!Bloque [[Classless Inter-Domain Routing|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
|{{esd|16 777 216}}
|Clase A.
|-
|bloque de 20-bit
|172.16.0.0/12
|172.16.0.0 – 172.31.255.255
|{{esd|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
|{{esd|65 536}}
|Rango contiguo de 256 bloques de clase C.
|}<section end="RedesPrivadasIPv4" />

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]] 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.<!--[[User:Kvng/RTH]]-->

===Direcciones de enlace-local===
{{Artículo principal|Automatic Private Internet Protocol Addressing}}
La <nowiki>RFC 3927</nowiki> 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 <nowiki>RFC 3927</nowiki>, titulado Configuración dinámica de direcciones de enlace local IPv4.

===''Loopback''===
{{Main article|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 [[Dominio de difusión|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.

{| class="wikitable" style="margin:left;"
! !! Forma binaria !! Notación decimal
|-
| Espacio de red
| <code>11000000.10101000.00000101.'''00000000'''</code>
| 192.168.5.0 
|-
| Direcciones de difusión
| <code>11000000.10101000.00000101.'''11111111'''</code>
| 192.168.5.255
|-
| colspan=3 |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.<ref>{{cite web
|url       = http://tools.ietf.org/html/rfc1122#page-31
|title     = Requirements for Internet Hosts&nbsp;– Communication Layers
|author     = [[Robert Braden]]
|date=October 1989
|publisher = [[Internet Engineering Task Force|IETF]]
|page      = 31
|rfc       = 1122
}}</ref> 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.<ref>{{cite web
|url       = http://tools.ietf.org/html/rfc1122#page-66
|title     = Requirements for Internet Hosts&nbsp;– Communication Layers
|author     = [[Robert Braden]]
|date=October 1989
|publisher = [[Internet Engineering Task Force|IETF]]
|page      = 66
|rfc       = 1122
}}</ref>

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.

{| class="wikitable" style="margin:left;"
! !! Forma binaria !! Notación decimal
|-
| Espacio de red
| <code>11001011.00000000.01110001.0001'''0000'''</code>
| 203.0.113.16
|-
| Direcciones de difusión
| <code>11001011.00000000.01110001.0001'''1111'''</code>
| 203.0.113.31
|-
| colspan=3 |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 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|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í:
{| class="wikitable"
!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:
{| class="wikitable"
!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 ==
[[Archivo:Ipv4 address Spanish.svg|thumb|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:

{|  class="wikitable" border="1" align="center"
|-
! 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&nbsp;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 [[subred]]es. 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 ''[[host]]s'', 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 ==

{{listaref}}

== Véase también ==

* [[Agotamiento de las direcciones IPv4]]
* [[IPv6]]
* [[Modelo OSI]]
* [[Red privada]]

{{Control de autoridades}}
[[Categoría:Protocolos de nivel de red]]
[[Categoría:Siglas de informática]]