Vemos la necesidad de realizar esta entrada del blog, debido a que el 90% de las personas reprobaron el Quiz de 10 preguntas sobre el header IPv4 que lanzamos hace unos días. Así que vamos a explicar de manera breve e introductoria, el protocolo IPv4 y los campos de su header. Con esta explicación esperamos que puedan responder correctamente las preguntas del Quiz.
Capa de Red
Comencemos la explicación analizando la capa de Red. La tarea de esta capa, es proporcionar los caminos a través de los cuales debe viajar la información desde un dispositivo de origen hasta un dispositivo de destino. La capa de Red logra esta tarea a través de las funciones de encapsulación/desencapsulación, direccionamiento y enrutamiento. Para el enrutamiento se utilizan diferentes protocolos como OSPF, EIGRP y RIP. Para el direccionamiento se utilizan los protocolos IPv4 e IPv6.
Proceso de encapsulación
En la imagen 1 podemos ver el proceso de encapsulación con los respectivos PDUs. Los datos son generados en las capas superiores, en estas capas el PDU lleva la denominación de datos. Los datos son entregados a la capa de Transporte, la capa de Transporte añade su header encapsulando los datos recibidos, y ahora el PDU se denomina segmento. El segmento es entregado a la capa de Red donde es encapsulado con un header, en esta capa el PDU se denomina paquete. El paquete es enviado a la capa de Enlace de datos donde es encapsulado con un header y un trailer de algún protocolo de la capa 2, en esta capa el PDU se denomina trama. Finalmente la trama es enviada a la capa Física donde el PDU lleva la denominación de bits.
En cada capa del modelo de red, trabaja un protocolo diferente que realiza diversas tareas para el cumplimiento de la comunicación entre 2 dispositivos. Vamos a asumir en esta oportunidad, que en la capa de red se encuentra trabajando el protocolo IPv4.
Protocolo IPv4
El protocolo IPv4 se encuentra definido en el RFC 791. En ese documento pueden encontrar todo lo referente a IPv4.
La función principal del protocolo IPv4, es encargarse del direccionamiento de los dispositivos en una red de manera que pueda existir comunicación entre esos dispositivos.
Características generales
El protocolo IPv4 tiene 3 características generales:
El protocolo IPv4 no se encarga de establecer una conexión previa con el dispositivo al cual desea enviar los paquetes.
En la imagen 2, si el router R1 quiere enviar paquetes al router R2, simplemente los envía sin previo aviso, el protocolo que se encarga de establecer una conexión previa con el dispositivo de destino, es TCP en la capa de Transporte.
IPv4 no tienen mecanismos que le permitan garantizar que un paquete haya sido recibido de manera correcta por el dispositivo de destino. En la imagen 2, si un paquete que envía el router R1 al router R2 se pierde por cualquier motivo, al protocolo IPv4 no le interesa ni tampoco tiene los mecanismos para volver a enviar ese paquete.
Al protocolo IPv4 no le interesa si se envían sus paquetes a través de fibra óptica, a través de cables de cobre o a través de medios inalámbricos, esa es la tarea de la capa 2.
Header IPv4
Para el cumplimiento de sus tareas, el protocolo IPv4 necesita ciertos datos, esos datos son almacenados en su header. El header del protocolo IPv4 lo vemos en la imagen 3.
Tamaño header IPv4
Lo primero que debemos saber es que el header IPv4 tiene un tamaño mínimo de 20 bytes hasta un máximo de 60 bytes. El tamaño del header depende del campo llamado “OPTIONS” que es de tamaño variable, ese campo puede crecer hasta 40 bytes haciendo un total de 60 bytes para todo el header IPv4, sin contar los datos de Aplicación y Transporte. Cuando el campo Opciones no lleva datos, el header IPv4 se mantiene en el mínimo valor de 20 bytes.
Versión
Como su nombre indica, este campo nos proporciona la versión del protocolo IP al cual pertenece el paquete, tiene un tamaño de 4 bits. Si haríamos una captura de tráfico, veríamos en el campo versión, el valor decimal “4” haciendo referencia al protocolo IP versión 4.
Header Length/Tamaño del header
Tiene un tamaño de 4 bits y nos proporciona el tamaño del header IPv4 en palabras de 32 bits o 4 bytes, ya sabemos que suena complicado. Hagamos un par de ejemplos para explicar ese concepto. Supongamos que vemos el valor decimal de 5 en el campo «Tamaño del header», para encontrar el tamaño real del header, tenemos que aplicar la siguiente formula:
Tamaño header = Valor del contenido Header Length * 32 bits
En este caso tendríamos que el tamaño del header es igual 5 * 32 bits que nos daría un valor real del tamaño del header de 160 bits o lo que es igual a 20 bytes, 1 byte son 8 bits. Si se dan cuenta el valor de 20 bytes es el tamaño mínimo del header del paquete IP, lo que significa que no podemos ver en este campo header length un valor más pequeño que 5.
Ojo que este campo solo contempla el tamaño del header IP, sin contar los datos encapsulados como vemos en la imagen 4.
DSCP/ECN
Este campo se utiliza para calidad de servicio (QoS), originalmente se denominaba Type of Service, tiene un tamaño de 8 bits, de los cuales los primeros 6 bits son llamados DiffServ Code Point (DSCP) y los últimos 2 bits son llamados Explicit Congestion Notification (ECN).
Total Length o Packet Length
Este campo nos indica el tamaño total del paquete en bytes. Este tamaño considera el header IP más el header TCP mas los datos de la capa de aplicación como vemos en la imagen 7.
Este campo tiene un tamaño de 16 bits, por lo tanto, el máximo valor decimal que podemos obtener con 16 bits es de 65535, lo que quiere decir que el tamaño máximo de un paquete IP es de 65535 bytes.
Identification, Flags y Fragment Offset
Estos campos son utilizados en el proceso de Fragmentación que lo explicamos en esta otra entrada del blog.
Time To Live
Cuando estudien los protocolos de enrutamiento, se van a dar cuenta que una configuración errónea puede provocar que un paquete circule de manera infinita en una red sin llegar al dispositivo de destino, esto se llama loop. El objetivo de este campo Time To Live es detener los loops de enrutamiento. A este campo se introduce un valor, el valor recomendado es de 64, este número ira disminuyendo en una unidad, por cada router que atraviese, cuando el campo TTL del paquete llegue a «0», el router que disminuyo el valor a 0 elimina el paquete y envía un mensaje de error ICMP «time exceeded» al dispositivo que originó el paquete.
Protocol
Este campo nos indica el protocolo que se está utilizando en la capa superior. Tiene un tamaño de 8 bits. Los números más comunes que encontraremos en esta campo se pueden ver en la imagen 6.
Checksum
Tiene un tamaño de 16 bits y ayuda a verificar la integridad del header IP. Es decir que los datos que se encuentran en el header IP no hayan sido alterados o modificados en su viaje. El Checksum se calcula en cada salto hasta llegar al dispositivo de destino.
Destination Address/Source Address
Estos campos son los más importantes para el estudio de CCNA y tienen un tamaño de 32 bits. En el campo Source Address se introduce la dirección IPv4 del dispositivo que inicia la comunicación, y en el campo Destination Address se introduce la dirección IPv4 del dispositivo de destino con el cual se desea entablar la comunicación.
Options
Tiene tamaño variable, desde 0 hasta 40 bytes. El mayor uso que se le da a este campo es para realizar Loose Source Routing, Stric Source Routing, Timestamp y Record Route que son opciones que pueden ser invocadas con el comando PING.
Padding
Este campo es simplemente un relleno que aumenta bits para que el header termine en un límite de 32 bits. Recuerden que el campo «Header Length» nos proporciona un valor del tamaño del header en palabras de 32 bits, por lo cual el header no puede tener otros tamaños que no sean múltiplos de 32 bits o 4 bytes, y gracias a este padding se logra cumplir esa restricción.
NOTA: respecto a los protocolos que se encargan del direccionamiento, les tiene quedar claro que IPv4 y IPv6 no son los únicos, pero son los protocolos más usados, es muy difícil que hoy en día vean los otros protocolos en la vida real, sin embargo si quieren leer un poco acerca de un par de ellos, pueden investigar sobre el protocolo Connectionless-mode Network Service CLNS y IPX Internetwork packet Exchange.
Esperamos que el presente artículo haya sido de su agrado. Una vez terminen esta entrada, vayan al quiz de 10 preguntas y respondan correctamente =).
Quiz: Preguntas IPv4
Clase IPv4 CCNA: Introducción a la Capa de Red y al protocolo IPv4
- Este debate tiene 31 respuestas, 14 mensajes y ha sido actualizado por última vez el hace 2 años, 4 meses por
.
-
Entradas
-
Hola.
Me surgen dos dudas al respecto:
1. Si la capa IP no fragmenta los paquetes ya que comentas que es «muy raro» que en la vida real nos encontremos con paquetes mayores a 1500 y que en tal caso estos se deberian fragmentar (cosa que no es recomendable)
¿Quien es el encargado entonces de no generar paquetes (headers+datos) mayores de 1500? ¿la aplicación?2.Referente a la imagen de wireshark que has mostrado con el ejemplo de la canción, en la columna ‘length’ aparece el valor 1514. ¿Que es este valor?
Ademas, queria aprovechar este mensaje para felicitarte Alvaro por el gran trabajo realizado, ya que, tu forma de explicar es excelente.
Muchas gracias.Hola José y bienvenido al foro!
En realidad TCP es el que va armando los segmentos de red con la cantidad de datos necesaria para no sobrepasar el MTU de la interface a través de la cual tienen que atravesar los datos; cuando se trabaja con TCP, existe un buffer donde la aplicación va introduciendo los datos, TCP se va a ese buffer y de ahí obtiene la cantidad necesaria para la construcción de 1 segmento.
El MTU lo conforman los datos de aplicación, el header de la capa transporte y el header de la capa de red. Más adelante aprendes un poco más sobre el MTU, la cuestión es que todas las interfaces de red tienen un límite (MTU) sobre la cantidad máxima de datos que pueden ser enviados en las tramas, esto se calcula en base a la mejor eficiencia de transmisión… en Ethernet este límite es de 1500 bytes, entonces las aplicaciones van colocando sus datos a un buffer, TCP se va ese buffer y va crear un segmento que tenga un tamaño no mayor al MSS (Tamaño máximo del segmento), cuando se utiliza Ethernet, este MSS es igual a 1460 bytes, el tamaño de 1460 bytes garantiza que no se sobrepase el valor del MTU de 1500 bytes…esto debido a que 1460 bytes más 20 bytes del header TCP, más 20 bytes del header IP dan como resultado los 1500 bytes de MTU.
Respecto a tu segunda consulta, el valor de 1514 bytes hace referencia al tamaño de la trama Ethernet, 1500 bytes de MTU +14 bytes del header Ethernet, esos 14 bytes consisten en 6 bytes de dirección MAC de origen, 6 bytes de dirección MAC de destino, y 2 bytes del campo «type», recuerda que en el MTU no se toma en cuenta esos bytes extras del header de la trama Ethernet, por lo tanto no se está incumpliendo ninguna regla. En el módulo 2 aprendes sobre la estructura de la trama Ethernet.
Te dejo un enlace del blog donde hablamos un poco más de la fragmentación y el MSS: https://netwgeeks.com/fragmentacion-ipv4/ y https://netwgeeks.com/opciones-tcp-tamano-maximo-del-segmento-mss/
Espero que queden claras tus consultas.
Estoy atento a cualquier otro comentario, y muchas gracias por tu felicitación! =D
Saludos cordiales!
Me ha quedado muy claro con tu explicación.
Me gustaria hacerte una consulta más, (solamente por curiosidad).
Suelo trabajar con equipos Mikrotik en los cuales levantamos tuneles Gre y eoip. Estos tuneles llevan una opción por defecto para habilitar el ‘Clamp TCP MSS’. ¿Que es exactamente eso y que es lo que hace? Por defecto viene marcada pero no se exactamente que es. He buscado algo de info al respecto pero no me queda muy claro.Muchas gracias.
Hola José
Esto lo vemos en curso CCNP ENCOR, pero de manera resumida, lo que ocurre cuando trabajas con túneles GRE/IPSEC/PPPOE entre otros, es que se añaden headers extras de estos protocolos a los datos que generan tus computadoras… por lo tanto cuando tus paquetes salgan por tu router, generaras paquetes más grandes que el MTU de sus interfaces; tu computadora generara 1500 bytes + los bytes extras de estas tecnologías darán como resultado más de 1500 bytes y por ende siempre fragmentaras tus paquetes haciendo tu comunicación ineficiente. TCP Clamping en tus routers lo que hace es que intercepta el establecimiento de sesión TCP, y básicamente les dicen a los dispositivos de origen y destino que realicen la creación de segmentos que no sobrepasen un determinado valor que tu configuras. En Cisco esto se logra con el comando ip tcp adjust-mss, y nosotros tenemos que proporcionar un valor de tamaño del segmento que sumado a los headers extras de TCP e IP, no superen el MTU de la tecnología que utiliza el router.
Por ejemplo, cuando configuras GRE en EL ROUTER, automáticamente el MTU de la interface túnel se reduce a 1476 para que se puedan añadir sin problemas los 24 bytes extras del header GRE dando como resultado los 1500 bytes que salen por tus interfaces físicas Ethernet del router. El problema es que tus host no saben de este cambio, y por ende seguirán enviando paquetes de 1500 bytes; como el MTU de GRE en el router es de 1476 y tus hosts envían 1500 bytes, de todas formas se van a fragmentar los paquetes. Por lo tanto nosotros tendríamos que configurar TCP Clamping en el router con un valor de 1436 bytes; esto significa que cuando tu PC envíe un establecimiento de sesión, ese paquete llega al router, y el router modifica esa sesión TCP e indica que el segmento no debe sobrepasar los 1436 bytes para que no se sobrepase el MTU de 1476 bytes de GRE… el paquete modificado llega al destino… y el destino ya sabe que no debe crear segmentos TCP que sean mayores a 1436. Cuando se envíe el segmento de 1436 bytes, se añaden 20 bytes de TCP y 20 bytes de IP dando como resultado los 1476 bytes de MTU de GRE. Si a esto le sumas tus 24 bytes de GRE, dan como resultado los 1500 bytes que tiene que tener una trama que utiliza una interface física Ethernet por defecto.
En síntesis esa tecnología busca que tus computadoras no generen segmentos TCP que provoquen fragmentación afectando a tu comunicación.
Espero que haya quedado clara la explicación.
Atentos a cualquier otra consulta.
Saludos cordiales.
Hola Jose! =)
Es correcto, TCP Clamping es uno de los mecanismos que trata de evitar la fragmentación, si configuras un valor correcto del tamaño de segmento efectivamente se EVITARA la fragmentación, pero si configuras un valor incorrecto de tamaño del segmento no podrás evitar nada. Se debe analizar los tamaños de los paquetes que viajan de principio a fin en la comunicación de tus hosts y las tecnologías de túneles e interfaces empleadas para que efectivamente configures un valor correcto de MSS/MTU.
Existe otra tecnología que también conjuntamente con TCP Clamping tratan de evitar la fragmentación y se denomina Path MTU Discovery.
Atento a cualquier otra consulta que puedas tener.
Saludos cordiales.
Buenas noches Álvaro, espero te encuentres bien y muy agradecido por todo el contenido, de verdad esta muy bien explicado. En esta ocasión tengo una duda con respecto al time to live (TTL), este valor se empieza a reducir (partiendo desde 255), al momento que sale del dispositivo emisor? Mas especifica mi pregunta, en la topología que colocas al momento de explicar este valor del header TCP lo realizas colocando una PC como emisor y 3 routers antes de llegar al destino, ese valor de 255 se empieza a reducir desde el momento que parte de la PC? O sea, desde el primer router? sin haber llegado al LOOP?, Saludos y espero puedas comprender mi pregunta, ya que en ese punto de la clase tuve dudas. Gracias de antemano.
Hola Jesus, a pesar que el máximo valor que podamos tener es de 255, en la realidad el valor que tengas en el campo TTL depende del sistema operativo de donde origines el paquete; en Windows por ejemplo generalmente tenemos un valor de TTL de 128, esto significa que tu paquete sale de tu dispositivo con un valor de 128, cuando atraviese tu primer router se reduce a 127 y así sucesivamente. En Linux por ejemplo este valor es de 64, y cuando llegue al primer router, se reduce a 63 y así sucesivamente. En el ejemplo efectivamente hacemos parecer como que se comienza a reducir ese valor al encontrar el loop, sin embargo esto no es así, no necesitas experimentar un loop para que ese valor se vaya reduciendo, se reduce apenas te pillas al primer router en tu red.
Atento a cualquier otra consulta/comentario.
Saludos! =)
he visto el video 3 veces, y aun no me queda claro ciertas cosas me parece que esta bastante confuso todo..
Por un lado el hedear IPv4 tiene un tamaño de 2 elevado a la 16 que es 65536, porque se habla entonces de 65535? donde queda el bit restante?
El header IPV4 es de tan solo 32 bits estos 32 bits se completarian con los 4 primeros campos del encabezado (4 bits de VERSION + 4 bits del header lenght + 8 bits del DSCP+ 16 bits de PACKET LEGHT =32) ya ahi estan los 32 bits, que pasa entonces con el resto de los campos del header como lo son TTL, Source Address, Dest, address etc? y eso que dice 20-60 bytes en la imagen abarca el tamaño total del header no del paquete ipv4… No se, no me queda para nada clara esta explicaciòn .
por otro lado de cara al examen de certificacion hay que aprenderse el tamaño de cada campo del header y su funciòn?
Favor aclarar.
Hola Richchri!
En el video se menciona que el tamaño de ese campo es de 16 bits, 16 bits te proporcionan 65536 VALORES diferentes, no te indica que el tamaño sea de 65536. Los 65536 valores van desde el valor binario 00000000 00000000 hasta el valor binario 11111111 11111111 que es equivalente al decimal 65535. Por lo tanto los VALORES decimales que encuentras en ese campo van desde 0 al 65535 (dando un total de 65536 valores diferentes).
Respecto a tu segunda consulta. El header IPv4 NO es de 32 bits, tal vez podrías indicarme a qué parte del video te refieres para poder aclararlo?… el header IPv4 tiene un tamaño mínimo de 20 BYTES.
Respecto a tu última consulta, sí, necesitas conocer las funciones de los diferentes campos del header IPv4 por lo menos de manera básica. En el examen podrían preguntarte por ejemplo cual es la función del campo Time To Live del header IPv4.
Atento a tus comentarios.
Saludos! =)
Hola Alvaro,
Como es que se interpreta que 16 bits = 65536 bytes (Para el campo Packet Length) ? Yo entiendo que 16 bits son 65536 en decimal y dividido entre 8 se obtendra los Bytes que en este caso seria 8192 Bytes.
¡Hola Ángel!
El concepto, es que el valor que obtengas en ese campo se debe interpretar como si fueran bytes… tienes 16 bits disponibles, ¿no es cierto?… supongamos que en ese campo encuentras el valor 00000000 00000010, eso es equivalente al valor decimal 2, entonces el resultado es que el header IP tendría un tamaño de 2 BYTES. Lo que encuentres en ese campo, DEBES asumir que se trata de bytes. Si haces una captura en Wireshark, lo más probable es que veas el valor de 1500, esos son 1500 BYTES. Si no fuera interpretado así, tendríamos que hacer más grande el header IPv4…tendríamos que tener un tamaño del Packet lenght de 19 bits.
La definición formal del RFC (https://datatracker.ietf.org/doc/html/rfc791#page-11), es que «El total lenght, es el tamaño del datagrama MEDIDO en OCTETOS (Bytes), donde se incluye el header de Internet y la información”. Lo mismo, si tienes un valor de 1500, significa 1500 OCTETOS, es decir 1500 bytes.
Espero haberte ayudado con mi respuesta.
Estoy atento a tus comentarios.
Saludos!
Hola Alvaro!
1. Qué hace que en el campo Header Lenght se tenga un valor de 5 o 15? es debido a que no todos los campos del header son utilizadas? tiene que ver con los datos en los otros campos del header? en algún momento se puede tener el valor de 11?
2. Respecto al cambio en el campo ToS por los valores DSCP y ECN, ese cambio se ve reflejado en la
página web de la IANA o de alguna otra entidad que se encarga de realizar esas modificaciones?3. Con el campo Time to Live se puede saber o tener una idea por cuantos routers a tenido que pasar un paquete IP hasta llegar a mi PC? existe algún comando en los SO para saber por cuantos routers un paquete IP ha tenido que pasar hasta llegar a mi PC?
4. Por curiosidad, si se pudiera enviar una trama con datos encapsulados de 65535 bytes, qué pasaría en una red? volvería más lenta la comunicación?
5. El MTU de Ethernet es de 1500 bytes, qué pasa con fibra óptica y con Wifi? También son de 1500 bytes?
Gracias de antemano!
- Debes estar registrado para responder a este debate.
Gracias, el Quiz se encuentra en este enlace: https://netwgeeks.com/preguntas-ipv4/
Saludos!