Matías Baeza Graf #29654

2021

Clase 1 – Redes II 2021

Recordemos que a todos los dispositivos que están en la misma red IP les debemos asignar la misma
dirección de red en su dirección IP. Cuando voy a asignar direcciones, todos los dispositivos que
comparten el Net-ID, debe ser adyacentes, es decir que pertenezcan a la misma red de capa 2.

Todo aquel que quiera desarrollar una solución compatible con las del resto de los fabricantes, toma un
estándar y crea una pieza de hardware o software que cumpla precisamente con ese estándar, sin
importar el hecho de que sean de diferentes fabricantes. La familia de protocolos que estamos
estudiando es TCP/IP.

Como el modelo OSI fue el modelo inicial, por más que hoy en día esté en desuso, reemplazado por un
modelo hibrido combinado con TCP/IP es posible encontrar bibliografía en la que se hace referencia a
protocolos de capa 7, es decir de capa de aplicación (la cual es la capa 5 en híbrido).

Para enviar los datos, en el emisor, los bits van bajando desde la capa de aplicación hasta la capa física
donde se transmiten a la capa física del lado receptor, donde van subiendo por todas las capas hasta la
capa superior. Recordemos que las capas igualmente trabajan como si estuvieran dialogando
directamente con su contraparte del otro dispositivo (Por ejemplo, capa transporte emisor con capa
transporte receptor). Para que esto sea posible, cuando la información va bajando por el emisor, cada
capa le va agregando un encabezado para que al momento de que esta vaya subiendo por las capas del
receptor, entonces cada capa lea el encabezado que agrego su contraparte.

La información que intercambia la misma capa de ambos lados tiene diferentes nombres dependiendo
de la capa de la que hablemos. En capa 2, se llaman tramas y en capa 3 paquetes. Sin embargo, si en
capa 3, utilizamos IP, les decimos datagramas. Vamos a ver como se envían estos datagramas.

Para armar el datagrama, IP debe armar un encabezado propio de IP. Este es parte de la estandarización
del protocolo.
Matías Baeza Graf #29654
2021

El campo de versión (4 bits) indica la versión de IP que se utiliza, siendo 0100 la versión 4 y 0110 la
versión 6, esto es lo primero que debe saber el receptor.

El campo HLEN (4 bits) indica la longitud del encabezado en palabras de 32 bits. La mayoría de los
datagramas tienen en mismo tamaño estándar que es 5 (es decir 5 x 4 = 20 bytes), sin embargo, hay
algunas opciones (fila 6, ya que cada fila representa una palabra de 32 bits) que pueden estar o no en el
encabezado, por lo que es posible que varíe el tamaño. Esta sexta palabra tiene una sección de padding,
para rellenar la palabra y que siempre sea de una cantidad de bits múltiplo de 32. Este campo es para
que el receptor sepa dónde termina el encabezado y donde arrancan los datos.

Luego tenemos el campo de total length, que tiene 16 bits, que indica la cantidad de bytes que tiene el
datagrama completo, no solo el encabezado. Con 16 bits, el máximo número que puedo expresar es
65535, así que este es el tamaño máximo que puede tener un datagrama. Igualmente, los datagramas
que se transmiten en la práctica ni siquiera se aproximan a ese tamaño.

El campo header checksum es un verificador de integridad del encabezado. Este contiene el resultado de
una suma de verificación, es decir información de control. Sirve para que el receptor calcule su propia
suma de verificación y compruebe que este recibió correctamente el datagrama. IP no hace reenvío. De
esta manera mínimamente te aseguras en el receptor que lo que recibís no tiene errores.

Los últimos dos campos de los que vamos a hablar son las direcciones IP de origen y destino, que cada
una no ocupa ni más ni menos que 32 bits.

ENTREGA DIRECTA

Este destino puede estar en la misma red que el origen (mismo Net-Id) o en otra red (distinto Net-ID). Si
las capas 3 de origen y destino están en la misma red (de capa 2), se puede entregar el datagrama
directamente por la red de capa 2 subyacente. Esto se llama entrega directa y solo se puede dar cuando
los dos dispositivos están en la misma subred IP.

La IP de destino la ingresamos nosotros mismos, explícita o implícitamente. Cuando escribimos en el

navegador una dirección web, estamos especificando una dirección IP de destino, aunque no sepamos.
Esto se logra mediante en servicio DNS que vamos a ver más adelante. Esta transformación de dirección
web a dirección IP la hace un servidor al que le pedimos que lo haga.

¿Sin embargo, como hace el origen para determinar los Net-Id del origen y destino sin la máscara del
destino? El origen conoce su configuración propia, su propia máscara de subred y la dirección del
destino. El problema es que no sabe la configuración del destino, es decir su máscara. Para averiguar
esto, hacemos una operación AND lógica entre la IP origen y la máscara del origen, para saber a que
subred pertenece esta y si luego hacemos esto mismo entre la IP de destino y la máscara del origen,
podemos averiguar si pertenece a la misma red que el origen, y entonces también, si comparten la
misma máscara. Si esto no es así, lo único que puede determinar el origen es que el destino no está en la
misma subred.

Entonces, si coincide la dirección de red de ambas direcciones, se puede hacer entrega directa. Todo el
datagrama IP, viaja con la trama de capa 2. Recordemos que en el encabezado de capa 2 que se le
agrega al datagrama, se especificaban direcciones de origen y destino, solo que estas son de capa 2, es
Matías Baeza Graf #29654
2021

