ARP y RARP

Son protocolos de la capa de Enlace de Datos (Data Link Layer)

TCP usa el protocolo de resolución de dirección ARP (Address Resolution Protocol) y el de resolución inversa, Reverse Address Resolution Protocol RARP para iniciar el uso del direccionamiento en una red que usa su propio control de acceso al medio (MAC), como es el caso de Ethernet. ARP permite que un host se comunique con otro cuando sólo se conoce la dirección de internet (IP addess) de su vecino y desconocemos la dirección física. Antes de usar IP, el host origen envía un broadcast a todas las MAC addresses (ff.ff.ff.ff.ff.ff) de ARP con la dirección IP del sistema de destino deseado.

EL formato de ARP es:



Los valores del campo de operación pueden ser:
1 ARP request.
2 ARP response.
3 RARP request.
4 RARP response.
5 Dynamic RARP request.
6 Dynamic RARP reply.
7 Dynamic RARP error.
8 InARP request.
9 InARP reply.

Los RFC involucrados son el 1390, 1293, 826, 2390

Más sobre la capa de enlace de datos, más sobre las direcciones MAC, más sobre el direccionamiento IP

Para recordar (2)

Hay que tener presentes los protocolos y procesos de la capa de aplicación; Telnet es un programa de emulación de terminal que te permite entrar a un host remoto y ejecutar programas. FTP es un servicio orientado a conexión que permite transferir archivos. TFTP es un servicio orientado a no conexión que también transfiere archivos. SMTP es un programa que permite enviar correo.

Los protocolos de la capa de host-to-host (transporte) son TCP, que es orientado a conexión y nos da un servicio de red confiable por medio del uso de acknowledgements y control de flujo. UDP es un protocolo sin conexión que con un overhead pequeño nos da un servicio considerado no confiable.

Los protocolos de la capa de Internet son IP, que es un protocolo no orientado a conexión que provee direccionamiento de red y enrutamiento a través de una red. ARP que encuentra direcciones MAC para una IP conocida. RARP que encuentra la IP de una MAC address conocida. ICMP provee diagnóstico y mensajes de estado de los destinos buscados.

Los rangos de clase de las direcciones IP:
Clase A, de 1.0.0.0 a 126.255.255.255 con 8 bits de red y 24 bits de host.
Clase B, de 128.0.0.0 a 191.255.255.255 con 16 bits de red y 16 bits de host.
Clase C, de 192.0.0.0 a 223.255.255.255 con 24 bits de red y 8 bits de host.

Los rangos de direccionamiento privados;
de 10.0.0.0 a 10.255.255.255
de 172.16.0.0 a 172.31.255.255
de 192.168.0.0 a 192.168.255.255

Recordemos que la dirección 127.0.0.1 está asignada al host local, es la dirección de loopback y es usada para diagnósticos sobre el funcionamiento de nuestro propio stack de TCP, cuando hacemos un ping a esta dirección, el paquete no llega a la interfase física.

Mapa de protocolos

He notado que muchas personas se preguntan, ¿en qué capa del modelo OSI se encuentra X protocolo?, o ¿cuáles son los protocolos de la capa de aplicación? o ¿de la capa de transporte?

Bueno, he aquí un mapa con los principales protocolos de red y su ubicación dentro del modelo de referencia OSI:

*update: faltó mencionar Frame Relay en la capa de enlace de datos (Data Link) junto a ATM

Ejemplo de Encapsulamiento (ilustración del datagrama)

Tomando el caso del ejemplo anterior, el datagrama será analizado en fragmentos de 8 bytes, indicando la longitud de cada campo; recordemos que es un paquete de ICMP encapsulado en IP.

Del byte 0 al 7:

y tenemos la siguiente información de sus campos:



IHL: Especifica la longitud del encabezado de IP en palabras de 32 bits (4 Bytes) y el valor mínimo es 5.

TOS: Type of service, 8 bits, especifica los parámetros para el tipo de servicio solicitado. Los parámetros pueden ser utilizados por las redes para defini el manejo del datagrama durante el transporte. El bit M fue agregado en el RFC 1349.



Total Lenght: es la longitud total del datagrama, en este caso es 0x003C (60 bytes).

