DATAGRAMA DE

INTERNET

Módulo 3 – Unidad 3

1
3.1. DATAGRAMA DE INTERNET ......................................................................................................... 3
3.1.1. DATAGRAMA IP ....................................................................................................................... 4
3.1.2. (TIPO DE SERVICIO) .................................................................................................................14
3.1.3. TTL (TIME TO LIVE).................................................................................................................15
3.1.4. SUMA DE CONTROL .................................................................................................................16

2
3.1. Datagrama de Internet

En la presente unidad vamos a explorar y desarrollar la estructura del datagrama del

Internet Protocol (IP), el cual es utilizado en la capa de red del modelo de referencia Open
Systems Interconection (OSI).

Como ya sabemos, internet es un conjunto de redes compartiendo un grupo de protocolos,

técnicamente internet es el grupo de redes antes mencionado, que están interconectadas
entre sí basándose en el protocolo de red IP.

Una red IP utiliza datagramas, que son las unidades de datos que se intercambian entre los
dispositivos, con la ventaja que es no orientada a conexión y no ofrecen garantía de entrega
de paquetes, ya que los mismos pueden ser descartados por cualquier router que esté en
el camino que debe recorrer el paquete.

En tanto, Comer (2015) nos expresa la siguiente idea sobre los datagramas IP y las tramas:

Los protocolos TCP/IP usan el nombre datagrama de IP para referirse a un paquete de

Internet. Lo sorprendente es que un datagrama de IP tiene el mismo formato general que
una trama de hardware: el datagrama comienza con un encabezado seguido de una carga
útil (es decir, datos). La cantidad de datos que se transportan en un datagrama no es fija.
Un emisor selecciona una cantidad de datos apropiada para un fin específico.
¿Qué contiene un encabezado de datagrama? Al igual que un encabezado de trama, un
encabezado de datagrama contiene información que se utiliza para reenviar el
datagrama. En especial, el encabezado contiene la dirección de origen (el emisor original),
la dirección de destino (el receptor final) y un campo que especifica el tipo de datos que
se van a transportar en el área de carga útil. Pero a diferencia de las tramas que se envían
a través de una sola red, un datagrama no contiene direcciones MAC. En su defecto, cada
dirección en el encabezado del datagrama es una dirección IP; las direcciones MAC no
aparecen en el datagrama. (p. 370)
En la siguiente imagen, vemos cómo se encapsula un datagrama de internet en una trama
Ethernet, es decir, que el datagrama viaja dentro de la trama física.

3
 Imagen 1: Encapsulamiento de datagrama IP en trama ethernet
Fuente: Douglas E. Comer (2015, p. 379)

3.1.1. Datagrama IP

Para adentrarnos en el mundo de las direcciones IP, es importante recordar que las
direcciones lógicas se componen de 0 y 1. Pero antes de entrar en detalle, debemos saber
que la información que se maneja a este nivel es transportada en datagramas cuya
estructura es más compleja que una trama Ethernet y que consta de dos partes
fundamentales, que son: el encabezado y el cuerpo.

En la siguiente imagen vemos la estructura que tiene un datagrama IP, junto con los campos
que los componen:

Imagen 2: Datagrama IP v4
Fuente: Tanenmaum (2012, p. 376).

4
A continuación, Tanenbaum (2012) nos describen cada uno de los campos, su uso y cuáles
son prescindibles y cuáles no:

El campo Versión lleva el registro de la versión del protocolo al que pertenece el