decir que son direcciones MAC de 48 bits (6 bloques de 2 caracteres hexadecimales u 8 bits). Estas
direcciones corresponden de forma única a una interfaz de red.

Entonces tenemos que para la capa 3 existen dos direcciones IP, origen y destino y para la capa 2 existen
dos direcciones MAC, origen y destino.

La capa 2 también tiene direcciones de broadcast, es decir cuando todos sus bits son 1, es decir, en
hexadecimal ff:ff:ff:ff:ff:ff.

Entonces el origen a nivel capa 3 sabe a qué dirección IP enviar, sin embargo, también es necesario
conocer la MAC de destino, porque la capa 2 no puede hacer nada con la IP. ¿Entonces, de donde salen
las direcciones MAC para completar el encabezado de la trama? Porque la capa 3 no conoce la MAC del
destino, porque no existe ninguna relación entre la dirección MAC y la dirección IPv4.

ARP

Para resolver el problema, está el protocolo ARP (Address

Resolution Protocol). Este es el responsable de encontrar la
dirección MAC que corresponde a una determinada dirección IP.
ARP arma una tabla en la cual va asociando una dirección IP con
la MAC correspondiente. Esta tabla se va actualizando de
manera dinámica, porque recordemos que las IP pueden
cambiar. O podemos cambiar piezas de hardware (cambia la
MAC), sin cambiar la configuración IP.
Matías Baeza Graf #29654
2021

¿Como funciona ARP? A le quiere mandar algo a B, pero para hacerlo debe
conocer la MAC de B. Entonces primero se fija si la MAC asociada a la IP de B
está en la tabla ARP. Si es así se envían los datos. Si no es así, A envía una
solicitud ARP, preguntando la MAC de la IP de B. Cuando se reciba la
respuesta, la información se agrega a la tabla y ahora es posible enviar los
datos.

Como no conocemos la MAC, no podemos hacerle la petición directamente

a B. Por eso el envío de la petición ARP, se hace mediante un broadcast de capa 2, es decir
FF:FF:FF:FF:FF:FF. En esta petición, está indicado de quién quiero averiguar la MAC.

En la solicitud ARP, se tienen

los campos para las
direcciones IP del origen y el
destino, así como las
direcciones MAC de origen y
destino. El campo MAC
destino, está con todos sus
bits en 0, porque es el que no
se conoce. ARP le pide
servicios a la capa inferior
para poder cumplir su función,
es decir a la capa 2. Esta petición viaja en una trama Ethernet, y la van a recibir tanto el destino como los
demás equipos adyacentes. La capa 2 desentrama y le pasa la información a ARP en todos los equipos.
Entonces cada equipo que la recibe, se fija si la IP destino coincide con la suya. A nivel de capa 2, todos
los dispositivos procesan la solicitud, en capa 3, no es así. Cuando B arma la respuesta, B ya conoce la
dirección MAC de A, porque en la solicitud ARP que recibió, consiguió no solo la IP de A, sino también la
MAC.

Con esta información se empieza a armar la tabla ARP,

llamada Caché ARP. Se debe mantener una caché de las
asociaciones IP / MAC recientemente adquiridas.
Cuando se agrega una fila a la caché, se inicia un
temporizador, que cuando se agota, esta fila se borra.
Entonces en el siguiente datagrama que haya que enviar
a B, hay que nuevamente arrancar el proceso de
petición/respuesta ARP. Si A está haciendo una
transmisión muy grande a B, cada cierta cantidad de
tiempo va a haber que hacer una pausa en el envío de
datos, para volver a obtener la MAC de B. Entonces
antes de enviar el siguiente datagrama, hay una pausa
para que se de este proceso.

Para evitar esta flucutación en el envío, se agregó la

posibilidad de una revalicadión temprana, es decir un
segundo temporizador. Entonces cuando se agrega una
Matías Baeza Graf #29654
2021

fila, arrancan dos temprizadores, el de revalidación y el de caché, siendo el primero apenas mas corto
que el segundo. Cuando se vence el de revalidación, se verifica si recientemente se enviaron datagramas
a esa IP / MAC. Antes que haya que borrar la fila, se envía una solicitud ARP para que todo el proceso
petición/respuesta se haga antes de que la fila se borre.

REFINAMIENTOS ARP

Si A envía una solicitud ARP a B, entonces B puede aprovechar e insertar en su cache la IP/MAC de A. Así
no hay que hacer el mismo proceso cuando B quiera enviar algo a A.

Así como B recibe la solicitud ARP, lo hacen todos los dispositivos adyacentes a A. Entonces solo si los
demas dispositivos, sean C y D, ya tienen la IP de A, van a poder revalidar la MAC de A. Es decir que
reinician el temporizador de caché. Si no tienen la IP de A, no se hace nada, sino que se ignora la
petición ARP.

Por último, si en una computadora se reemplaza su interfaz de host, reemplaza su dirección MAC, o
también cuando una placa se reinicia por ejemplo, se va a enviar via broadcast, una solicitud ARP
gratuita. Es como una carta de presentación del host. Los que no saben nada de la IP o MAC de esta, la
ignora. Los que tienen información de la IP o la MAC de este host, actualizan su caché ARP.

Mediante un software malicioso, puedo enviar peticiones ARP con información falsa (IP o MAC falsas).
Entonces ARP antes de agregar una fila a la caché, puede validarla para ver si es verdadera. Para hacer
esto, se envía una petición ARP al emisor original. Entonces si este responde, significa que la petición del
emisor original, proviene de un emisor real y no un impostor. Esto se llama ARP Spoofing.