Identification: Usado para indentificar fragmentos de un datagrama deaquellos de otro. El módulo de protocolo que origina al datagrama fija el valor del campo de identificación a un valor que debe ser único para el par de Fuente-Destino y protocolo por todo el tiempo que el datagrama estará activo en el sistema de red. El módulo de protocolo de origen de un datagrama completo pone los bits MF y el Fragment Offset a cero.



Fragment Offset, 13 bits: usado para dirigir el reensamblado de un datagrama fragmentado. En este caso es cero porque no hay más fragmentos.

Del byte 8 al 15:

TTL: Time to live, es un temporizador para llevar un control del tiempo de vida del datagrama. Cuando el TTL es decrementado a cero, el datagrama es desechado.

Protocol: este campo especifica el protocolo encapsulado, en este caso el valor es 1, lo que nos indica que se trata de un paquete de ICMP (ping). Consulta los valores en la tabla (click aquí).

Header Checksum: 16 bits de la suma de verificación del encabezado de IP y las opciones IP.

Source IP Address: Es la dirección IP del transmisor, en este caso 192.168.1.1 (0xC0.A8.01.01).

Del byte 16 al 27:

Destination IP Address: es la dirección IP del destino, en este caso 192.168.1.17 (0xC0.A8.01.11).

C, Class y Option: en este caso indican (tabla de valores):

• 0x0: no copiar


• 0x00: mensaje de control


• 0x1000: solicitud de Echo (RFC 792, Summary of Message Types, 8 Echo).

Padding: es de longitud variable y sirve como relleno para asegurar que los datos comienzan tras de una frontera de 32 bits después de la dirección de destino.

Aquí es importante destacar que al tratarse de un mensaje de control (ICMP) se utilizan los bytes del 20 al 27 para información de control; y se usan de la siguiente manera (RFC792):

    20                  21                  22                  23
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Type           Code                Checksum            
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Identifier                  Sequence Number       
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Data ...

  +-+-+-+-+-

De aquí obtenemos que:

• byte 20, es un paquete tipo 8 (echo request)
• byte 21, siempre va a cero
• byte 22 y 23, es el checksum de ICMP
• bytes 24 y 25, si el byte 21=0 el identificador ayuda a hacer match entre las solicitudes y las respuestas de eco; puede ser 0 o puede usarse para identificar una sesión.
• bytes 26 y 27 son para llevar la secuencia de las solicitudes de eco, y quien responde debe usar el mismo número; la secuencia debe incrementarse con cada nueva solicitud (en una instrucción típica de ping se envían 4 paquetes, y pueden enviarse cuantos se desee).

Bytes del 28 al 59 (32 bytes)

Son los datos de relleno que se colocaron dentro del mensaje de Echo, y se trata de una secuencia, del 0x61 al 0x77, y se vuelve a comenzar. Cuando se responde la solicitud de eco se debe incluir exactamente la misma información en el campo de datos.

Ejemplo de Encapsulamiento

Para comenzar, la dirección de origen usada 192.168.1.1 se escribe así en hexadecimal: C0 A8 01 01

Cuando escribimos el comando:

C:\>ping 192.168.1.1

Este es el paquete de Ping (74 Bytes)como aparece en la red Ethernet, y cada par de números representa un byte (8 bits) de información dentro del frame o paquete:

[sourcecode language='css']
000000: 00 A0 CC 63 08 1B 00 40 : 95 49 03 5F 08 00 45 00 ...c...@.I._..E.

000010: 00 3C 82 47 00 00 20 01 : 94 C9 C0 A8 01 01 C0 A8 .<.G.. ...... ..

000020: 01 11 08 00 48 5C 01 00 : 04 00 61 62 63 64 65 66 .@..H\....abcdef

000030: 67 68 69 6A 6B 6C 6D 6E : 6F 70 71 72 73 74 75 76 ghijklmnopqrstuv

000040: 77 61 62 63 64 65 66 67 : 68 69 wabcdefghi......

[/sourcecode]

donde tenemos que los primeros 14 bytes componen el encabezado Ethernet, y son:

• 00 A0 CC 63 08 1B la dirección MAC de destino
• 00 40 95 49 03 5F la dirección MAC de origen
• 08 00 el campo Tipo de Ethernet (0x0800 IP Datagram)