datagrama. La versión 4 es la que domina Internet en la actualidad, y ahí es donde
empezamos nuestro estudio. Al incluir la versión al inicio de cada datagrama, es posible
tener una transición entre versiones a través de un largo periodo de tiempo. De hecho,
IPv6 (la siguiente versión de IP) se definió hace más de una década y apenas se está
empezando a implementar. Lo describiremos más adelante en esta sección. En un
momento dado nos veremos obligados a usarlo cuando cada uno de los casi 231
habitantes de China tenga una PC de escritorio, una computadora portátil y un teléfono
IP. Como observación adicional en cuanto a la numeración, IPv5 fue un protocolo de flujo
experimental en tiempo real que nunca fue muy popular.
Dado que la longitud del encabezado no es constante, se incluye un campo en el
encabezado (IHL) para indicar su longitud en palabras de 32 bits. El valor mínimo es de 5,
cifra que se aplica cuando no hay opciones. El valor máximo de este campo de 4 bits es
15, lo que limita el encabezado a 60 bytes y, por lo tanto, el campo Opciones a 40 bytes.
Para algunas opciones, por ejemplo, una que registre la ruta que ha seguido un paquete,
40 bytes es muy poco, lo que hace inútiles estas opciones.
El campo de Servicio diferenciado es uno de los pocos campos que ha cambiado su
significado (ligeramente) con el transcurso de los años. En un principio el nombre de este
campo era Tipo de servicio. Su propósito era, y aún es, distinguir entre las diferentes
clases de servicios. Son posibles varias combinaciones de confiabilidad y velocidad. Para
voz digitalizada, la entrega rápida le gana a la entrega precisa. Para la transferencia de
archivos, es más importante la transmisión libre de errores que la transmisión rápida. El
campo Tipo de servicio contaba con 3 bits para indicar la prioridad y 3 bits para indicar si
a un host le preocupaba más el retardo, la velocidad de transmisión real o la confiabilidad.
Sin embargo, nadie sabía realmente qué hacer con estos bits en los enrutadores, por lo
que se quedaron sin uso durante muchos años. Cuando se diseñaron los servicios
diferenciados, la IETF tiró la toalla y reutilizó este campo. Ahora, los 6 bits superiores se
utilizan para marcar el paquete con su clase de servicio; anteriormente en este capítulo
describimos los servicios expedito y asegurado. Los 2 bits inferiores se utilizan para
transportar información sobre la notificación de congestión; por ejemplo, si el paquete
ha experimentado congestión o no. Asimismo, también describimos la notificación
explícita de congestión como parte del control de la congestión.
El campo Longitud total incluye todo en el datagrama: tanto el encabezado como los
datos. La longitud máxima es de 65 535 bytes. En la actualidad este límite es tolerable,
pero con las redes futuras tal vez se requieran datagramas más grandes.
El campo Identificación es necesario para que el host de destino determine a qué paquete
pertenece un fragmento recién llegado. Todos los fragmentos de un paquete contienen
el mismo valor de Identificación.

5
A continuación, viene un bit sin uso, lo cual es sorprendente, ya que el espacio en el
encabezado IP es muy escaso. Como broma del día de los inocentes, Bellovin (2003)
propuso usar este bit para detectar el tráfico malicioso. Esto simplificaría de manera
considerable la seguridad, puesto que se sabría que los paquetes con el bit “malo” habían
sido enviados por atacantes y sólo había que descartarlos. Por desgracia, la seguridad de
las redes no es tan simple.
Después vienen dos campos de 1 bit relacionados con la fragmentación. DF significa no
fragmentar (Don’t Fragment), es una orden para que los enrutadores no fragmenten el
paquete. En un principio estaban destinados para soportar a los hosts incapaces de reunir
las piezas otra vez. Ahora se utiliza como parte del proceso para descubrir la MTU de la
ruta: el paquete más grande que puede viajar a través de una ruta sin necesidad de
fragmentarse. Al marcar el datagrama con el bit DF, el emisor sabe que llegará en una
pieza o recibirá de vuelta un mensaje de error.
MF significa más fragmentos (More Fragments). Todos los fragmentos excepto el último
tienen establecido este bit, que es necesario para saber cuándo han llegado todos los
fragmentos de un datagrama.
El Desplazamiento del fragmento indica a qué parte del paquete actual pertenece este
fragmento. Todos los fragmentos excepto el último del datagrama deben ser un múltiplo
de 8 bytes, que es la unidad de fragmentos elemental. Dado que se proporcionan 13 bits,
puede haber un máximo de 8192 fragmentos por datagrama, para soportar una longitud
máxima de paquete de hasta el límite del campo Longitud total. En conjunto, los campos
Identificación, MF y Desplazamiento del fragmento se utilizan para implementar la
fragmentación […].
El campo TTL (Tiempo de vida) es un contador que se utiliza para limitar el tiempo de vida
de un paquete. En un principio se suponía que iba a contar el tiempo en segundos, lo cual
permitía un periodo de vida máximo de 255 seg. Hay que decrementarlo en cada salto y
se supone que se decrementa muchas veces cuando un paquete se pone en cola durante
un largo tiempo en un enrutador. En la práctica, simplemente cuenta los saltos. Cuando
el contador llega a cero, el paquete se descarta y se envía de regreso un paquete de aviso
al host de origen. Esta característica evita que los paquetes anden vagando eternamente,
algo que de otra manera podría ocurrir si se llegaran a corromper las tablas de
enrutamiento.
Una vez que la capa de red ha ensamblado un paquete completo, necesita saber qué
hacer con él. El campo Protocolo le indica a cuál proceso de transporte debe entregar el
paquete. TCP es una posibilidad, pero también están UDP y otros más. La numeración de
los protocolos es global en toda la Internet. Anteriormente los protocolos y otros
números asignados se listaban en el RFC 1700, pero en la actualidad están contenidos en
una base de datos en línea localizada en www.iana.org.
Puesto que el encabezado transporta información vital, como las direcciones, estima su
propia suma de verificación por protección, la Suma de verificación del encabezado. El
algoritmo suma todas las medias palabras de 16 bits del encabezado a medida que vayan