sigue el datagrama de IP (60 Bytes), que ya sin el encapsulado de Ethernet nos queda así:

[sourcecode language='css']
000000: 45 00 00 3C 82 47 00 00 : 20 01 94 C9 C0 A8 01 01 E..<.G.. ......

000010: C0 A8 01 11 08 00 48 5C : 01 00 04 00 61 62 63 64 ...@..H\....abcd

000020: 65 66 67 68 69 6A 6B 6C : 6D 6E 6F 70 71 72 73 74 efghijklmnopqrst

000030: 75 76 77 61 62 63 64 65 : 66 67 68 69 uvwabcdefghi......

[/sourcecode]

y comienza con un valor 0x4500, el 4 indica que es un paquete de IPv4 y el 5 que el encabezado de IP tiene una longitud de 5 palabras de 32 bits; es decir, 160 bits o 20 bytes.

tenemos una dirección de origen 192.168.1.1 (C0 A8 01 01)
y una dirección de destino 192.168.1.17 (C0 A8 01 11)

y nos quedan 40 bytes de datos IP, que en este caso son de una solicitud de eco (ICMP Echo Request), incluyendo 32 bytes de datos (longitud por default para un paquete de ping).

Este post es un complemento al anterior:

http://ipref.wordpress.com/2008/06/03/encapsulamiento/

y posteriormente pondré una descripción detallada de cada uno de los números presentes en el frame de ejemplo.

Movilidad IPv6

del documento de cisco: IPv6 Mobility At-a-Glance

Los objetivos de la movilidad de IPv6 son:

• no estar limitado a una ubicación
• tener siempre conectividad IP
• que sea independiente del transporte
• conexiones en roaming robustas
• movilidad de las aplicaciones
• continuidad de las aplicaciones
• que un server pueda ser un dispositivo móvil

Mobile IPv6 (MIPv6) se define en:

• RFC 3775: Mobility Support in IPv6
• RFC 3776: Using IPSec to Protect Mobile IPv6 Signalling between Mobile Nodes and Home Agents

Existen los mismos componentes básicos en MIPv6 como en MIPv4, excepto que no hay agentes externos en MIPv6.

figura 1

[caption id="" align="alignnone" width="445" caption="MIPv6"][/caption]

Data Link Layer, el hardware.

En la capa de enlace de datos operan los switches y los bridges, y son hardware de aplicación específica ya que usan procesadores y circuitos que son diseñados únicamente para esta tarea. (application-specific integrated cirtuit), y es lo que permite que los switches alcancen velocidades de proceso de Gigabits con latencias muy bajas.

Menciono brevemente los dispositivos en una entrada previa:

http://ipref.blogspot.com/2009/04/dispositivos-de-red-capa-de-enlace-de.html

El proceso es el siguiente:

El switch recibe un frame y lee su encabezado, determina su origen y lo pone en su tabla para recordar de que puerto provino; entonces, busca el destino en esa misma tabla y envía el frame hacia el puerto asociado a esa dirección MAC; en caso de desconocer el destino, el frame es enviado a todos los puertos excepto al de origen, y cuando reciba un nuevo frame con esa dirección MAC de origen, sabrá de que puerto proviene, y la agregará a su tabla, por lo que conocerá donde está ubicado ese host. Así van formando su tabla de MAC addresses que ayuda a disminuir el tráfico en la red y a formar un mapa de la misma. Todos los dispositivos que reciben este mensaje están en un dominio de Broadcast, y si tenemos muchos mensajes de broadcast, afectarán el desempeño de la red.



Es algo similar a una tabla de ruteo, que contiene redes en un router y que las asocia a una interface, con lo que el router conoce hacia donde enviar paquetes para alcanzar una red.

En el caso de un switch o un bridge, conocemos direcciones MAC que se asocian igualmente a un puerto o interface, y básicamente, un switch es un bridge evolucionado, con más puertos y que igualmente forma un dominio de colisión en cada puerto.

Anteriormente mencioné que Ethernet funciona en un bus lógico y por tanto los hosts presentes en ese dominio deben "competir" para tener acceso al medio (cable) y que no se presenten colisiones; debido a que cada puerto de un switch es un dominio de colisión distinto, todos pueden transmitir simultáneamente siempre y cuando exista sólo un host por puerto, mientras que en un Hub, todos deberán competir por el medio.

Una vez que la tabla está completa en el switch, se enviarán frames sólo hacia la interface que se sabe que tiene conectado al segmento de destino, y en caso de que el frame vaya destinado al mismo puerto del que vino será bloqueado para que no llegue a ningún otro segmento de red. Esto se llama Transparent Bridging.

La Capa de Enlace de Datos

La capa de enlace de datos (data link layer) provee la transmisión física de los datos y se encarga de detectar errores, de la topología de la red y del control de flujo; es decir, se encarga de que los mensajes lleguen a sus destinatarios usando la dirección física (MAC address) y traduce los mensajes de la capa de red en bits que la capa física transmitirá.

Los mensajes son divididos en fragmentos que se llaman marco de datos (data frames) y yo me referiré a ellos por su nombre en inglés, ya que considero que parte de entender una materia es conocer su lenguaje técnico. Cada frame, al igual que las unidades de datos de capas superiores (PDU o packet data unit) contienen un encabezado, al que se le agrega la información del destino y el origen (en direcciones MAC, no IP), pero en este caso, tenemos un elemento de empaquetamiento al final, que sirve para detectar errores y es el Cyclic Redundancy Check (CRC revisión de redundancia cíclica) y que es un número que se calcula a través del valor de los bits contenidos dentro del mensaje; en caso de que al recibir el frame y recalcular el CRC, éste no coincida con el enviado, se notificará para que sea transmitido nuevamente.



Es importante distinguir que un router no trabaja en esta capa, ya que sólo conoce redes, no sabe donde se ubica un host en particular, y manda paquetes hacia la red que debe contener ese host, pero no sabe si el host está ahí. Es el switch quien determina en que puerto se encuentra un host particular y lo hace a través de sus tablas de MAC addresses, no usa las direcciones IP, y envía frames que contienen paquetes encapsulados.

La capa de enlace de datos es la capa 2 del modelo OSI, y contiene dos subcapas, LLC (Logical Link Control) y MAC (Media Access Control), ambas están definidas por estándares en cuanto que tareas deben efectuar para que la capa de red se sirva de ellas y la capa física entienda los mensajes.

La subcapa MAC es la que está ubicada sobre la capa física, y sobre la MAC se encuentra la LLC, en contacto directo con la capa de red.

Ahora bien, Ethernet trabaja en la capa 2, y por tanto tiene una capa MAC y una LLC. En este caso, MAC se define por el estándar IEEE 802.3, que especifica como los paquetes entran al medio; también aquí se define el direccionamiento físico (MAC addresses) así como las topologías lógicas, es decir, la manera en la que se transmite en la línea (bus lógico en el caso de Ethernet, aunque un switch presente una topología física de estrella), también la notificación de errores (no corrige), la entrega de frames, y a veces control de flujo.

La LLC se define por IEEE 802.2 y es responsable de identificar los protocolos de la capa de red y de encapsularlos. El encabezado de LLC le dice a la Data Link Layer que hacer con los paquetes una vez que recibe un frame, ya que el host recibe el frame, lee el encabezado LLC y determina el destino de ese paquete encapsulado. La LLC provee también control de flujo y bits de control para las secuencias (orden de los frames).

Definiendo la capa de Transporte

Comunicación entre dispositivos.
Las redes de computadoras usan muchos protocolos, aquí se definirán los protocolos de comunicación en un entorno de red.
Cuando un dispositivo se comunica con otro, intercambian una serie de mensajes. Para entender y actuar en estos mensajes, los dispositivos deben estar de acuerdo en el formato y el orden de los mensajes intercambiados, así como las acciones tomadas en la transmisión o recibo de dichos mensajes.
Los dispositivos que se comuncan usan una serie de reglas, llamadas protocolo, para definir sus tareas, diferentes protocolos cumplen diferentes funciones.

Definiendo el campo de Protocolo.

IP usa un número de protocolo en el el encabezado para identificar cual protocolo usar para un datagrama en particular. El ruteador lee el número de protocolo del encabezado, lo compara a las entradas en la tabla de protocolos de transporte, y entonces lo pasa al protocolo apropiado. Por ejemplo, si el número es 6, IP entrega el datagrama a TCP; si el número de protocolo es 17, IP lo entrega a UDP.