6
 llegando, mediante el uso de la aritmética de complemento a uno, y después obtiene el
complemento a uno del resultado. Para los fines de este algoritmo, se supone que la Suma
de verificación del encabezado es cero al momento de la llegada. Dicha suma de
verificación es útil para detectar errores mientras el paquete viaja por la red. Tenga en
cuenta que se debe recalcular en cada salto, ya que por lo menos hay un campo que
siempre cambia (el campo Tiempo de vida), aunque se pueden usar trucos para agilizar
ese cálculo.
Los campos Dirección de origen y Dirección de destino indican la dirección IP de las
interfaces de red de la fuente y del destino. En la siguiente sección estudiaremos las
direcciones de Internet.
El campo Opciones se diseñó para proporcionar un recurso que permitiera que las
versiones subsiguientes del protocolo incluyeran información que no estuviera presente
en el diseño original, para que los experimentadores puedan probar ideas nuevas y evitar
la asignación de bits de encabezado a la información que se necesite muy poco. Las
opciones son de longitud variable. Cada una empieza con un código de 1 byte que
identifica la opción. Algunas opciones van seguidas de un campo de longitud de la opción
de 1 byte, y luego de uno o más bytes de datos. El campo Opciones se rellena para
completar múltiplos de 4 bytes. (pp. 376 – 379).

En tanto, el campo Versión va adquiriendo cada día más importancia, esto se debe a que
existen dos versiones de IP: IPv4 e IPv6.

IPv4 es una dirección jerárquica de 32 bits, cada host y router que componen las redes tiene
una dirección IP que son las que se usan en los campos origen y destino. Es importante
aclarar que, en realidad, son las interfaces de red las que poseen direcciones y no los hosts,
ya que puede existir un host con 2 o más interfaces de red pudiendo tener cada una de ellas
varias direcciones IP. Un caso de aplicación es la conexión de un servidor físico conectado a
un storage (servidor de almacenamiento). Ambos servidores tienen al menos 2 interfaces
de red, esto se configura de esta manera como una medida de seguridad por 2 motivos:
uno es el balanceo de carga, esto se basa en dividir las cargas de transferencia de datos
entre ambas interfaces para evitar la saturación y que ninguna trabaje de forma forzada, lo
cual provocaría una reducción de su vida útil. El segundo motivo se relaciona con la
estrategia de fail over o redundancia, este concepto considera que, si una interfaz falla, el

7
tráfico de red se redirige hacia la otra para evitar que los servicios de red caigan, que puedan
seguir operando con normalidad y de forma transparente para el usuario, generando una
alarma para que el administrador de red vea la situación.

Como mencionamos, IP es una dirección jerárquica de 32 bits, cada dirección se divide en 2

sectores: uno de porción de red de longitud variable, y otra porción usada para los hosts
que pertenecen a una misma red.

Además, Tanenbaum (2012) nos explica cómo es la notación de una dirección IP:

Las direcciones IP se escriben en notación decimal con puntos. En este formato, cada uno
de los 4 bytes se escribe en decimal, de 0 a 255. Por ejemplo, la dirección hexadecimal
80D00297 de 32 bits se escribe como 128.208.2.151. Para escribir los prefijos, se
proporciona la dirección IP menor en el bloque y el tamaño de este. El tamaño se
determina mediante el número de bits en la porción de red; el resto de los bits en la
porción del host pueden variar. Esto significa que el tamaño debe ser una potencia de
dos. (p. 379)

Por otro lado, la IPv6 nace ante la necesidad de comenzar a implementar una nueva forma
de direccionamiento que sea alternativa a IPv4, debido al agotamiento de las direcciones
de versión 4, lo cual es un gran problema hoy en día. Esta escasez provoca muchos
problemas de conectividad, dado que cada vez son más los dispositivos que tenemos y que
necesitan conectividad a internet.

Además, estructuralmente la IPv6 se compone de 128 bits, lo cual nos provee una cantidad
casi ilimitada de direcciones, también se aprovechó para poder mejorar el protocolo y
explotar mejor las capacidades de IPv4, renovando, por ejemplo, su encabezado para
conseguir mejoras en la performance. Esto lo logra eliminando algunos campos, lo cual
consigue que el router demore menos en procesar un datagrama IP.

Seguidamente, veamos el encabezado fijo de una IPv6:

8
 Imagen 3: Datagrama IP v6
Fuente: Tanenmaum (2012, p. 393).

De acuerdo con lo anteriormente descrito, Vélez Varela y Gutiérrez Rancruel (2016), nos
describen los campos que componen el encabezado del paquete IPv6:

• El campo Versión, sigue siendo un campo de 4 bits que permanece al principio del
encabezado, para mantener consistencia en los dos tipos de encabezado, poder
verificar la versión de entrada de los routers y así saber en primera instancia de que
versión se está hablando.
[…]
• El campo de Clase, mide 8 bits y es la que hace referencia a la prioridad del
datagrama. Este campo, es uno de los que se integraron para mejorar la versión
anterior, sirve para dar prioridad a mensajes de telefonía o videoconferencia.
• El campo de Tipo de Flujo, mide 16 bits y trabaja en conjunto con el campo de clase
en el caso de aplicaciones en tiempo real, ya que especifica si varios datagramas van
de un mismo origen a un mismo destino, por lo cual necesita el mismo trato.

9
 • El campo de Tamaño de los Datos, mide igual que la versión 4, 16 bits, sin embargo,
esta versión hace referencia solamente a los datos que transporta este datagrama sin
incluir el encabezado.
• El campo de Siguiente Encabezado, mide 8 bits e indica al router si después del
datagrama existen opciones o extensiones. Este campo sustituye el campo de
bandera de la versión 4. En otras palabras, se eliminaron del encabezado la
interpretación de las varias opciones que se tienen y se ubicaron fuera del datagrama
básico. El hacer este movimiento no complica las cosas al router ya que también se
definieron una serie de encabezados de extensión que se ubican después de los datos
en forma de cadena y permiten que los datagramas se personalicen, por lo tanto, se
puede tener varios encabezados solamente con indicarlo en este campo. Para que el
router o switch, sepa el tipo de encabezado que está procesando a cada tipo de
encabezado se le asignó un número y una abreviatura, […].
• El campo de Alcance de Datagrama, mide 8 bits es parecido al campo time to live en
la versión 4 e indica la cantidad máxima de routers que debe pasar el datagrama antes
de llegar a su destino, igualmente, cada vez que pasa por un router, se decrementa
el valor inicial en uno y si no llega a su destino el valor llega a cero, se descarta el
datagrama. (p. 9)