Aunque casi siempre se usa TCP o UDP, hay otros protocolos que pueden usar IP, hay aproximadamente 100 protocolos registrados para propósitos especiales. Los números usados por protocolosTCP son asignados y publicados por un grupo llamado Internet Assigned Numbers Authority (IANA). Los números asignados por la IANA son documentados en el RFC1700.

• Protocolo [Campo de Protocolo ]
• Transmission Control Protocol (TCP) 6
• User Datagram Protocol (UDP) 17
• Internet Control Message Protocol (ICMP) 1
• IPv6 41
• ICMP para IPv6 58
• EIGRP 88

http://www.iana.org/assignments/protocol-numbers

No. Protocol
0 IPv6 Hop-by-Hop Option
1 Internet Control Message
2 Internet Group Management
3 Gateway-to-Gateway
4 IP in IP (encapsulation)
5 Stream
6 Transmission Control
7 CBT
8 Exterior Gateway Protocol
9 any private interior gateway
10 [SGC]
11 Network Voice Protocol
12 PUP
13 ARGUS
14 EMCON
15 Cross Net Debugger
16 Chaos
17 User Datagram
18 Multiplexing
19 DCN Measurement Subsystems
20 Host Monitoring
21 Packet Radio Measurement
22 XEROX NS IDP
23 Trunk-1
24 Trunk-2
25 Leaf-1
26 Leaf-2
27 Reliable Data Protocol
28 Internet Reliable Transaction [RFC938
29 ISO Transport Protocol Class 4 [RFC905
30 Bulk Data Transfer Protocol
31 MFE Network Services Protocol [MFENET
32 [HWB]
33 Sequential Exchange Protocol
34 Third Party Connect Protocol
35 Inter-Domain Policy Routing Protocol [MXS1]
36 XTP
37 Datagram Delivery Protocol
38 IDPR-CMTP IDPR Control Message Transport Proto [MXS1]
39 TP++ Transport Protocol
40 IL Transport Protocol
41 Ipv6
42 Source Demand Routing Protocol
43 [Deering]
44 [Deering]
45 Inter-Domain Routing Protocol [Sue Hares]
46 Reservation Protocol
47 General Routing Encapsulation
48 Mobile Host Routing Protocol[David Johnson]
49 BNA
50 Encap Security Payload for IPv6 [RFC2406]
51 Authentication Header for IPv6
52 Integrated Net Layer Security TUBA [GLENN]
53 IP with Encryption
54 NBMA Address Resolution Protocol [RFC1735]
55 IP Mobility
56 Transport Layer Security Protocol [Oberg] using Kryptonet key management
57 SKIP
58 [RFC1883]
59 [RFC1883]
60 [RFC1883]
61 [IANA]
62 CFTP
63 [IANA]
64 [SHB]
65 [PXL1]
66 MIT Remote Virtual Disk Protocol
67 Internet Pluribus Packet Core
68 [IANA]
69 SATNET Monitoring
70 VISA Protocol
71 Internet Packet Core Utility
72 Computer Protocol Network Executive [DXM2]
73 Computer Protocol Heart Beat
74 Wang Span Network
75 Packet Video Protocol
76 [SHB]
77 SUN ND PROTOCOL-Temporary
78 WIDEBAND Monitoring
79 WIDEBAND EXPAK
80 ISO Internet Protocol
81 VMTP
82 [DRC3]
83 VINES
84 TTP
85 [HWB]
86 Dissimilar Gateway Protocol
87 TCF
88 EIGRP
89 OSPFIGP
90 [SPRITE
91 Locus Address Resolution Protocol
92 Multicast Transport Protocol
93 AX.25 Frames
94 IP-within-IP Encapsulation Protocol [JI6]
95 Mobile Internetworking Control Pro. [JI6]
96 Semaphore Communications Sec. Pro.
97 Ethernet-within-IP Encapsulation [RFC3378]
98 Encapsulation Header
99 [IANA]
100 GMTP
101 Ipsilon Flow Management Protocol [Hinden]
102 PNNI over IP
103 Protocol Independent Multicast [Farinacci]
104 ARIS
105 SCPS
106 QNX
107 Active Networks
108 IP Payload Compression Protocol [RFC2393]
109 Sitara Networks Protocol
110 [Volpe]
111 [Lee]
112 Virtual Router Redundancy Protocol [RFC3768]
113 PGM Reliable Transport Protocol [Speakman]
114 [IANA]
115 Layer Two Tunneling Protocol
116 D-II Data Exchange (DDX)
117 Interactive Agent Transfer Protocol [Murphy]
118 Schedule Transfer Protocol
119 SpectraLink Radio Protocol
120 UTI
121 Simple Message Protocol
122 SM
123 Performance Transparency Protocol
124 [Przygienda]
125 [Partridge]
126 Combat Radio Transport Protocol
127 Combat Radio User Datagram
128 [Waber]
129 [Hollbach]
130 Secure Packet Shield
131 [Petri]
132 SCTP Stream Control Transmission Protocol [Stewart]
133 Fibre Channel
134 [RFC3175]
135[RFC-ietf-mobileip-ipv6-24.txt]
136 [RFC-ietf-tsvwg-udp-lite-02.txt]
137 unassigned
252
253 [RFC3692]
254 [RFC3692]
255 [IANA]

Comparación entre el modelo OSI y la Pila de TCP

Similitudes

• Ambos modelos tienen capa de aplicación, pero incluyen servicios diferentes.


• Ambos tienen capas comparables de transporte y de red.


• Ambos asumen la tecnología de conmutación de paquetes, no de circuitos conmutados, (las redes de telefonía analógica son de conmutación de circuitos).

Diferencias

• TCP/IP combina las capas de presentación y sesión en un su capa de aplicación


• TCP/IP combina la capa Data-Link y Physical en su capa de Network Access.

Los protocolos de TCP/IP son los estándares alrededor de los cuales se desarrollo el Internet, así que la pila de TCP/IP ganó credibilidad sólo por sus protocolos. En contraste, las redes no están típicamente construidas en el modelo OSI, aunque se use como guía.

La Pila de Protocolos de TCP/IP

Junto al modelo OSI universalmente reconocido, está el estándar abierto de internet, que es la pila de protocolos de TCP/IP.

Este modelo tiene 4 capas, y algunos autores consideran que la capa inferior debería ser dividida en dos, y sus niveles son:

Capa de Aplicación: maneja los protocolos de alto nivel, incluyendo los asuntos de representación, codificación y control de diálogo. Esta capa maneja todo lo relacionado con aplicaciones y que se empaquen los datos adecuadamente para la siguiente capa.

Capa de Transporte: Esta capa maneja la calidad de servicio, confiabilidad, control de flujo y corrección de errores. Uno de sus protocolos es el Transmission Control Protocol (TCP), que provee de comunicaciones de red confiables, orientadas a la conexión, a diferencia de UDP, no orientado a conexión.

Capa de Internet: el propósito de la capa de internet es enviar los paquetes de la fuente de cualquier red en el intenetwork y hacer que lleguen a su destino, sin importar la ruta que tomen para llegar ahí.

Capa de Acceso a la Red: el nombre de la capa engloba muchas cosas y es un poco confuso. También se llama host-to-host network layer. Incluye los protocolos LAN y WAN, y los detalles en las capas física y de enlace de datos del modelo OSI.

Encapsulamiento

Todas las comunicaciones de una red se originan en una fuente y son enviadas a un destino, aquí se explica cómo es el proceso de transmitir la información de un sitio a otro.

Si una computadora A quiere enviar datos a una computadora B, los datos deben ser empacados primero por un proceso llamado encapsulamiento. Este proceso puede pensarse como poner una carta dentro de un sobre, y poner las direcciones correctas del destinatario y el remitente para que sea entregada apropiadamente por el sistema postal.

El encapsulamiento envuelve los datos con la información de protocolo necesaria antes de transitar por la red. Así, mientras la información se mueve hacia abajo por las capas del modelo OSI, cada capa añade un encabezado, y un trailer si es necesario, antes de pasarla a una capa inferior. Los encabezados y trailers contienen información de control para los dispositivos de red y receptores para asegurar la apropiada entrega de de los datos y que el receptor interprete correctamente lo que recibe.