A mediados de la década de 1990 se observa, por parte del Institute of Electrical and
Electronics Engineers (IEEE), un crecimiento exponencial de Internet, sumado a un
deficiente manejo y administración de los bloques de IP por parte de las entidades que se
encargan de otorgar los mencionados bloques. El gran aumento de las conexiones se
empezó a visibilizar en el aumento de las tablas de ruteo en los dispositivos de red
(Tanenbaum, 2012). Como consecuencia, la IEEE se reúne para determinar el fin de
protocolo IPv4, ya que no estaba en condiciones de adecuarse a las nuevas necesidades que
estaban surgiendo y al agotamiento de las direcciones IP.

En el mismo sentido, Vélez Varela y Gutiérrez Rancruel (2016) nos explican otras
problemáticas referidas a IPv4:

• IPV4 no soporta servicios de forma nativa tales como: Calidad de servicio (QoS),
seguridad, movilidad (Principalmente); estos deben ser añadidos regularmente, no es
posible que estos servicios trabajen juntos.
• “Delegación de Direcciones y Direccionamiento mundial no optimizado (Estados
Unidos tiene asignado el 70% de las direcciones en el mundo; por ejemplo: La

10
 universidad de Stanford tiene asignadas más direcciones IP que toda China)” [Gómez
A., Gonzalo A., 2004].
• La gran dimensión de las tablas de Routing en el backbone de INTERNET, que la hace
ineficaz y perjudica enormemente los tiempos de respuesta.
• Soporte inadecuado para las necesidades actuales, en este mundo cambiante y
globalizado, las nuevas aplicaciones son mas demandantes, aplicaciones como:
videoconferencias, multimedia, VoIP y de tiempo real. (pp. 15-16)

Finalmente, se toma la decisión de crear un nuevo protocolo que se llama IPv6 con una
nueva estructura, y esto trae aparejado una serie de inconvenientes en la migración de un
protocolo a otro. Por ese motivo, se definen una serie de estrategias para poder convivir
con ambos y poder realizar una transición que es inevitable, así lo especifican Vélez Varela
y Gutiérrez Rancruel (2016):

Dual Stack (Doble Pila)

Cuando un dispositivo tiene capacidades de doble pila, entonces tiene el acceso a la
tecnología disponible, tanto IPv4 como IPv6. Se pueden utilizar ambas tecnologías para
conectarse a distancia, servidores y destinos en paralelo. La solución de pila dual (RFC
2893), a la que a partir de ahora se refiere mediante su nombre original en inglés, Dual
Stack, consiste en implementar ambas pilas de protocolos, IPv4 e IPv6, en los dispositivos
que requieran acceso a las capas de red de ambas tecnologías, incluidos routers,
dispositivos de usuario final o cualquier otro nodo de la infraestructura de red. Tales
dispositivos serán configurados tanto con direcciones IPv4 como con direcciones IPv6 y
podrán obtener estas direcciones por medio de cualquier método previsto por los
respectivos protocolos y siempre que el administrador o administradores los hayan
habilitado. (p. 89)

Imagen 4: Arquitectura de capa IP Dual.

Fuente: Vélez Varela y Gutiérrez Rancruel (2016, p. 89)

11
Continúan explicando los autores:

Mecanismo de encapsulamiento de paquetes. Túneles

Uno de los mecanismos más usados para la transición de IPv4 a IPv6, es la implementación
de túneles, como se define en el RFC 2893 “un túnel hace routing de paquetes IPv6 sobre
las infraestructuras de IPv4. Están diseñados para permitir que los nodos IPv6 mantengan
una compatibilidad completa con IPv4, por ende, esto mejorarán notablemente el
despliegue de IPv6 en la INTERNET, y facilita la eventual transición de todo el INTERNET a
IPv6”. [INTERNET Engineering Task Force (IETF): RFC 2893]
Básicamente, el proceso de encapsulamiento se realizada cuando el nodo de entrada de
un túnel, es decir, el nodo de encapsulamiento, genera un paquete IPv4 en el cual
encapsula el paquete IPv6 para posteriormente transmitirlo por la infraestructura IPv4,
dicho paquete queda con un header IPv4, el cual contiene las direcciones de fuente y
destino, un cuerpo que contiene el header IPv6 seguidamente de los datos. En el nodo
final del túnel, es decir, el nodo encargado de desencapsular, elimina el header IPv4,
seguidamente actualiza el header IPv6 y procesa el paquete IPv6 recibido. (Vélez Varela y
Gutiérrez Rancruel, 2016, pp. 90-91)

Imagen 5: Encabezado de encapsulado de paquete IPv6 dentro de un IPv4.

Fuente: Vélez Varela y Gutiérrez Rancruel (2016, p.91)

12
Sobre los Mecanismos de Traducción, Vélez y Gutiérrez (2016) explican:

Se trata de un desarrollo relativamente reciente y ya se ha convertido en toda una

revolución para la migración de los dispositivos. Una vez que fue considerada la
herramienta de último recurso por la IETF (Internet Engineering Task Force), los esquemas
de traducción están empezando a ser tremendamente populares a la hora de abordar
muchas transiciones. La tecnología de traducción es utilizada cuando un único host IPv6
necesita comunicarse con otro IPv4 o viceversa. Este método de migración es la única de
las soluciones en IPv6 que permite eliminar definitivamente el direccionamiento IPv4 de
los nodos de red.
Esto ofrece ventajas muy significativas respecto a otras soluciones de migración, como,
por ejemplo, la posibilidad de integrar sistemas IPv6 nativos en redes que aún mantienen
un soporte para dispositivos IPv4 más antiguos. Además, mantiene la seguridad punto a
punto de la conexión. Un aspecto crítico de la tecnología de traducción es su enfoque
single-stack, que reduce al mínimo la cantidad de hardware necesario (que funciona de
manera nativa en IPv6 o IPv4), lo que reduce la cantidad de recursos de TI necesarios para
mantener la red de datos.
El enfoque single-stack ofrece un modo simple y más económico para manejar redes
nativas en IPv6. Tan pronto como las aplicaciones IPv6 aparezcan, los departamentos de
TI simplemente tienen que eliminar el viejo hardware IPv4 y reemplazarlo por otro nuevo
con protocolo IPv6. (pp. 106 – 107)

Imagen 6: Estrategia de tunelizado NAT-PT

Fuente: Vélez Varela y Gutiérrez Rancruel (2016, p. 103)

13
 3.1.2. (Tipo de servicio)

Type Of Service (TOS) es un campo que forma parte del datagrama IPv4 que tiene a
disposición 8 bits para resaltar el nivel de urgencia, permitiendo indicar parámetros sobre
una calidad de servicio mientras transita en la red (Castaño Ribes, 2013).

La importancia de este campo dentro de la cabecera es que los routers pueden ofrecer un
tratamiento especial y prioritario a determinados tipos de datagramas, que se diferencian
según la secuencia de bits que se forme, según RFC 791 (1981):

Bits 0-2: Precedencia

• 111: Network Control (control de red)
• 110: Internetwork Control (control de trabajo de internet)
• 101: CRITIC/ECP (procesando llamada critica y de emergencia)
• 100: Flash Override (invalidación relámpago)
• 011: Flash (relámpago)
• 010: Immediate (inmediato)
• 001: Priority (prioritario)
• 000: Routine (de rutina)
Bit 3: Retardo
• 0: Normal
• 1: Bajo
Bit 4: Rendimiento
• 0: Normal
• 1: Alto
Bit 5: Fiabilidad
• 0: Normal
• 1: Alta
Bits 6-7: Reservados para uso futuro. (p. 12)

Este campo también está presente en el encabezado del paquete IPv4, bajo el nombre de
clase de tráfico o tráfico diferenciado, Tanenbaum (2012) referido al campo mencionado
asegura:

se utiliza para distinguir la clase de servicio para los paquetes con distintos
requerimientos de entrega en tiempo real. Se utiliza con la arquitectura de servicio
diferenciado para la calidad del servicio, de la misma forma que el campo con el mismo

14
 nombre en el paquete IPv4. Además, los 2 bits de menor orden se usan para señalar las
indicaciones explícitas de congestión, de nuevo en la misma forma que IPv4. (p. 392)

En la siguiente imagen veremos la composición del campo TOS definida unos años después
en RFC 1349 (1992), como ya mencionamos se compone de 8 bits, es decir, 1 byte:

Imagen 7: Estructura del campo TOS

Fuente: RFC 1349 (p. 4)

En tanto, como lo especifica el RFC 1349 el campo PRECEDENCE está destinado a denotar la
importancia o prioridad del datagrama. El campo TOS indica como la red debe realizar
compensaciones entre rendimiento, demora, confiabilidad y costo. Y, por último, el campo
MBZ (must be zero) como su nombre lo indica debe ser cero y no se usa actualmente (p. 4).

3.1.3. TTL (Time to live)

Time to Live (TTL) es un campo del encabezado de un datagrama IPv4 que tiene un tamaño
de 8 bits y que marca la cantidad de saltos que puede dar un paquete, es decir, cuantas
veces puede pasar de un router a otro para ir de un origen a un destino; está limitado a 256
saltos, al llegar al límite el paquete se descarta y se informa al origen. Castaño Ribes (2013)
lo describe de la siguiente manera:

- TTL (Time to live): (8 bits) se trata de un contador que va disminuyendo cada vez que
el paquete atraviesa un router. Cuando este contador llega a 0, el paquete se
descarta, así se evita que los paquetes que no encuentran su ruta queden atrapados
en bucles infinitos saturando la red. (p. 164)

15
Haciendo una analogía del campo TTL sobre el encabezado de IPv6, si bien no existe como
tal, el equivalente se llama Límite de saltos y se implementa en IPv6 para evitar que el
paquete esté transmitiéndose de forma eterna, saltando de un router a otro. También tiene
un tamaño de 8 bits y por cada reenvío descuenta de a un punto y al llegar a cero, el router
lo descarta.

En la próxima imagen veremos cómo es la secuencia de conteo del campo, notar que el TTL
no llega a decrementarse hasta cero y por lo tanto se entrega de manera efectiva al host
destinatario.

Imagen 8: Conteo de saltos

Fuente: Elaboración propia

3.1.4. Suma de control

La suma de control es una operación matemática que se realiza en un dispositivo de red,

para determinar la integridad de un paquete IP. Es importante tener en cuenta que esta
comprobación es realizada únicamente en el encabezado y es un campo que posee 16 bits.

En tanto, Vélez Varela y Gutiérrez Rancruel (2011), nos expresan el siguiente concepto sobre
la suma de control:

16
  El campo de Suma de Comprobación (checksum), se utiliza para verificar el
encabezado, ya que tanto UTP como TCP y demás protocolos tienen su propio
checksum y verifican sus datos de manera autónoma. Sirve para verificar que el
encabezado llegue completo y no se descarte el paquete por pérdida de información
en el camino. (p.6)

Es preciso destacar que esta comprobación se realiza en el encabezado de IPv4, no así en

IPv6, dado la alta confiabilidad y disponibilidad de las redes que existen hoy en día. Además,
esta verificación que debe realizar cada router suma responsabilidades a estos equipos,
quitándoles capacidad de procesos y performance. También debemos tener en cuenta que
el datagrama IP viaja encapsulado en una trama Ethernet y en sus respectivas capas físicas
y de enlace, ya que posee sus propias comprobaciones por suma de verificación. De esta
forma, cumplimos con la premisa de IPv6 de lograr un diseño compacto, rápido y flexible.

En la siguiente imagen vemos un ejemplo de una cabecera IPv4, con una implementación
de una suma de verificación, con un complemento a 1:

Imagen 9: Suma de comprobación

Fuente: Elaboración propia a partir de Vélez Varela y Gutiérrez Rancruel (2011).

17