Capítulo 

4: Protocolos y servicios de red

Los analistas de ciberseguridad trabajan para identificar y analizar los rastros de incidentes de seguridad de la
red. Estos rastros consisten en registros de eventos de la red. Estos eventos, guardados en archivos de
registro de varios dispositivos, se componen principalmente de detalles de las operaciones de protocolo de
red. Las direcciones permiten identificar qué hosts se conectan entre sí (dentro de una organización) o con
hosts distantes en Internet. Las direcciones en los archivos de registro también determinan qué hosts se
conectaron (o intentaron conectarse) con hosts dentro de una organización. Otros rastros, en forma de
direcciones de protocolo, permiten identificar lo que intentaron hacer las conexiones de red, y si este
comportamiento era normal, sospechoso o perjudicial. Finalmente, los rastros de la red se registran para las
aplicaciones que nos permiten recibir y utilizar información de la red. Con todos estos rastros, los analistas de
ciberseguridad detectan amenazas a la seguridad de las organizaciones y sus datos.

Los analistas de ciberseguridad deben entender la red en la que viajan los datos normales para poder
detectar el comportamiento anormal creado por hackers, software malicioso y usuarios deshonestos
de la red. Los protocolos están en el centro de las comunicaciones de la red y los servicios de red
respaldan las tareas que realizamos en la red. En este capítulo, se brinda una perspectiva general
del comportamiento normal de las redes mediante el análisis de los protocolos en el conjunto de
protocolos TCP/IP y los servicios asociados que nos permiten realizar tareas en redes de
computadoras.

En la figura vemos un collage con el título del capítulo.

Vistas de la red

Hay redes de todo tamaño. Pueden ir desde redes simples, compuestas por dos PC, hasta redes que
conectan millones de dispositivos. Haga clic en los signos más (+) de las figuras para leer sobre los distintos
tamaños de redes.

Con frecuencia, las personas que trabajan desde una oficina en el hogar o remota y necesitan conectarse a
una red corporativa u otros recursos centralizados configuran redes de oficinas en el hogar y de oficinas
pequeñas. Además, muchos emprendedores independientes utilizan redes de oficinas en el hogar y de
oficinas pequeñas para publicitar y vender productos, hacer pedidos y comunicarse con clientes.

En las empresas y grandes organizaciones, las redes se pueden utilizar incluso de manera más amplia para
proporcionar consolidación y almacenamiento de la información en los servidores de red, así como acceso a
dicha información. Las redes también proporcionan formas de comunicación rápida, como el correo
electrónico y la mensajería instantánea, y permiten la colaboración entre empleados. Además de las ventajas
que perciben en el nivel interno, muchas organizaciones utilizan sus redes para ofrecer productos y servicios
a los clientes a través de su conexión a Internet.

Internet es la red más extensa que existe. De hecho, el término Internet significa “red de redes”. Internet es,
literalmente, una colección de redes privadas y públicas interconectadas.

La figura muestra diferentes tamaños y configuraciones para redes. La primera es una pequeña red
doméstica. Las redes domésticas pequeñas conectan algunas computadoras entre sí y a Internet. La segunda
es una red de oficinas pequeñas y oficinas en el hogar (o red SOHO) que permite que las computadoras de
una oficina en el hogar o una oficina remota se conecten a una red corporativa y tengan acceso a recursos
compartidos centralizados. La tercera es una red mediana o grande, como la que se utiliza en corporaciones y
escuelas, y puede tener muchas ubicaciones con cientos o miles de computadoras interconectadas. La cuarta
es la red informática mundial. Internet es una red de redes que conecta cientos de millones de computadoras
en todo el mundo.
Comunicaciones entre cliente y servidor

Todas las computadoras conectadas a una red que participan directamente en las comunicaciones de la red
se clasifican como hosts. Los hosts también se denominan terminales o nodos. Gran parte de la interacción
entre dispositivos terminales es tráfico entre cliente y servidor. Por ejemplo, cuando se tiene acceso a una
página web en Internet, el navegador (el cliente) tiene acceso a un servidor. Cuando se envía un mensaje de
correo electrónico, el cliente de correo se conecta a un servidor de correo electrónico.

Los servidores son simplemente computadoras con software especializado. Este software les permite a los
servidores brindar información a otros terminales de la red. Un servidor puede tener un solo propósito y
brindar un solo servicio, como páginas web. Un servidor puede ser multipropósito y brindar una variedad de
servicios, como páginas web, correo electrónico y transferencias de archivos.

Las computadoras cliente tienen software instalado, como navegadores web, correo electrónico y
herramientas de transferencia de archivos. Este software les permite solicitar y mostrar la información
obtenida desde el servidor. Una única PC también puede ejecutar varios tipos de software de cliente. Por
ejemplo, un usuario puede revisar su correo electrónico y ver una página web mientras oye la radio por
Internet. Haga clic en los signos más (+) en la figura para leer acerca de los diferentes clientes en una red de
cliente y servidor.

La figura es una actividad interactiva.

Seguir la ruta

Solemos pensar en las redes de datos que utilizamos en nuestra vida cotidiana como pensamos en conducir
un coche. No nos importa realmente lo que sucede en el motor, siempre y cuando el coche nos lleve donde
queremos ir. Sin embargo, al igual que un mecánico conoce los detalles de cómo funciona un coche, los
analistas de ciberseguridad necesitan comprender profundamente cómo funcionan las redes.

Cuando nos conectamos a un sitio web para consultar las redes sociales o hacer compras, rara vez nos
preocupamos por cómo llegan nuestros datos al sitio web y cómo regresan. No somos conscientes de las
numerosas tecnologías que nos permiten usar Internet. Una combinación de cables de cobre y fibra óptica
que van sobre la tierra y bajo el mar transportan el tráfico de datos. También se usan tecnologías inalámbricas
y por satélite de alta velocidad. Estas conexiones vinculan centros de telecomunicaciones e ISP que se
encuentran en todo el mundo, como se ve en la figura. Estos ISP mundiales de capa 1 y capa 2 conectan
partes de Internet entre sí, generalmente mediante un punto de intercambio de Internet (IXP, Internet
Exchange Point). Las redes de mayor tamaño se conectan a redes de capa 2 mediante un punto de presencia
(PoP, Point of Presence), que suele ser un lugar en el edificio donde se realizan las conexiones físicas al ISP.
Los ISP de capa 3 conectan hogares y empresas a Internet.

Debido a las diferentes relaciones entre ISP y empresas de telecomunicaciones, el tráfico de una
computadora a un servidor de Internet puede recorrer muchas rutas. El tráfico de un usuario en un país puede
recorrer un camino muy indirecto para llegar a su destino. Podría viajar primero desde el ISP local a un centro
que tenga conexiones con muchos otros ISP. El tráfico de Internet de un usuario puede recorrer muchos
cientos de millas en una dirección solamente para dirigirse en un sentido totalmente diferente para llegar a su
destino. Parte del tráfico puede recorrer ciertas rutas para llegar a su destino y, luego, rutas totalmente
diferentes para regresar.

Los analistas de ciberseguridad deben ser capaces de determinar el origen del tráfico que ingresa en la red y
el destino del tráfico que sale de ella. Entender el camino que recorre el de tráfico de la red resulta esencial
para esta tarea.

Hay 10 nubes conectadas por routers. La nube inferior está etiquetada como Usuarios de Internet (empresas,
clientes, etc.). Esta nube se conecta a dos nubes mediante 4 routers diferentes, cada una con la etiqueta Red
de categoría 3 (ISP multiconectado). La nube izquierda de la categoría 3 se conecta a una nube con la
etiqueta PoP 1 y a una nube con la etiqueta ISP de categoría 2. La nube de la red de la categoría 3 de la
derecha se conecta a esta misma nube de ISP de categoría 2 que, a su vez, se conecta a una nube con la
etiqueta Redes de la capa 1 en la parte superior derecha y con una nube con la etiqueta IXP. La nube de ISP
también se conecta al router situado directamente entre la nube Pop 1 y una nube encima que tiene la
etiqueta Redes de la categoría 2. La nube Redes de la categoría 1 en la parte superior derecha también se
conecta a un router que se encuentra entre la nube Redes de la categoría 2 y una nube con la etiqueta Pop 3.
La nube Redes de categoría 2 también tiene un router que se conecta entre ella y una nube Pop 2.
Práctica de laboratorio: Seguir una ruta

En esta práctica de laboratorio, utilizará dos utilidades de seguimiento de rutas para examinar la ruta de
Internet hacia las redes de destino. El primer paso será verificar la conectividad a un sitio web. El segundo
paso será emplear la utilidad traceroute en la línea de comandos de Linux. El tercer paso consistirá en utilizar
una herramienta traceroute con base en la web.

Práctica de laboratorio: Seguir una ruta

Esta página contiene una práctica de laboratorio titulada “Seguir una ruta”.
¿Qué son los protocolos?

Sin embargo, realizar simplemente la conexión física por cable o inalámbrica entre los terminales no es
suficiente para habilitar la comunicación. Para que se produzca la comunicación, los dispositivos deben saber
“cómo” comunicarse. La comunicación, ya sea cara a cara o por una red, está regida por reglas denominadas
protocolos. Estos protocolos son específicos del tipo de método de comunicación en cuestión.

Por ejemplo, considere a dos personas que se comunican cara a cara. Antes de comunicarse, deben acordar
cómo hacerlo. Si en la comunicación se utiliza la voz, primero deben acordar el idioma. A continuación,
cuando tienen un mensaje que compartir, deben poder dar formato a ese mensaje de una manera que sea
comprensible. Por ejemplo, si alguien utiliza el idioma español, pero la estructura de las oraciones es
deficiente, el mensaje se puede malinterpretar fácilmente. En la Figura 1, se ve un ejemplo de comunicación
que no respeta los protocolos para la gramática y el lenguaje.

La comunicación de protocolos de red funciona de la misma manera. Los protocolos de red ofrecen los
medios para que las computadoras se comuniquen en las redes. Los protocolos de red determinan la
codificación, el formato, la encapsulación, el tamaño, la distribución y las opciones de entrega del mensaje,
como se ve en la Figura 2. Como analista de ciberseguridad, debe estar muy familiarizado con la estructura
de los protocolos y cómo se utilizan en las comunicaciones de red.

En la Figura 1, hay dos oraciones que se usan para representar la importancia de establecer reglas en la
comunicación. La primera oración es una oración larga que no cuenta con espacios entre las palabras, lo cual
la hace difícil de leer. Una segunda oración está escrita en español y podría ser difícil de entender si el
receptor no habla el idioma. El alumno puede seleccionar el botón Traducir para agregar los espacios entre
las palabras y también traducir del español al inglés. En la Figura 2, hay un diagrama circular con la palabra
Protocolos en el centro y las características de los protocolos en las ramificaciones. Estas características
incluyen opciones de codificación, formatación y encapsulamiento, tamaño, sincronización y entrega de
mensajes.
Conjuntos de protocolos de red

Una suite de protocolos es un grupo de protocolos que trabajan en forma conjunta para proporcionar servicios
integrales de comunicación de red. Las suites de protocolos pueden estar especificadas por una organización
de estandarización o pueden ser desarrolladas por un proveedor.

Para que los dispositivos se puedan comunicar en forma exitosa, un nuevo conjunto de protocolos de red
debe describir los requerimientos e interacciones precisos. Los protocolos de red definen un formato y un
conjunto de reglas comunes para intercambiar mensajes entre dispositivos. Algunos de los protocolos de red
más comunes son Hypertext Transfer Protocol (HTTP), el protocolo de control de transmisión (TCP) y el
protocolo de Internet (IP).

Nota: en este curso, IP refiere a los protocolos IPv4 e IPv6. IPv6 es la versión más reciente de IP y, con el
tiempo, sustituirá al protocolo IPv4 más común.

De las figuras 1 a la 4, se ilustra el papel que desempeñan los protocolos de red:

  La manera en que se da formato o se estructura el mensaje, como se muestra en la Figura 1.

 El proceso por el cual los dispositivos de red comparten información sobre rutas con otras redes, como
se muestra en la Figura 2.

 La manera y el momento en que se transmiten mensajes de error y del sistema entre los dispositivos,
como se muestra en la Figura 3.

 La configuración y la terminación de sesiones de transferencia de datos, como se muestra en la figura 4.

En la Figura 1, se ve el rol que desempeñan los protocolos en las transferencias de datos. En la parte
superior, hay dos cuadros unidos. El cuadro de la izquierda está etiquetado como IP y el de la derecha se
denomina Datos. Hay tres routers conectados entre sí para formar un triángulo. El router inferior izquierdo se
conecta a una computadora de escritorio. El router inferior derecho se conecta a un servidor. El texto debajo
de la computadora dice “Enviaré este mensaje por la red mediante un encabezado de IPv4”. El texto debajo
del router que se conecta a la computadora dice “Puedo reenviar este mensaje porque entiendo el
encabezado de IPv4”. El texto debajo del servidor dice “Puedo aceptar este mensaje porque entiendo IPv4”.
El texto debajo de la figura dice “El formato o estructura de las partes de la comunicación”. La Figura 2
muestra routers compartiendo información acerca de la las rutas hacia otras redes. Es común que los routers
compartan información. La Figura 3 muestra routers que se comunican entre sí en relación a una ruta lenta
debido a otra ruta que se cayó; este intercambio de información es crítico para una red. La figura 4 muestra la
configuración y finalización de una sesión de transferencia de datos entre un host y un servidor.

La suite de protocolos TCP/IP

Las redes hoy utilizan el conjunto de protocolos TCP/IP. Haga clic en la sigla de cada protocolo en la figura
para ver su descripción y traducción. Los protocolos individuales se organizan en capas mediante el modelo
de protocolo TCP/IP: aplicación, transporte, Internet y capa de acceso a la red. Los protocolos TCP/IP son
específicos de las capas Aplicación, Transporte e Internet. Los protocolos de capa de acceso a la red son
responsables de entregar el paquete IP por el medio físico y por un cable de red o una señal inalámbrica.

El conjunto de protocolos TCP/IP se implementa tanto en los hosts emisores como en los receptores para
proporcionar una entrega de extremo a extremo de mensajes por la red. TCP/IP ha estandarizado la manera
en que se comunican las computadoras, lo que ha dado origen a Internet como la conocemos hoy.
Desgraciadamente, este uso generalizado ha atraído la atención de personas que quieren usar indebidamente
las redes. Gran parte del trabajo del analista de ciberseguridad abarca el análisis del comportamiento del
conjunto de protocolos TCP/IP.

En la figura, se enumeran las cuatro capas del conjunto del protocolo TCP/IP. Cada capa tiene protocolos que
tienen una descripción cuando se hace clic en ellos. La capa superior es la capa de aplicación y tiene
cinco secciones en su interior: nombre del sistema, configuración del host, correo electrónico, transferencia de
archivos y web. En el nombre del sistema está el botón del protocolo de DNS. El DNS o sistema de nombres
de dominio traduce nombres de dominio, como cisco.com, en direcciones IP. La configuración de host tiene
dos botones: BOOTP y DHCP. BOOTP es el protocolo de arranque que le permite a una estación de trabajo
sin disco detectar su propia dirección IP y la dirección IP de un servidor de BOOTP en la red, y cargar un
archivo en la memoria para iniciar la máquina. BOOTP será reemplazado por DHCP. DHCP es el protocolo de
configuración dinámica de host y asigna de manera dinámica direcciones IP a las estaciones de cliente
durante la fase de inicio, además de permitir que se reutilicen las direcciones cuando ya no se necesiten. En
la sección de correo electrónico hay tres protocolos: SMTP, POP e IMAP. SMTP es el protocolo simple de
transferencia de correo que les permite a los clientes enviar correo electrónico a un servidor de correo y les
permite a los servidores enviar correo electrónico a otros servidores. POP es el protocolo de oficina de correos
versión 3 (o POP3) que les permite a los clientes recuperar correo electrónico desde un servidor de correo y
descargar correo electrónico desde el servidor de correo al escritorio. IMAP es el protocolo de acceso a
mensajes de Internet que les permite a los clientes tener acceso a correo electrónico almacenado en un
servidor de correo y mantiene el correo electrónico en el servidor. La sección de transferencia de archivos
tiene los protocolos FTP y TFTP. El protocolo de transferencia de archivos (o FTP) establece las reglas que le
permiten a un usuario en un host tener acceso a archivos y transferirlos hacia y desde otro host por una red.
Es un protocolo confiable de entrega de archivos, orientado a la conexión y con acuse de recibo. El protocolo
trivial de transferencia de archivos o TFTP es un protocolo de transferencia de archivos sencillo sin conexión.
También es un protocolo de entrega de archivos sin acuse de recibo y de máximo esfuerzo que utiliza menos
sobrecarga que el FTP. El protocolo de web que se muestra es el de protocolo de transferencia de hipertexto
(o HTTP), que es un conjunto de reglas para el intercambio de texto, imágenes gráficas, sonido, vídeo y otros
archivos multimedia en la red informática mundial. En la siguiente capa hacia abajo en el gráfico, aparece la
capa de transporte, que se compone de los protocolos UDP y TCP. El protocolo de datagramas del usuario (o
UDP) permite que un proceso que se ejecuta en un host envíe paquetes a un proceso que se ejecuta en otro
host y no confirma la transmisión exitosa de los datagramas. El protocolo de control de transmisión (o TCP)
permite la comunicación confiable entre procesos que se ejecutan en hosts independientes y tiene
transmisiones fiables y con acuse de recibo que confirman la entrega exitosa. La tercera capa hacia abajo es
la capa de Internet. Esta capa tiene tres secciones principales: una sección que contiene botones para IP y
NAT, una sección de compatibilidad IP que contiene el protocolo ICMP, y una sección de protocolos de routing
que contiene botones para OSPF y EIGRP. IP es el protocolo de Internet y recibe segmentos del mensaje de
la capa de transporte, los empaqueta y los direcciona para entregarlos de extremo a extremo en una
interconexión de redes. La traducción de direcciones de redes (o NAT) traduce direcciones IP de una red
privada a direcciones IP públicas únicas en el mundo. El protocolo de mensajería de control de Internet (o
ICMP) proporciona información acerca de los errores en la entrega de paquetes desde un host de destino a
uno de origen. El protocolo para abrir primero la ruta más corta (u OSPF) es un protocolo de routing de estado
del enlace que tiene un diseño jerárquico con base en áreas. Es un protocolo de routing interior de estándar
abierto. El protocolo de routing de gateway interior mejorado (o EIGRP), que es un protocolo de routing
exclusivo de Cisco, utiliza una métrica compuesta en función del ancho de banda, la demora, la carga y la
confiabilidad. La última capa en la parte inferior es la capa de acceso de red que contiene 4 botones: ARP,
PPP, Ethernet y controladores de interfaz. El protocolo de resolución de direcciones (o ARP) proporciona
asignación dinámica de direcciones entre una dirección IP y una dirección de hardware. El protocolo de punto
a punto (o PPP) proporciona una manera de encapsular los paquetes para transmitirlos por un enlace serie.
Ethernet define las reglas para conectar y señalizar estándares de la capa de acceso a la red. Los
controladores de interfaz proporcionan instrucciones a una máquina para controlar una interfaz específica en
un dispositivo de red.

Formato, tamaño y sincronización

Los protocolos definen el formato, el tamaño y la sincronización de los diferentes tipos de mensajes.

Formatear

Cuando se envía un correo electrónico, el dispositivo usa los protocolos del conjunto de protocolos TCP/IP
para formatear el mensaje y enviarlo por la red. Esto es similar a enviar una carta por correo. Se coloca la
carta en un sobre con la dirección del remitente y la del destinatario, cada una escrita en el lugar adecuado
del sobre, como se ve en la Figura 1. Si la dirección de destino y el formato no son correctos, la carta no se
entrega. El proceso que consiste en colocar un formato de mensaje (la carta) dentro de otro formato de
mensaje (el sobre) se denomina encapsulamiento. Cuando el destinatario revierte este proceso y quita la
carta del sobre se produce el desencapsulamiento del mensaje.

De la misma manera en la que una carta se encapsula en un sobre para la entrega, los mensajes de las PC
también se encapsulan. Cada mensaje de computadora se encapsula en un formato específico, llamado
trama, antes de enviarse a través de la red. La estructura de la trama se analiza más adelante en este
capítulo.

Tamaño
Otra regla de comunicación es el tamaño. Cuando las personas se comunican en persona o por teléfono, una
conversación suele estar conformada por muchas oraciones breves para garantizar la recepción y
comprensión de cada parte del mensaje.

De manera similar, cuando se envía un mensaje extenso de un host a otro a través de una red, es necesario
separarlo en varias tramas, como se ve en la Figura 2. Cada trama, a su vez, tiene su propia información de
direccionamiento. En el host receptor, las tramas individuales del mensaje se vuelven a unir para reconstruir el
mensaje original.

Sincronización

La sincronización incluye el método de acceso (cuándo puede realizar envíos un host), el control de flujo
(cuánta información puede enviar un host al mismo tiempo) y el tiempo de espera de respuesta (cuánto
tiempo esperar por una respuesta). En este capítulo, analizaremos cómo los protocolos de red se ocupan de
la sincronización.

Unidifusión, multidifusión y difusión

Un mensaje se puede entregar de diferentes maneras. En algunos casos, una persona desea comunicar
información a un solo individuo. Otras veces, esa persona puede necesitar enviar información a un grupo de
personas simultáneamente o, incluso, a todas las personas de un área.

Los hosts en una red utilizan opciones de entrega similares para comunicarse, como se ve en la figura.

Una opción de entrega de uno a uno se denomina “unidifusión”, que significa que el mensaje tiene solo un
destinatario.

Si un host necesita enviar mensajes utilizando una opción de uno a varios, se denomina “multidifusión”.

Si es necesario que todos los hosts de la red reciban el mensaje a la vez, se utiliza el método de difusión. La
difusión representa una opción de entrega de mensaje de uno a todos.

Modelos de referencia

Como se mencionó anteriormente, el conjunto de protocolos TCP/IP está representado por el modelo de
cuatro capas: aplicación, transporte, Internet y acceso a la red. Otro modelo de referencia conocido es el
modelo de interconexión de sistemas abiertos (OSI, Open Systems Interconnection), que utiliza un modelo de
siete capas, como se ve en la figura. En la documentación sobre redes, cuando se hace referencia a una capa
con un número (p. ej., capa 4), la referencia utiliza el modelo OSI. Para hacer referencia a las capas, el
modelo TCP/IP utiliza el nombre de la capa, p. ej., capa de transporte.

El modelo de referencia OSI

El modelo OSI proporciona una amplia lista de funciones y servicios que se pueden presentar en cada capa.
También describe la interacción de cada capa con las capas directamente por encima y por debajo de él.
Haga clic en cada capa del modelo OSI de la figura 2 para ver los detalles.

Modelo de protocolo TCP/IP

El modelo de protocolo TCP/IP para comunicaciones de internetwork se creó a principios de la década del
setenta. Como se muestra en la figura 3, en ella se definen cuatro categorías de funciones que deben ocurrir
para que las comunicaciones se lleven a cabo correctamente.

Tres direcciones
Los protocolos de red exigen el uso de direcciones para la comunicación de red. El cliente usa el
direccionamiento para enviar solicitudes y otros datos a un servidor. El servidor utiliza la dirección del cliente
para regresar los datos solicitados al cliente que los pidió.

Los protocolos funcionan en capas. Las capas de OSI de transporte, red y enlace de datos utilizan todas
algún tipo de direccionamiento. La capa de transporte utiliza direcciones de protocolo en forma de números de
puerto para identificar aplicaciones de red que deben procesar datos de cliente y servidor. La capa de red
especifica direcciones que identifican las redes a las que los clientes y servidores están conectados, y los
clientes y servidores propiamente dichos. Por último, la capa de enlace de datos especifica los dispositivos de
la red LAN local que deben manejar tramas de datos. Las tres direcciones son necesarias para la
comunicación entre cliente y servidor, como se ve en la figura.

Encapsulamiento

Como hemos visto, los datos se dividen en partes más pequeñas y manejables para enviarlas por la red. Esta
división de los datos en partes más pequeñas se denomina segmentación. La segmentación de mensajes
tiene dos beneficios principales.

 Segmentación: este proceso aumenta la eficiencia de las comunicaciones de red. Si parte del mensaje
no logra llegar al destino debido a una falla en la red o a congestión, solo se deben retransmitir las
partes faltantes.

 Multiplexación: al enviar partes individuales más pequeñas del origen al destino, se pueden intercalar
muchas conversaciones diferentes en la red. Este proceso se denomina multiplexación.

Haga clic en cada botón de la figura 1 y, a continuación, haga clic en el botón Reproducir para ver las
animaciones de segmentación y de multiplexión.

En las comunicaciones de red, cada segmento del mensaje debe estar correctamente etiquetado para
garantizar que llegue al destino correcto y que pueda volver a ensamblarse en el contenido del mensaje
original, como se ve en la Figura 2.

Mientras los datos de la aplicación bajan a la pila del protocolo y se transmiten por los medios de la red, se
encapsulan con diversa información de protocolos en cada nivel.

La forma que adopta una parte encapsulada de los datos en cualquier capa se denomina unidad de datos del
protocolo (PDU, Protocol Data Unit). Cada capa sucesiva encapsula las PDU que recibe de la capa anterior de
acuerdo con el protocolo que se utilice. En cada etapa del proceso, una PDU tiene un nombre distinto para
reflejar sus funciones nuevas. Aunque no existe una convención universal de nomenclatura para las PDU, en
este curso, se denominan de acuerdo con los protocolos del conjunto de protocolos TCP/IP, como se ve en la
Figura 3. Haga clic en el signo más (+) en cada PDU de la Figura 3 para obtener más información.

Cuando se envían mensajes en una red, el proceso de encapsulamiento opera desde las capas superiores
hacia las capas inferiores. En cada capa, la información de la capa superior se considera como datos en el
protocolo encapsulado. Por ejemplo, el segmento TCP se considera como datos en el paquete IP. En la
Figura 4, haga clic en Reproducir para ver el proceso de encapsulamiento cuando un servidor web envía una
página web a un cliente web.

El host emisor, primero convierte en bits los mensajes enviados a través de la red. Cada bit se codifica en un
patrón de sonidos, ondas de luz o impulsos electrónicos, según el medio de red a través del cual se
transmitan los bits. El host de destino recibe y decodifica las señales para interpretar el mensaje.

Este proceso se invierte en el host receptor, y se conoce como desencapsulamiento. Los datos se
desencapsulan mientras suben por la pila hacia la aplicación del usuario final. En la Figura 5, haga clic en el
botón Reproducir para ver el proceso de desencapsulamiento.
Situación: Envío y recepción de una página web

Para resumir el tema de protocolos y procesos de comunicación de red, analicemos la situación que supone el
envío y la recepción de una página web. En la Figura 1, se ven algunos de los protocolos utilizados entre un
servidor web y un cliente web:

 HTTP: este protocolo de aplicación rige la manera en que interactúan un servidor web y un cliente web.

 TCP: este protocolo de transporte gestiona conversaciones individuales. TCP divide los mensajes HTTP
en partes más pequeñas, llamadas “segmentos”. También es responsable de controlar el tamaño y los
intervalos a los que se intercambian los mensajes entre el servidor y el cliente.

 IP: es responsable de tomar los segmentos formateados del TCP, encapsularlos en paquetes,
asignarles las direcciones apropiadas y entregarlos al host de destino.

 Ethernet: este protocolo de acceso a la red es responsable de tomar los paquetes de IP y formatearlos
para transmitirlos por los medios.

En las Figuras 2 y 3, se ilustra el proceso de comunicación completo con un ejemplo de un servidor web que
transmite los datos a un cliente (Figura 2) y el cliente recibe los datos (Figura 3). Haga clic en el botón
Reproducir para ver las demostraciones animadas. Este proceso y estos protocolos se analizarán con más
profundidad en capítulos posteriores.

1. En la figura 2, la animación comienza con el servidor web preparando la página de lenguaje de marcado de
hipertexto (HTML) como los datos que se van a enviar.

2. El encabezado HTTP del protocolo de aplicación se agrega al frente de los datos HTML. El encabezado
contiene diversos tipos de información, incluida la versión de HTTP que utiliza el servidor y un código de
estado que indica que tiene información para el cliente web.

3. El protocolo de capa de aplicación HTTP entrega los datos de la página web con formato HTML a la capa
de transporte. El TCP segmenta los datos agregando los números de puerto de origen y destino.

4. Luego, la información IP se agrega al frente de la información TCP. IP asigna las direcciones IP de origen y
de destino que corresponden. Luego de este proceso, el segmento de TCP se encapsula en un paquete IP.

5. El protocolo Ethernet agrega información en ambos extremos del paquete IP para crear una trama. Esta
trama se entrega al cliente web mediante la red.

6. En la figura 3, la animación comienza con el cliente que recibe las tramas de enlace de datos que contienen
los datos. Cada encabezado de protocolo se procesa y luego se elimina en el orden inverso al que se agregó.
La información de Ethernet se procesa y se elimina, seguida por la información del protocolo IP, luego la
información de TCP y, finalmente, la información de HTTP.

7. A continuación, la información de la página web se transfiere al software de navegador web del cliente.

Los analistas de ciberseguridad son expertos en el uso de herramientas para ver el comportamiento de los
protocolos de red. Por ejemplo, Wireshark captura todos los detalles de los protocolos encapsulados en
paquetes y datos que viajan por la red. En este curso, nos centraremos en el uso de Wireshark y la
interpretación de los datos de Wireshark.

Práctica de laboratorio: Introducción a Wireshark

Wireshark es un analizador de protocolos de software o una aplicación “husmeador de paquetes” que se

utiliza para la solución de problemas de red, análisis, desarrollo de protocolo y software y educación.
Wireshark se utiliza en todo el curso para demostrar conceptos de red. En esta práctica de laboratorio, se
utilizará Wireshark para capturar y analizar el tráfico de la red.

Práctica de laboratorio: Introducción a Wireshark

Esta página contiene una práctica de laboratorio titulada “Introducción a Wireshark”.

El protocolo de Ethernet

Ethernet funciona en la capa de enlace de datos y la capa física, como se ve en la figura. Se trata de una
familia de tecnologías de red que se definen en los estándares IEEE 802.2 y 802.3. Ethernet depende de las
dos subcapas separadas de la capa de enlace de datos para funcionar. Estas subcapas son la subcapa de
control de enlace lógico (LLC, Logical Link Control) y la subcapa de control de acceso a medios (MAC, Media
Access Control).

LLC es el responsable de la comunicación con la capa de red. MAC lo implementa la tarjeta de interfaz de red
(NIC, Network Interface Card) de la computadora. La subcapa MAC tiene dos responsabilidades principales:

 Encapsulamiento de datos: Ethernet encapsula el paquete IP en una trama, agrega información de

sincronización, las direcciones MAC de destino y origen, y una función de comprobación de errores.

 Control de acceso a medios: Ethernet administra el proceso de convertir la trama en partes pequeñas
y enviarlo al exterior, hacia la red. En redes cableadas más antiguas, los dispositivos no podían enviar y
recibir datos al mismo tiempo. Esto todavía ocurre con las redes inalámbricas. En tales situaciones,
Ethernet utiliza un proceso para determinar cuándo un dispositivo puede realizar envíos y qué hacer si
los datos enviados por dos dispositivos chocan en la red. Analizaremos este proceso más adelante en
este capítulo.

La trama de Ethernet

El tamaño mínimo de trama de Ethernet es de 64 bytes, y el máximo es de 1518 bytes. Esto incluye todos los
bytes del campo “Dirección MAC de destino” hasta el campo “Secuencia de verificación de trama (FCS)”
inclusive. El campo “Preámbulo” no se incluye al describir el tamaño de una trama.

Cualquier trama con una longitud inferior a 64 bytes se considera un “fragmento de colisión” o “runt frame”.
Las tramas con más de 1518 bytes de datos se consideran “jumbo” o tramas bebés gigantes.

Si el tamaño de una trama transmitida es menor que el mínimo o mayor que el máximo, el dispositivo receptor
descarta la trama. Es posible que las tramas descartadas se originen en colisiones u otras señales no
deseadas y, por lo tanto, se consideran no válidas.

En la ilustración, haga clic en cada campo de la trama de Ethernet para leer más acerca de su función.

Formato de dirección MAC

Una dirección MAC de Ethernet es un valor binario de 48 bits expresado como 12 dígitos hexadecimales
(4 bits por dígito hexadecimal). Los dígitos hexadecimales usan los números del 0 al 9 y las letras de la A a la
F. En la Figura 1, se ven los valores decimales y hexadecimales equivalentes para los números binarios del
0000 al 1111. Los valores hexadecimales suelen usarse para representar datos binarios. Las direcciones IPv6
son otro ejemplo de direccionamiento hexadecimal.

Según el dispositivo y el sistema operativo, puede ver varias representaciones de direcciones MAC, como se
muestra en la figura 2.
Todos los datos que circulan por la red se encapsulan en tramas de Ethernet. Un analista de ciberseguridad
debe ser capaz de interpretar los datos de Ethernet capturados por los analizadores de protocolo y otras
herramientas.

Encapsulamiento de IPv4

Como sabemos, Ethernet funciona en la capa física y la capa de enlace de datos del modelo OSI. Nos
centraremos ahora en la capa de red. Al igual que la capa de enlace de datos encapsula paquetes IP como
tramas, la capa de red encapsula los segmentos de la capa de transporte en paquetes IP, como se ve en la
Figura 1.

Para encapsular el segmento de capa de transporte, IP le agrega un encabezado IP. Este encabezado incluye
información necesaria para entregar el paquete al host de destino.

En la figura 2, se muestra cómo la PDU de capa de red encapsula la PDU de capa de transporte para crear un
paquete IP.

Características de IPv4

En la Figura 1, se describen las características básicas de IP.

Sin conexión

IP no tiene conexión, lo que significa que no se genera una conexión completa exclusiva antes de enviar los
datos. Como se muestra en la figura 2, la comunicación sin conexión es conceptualmente similar a enviarle
una carta a alguien sin avisarle al receptor con anterioridad.

Las comunicaciones de datos sin conexión funcionan con el mismo principio. Como se muestra en la figura 3,
IP no necesita un intercambio inicial de información de control para establecer una conexión completa para
que se reenvíen los paquetes. IP tampoco necesita campos adicionales en el encabezado para mantener una
conexión establecida. Este proceso reduce en gran medida la sobrecarga del protocolo IP. Sin embargo, sin
una conexión completa preestablecida, los remitentes no saben si los dispositivos de destino están presentes
y en funcionamiento cuando envían paquetes, ni tampoco si el destinatario recibe el paquete o si puede
acceder al paquete y leerlo.

No confiable

En la Figura 4, se ven las características de máximo esfuerzo de entrega o de entrega poco fiable propias del
IP. El protocolo IP no garantiza que todos los paquetes que se envían, de hecho, se reciban.

Que sea poco confiable significa que IP no tiene la funcionalidad para administrar o recuperar paquetes no
recibidos o dañados. Esto se debe a que, si bien los paquetes IP se envían con información sobre la ubicación
de entrega, no tienen información que pueda procesarse para informar al remitente si la entrega se realizó
correctamente. Es posible que los paquetes lleguen dañados o fuera de secuencia al destino o que no lleguen
en absoluto. IP no tiene la funcionalidad de retransmitir paquetes si se producen errores.

Los servicios de capas superiores deben solucionar problemas, como el envío de paquetes fuera de orden o
la pérdida de paquetes. Esta característica permite que IP funcione de manera muy eficaz. En el conjunto de
protocolos TCP/IP, la confiabilidad es el papel que desempeña la capa de transporte, como se analizará más
adelante en el capítulo.

Independiente de los medios

IP funciona independientemente de los medios que transportan los datos en las capas más bajas de la pila de
protocolos. Como se ve en la Figura 5, los paquetes IP pueden enviarse como señales electrónicas por cables
de cobre, señales ópticas por fibra óptica o señales de radio inalámbricas.
La capa de enlace de datos se encarga de preparar los paquetes IP para la transmisión por el medio de
comunicación. Esto significa que el transporte de paquetes IP no está limitado a un medio en particular.

Sin embargo, la capa de red tiene en cuenta una de las características más importantes del medio, que es el
tamaño máximo de PDU que cada medio puede transportar. Esta característica se conoce como "unidad de
transmisión máxima" (MTU). Parte del control de la comunicación entre la capa de enlace de datos y la capa
de red consiste en establecer el tamaño máximo del paquete. La capa de enlace de datos pasa el valor de
MTU a la capa de red. La capa de red luego determina qué tamaño pueden tener los paquetes.

En algunos casos, un dispositivo intermediario, que por lo general es un router, debe dividir el paquete cuando
se reenvía de un medio a otro con una MTU menor. Este proceso se denomina “fragmentación de paquetes” o
“fragmentación”.

El paquete IPv4

El encabezado de paquetes IPv4 consta de campos que contienen información importante sobre el paquete.
Estos campos tienen números binarios que examinan el proceso de capa 3. Los valores binarios de cada
campo identifican diversos parámetros de configuración del paquete IP. Los diagramas de encabezado del
protocolo, que se leen de izquierda a derecha y de arriba hacia abajo, proporcionan una representación visual
de consulta al analizar los campos de protocolo. El diagrama de encabezado del protocolo IP en la ilustración
identifica los campos de un paquete IPv4.

Los campos en el encabezado del paquete IPv4 se analizarán en detalle más adelante en el curso.

Los dos campos a los que se hace más referencia son los de dirección IP de origen y de destino En estos
campos, se identifica de dónde viene el paquete y a dónde va.

Los analistas de ciberseguridad deben conocer muy bien el funcionamiento del IP y el significado de los datos
de IP capturados por los analizadores de protocolo y otros dispositivos de red. En su mayoría, estos datos
adoptan la forma de la información en los encabezados de paquetes IP.

Demostración en video: Ejemplos de encabezados IPv4 en Wireshark

Haga clic en Reproducir en la ilustración para ver una demostración de una revisión de encabezados IPv4 en
una captura de Wireshark.

Haga clic aquí para descargar un archivo en formato PDF sobre las capturas de Wireshark y las notas que se
usan en la demostración.

Haga clic aquí para leer la transcripción de este video.

Esta página contiene un vídeo titulado “Ejemplos de encabezados IPv4 en Wireshark”.

Notación de direcciones IPv4

Una dirección IPv4 es simplemente una serie de 32 bits binarios (unos y ceros). Para una persona sería muy
difícil leer una dirección IPv4 binaria. Por este motivo, los 32 bits están agrupados en cuatro bytes de 8 bits
llamados octetos. Por ese motivo, cada octeto se representa como su valor decimal separado por un punto
decimal. Esto se conoce como notación decimal punteada.

Cuando un host está configurado con una dirección IPv4, esta se introduce como un número decimal
punteado, por ejemplo, 192.168.10.10. La dirección equivalente en formato binario es
1100000.10101000.00001010.00001010. En la figura, se ve la conversión a decimales con punto.
Nota: Si no está familiarizado con la conversión del sistema binario al decimal, busque tutoriales en Internet.
Un nivel alto de conocimiento sobre el sistema binario le resultará útil en su trabajo como analista de
ciberseguridad. Haga clic aquípara tener acceso al juego de Cisco sobre el sistema binario y probar sus
habilidades de conversión.

Estructura de la dirección de host de IPv4

Una dirección IPv4 es una dirección jerárquica compuesta de una parte de red y una de host. Cuando se
determina la porción de red en comparación con la porción de host, se debe observar la secuencia de 32 bits.
Dentro de la secuencia de 32 bits, una parte de los bits identifica la red y otra parte identifica el host, como se
ve en la Figura 1.

Los bits dentro de la porción de red de la dirección deben ser idénticos para todos los dispositivos que residen
en la misma red. Los bits dentro de la porción de host de la dirección deben ser únicos para identificar un host
específico dentro de una red. Por ejemplo, si echamos un vistazo a las direcciones IPv4 para los diferentes
dispositivos de una red doméstica, probablemente veremos la misma parte de red. En la Figura 2, se ve la
configuración de IPv4 para una computadora con Windows. En la Figura 3, se ve la dirección IPv4 de un
iPhone. En la Figura 4, se ve la configuración de IPv4 para una consola de juegos Xbox One. Observe que los
tres dispositivos comparten la misma parte de la dirección de red (192.168.10) y que cada dispositivo tiene
una parte única host (.10, .7 y.12), respectivamente.

¿Pero cómo saben los hosts qué porción de los 32 bits identifica la red y qué porción identifica el host? Esa
tarea le corresponde a la máscara de subred.

Máscara de subred y dirección de red de IPv4

Lógicamente, en la máscara de subred se aplica la operación AND con la dirección de host para determinar la
dirección de red. La operación lógica AND es la comparación de dos bits que producen los resultados que se
muestran en la figura 1. Observe que solo mediante 1 AND 1 se obtiene 1.

Para identificar la dirección de red de un host IPv4, se recurre a la operación lógica AND para la dirección
IPv4, bit por bit, con la máscara de subred. El uso de la operación AND entre la dirección y la máscara de
subred produce la dirección de red.

Para demostrar cómo se usa AND para detectar una dirección de red, piense en un host con la dirección IPv4
192.168.10.10 y la máscara de subred 255.255.255.0. En la figura 2, se muestra la dirección de host IPv4 y la
conversión a dirección binaria. En la figura 3, se agrega la dirección binaria de la máscara de subred del host.

En las secciones resaltadas en amarillo de la figura 4, se identifican los bits AND que produjeron un 1 binario
en la fila de Resultados AND. Todas las demás comparaciones de bits producen 0 binarios. Observe cómo el
último octeto ya no tiene bits 1 binarios.

Por último, en la figura 5, se muestra la dirección de red resultante 192.168.10.0 255.255.255.0. Por lo tanto,
el host 192.168.10.10 está en la red 192.168.10.0 255.255.255.0.

División en subredes de los dominios de difusión

La red 192.168.10.0/24 puede admitir 254 hosts. Las redes de mayor tamaño, como 172.16.0.0/16, admite
muchas más direcciones de host (más de 65 000). Sin embargo, es posible que esto pueda crear un dominio
de difusión mayor. Un problema con un dominio de difusión grande es que estos hosts pueden generar
difusiones excesivas y afectar la red de manera negativa. En la Figura 1, LAN 1 conecta 400 usuarios, cada
uno con capacidad para generar tráfico de difusión. Esa cantidad de tráfico de difusión puede ralentizar las
operaciones de red. Puede reducir las operaciones de los dispositivos, debido a que cada dispositivo debe
aceptar y procesar cada paquete de difusión.
La solución es reducir el tamaño de la red para crear dominios de difusión más pequeños mediante un
proceso que se denomina división en subredes. Estos espacios de red más pequeños se denominan
subredes.

En la figura 2, por ejemplo, se dividieron los 400 usuarios de la LAN 1 con la dirección de red 172.16.0.0 /16
en dos subredes de 200 usuarios cada una: 172.16.0.0 /24 y 172.16.1.0 /24. Las difusiones solo se propagan
dentro de los dominios de difusión más pequeños. Por lo tanto, una difusión en la LAN 1 no se propagaría a la
LAN 2.

Observe cómo la longitud del prefijo cambió de /16 a /24. Esta es la base de la división en subredes: el uso de
bits de host para crear subredes adicionales.

Nota: Los términos subred y red se suelen usar indistintamente. La mayoría de las redes son una subred de
un bloque de direcciones más grande.

La división en subredes disminuye el tráfico de red general y mejora su rendimiento. A su vez, le permite a un
administrador implementar políticas de seguridad, por ejemplo, qué subredes están habilitadas para
comunicarse entre sí y cuáles no lo están.

Existen diversas maneras de usar las subredes para contribuir a administrar los dispositivos de red. Los
administradores de red pueden agrupar dispositivos y servicios en subredes que pueden estar determinadas
por una variedad de factores:

 Ubicación, por ejemplo, los pisos de un edificio (figura 3)

 Unidad de organización (figura 4)

 Tipo de dispositivo (figura 5)

 Cualquier otra división que tenga sentido para la red

Un analista de ciberseguridad no necesita saber cómo dividir en subredes. Sin embargo, es importante
conocer el significado de la máscara de subred y que los hosts con direcciones en subredes diferentes vienen
de lugares distintos en una red.

Demostración en vídeo: Direcciones de red, de host y de difusión

Haga clic en Reproducir para ver una demostración de cómo se determinan las direcciones de red, de host y
de difusión para una dirección IPv4 y una máscara de subred dadas.

Haga clic aquí para leer la transcripción de este video.

Esta página contiene un vídeo titulado “Direcciones de red, de host y de difusión”.

Clases de direcciones IPv4 y máscaras de subred predeterminadas

Hay varios tipos y clases de direcciones IPv4. Mientras que las clases de direcciones son cada vez menos
importantes en las redes, todavía se utilizan y mencionan con frecuencia en la documentación sobre redes.

Clases de direcciones

En 1981, las direcciones IPv4 se asignaban mediante el direccionamiento con base en clase, según se define
en RFC 790. A los clientes se les asignaba una dirección de red basada en una de tres clases: A, B o C. RFC
dividía los rangos de unidifusión en las siguientes clases específicas:
  Clase A (0.0.0.0/8 a 127.0.0.0/8): diseñada para admitir redes extremadamente grandes, con más de 16
millones de direcciones de host. Usaba un prefijo /8 fijo donde el primer octeto indicaba la dirección de
red y los tres octetos restantes eran para las direcciones de host.

 Clase B (128.0.0.0/16 a 191.255.0.0/16): diseñada para satisfacer las necesidades de redes de tamaño
moderado a grande, con hasta 65 000 direcciones de host. Usaba un prefijo /16 fijo donde los dos
octetos de valor superior indicaban la dirección de red y los dos octetos restantes eran para las
direcciones de host.

 Clase C (192.0.0.0/24 a 223.255.255.0/24): diseñada para admitir redes pequeñas con un máximo de
254 hosts. Usaba un prefijo /24 fijo donde los tres primeros octetos indicaban la red y el octeto restante
era para las direcciones de host.

Nota: También existe un bloque de multidifusión de clase D que va de 224.0.0.0 a 239.0.0.0, y un bloque de

direcciones experimentales de clase E que va de 240.0.0.0 a 255.0.0.0.

Tal como se indica en la figura, el sistema de clases asignaba el 50% de las direcciones IPv4 disponibles a
128 redes Clase A, el 25% de las direcciones a la Clase B y, luego, la Clase C compartía el 25% restante con
las Clases D y E. Aunque era adecuado en su momento, con la expansión de Internet resultó obvio que este
método estaba desperdiciando direcciones y reducía la cantidad de direcciones de red IPv4 disponibles.

El direccionamiento con clase se abandonó a fines de la década de 1990 para favorecer el sistema de
direccionamiento sin clase actual. Sin embargo, como veremos más adelante en esta sección, el
direccionamiento sin clases fue solamente una solución temporal para el agotamiento de direcciones IPv4.

Direcciones privadas reservadas

Las direcciones IPv4 públicas son direcciones en las que se realiza routing globalmente entre los routers ISP.
Sin embargo, no todas las direcciones IPv4 disponibles pueden usarse en Internet. Existen bloques de
direcciones denominadas direcciones privadas que la mayoría de las organizaciones usan para asignar
direcciones IPv4 a los hosts internos.

A mediados de la década de 1990, se presentaron las direcciones IPv4 privadas debido al agotamiento del
espacio de direcciones IPv4. Las direcciones IPv4 privadas no son exclusivas y cualquier red interna puede
usarlas.

Estos son los bloques de direcciones privadas:

 10.0.0.0 /8 o 10.0.0.0 a 10.255.255.255

 172.16.0.0 /12 o 172.16.0.0 a 172.31.255.255

 192.168.0.0 /16 o 192.168.0.0 a 192.168.255.255

Es importante saber que las direcciones dentro de estos bloques de direcciones no están permitidas en
Internet y deben ser filtradas (descartadas) por los routers de Internet. Por ejemplo, como se ve en la figura,
los usuarios de las redes 1, 2 o 3 envían paquetes a destinos remotos. Los routers ISP detectan que las
direcciones IPv4 de origen de los paquetes provienen de direcciones privadas y, por lo tanto, descartan los
paquetes.

La mayoría de las organizaciones usan direcciones IPv4 privadas para los hosts internos. Sin embargo, no se
puede realizar routing de estas direcciones RFC 1918 en Internet y deben traducirse a direcciones IPv4
públicas. Se usa la traducción de direcciones de red (NAT) para traducir entre direcciones IPv4 privadas y
públicas. En general, esto se hace en el router que conecta la red interna a la red del ISP.
Los routers domésticos brindan la misma funcionalidad. Por ejemplo, la mayoría de los routers domésticos
asignan direcciones IPv4 a sus hosts cableados e inalámbricos desde la dirección privada 192.168.1.0 /24. A
la interfaz de router doméstico que se conecta a la red del proveedor de servicios de Internet (ISP) se le suele
asignar una dirección IPv4 pública para usar en Internet.

La decisión de reenvío de host

Un host puede enviar un paquete a tres tipos de destinos:

 A sí mismo: Un host puede hacerse ping a sí mismo al enviar un paquete a una dirección IPv4
127.0.0.1, denominada "interfaz de bucle invertido". El hacer ping a la interfaz de bucle invertido, pone a
prueba la pila del protocolo TCP/IP en el host.

 A un host local: este es un host en la misma red local que el host de envío (de PC1 a PC2 en la figura).
Los hosts comparten la misma dirección de red.

 A un módulo remoto de E/S: Este es un host en una red remota. Los hosts no comparten la misma
dirección de red. Observe que, entre PC1 y el host remoto, se encuentra un R1 (router). R1 es el
gateway predeterminado para PC1 y PC2. La función de R1 es realizar el routing de todo el tráfico
destinado a redes remotas.

Como hemos visto, la máscara de subred se utiliza para determinar a qué red pertenece una dirección IPv4
del host. Para determinar si un paquete está destinado a un host local o un host remoto, se compara la
combinación de la dirección IP y la máscara de subred del dispositivo de origen con la combinación de la
dirección IP y la máscara de subred del dispositivo de destino. En la figura, PC1 sabe que está en la red 192.
168 . 10. 0/24. Por lo tanto, sabe que PC2 también está en la misma red y que el servidor (el host remoto) no
está en la misma red. Cuando un dispositivo de origen envía un paquete a un host remoto, se necesita la
ayuda de los routers y del routing. El routing es el proceso de identificación de la mejor ruta para llegar a un
destino. El router conectado al segmento de red local se denomina gateway predeterminado.

Gateway predeterminado

Como se muestra en la figura, se deben configurar tres direcciones IPv4 decimales con puntos cuando se
asigna una configuración IPv4 al host:

 Dirección IPv4: dirección IPv4 única del host.

 Máscara de subred: se usa para identificar la parte de red/host de la dirección IPv4.

 Gateway predeterminado: identifica el gateway local (es decir, la dirección IPv4 de interfaz de router
local) para llegar a redes remotas.

El gateway predeterminado es el dispositivo de red que puede enrutar el tráfico a otras redes. Es el router el
que puede enrutar el tráfico fuera de la red local.

Si se piensa en una red como si fuera una habitación, el gateway predeterminado es como la puerta. Si desea
ingresar a otra habitación o red, debe encontrar la puerta.

A su vez, una PC o computadora que no conoce la dirección IP del gateway predeterminado es como una
persona, en una habitación, que no sabe dónde está la puerta. Las personas en la habitación o la red pueden
hablar entre sí, pero si no conocen la dirección del gateway predeterminado o si esta no existiera, no hay
salida.
Uso del gateway predeterminado

La tabla de routing de un host incluye, por lo general, un gateway predeterminado. El host recibe la dirección
IPv4 del gateway predeterminado ya sea de manera dinámica del protocolo DHCP o si se la configura
manualmente. En la Figura 1, PC1 y PC2 están configuradas con la dirección IPv4 del gateway
predeterminado 192.168.10.1. La configuración de un gateway predeterminado genera una ruta
predeterminada en la tabla de routing de la PC. Una ruta predeterminada es la ruta o camino que la PC utiliza
cuando intenta conectarse a la red remota.

La ruta predeterminada se desprende de la configuración del gateway predeterminado y se ubica en la tabla

de routing del servidor. Tanto PC1 como PC2 tendrán una ruta predeterminada para enviar todo el tráfico
destinado a las redes remotas al R1.

Es posible ver la tabla de routing para un host de Windows usando los comandos netstat -r o route print,
como se ve en la Figura 2.

Necesidad de utilizar IPv6

El agotamiento del espacio de direcciones IPv4 fue el factor que motivó la migración a IPv6. Debido al
aumento de la conexión a Internet en África, Asia y otras áreas del mundo, las direcciones IPv4 ya no son
suficientes como para admitir este crecimiento. Como se ve en la figura, a cuatro de los cinco Registros de
Internet regionales (RIR, Regional Internet Registry) se les agotaron las direcciones IPv4.

IPv4 tiene un máximo teórico de 4300 millones de direcciones. Las direcciones privadas en combinación con
la traducción de direcciones de red (NAT) fueron esenciales para demorar la reducción del espacio de
direcciones IPv4. Sin embargo, la NAT rompe muchas aplicaciones y tiene limitaciones que obstaculizan
considerablemente las comunicaciones entre pares.

Nota: NAT se analiza en más detalle más adelante en este capítulo.

Representación y tamaño de IPv6

IPv6 está diseñado para ser el sucesor de IPv4. IPv6 tiene un espacio de direcciones de 128 bits, lo que
proporciona 340 sextillones de direcciones. (Es decir, el número 340 seguido por 36 ceros). Sin embargo,
IPv6 es más que un mayor grupo de direcciones. Cuando el Grupo de Trabajo de Ingeniería de Internet (IETF,
Internet Engineering Task Force) comenzó el desarrollo de un sucesor de IPv4, utilizó esta oportunidad para
corregir las limitaciones de IPv4 e incluir mejoras adicionales. Un ejemplo es el protocolo de mensajes de
control de Internet versión 6 (ICMPv6), que incluye la resolución de direcciones y la configuración automática
de direcciones, las cuales no se encuentran en ICMP para IPv4 (ICMPv4).

Las direcciones IPv6 se escriben como una cadena de valores hexadecimales. Cuatro bits se representan
mediante un único dígito hexadecimal, con un total de 32 valores hexadecimales. Las direcciones IPv6 no
distinguen entre mayúsculas y minúsculas, y pueden escribirse en minúsculas o en mayúsculas.

Como se ve en la figura, el formato para escribir una dirección IPv6 es x:x:x:x:x:x:x:x, donde cada “x” consta
de cuatro valores hexadecimales. Al hacer referencia a 8 bits de una dirección IPv4, utilizamos el término
“octeto”. En IPv6, un “hexteto” es el término no oficial que se utiliza para referirse a un segmento de 16 bits o
cuatro valores hexadecimales. Cada “x” es un único hexteto, 16 bits o cuatro dígitos hexadecimales.

Formato de direcciones IPv6

Las computadoras no tienen ningún problema para leer las nuevas direcciones IPv6 de 128 bits. IPv6 solo
agrega más unos y ceros a las direcciones de origen y de destino en el paquete. Para las personas, sin
embargo, pasar de una dirección de 32 bits escrita en notación decimal punteada a una dirección IPv6 escrita
como una serie de 32 dígitos hexadecimales puede ser bastante difícil. Se han desarrollado técnicas para
comprimir una dirección IPv6 escrita y convertirla a un formato más entendible.

Cómo comprimir direcciones IPv6

Las direcciones IPv6 se escriben como una cadena de valores hexadecimales. Cuatro bits se representan
mediante un único dígito hexadecimal, con un total de 32 valores hexadecimales. En la figura se muestra una
dirección IPv6 totalmente expandida y dos métodos para hacerla más legible. Dos reglas ayudan a reducir el
número de dígitos necesarios para representar una dirección IPv6.

Regla 1: Omitir los ceros iniciales

La primera regla para ayudar a reducir la notación de las direcciones IPv6 consiste en omitir los 0 (ceros)
iniciales en cualquier sección de 16 bits. Por ejemplo:

 0DB8 se puede representar como DB8

 0000 se puede representar como 0

 0200 se puede representar como 200

Regla 2: Omitir un segmento con “solo ceros”

La segunda regla que permite reducir la notación de direcciones IPv6 es utilizar signos de dos puntos dobles
(::) para reemplazar cualquier grupo de segmentos que solo contengan ceros. Los dos puntos dobles (::) se
pueden utilizar solamente una vez dentro de una dirección; de lo contrario, habría más de una dirección
resultante posible.

Longitud de prefijo IPv6

Recuerde que el prefijo, o la porción de red, de una dirección IPv4 se puede identificar con una máscara de
subred decimal punteada o con la longitud de prefijo (notación con barra diagonal). Por ejemplo, la dirección
IPv4 192.168.1.10 con la máscara de subred decimal punteada 255.255.255.0 equivale a 192.168.1.10/24.

IPv6 utiliza la longitud de prefijo para representar la porción de prefijo de la dirección. IPv6 no utiliza la
notación decimal punteada de máscara de subred. La longitud de prefijo se utiliza para indicar la porción de
red de una dirección IPv6 mediante el formato de dirección IPv6/longitud de prefijo.

La longitud de prefijo puede ir de 0 a 128. Una longitud de prefijo IPv6 típica para LAN y la mayoría de los
demás tipos de redes es /64, como se ve en la figura. Esto significa que la porción de prefijo o de red de la
dirección tiene una longitud de 64 bits, lo cual deja otros 64 bits para la ID de interfaz (porción de host) de la
dirección.

En la figura, se ve un ejemplo de la notación de prefijo /64 en IPv6. La dirección IPv6

2001:0DB8:000A:0000:0000:0000:0000:0000 se divide en dos partes. Cuatro hextetos o 64 bits a la izquierda
representan el prefijo de red y cuatro hextetos o 64 bits a la derecha representan la ID de la interfaz. La
dirección de red IPv6 comprimida se escribe 2001:DB8:A::/64.

Tutorial en vídeo: Asignación de direcciones de capa 2 y de capa 3

Haga clic en reproducir para repasar las nociones de asignación de direcciones de la capa 2 y la capa 3.

Haga clic aquí para leer la transcripción de este video.

Haga clic en aquí para descargar el archivo de Packet Tracer que se utiliza en el vídeo.

Esta página contiene un vídeo titulado “Asignación de direcciones de capa 2 y de capa 3”.

Mensajes de ICMPv4

Si bien IP es solo un protocolo de máximo esfuerzo, el paquete TCP/IP permite que los mensajes se envíen
en caso de que se produzcan determinados errores. Estos mensajes se envían mediante los servicios de
ICMP. El objetivo de estos mensajes es proporcionar respuestas acerca de temas relacionados con el
procesamiento de paquetes IP en determinadas condiciones, no es hacer que IP sea confiable. Los mensajes
de ICMP no son obligatorios y, a menudo, no se permiten dentro de una red por razones de seguridad.

El protocolo ICMP está disponible tanto para IPv4 como para IPv6. El protocolo de mensajes para IPv4 es
ICMPv4. ICMPv6 proporciona estos mismos servicios para IPv6, pero incluye funcionalidad adicional. En este
curso, el término ICMP se utilizará para referirse tanto a ICMPv4 como a ICMPv6.

Existe una gran variedad de tipos de mensajes de ICMP y de razones para enviarlos. Analizaremos algunos
de los mensajes más comunes.

Los mensajes ICMP comunes a ICMPv4 y a ICMPv6 incluyen lo siguiente:

 Confirmación de host

 Destino o servicio inaccesible

 Tiempo superado

 Redireccionamiento de ruta

Confirmación de host

Se puede utilizar un mensaje de eco ICMP para determinar si un host funciona. El host local envía una
solicitud de eco ICMP a un host. Si el host se encuentra disponible, el host de destino responde con una
respuesta de eco. En la figura, haga clic en el botón Reproducir para ver una animación de la solicitud de
eco/respuesta de eco de ICMP. Este uso de los mensajes de eco ICMP es la base de la utilidad ping.

Destino o servicio inaccesible

Cuando un host o gateway recibe un paquete que no puede entregar, puede utilizar un mensaje ICMP de
destino inalcanzable para notificar al origen que el destino o el servicio son inalcanzables. El mensaje incluye
un código que indica el motivo por el cual no se pudo entregar el paquete.

Estos son algunos de los códigos de destino inalcanzable para ICMPv4:

 0: red inalcanzable

 1: host inalcanzable

 2: protocolo inalcanzable

 3: puerto inalcanzable

Nota: ICMPv6 tiene códigos similares, pero levemente diferentes para los mensajes de destino inalcanzable.
Tiempo superado

Los routers utilizan los mensajes de tiempo superado de ICMPv4 para indicar que un paquete no puede
reenviarse debido a que el campo de tiempo de duración (TTL) del paquete se disminuyó a 0. Si un router
recibe un paquete y disminuye el campo TTL en el paquete IPV4 a cero, descarta el paquete y envía un
mensaje de tiempo superado al host de origen.

ICMPv6 también envía un mensaje de tiempo superado si el router no puede reenviar un paquete IPv6 debido
a que el paquete caducó. IPv6 no tiene un campo TTL, por lo que utiliza el campo de límite de saltos para
determinar si el paquete caducó.

Mensajes de RS y RA de ICMPv6

Los mensajes informativos y de error que se encuentran en ICMPv6 son muy similares a los mensajes de
control y de error que implementa ICMPv4. Sin embargo, ICMPv6 tiene nuevas características y funcionalidad
mejorada que no se encuentran en ICMPv4. Los mensajes ICMPv6 están encapsulados en IPv6.

ICMPv6 incluye cuatro mensajes nuevos como parte del protocolo de detección de vecino (ND o NDP).

Mensajería entre un router IPv6 y un dispositivos IPv6:

 Mensaje de solicitud de router (RS)

 Mensaje de anuncio de router (RA)

Mensajería entre dispositivos IPv6:

 Mensaje de solicitud de vecino (NS)

 Mensaje de anuncio de vecino (NA)

Nota: El ND de ICMPv6 también incluye el mensaje de redireccionamiento, que tiene una función similar al
mensaje de redireccionamiento utilizado en ICMPv4.

En la figura 1, se muestra un ejemplo de una PC y un router que intercambian mensajes de anuncio de router
y de solicitud. Haga clic en cada mensaje para obtener más información.

Los mensajes de solicitud y anuncio de vecino se usan para la resolución de direcciones y para la detección
de direcciones duplicadas (DAD).

Resolución de direcciones

La resolución de direcciones se utiliza cuando un dispositivo en la LAN conoce la dirección IPv6 de unidifusión
de un destino, pero no conoce la dirección MAC de Ethernet. Para determinar la dirección MAC del destino, el
dispositivo envía un mensaje de NS a la dirección de nodo solicitado. El mensaje incluye la dirección IPv6
conocida (objetivo). El dispositivo que se destinó a la dirección IPv6 responde con un mensaje NA que
contiene la dirección MAC de Ethernet. En la figura 2, se muestran dos PC que intercambian mensajes de NS
y NA. Haga clic en cada mensaje para obtener más información.

Detección de direcciones duplicadas

Cuando se asigna una dirección de unidifusión global o link-local a un dispositivo, se recomienda realizar una
operación DAD en la dirección para garantizar que sea única. Para verificar la singularidad de una dirección,
el dispositivo envía un mensaje de NS con su propia dirección IPv6 como dirección IPv6 de destino, como se
muestra en la figura 3. Si otro dispositivo de la red tiene esta dirección, responde con un mensaje NA. Este
mensaje NA notifica al dispositivo emisor que la dirección está en uso. Si no se devuelve un mensaje NA
correspondiente dentro de determinado período, la dirección de unidifusión es única y su uso es aceptable.

Nota: no es necesaria la operación DAD, pero la RFC 4861 recomienda que se realice una DAD en las
direcciones de unidifusión.

Ping: Prueba de la pila local

Ping es una utilidad de prueba que utiliza mensajes de solicitud y de respuesta de eco ICMP para probar la
conectividad entre hosts. Ping funciona con hosts IPv4 e IPv6.

Para probar la conectividad con otro host de una red, se envía una solicitud de eco a la dirección de host
mediante el comando ping. Si el host en la dirección especificada recibe la solicitud de eco, responde con una
respuesta de eco. A medida que se recibe cada respuesta de eco, el comando ping proporciona comentarios
acerca del tiempo transcurrido entre el envío de la solicitud y la recepción de la respuesta. Esto puede ser una
medida del rendimiento de la red.

El comando ping tiene un valor de tiempo de espera para la respuesta. Si no se recibe una respuesta dentro
del tiempo de espera, el comando ping proporciona un mensaje que indica que no se recibió una respuesta.
Generalmente, esto indica que existe un problema, pero también podría indicar que se habilitaron
características de seguridad que bloquean los mensajes ping en la red.

Una vez que se envían todas las solicitudes, la utilidad ping proporciona un resumen que incluye la tasa de
éxito y el tiempo promedio del viaje de ida y vuelta al destino.

Ping del bucle invertido local

Existen casos especiales de prueba y verificación para los cuales se puede usar el comando ping. Un caso es
la prueba de la configuración interna de IPv4 o de IPv6 en el host local. Para realizar esta prueba, se debe
hacer ping a la dirección de bucle invertido local 127.0.0.1 para IPv4 (::1 para IPv6). En la ilustración, se
muestra la prueba de la dirección IPv4 de bucle invertido.

Una respuesta de 127.0.0.1 para IPv4 (o ::1 para IPv6) indica que IP está instalado correctamente en el host.
Esta respuesta proviene de la capa de red. Sin embargo, esta respuesta no indica que las direcciones, las
máscaras o los gateways estén configurados adecuadamente. Tampoco indica nada acerca del estado de la
capa inferior de la pila de red. Simplemente, prueba el protocolo IP en la capa de red de dicho protocolo. Un
mensaje de error indica que TCP/IP no funciona en el host.

Ping para prueba de conectividad a la LAN local

También es posible utilizar el comando ping para probar la capacidad de comunicación de un host en la red
local. Por lo general, esto se realiza haciendo ping a la dirección IP del gateway del host. Un ping al gateway
indica que la interfaz del host y la interfaz del router que cumplen la función de gateway funcionan en la red
local.

Para esta prueba, se suele usar la dirección de gateway porque el router generalmente está en
funcionamiento. Si la dirección de gateway no responde, se puede enviar un ping a la dirección IP de otro host
en la red local que se sepa que funciona.

Si el gateway u otro host responden, los hosts locales pueden comunicarse correctamente en la red local. Si el
gateway no responde pero otro host sí lo hace, esto podría indicar un problema con la interfaz de router que
sirve como gateway.

Una posibilidad es que se haya configurado la dirección de gateway incorrecta en el host. Otra posibilidad es
que la interfaz del router puede estar en funcionamiento, pero se le ha aplicado seguridad, de manera que no
procesa o responde solicitudes de ping.
Ping: Prueba de la conectividad a un host remoto

También se puede utilizar el comando ping para probar la capacidad de un host local para comunicarse en
una interconexión de redes. El host local puede hacer ping a un host IPv4 operativo de una red remota, como
se muestra en la ilustración.

Si este ping se realiza correctamente, se puede verificar el funcionamiento de una amplia porción de la
interconexión de redes. Un ping correcto en la interconexión de redes confirma la comunicación en la red
local. También confirma el funcionamiento del router que sirve como gateway y el funcionamiento de todos los
routers que podrían estar en la ruta entre la red local y la red del host remoto.

De manera adicional, se puede verificar la funcionalidad del módulo remoto de E/S. Si el módulo remoto de
E/S no podía comunicarse fuera de la red local, no hubiera respondido.

Nota: Por motivos de seguridad, muchos administradores de redes limitan o prohíben la entrada de mensajes
ICMP a la red corporativa; por lo tanto, la falta de una respuesta de ping puede deberse a restricciones de
seguridad.

Traceroute, prueba de la ruta

El comando ping se usa para probar la conectividad entre dos hosts, pero no proporciona información sobre
los detalles de los dispositivos entre los hosts. Traceroute (tracert) es una utilidad que genera una lista de
saltos que se alcanzaron correctamente a lo largo de la ruta. Esta lista puede proporcionar información
importante sobre la verificación y la solución de problemas. Si los datos llegan al destino, el rastreo indica la
interfaz de cada router que aparece en la ruta entre los hosts. Si los datos fallan en algún salto durante el
camino, la dirección del último router que respondió al rastreo puede indicar dónde se encuentra el problema
o las restricciones de seguridad.

Tiempo de ida y vuelta (RTT)

El uso de traceroute proporciona el tiempo de ida y vuelta para cada salto a lo largo de la ruta e indica si un
salto no responde. El tiempo de ida y vuelta es el tiempo que le lleva a un paquete llegar al módulo remoto de
E/S y el tiempo que la respuesta del host demora en regresar. Se utiliza un asterisco (*) para indicar un
paquete perdido o sin acuse de recibo.

Esta información se puede utilizar para ubicar un router problemático en la ruta. Si aparecen en pantalla
tiempos de respuesta elevados o pérdidas de datos de un salto específico, esto indica que los recursos del
router o sus conexiones pueden estar sobrecargados.

TTL de IPv4 y límite de saltos de IPv6

Traceroute utiliza una función del campo TTL en IPv4 y del campo límite de saltos de IPv6 en los
encabezados de capa 3, junto con el mensaje de tiempo superado de ICMP.

En la figura, haga clic en el botón Reproducir para ver una animación del modo en que traceroute aprovecha
el TTL.

La primera secuencia de mensajes enviados desde traceroute tiene un valor de 1 en el campo TTL. Esto hace
que el TTL agote el tiempo de espera del paquete IPv4 en el primer router. Este router luego responde con un
mensaje de ICMPv4. Traceroute ahora tiene la dirección del primer salto.

A continuación, Traceroute incrementa progresivamente el campo TTL (2, 3, 4...) para cada secuencia de
mensajes. De esta manera se proporciona al rastreo la dirección de cada salto a medida que los paquetes
agotan el límite de tiempo a lo largo del camino. El campo TTL sigue aumentando hasta que se alcanza el
destino, o se incrementa a un máximo predefinido.
Después de alcanzar el destino final, el host responde con un mensaje ICMP de puerto inalcanzable o con un
mensaje ICMP de respuesta de eco en lugar del mensaje ICMP de tiempo superado.

Formato de paquetes ICMP

ICMP se encapsula directamente en paquetes IP. En este sentido, es casi como un protocolo de capa de
transporte, porque se encapsula en un paquete; sin embargo, se considera un protocolo de capa 3. ICMP
actúa como una carga útil de datos dentro del paquete IP. Tiene un campo de datos de encabezado especial,
como se ve en la figura.

ICMP utiliza códigos de mensaje para diferenciar entre distintos tipos de mensajes ICMP. Los siguientes son
algunos códigos de mensaje comunes:

 0: respuesta de eco (respuesta a un ping)

 3: destino inalcanzable

 5: redireccionamiento (utilizar otra ruta al destino)

 8: solicitud de eco (para ping)

 11: tiempo excedido (TTL se convirtió en 0)

Como se verá más adelante en el curso, un analista de ciberseguridad sabe que el campo de carga útil
opcional de ICMP se puede utilizar en un vector de ataque para extraer datos.

Destino en la misma red

Hay dos direcciones primarias asignadas a un dispositivo en una LAN Ethernet:

 Dirección física (dirección MAC): se utiliza para comunicaciones de NIC de Ethernet a NIC de
Ethernet en la misma red.

 Dirección lógica (dirección IP): se utiliza para enviar el paquete del origen inicial al destino final.

Las direcciones IP se utilizan para identificar la dirección del dispositivo de origen inicial y el dispositivo de
destino final. La dirección IP de destino puede estar en la misma red IP que la de origen o en una red remota.

Nota: la mayoría de las aplicaciones utilizan el sistema de nombres de dominio (DNS) para determinar la
dirección IP cuando se les indica un nombre de dominio, como “www.cisco.com”. El DNS se analiza en detalle
en otro capítulo.

Las direcciones de capa 2, o físicas, como las direcciones MAC Ethernet, tienen un propósito diferente: se
utilizan para distribuir la trama de enlace de datos con el paquete IP encapsulado de una NIC a otra en la
misma red. Si la dirección IP de destino está en la misma red, la dirección MAC de destino es la del dispositivo
de destino.

En la ilustración, se muestran las direcciones MAC Ethernet y la dirección IP de la PC-A enviando un paquete
IP al servidor de archivos en la misma red.

La trama Ethernet de capa 2 contiene lo siguiente:

  Dirección MAC de destino: es la dirección MAC de la NIC de Ethernet del servidor de archivos.

 Dirección MAC de origen: es la dirección MAC de la NIC Ethernet de la PC-A.

El paquete IP de capa 3 contiene lo siguiente:

 Dirección IP de origen: es la dirección IP del origen inicial, la PC-A.

 Dirección IP de destino: es la dirección IP del destino final, el servidor de archivos.

Destino en una red remota

Cuando la dirección IP de destino está en una red remota, la dirección MAC de destino es la dirección del
gateway predeterminado del host (que es la NIC del router), como se muestra en la figura. Si utilizamos una
analogía de correo postal, esto sería similar a cuando una persona lleva una carta a la oficina postal local.
Todo lo que debe hacer es llevar la carta a la oficina postal. A partir de ese momento, se vuelve
responsabilidad de la oficina postal reenviar la carta al destino final.

En la figura, se ven las direcciones MAC de Ethernet y las direcciones IPv4 de la computadora A enviando un
paquete IP a un servidor de archivos en una red remota. Los routers examinan la dirección IPv4 de destino
para determinar la mejor ruta para reenviar el paquete IPv4. Esto es similar a la manera en que el servicio
postal reenvía el correo según la dirección del destinatario.

Cuando el router recibe una trama de Ethernet, desencapsula la información de capa 2. Por medio de la
dirección IP de destino, determina el dispositivo del siguiente salto y desencapsula el paquete IP en una
nueva trama de enlace de datos para la interfaz de salida. Junto con cada enlace en una ruta, se encapsula
un paquete IP en una trama específica para la tecnología de enlace de datos particular relacionada con ese
enlace, como Ethernet. Si el dispositivo del siguiente salto es el destino final, la dirección MAC de destino es
la de la NIC Ethernet del dispositivo.

¿Cómo se asocian las direcciones IPv4 de los paquetes IPv4 en un flujo de datos con las direcciones MAC en
cada enlace a lo largo de la ruta hacia el destino? Esto se realiza mediante un proceso llamado “protocolo de
resolución de direcciones (ARP)”.

Introducción a ARP

Recuerde que cada dispositivo que tiene una dirección IP en una red Ethernet también tiene una dirección
MAC Ethernet. Cuando un dispositivo envía una trama de Ethernet, esta contiene estas dos direcciones:

 Dirección MAC de destino: la dirección MAC de la NIC Ethernet, que es la dirección del destino final o
del router.

 Dirección MAC de origen: la dirección MAC de la NIC Ethernet del remitente.

Para determinar la dirección MAC de destino, el dispositivo utiliza ARP. El ARP resuelve las direcciones IPv4
en direcciones MAC y mantiene una tabla de asignaciones.

Funciones del ARP

Cuando se envía un paquete a la capa de enlace de datos para encapsularlo en una trama de Ethernet, el
dispositivo consulta una tabla en su memoria para encontrar la dirección MAC que está asignada a la
dirección IPv4. Esta tabla se denomina “tabla ARP” o “caché ARP”. La tabla ARP se almacena en la RAM del
dispositivo.

El dispositivo emisor busca en su tabla ARP la dirección IPv4 de destino y la dirección MAC correspondiente.
Si la dirección IPv4 de destino del paquete está en la misma red que la dirección IPv4 de origen, el dispositivo
busca la dirección IPv4 de destino en la tabla ARP. Si la dirección IPv4 de destino está en una red diferente
que la dirección IPv4 de origen, el dispositivo busca la dirección IPv4 del gateway predeterminado.

En ambos casos, se realiza una búsqueda de la dirección IPv4 y la dirección MAC correspondiente para el
dispositivo.

En cada entrada o fila de la tabla ARP, se enlaza una dirección IPv4 con una dirección MAC. La relación entre
los dos valores se denomina asignación. Esto solamente significa que es posible buscar una dirección IPv4 en
la tabla y encontrar la dirección MAC correspondiente. La tabla ARP almacena temporalmente (en caché) la
asignación para los dispositivos de la LAN.

Si el dispositivo localiza la dirección IPv4, se utiliza la dirección MAC correspondiente como la dirección MAC
de destino de la trama. Si no se encuentra ninguna entrada, el dispositivo envía una solicitud de ARP. En la
figura, haga clic en el botón Reproducir para ver una animación del proceso de solicitud de ARP.

Vídeo: Funcionamiento y solicitud de ARP

Una solicitud de ARP se envía cuando un dispositivo necesita asociar una dirección MAC a una dirección IPv4
y no tiene una entrada para la dirección IPv4 en su tabla ARP.

Los mensajes de ARP se encapsulan directamente dentro de una trama de Ethernet. No se utiliza un
encabezado de IPv4. El mensaje de solicitud de ARP incluye lo siguiente:

 Dirección IPv4 objetivo: esta es la dirección IPv4 que requiere una dirección MAC correspondiente.

 Dirección MAC objetivo: esta es la dirección MAC desconocida; en el mensaje de solicitud de ARP,

está vacía.

La solicitud de ARP se encapsula en una trama de Ethernet con la siguiente información de encabezado:

 Dirección MAC de destino: esta es una dirección de difusión que requiere que todas las NIC Ethernet
de la LAN acepten y procesen la solicitud de ARP.

 Dirección MAC de origen: este es el remitente de la dirección MAC de la solicitud de ARP.

 Tipo: los mensajes de ARP tienen un campo de tipo 0x806. Esto informa a la NIC receptora que la
porción de datos de la trama se debe enviar al proceso ARP.

Como las solicitudes de ARP son de difusión, el switch las envía por todos los puertos, excepto el de
recepción. Todas las NIC Ethernet de la LAN procesan difusiones. Cada dispositivo debe procesar la solicitud
de ARP para ver si la dirección IPv4 objetivo coincide con la suya. Un router no reenvía difusiones por otras
interfaces.

Solo un dispositivo de la LAN tiene la dirección IPv4 que coincide con la dirección IPv4 objetivo de la solicitud
de ARP. Todos los demás dispositivos no envían una respuesta.

Haga clic en Reproducir para ver una demostración de una solicitud de ARP para una dirección IPv4 de
destino que está en la red local.

Haga clic aquí para descargar el video de diapositivas de la demostración.

Haga clic en aquí para leer la transcripción de este video.

Esta página contiene un vídeo titulado “Funcionamiento y solicitud de ARP”.

Vídeo - Funcionamiento de ARP - Respuesta de ARP

Solamente el dispositivo que tiene la dirección IPv4 asociada con la dirección IPv4 objetivo de la solicitud de
ARP envía una respuesta de ARP. El mensaje de respuesta de ARP incluye lo siguiente:

 Dirección IPv4 del remitente: esta es la dirección IPv4 del dispositivo cuya dirección MAC se solicitó.

 Dirección MAC del remitente: es la dirección MAC del remitente. Es la dirección MAC que se solicitó
en el mensaje original de la solicitud de ARP.

La respuesta de ARP se encapsula en una trama de Ethernet con la siguiente información de encabezado:

 Dirección MAC de destino: es la dirección MAC del remitente original de la solicitud de ARP.

 Dirección MAC de origen: esta es la dirección MAC de la respuesta de ARP.

 Tipo: los mensajes de ARP tienen un campo de tipo 0x806. Esto informa a la NIC receptora que la
porción de datos de la trama se debe enviar al proceso ARP.

Solamente el dispositivo que envió inicialmente la solicitud de ARP recibe la respuesta de ARP de unidifusión.
Una vez que recibe la respuesta de ARP, el dispositivo agrega la dirección IPv4 y la dirección MAC
correspondiente a su tabla ARP. A partir de ese momento, los paquetes destinados para esa dirección IPv4 se
pueden encapsular en las tramas con su dirección MAC correspondiente.

Haga clic en Reproducir en la ilustración para ver una demostración de una respuesta de ARP.

Haga clic aquí para descargar el video de diapositivas de la demostración.

Si ningún dispositivo responde a la solicitud de ARP, el paquete se descarta porque no se puede crear una
trama.

Las entradas de la tabla ARP tienen marcas de tiempo. Si un dispositivo no recibe una trama de un dispositivo
determinado antes de que caduque la marca horaria, la entrada para este dispositivo se elimina de la tabla
ARP.

Además, se pueden introducir entradas estáticas de asignaciones en una tabla ARP, pero esto no sucede con
frecuencia. Las entradas estáticas de la tabla ARP no caducan con el tiempo y se deben eliminar de forma
manual.

Nota: IPv6 utiliza un proceso similar a ARP. Se denomina detección de vecinos de ICMPv6. ICMPv6 utiliza
mensajes de solicitación de vecino y de anuncio de vecino similares a las solicitudes y respuestas de ARP de
IPv4.

Haga clic aquí para leer la transcripción de este video.

Esta página contiene un vídeo titulado “Funcionamiento y respuesta de ARP”.

Vídeo: Función de ARP en la comunicación remota

Cuando la dirección IPv4 de destino no está en la misma red que la dirección IPv4 de origen, el dispositivo de
origen debe enviar la trama al gateway predeterminado, es decir a la interfaz del router local. Cuando un
dispositivo de origen tiene un paquete con una dirección IPv4 de otra red, lo encapsula en una trama con la
dirección MAC de destino del router.

La dirección IPv4 de la dirección del gateway predeterminado se almacena en la configuración IPv4 de los
hosts. Cuando un host crea un paquete para un destino, compara la dirección IPv4 de destino con la propia
para determinar si ambas están ubicadas en la misma red de capa 3. Si el host de destino no está en la
misma red, el origen busca en la tabla ARP una entrada que contenga la dirección IPv4 del gateway
predeterminado. Si no existe una entrada, utiliza el proceso ARP para determinar la dirección MAC del
gateway predeterminado.

Haga clic en Reproducir para ver una demostración de una solicitud de ARP y una respuesta de ARP
asociadas con el gateway predeterminado.

Haga clic aquí para descargar el video de diapositivas de la demostración.

Haga clic en aquí para leer la transcripción de este video.

Esta página contiene un vídeo titulado “Función de ARP en la comunicación remota”.

Eliminación de entradas de una tabla ARP

Para cada dispositivo, un temporizador de memoria caché ARP elimina las entradas de ARP que no se hayan
utilizado durante un período especificado. El temporizador varía según el sistema operativo del dispositivo.
Por ejemplo, algunos sistemas operativos Windows almacenan entradas de ARP en la memoria caché
durante dos minutos, como se muestra en la ilustración.

También se pueden utilizar comandos para eliminar de manera manual todas las entradas de la tabla ARP o
algunas de ellas. Después de eliminar una entrada, el proceso de envío de una solicitud de ARP y de
recepción de una respuesta de ARP debe ocurrir nuevamente para que se introduzca la asignación en la tabla
ARP.

Tablas ARP en dispositivos de red

Los hosts y routers de la red mantienen las tablas de ARP. La información de ARP se conserva en la memoria
de estos dispositivos, en lo que suele denominarse caché de ARP. Las entradas de la tabla se conservan
durante un plazo hasta que “envejecen” y se eliminan automáticamente de la caché de ARP. Esto garantiza la
exactitud de las asignaciones. Mantener las tablas de ARP en la memoria ayuda a mejorar la eficiencia de la
red al reducir el tráfico de ARP.

La tabla de ARP en una computadora con Windows se puede mostrar con el comando arp -a, como se ve en
la figura.

Práctica de laboratorio: Uso de Wireshark para examinar las tramas de

Ethernet

En esta práctica de laboratorio se cumplirán los siguientes objetivos:

 Parte 1: Examinar los campos de encabezado de una trama de Ethernet II

 Parte 2: Utilizar Wireshark para capturar y analizar tramas de Ethernet

Práctica de laboratorio: Uso de Wireshark para examinar las tramas de Ethernet

Esta página contiene una actividad de laboratorio titulada “Uso de Wireshark para examinar las tramas de
Ethernet”.

Difusiones ARP

Todos los dispositivos de la red local reciben y procesan una solicitud de ARP debido a que es una trama de
difusión. En una red comercial típica, estas difusiones tendrían, probablemente, un efecto mínimo en el
rendimiento de la red. Sin embargo, si se encendiera una gran cantidad de dispositivos que comenzaran a
acceder a los servicios de red al mismo tiempo, el rendimiento podría disminuir brevemente, como se ve en la
figura. Después de que los dispositivos envían las difusiones ARP iniciales y obtienen las direcciones MAC
necesarias, se minimiza cualquier efecto en la red.

Suplantación ARP

En algunos casos, el uso de ARP puede ocasionar un riesgo de seguridad potencial conocido como
“suplantación de ARP” o “envenenamiento ARP”. Esta es una técnica utilizada por un atacante para responder
a una solicitud de ARP de una dirección IPv4 que pertenece a otro dispositivo, como el gateway
predeterminado, como se muestra en la ilustración. El atacante envía una respuesta de ARP con su propia
dirección MAC. El receptor de la respuesta de ARP agrega la dirección MAC incorrecta a la tabla ARP y envía
estos paquetes al atacante.

Las vulnerabilidades de ARP se analizarán en mayor detalle más adelante en el curso.

La función del protocolo de capa de transporte en las comunicaciones de

red

La capa de transporte es responsable de establecer una sesión de comunicación temporal entre dos
aplicaciones y de transmitir datos entre ellas. Una aplicación genera datos que se envían desde una
aplicación en un host de origen a una aplicación en un host de destino. Este es, independientemente del tipo
de host destino, el tipo de medios a través de los cuales deben viajar los datos, la ruta seguida por los datos,
la congestión en un enlace o el tamaño de la red. Como se muestra en la Figura 1, la capa de transporte es el
enlace entre la capa de aplicación y las capas inferiores que son responsables de la transmisión a través de la
red.

Seguimiento de conversaciones individuales

En la capa de transporte, cada conjunto de datos que fluye entre una aplicación de origen y una de destino se
conoce como “conversación” (figura 2). Un host puede tener varias aplicaciones que se comunican a través de
la red de forma simultánea. Cada una de estas aplicaciones se comunica con una o más aplicaciones en uno
o más hosts remotos. Es responsabilidad de la capa de transporte mantener y hacer un seguimiento de todas
estas conversaciones.

Segmentación de datos y rearmado de segmentos

Se deben preparar los datos para el envío a través de los medios en partes manejables. La mayoría de las
redes tienen un límite de la cantidad de datos que se puede incluir en un solo paquete. Los protocolos de
capa de transporte tienen servicios que segmentan los datos de la aplicación en bloques de un tamaño
adecuado, como se ve en la Figura 3. Estos servicios incluyen el encapsulamiento necesario en cada porción
de datos. Se agrega un encabezado a cada bloque de datos para el rearmado. Este encabezado se utiliza
para hacer un seguimiento del flujo de datos.
En el destino, la capa de transporte debe poder reconstruir las porciones de datos en un flujo de datos
completo que sea útil para la capa de aplicación. Los protocolos en la capa de transporte describen cómo se
utiliza la información del encabezado de dicha capa para rearmar las porciones de datos en flujos y
transmitirlos a la capa de aplicación.

Identificación de las aplicaciones

Para pasar flujos de datos a las aplicaciones adecuadas, la capa de transporte debe identificar la aplicación
objetivo (figura 4). Para lograrlo, la capa de transporte asigna un identificador a cada aplicación, llamado
número de puerto. A todos los procesos de software que requieran acceso a la red se les asigna un número
de puerto exclusivo para ese host.

Mecanismos de la capa de transporte

El envío de algunos tipos de datos (por ejemplo, una transmisión de vídeo) a través de una red, como un flujo
completo de comunicación, puede consumir todo el ancho de banda disponible. Esto impedirá que se
produzcan otras comunicaciones al mismo tiempo. También podría dificultar la recuperación de errores y la
retransmisión de datos dañados.

En la Figura 1, se ve que la segmentación de los datos en partes más pequeñas permite que se intercalen
(multiplexen) varias comunicaciones diferentes de distintos usuarios en la misma red.

Para identificar cada segmento de datos, la capa de transporte agrega un encabezado que contiene datos
binarios organizados en varios campos. Los valores de estos campos permiten que los distintos protocolos de
la capa de transporte lleven a cabo variadas funciones de administración de la comunicación de datos.

La capa de transporte también es responsable de administrar los requisitos de confiabilidad de las

conversaciones. Las diferentes aplicaciones tienen diferentes requisitos de confiabilidad de transporte.

IP se ocupa solo de la estructura, el direccionamiento y el routing de paquetes. IP no especifica la manera en

que se lleva a cabo la entrega o el transporte de los paquetes. Los protocolos de transporte especifican la
manera en que se transfieren los mensajes entre los hosts. TCP/IP proporciona dos protocolos de capa de
transporte: el protocolo de control de transmisión (TCP) y el protocolo de datagramas de usuario (UDP), como
se ve en la Figura 2. IP utiliza estos protocolos de transporte para habilitar la comunicación y la transferencia
de datos entre los hosts.

TCP se considera un protocolo de la capa de transporte confiable y completo, ya que garantiza que todos los
datos lleguen al destino. Sin embargo, esto requiere campos adicionales en el encabezado TCP que
aumentan el tamaño del paquete y también la demora. En cambio, UDP es un protocolo de capa de transporte
más simple, aunque no proporciona confiabilidad. Por lo tanto, tiene menos campos y es más rápido que TCP.

Puertos locales y remotos de TCP

La capa de transporte debe poder separar y administrar varias comunicaciones con diferentes necesidades de
requisitos de transporte. Los usuarios tienen la expectativa de poder recibir y enviar correo electrónico y
mensajes instantáneos, explorar sitios web y realizar una llamada telefónica de VoIP de manera simultánea.
Cada una de estas aplicaciones envía y recibe datos a través de la red al mismo tiempo, a pesar de los
diferentes requisitos de confiabilidad. Además, los datos de la llamada telefónica no están dirigidos al
navegador web, y el texto de un mensaje instantáneo no aparece en un correo electrónico.

TCP y UDP administran estas diferentes conversaciones simultáneas por medio de campos de encabezado
que pueden identificar de manera exclusiva estas aplicaciones. Estos identificadores únicos son números de
puertos.

El número de puerto de origen está asociado con la aplicación que origina la comunicación en el host local,
como se ve en la Figura 1. El número de puerto de destino está asociado con la aplicación de destino en el
host remoto.
Puerto de origen

El número de puerto de origen es generado de manera dinámica por el dispositivo emisor para identificar una
conversación entre dos dispositivos. Este proceso permite establecer varias conversaciones simultáneamente.
Resulta habitual para un dispositivo enviar varias solicitudes de servicio HTTP a un servidor web al mismo
tiempo. El seguimiento de cada conversación HTTP por separado se basa en los puertos de origen.

Puerto de destino

El cliente coloca un número de puerto de destino en el segmento para informar al servidor de destino el
servicio solicitado, como se ve en la Figura 2. Por ejemplo, cuando un cliente especifica el puerto 80 en el
puerto de destino, el servidor que recibe el mensaje sabe que se solicitan servicios web. Un servidor puede
ofrecer más de un servicio de manera simultánea, por ejemplo, servicios web en el puerto 80 al mismo tiempo
que ofrece el establecimiento de una conexión FTP en el puerto 21.

Pares de sockets

Los puertos de origen y de destino se colocan dentro del segmento. Los segmentos se encapsulan dentro de
un paquete IP. El paquete IP contiene la dirección IP de origen y de destino. Se conoce como socket a la
combinación de la dirección IP de origen y el número de puerto de origen, o de la dirección IP de destino y el
número de puerto de destino. El socket se utiliza para identificar el servidor y el servicio que solicita el cliente.
Un socket de cliente puede ser parecido a esto, donde 1099 representa el número de puerto de origen:
192.168.1.5:1099

El socket en un servidor web podría ser el siguiente: 192.168.1.7:80

Juntos, estos dos sockets se combinan para formar un par de sockets: 192.168.1.5:1099, 192.168.1.7:80

Los sockets permiten que los diversos procesos que se ejecutan en un cliente se distingan entre sí. También
permiten la diferenciación de diferentes conexiones a un proceso de servidor.

El número de puerto de origen actúa como dirección de retorno para la aplicación que realiza la solicitud. La
capa de transporte hace un seguimiento de este puerto y de la aplicación que generó la solicitud de manera
que cuando se devuelva una respuesta, esta se envíe a la aplicación correcta.

Comparación entre TCP y UDP

Para algunas aplicaciones, los segmentos deben llegar en una secuencia muy específica para que se puedan
procesar correctamente. Con otras aplicaciones, los datos se consideran útiles una vez que todos se reciben
en forma completa. En ambos casos, se utiliza TCP como protocolo de transporte. Los desarrolladores de
aplicaciones deben elegir qué tipo de protocolo de transporte es adecuado según los requisitos de las
aplicaciones.

Por ejemplo, las aplicaciones como las bases de datos, los navegadores web y los clientes de correo
electrónico, requieren que todos los datos que se envían lleguen a destino en su formato original. Cualquier
pérdida de datos puede dañar una comunicación y dejarla incompleta o ilegible. Estas aplicaciones están
diseñadas para utilizar TCP.

La función del protocolo de transporte TCP es similar al envío de paquetes de los que se hace un seguimiento
de origen a destino. Si se divide un pedido de envío en varios paquetes, el cliente puede revisar en línea el
orden de la entrega.

Con TCP, hay tres operaciones básicas de confiabilidad:

 Numeración y seguimiento de los segmentos de datos transmitidos a un host específico desde una
aplicación específica
  Reconocimiento de los datos recibidos

 Retransmisión de los datos sin reconocimiento después de un tiempo determinado

En la Figura 1, haga clic en Reproducir para ver cómo los segmentos de TCP y los acuses de recibo se
transmiten entre emisor y receptor.

En otros casos, una aplicación puede tolerar cierta pérdida de datos durante la transmisión a través de la red,
pero no se admiten retrasos en la transmisión. UDP es la mejor opción para estas aplicaciones, ya que se
requiere menos sobrecarga de red. Existe una compensación entre el valor de la confiabilidad y la carga que
implica para los recursos de la red. Agregar sobrecarga para garantizar la confiabilidad para algunas
aplicaciones podría reducir la utilidad a la aplicación e incluso ser perjudicial. En estos casos, UDP es un
protocolo de transporte mejor. Con aplicaciones como la transmisión de audio y vídeo en vivo o de voz sobre
IP (VoIP), es preferible utilizar UDP. Los reconocimientos y la retransmisión reducirían la velocidad de
entrega.

Por ejemplo, si uno o dos segmentos de una transmisión de vídeo en vivo no llegan al destino, se interrumpe
momentáneamente la transmisión. Esto puede manifestarse como distorsión en la imagen o el sonido, pero
puede no ser perceptible para el usuario. Si el dispositivo de destino tuviera que dar cuenta de los datos
perdidos, la transmisión se podría demorar mientras espera las retransmisiones, lo que ocasionaría que la
imagen o el sonido se degraden considerablemente. En este caso, es mejor producir el mejor vídeo o audio
posible con los segmentos recibidos y prescindir de la confiabilidad.

UDP proporciona las funciones básicas para entregar segmentos de datos entre las aplicaciones adecuadas,
con muy poca sobrecarga y revisión de datos. UDP se conoce como un protocolo de entrega de máximo
esfuerzo. En el contexto de redes, la entrega de máximo esfuerzo se denomina “poco confiable” porque no
hay reconocimiento que indique que los datos se recibieron en el destino. Con UDP, no existen procesos de
capa de transporte que informen al emisor si la entrega se realizó correctamente.

El proceso de UDP es similar al envío por correo de una carta simple sin registrar. El emisor de la carta no
conoce la disponibilidad del receptor para recibir la carta. Además, la oficina de correos tampoco es
responsable de hacer un seguimiento de la carta ni de informar al emisor si esta no llega a destino.

En la Figura 2, haga clic en Reproducir para ver una animación de la transmisión de los segmentos de UDP
del emisor al receptor.

En la Figura 3, se incluyen un resumen y una comparación de las características de TCP y UDP.

Nota: Las aplicaciones que transmiten audio y vídeo almacenado utilizan TCP. Por ejemplo, si de repente la
red no puede admitir el ancho de banda necesario para ver una película a pedido, la aplicación detiene la
reproducción. Durante la pausa, es posible que vea un mensaje de “almacenando en búfer...” mientras TCP
intenta restablecer la transmisión. Una vez que todos los segmentos estén en orden y se restaure un nivel
mínimo de ancho de banda, la sesión de TCP se reanuda y la película continúa reproduciéndose.

Encabezados TCP y UDP

TCP es un protocolo con información de estado. Un protocolo con información de estado es un protocolo que
realiza el seguimiento del estado de la sesión de comunicación. Para hacer un seguimiento del estado de una
sesión, TCP registra qué información se envió y qué información se reconoció. La sesión con estado
comienza con el establecimiento de sesión y finaliza cuando se cierra en la terminación de sesión.

Como se ve en la Figura 1, cada segmento de TCP tiene 20 bytes de sobrecarga en el encabezado que
encapsula los datos de la capa de aplicación:

 Puerto de origen (16 bits) y puerto de destino (16 bits): se utilizan para identificar la aplicación.

 Número de secuencia (32 bits): se utiliza para rearmar los datos.

  Número de acuse de recibo (32 bits): indica los datos que se recibieron.

 Longitud del encabezado (4 bits): conocido como “desplazamiento de datos”. Indica la longitud del
encabezado del segmento de TCP.

 Reservado (6 bits): este campo está reservado para el futuro.

 Bits de control (6 bits): incluye códigos de bit, o marcadores, que indican el propósito y la función del
segmento de TCP.

 Tamaño de la ventana (16 bits): indica la cantidad de bytes que se pueden aceptar cada vez.

 Suma de comprobación (16 bits): se utiliza para la verificación de errores en el encabezado y los

datos del segmento.

 Urgente (16 bits): indica si los datos son urgentes.

Hay seis bits de control:

 URG: indica que el segmento debe clasificarse como urgente.

 ACK: indica que el campo de número de acuse de recibo es importante. Todos los segmentos de una
conexión establecida tendrá este conjunto de bits.

 PSH: esta es la función de empuje. Indica que el segmento no debe quedar en el búfer, sino que debe
enviarse inmediatamente a la aplicación de destino.

 RST: indica que se ha producido una condición inesperada y que se debe restablecer la conexión.

 SYN: se utiliza para iniciar una conexión. Solo debe establecerse en los segmentos iniciales en la etapa
en la que se establece la conexión de la comunicación de datos.

 FIN: indica que no se transferirán más datos y que debe finalizar la conexión.

UDP es un protocolo sin información estado, lo cual significa que ni el cliente ni el servidor están obligados a
hacer un seguimiento del estado de la sesión de comunicación. Si se requiere confiabilidad al utilizar UDP
como protocolo de transporte, a esta la debe administrar la aplicación.

Uno de los requisitos más importantes para transmitir vídeo en vivo y voz a través de la red es que los datos
fluyan rápidamente. Las aplicaciones de vídeo y de voz en vivo pueden tolerar cierta pérdida de datos con un
efecto mínimo o imperceptible, y se adaptan perfectamente a UDP.

Los fragmentos de comunicación en UDP se llaman datagramas, como se ve en la Figura 2. El protocolo de la

capa de transporte envía estos datagramas como máximo esfuerzo. UDP tiene una sobrecarga baja de
8 bytes.

Asignación del puerto TCP

El administrador del sistema configura cada proceso de aplicación que se ejecuta en el servidor para utilizar
un número de puerto, ya sea de manera predeterminada o manual. Un servidor individual no puede tener dos
servicios asignados al mismo número de puerto dentro de los mismos servicios de la capa de transporte.
A modo de ejemplo, un servidor que ejecuta una aplicación de servidor web y una de transferencia de
archivos no puede configurar ambas para utilizar el mismo puerto (por ejemplo, el puerto TCP 80). Una
aplicación de servidor activa asignada a un puerto específico se considera abierta. Esto significa que la capa
de transporte que se ejecuta en el servidor acepta y procesa segmentos direccionados a ese puerto. Toda
solicitud entrante de un cliente direccionada al socket correcto es aceptada y los datos se envían a la
aplicación del servidor. Pueden existir varios puertos abiertos simultáneamente en un servidor, uno para cada
aplicación de servidor activa.

Cuando se establece una conexión con un servidor, la capa de transporte en el cliente establece un puerto de
origen para mantener un registro de los datos enviados desde el servidor. Igual que un servidor puede tener
muchos puertos abiertos para los procesos del servidor, los clientes pueden tener muchos puertos abiertos
para conexiones a varios sockets. Los puertos de origen locales se asignan aleatoriamente a partir de un
intervalo de números que, generalmente, va del 49152 al 65535. Los segmentos enviados al cliente desde un
servidor utilizarán el número de puerto de cliente como puerto de destino para los datos desde el socket.

Consulte las figuras 1 a 5 para ver la asignación típica de puertos de origen y de destino en las operaciones
TCP de cliente y servidor.

Sesión de TCP, parte I: Cómo establecer y terminar la conexión

En algunas culturas, cuando dos personas se conocen, generalmente se saludan dándose la mano. Ambas
culturas entienden el acto de darse la mano como señal de un saludo amigable. Las conexiones en la red son
similares. En las conexiones TCP, el cliente del host establece la conexión con el servidor.

Cómo establecer la conexión

Los hosts hacen un seguimiento de cada segmento de datos dentro de una sesión e intercambian información
sobre qué datos se reciben mediante la información del encabezado TCP. TCP es un protocolo dúplex
completo, en el que cada conexión representa dos transmisiones de comunicación unidireccionales o
sesiones. Para establecer la conexión, los hosts realizan un enlace de tres vías. Los bits de control en el
encabezado TCP indican el progreso y estado de la conexión.

La comunicación tridireccional logra tres objetivos:

 Establece que el dispositivo de destino está presente en la red.

 Verifica que el dispositivo de destino tenga un servicio activo y acepte solicitudes en el número de
puerto de destino que el cliente de origen desea utilizar.

 Informa al dispositivo de destino que el cliente de origen intenta establecer una sesión de comunicación
en dicho número de puerto

Una conexión TCP se establece en tres pasos:

1. El cliente de origen solicita una sesión de comunicación con el servidor.

2. El servidor acusa recibo de la sesión de comunicación de cliente a servidor y solicita una sesión de
comunicación de servidor a cliente.

3. El cliente de origen acusa recibo de la sesión de comunicación de servidor a cliente.

En la Figura 1, haga clic en los botones del 1 al 3 para ver cómo se establece la conexión de TCP.

Cómo finalizar la conexión

Una vez que se completa la comunicación, se cierran las sesiones y se finaliza la conexión. Los mecanismos
de conexión y sesión habilitan la función de confiabilidad de TCP.
Para cerrar una conexión, se debe establecer el marcador de control de finalización (FIN) en el encabezado
del segmento. Para finalizar todas las sesiones TCP de una vía, se utiliza un enlace de dos vías, que consta
de un segmento FIN y un segmento de reconocimiento (ACK). Por lo tanto, para terminar una conversación
simple admitida por TCP, se requieren cuatro intercambios para finalizar ambas sesiones.

En la Figura 2, haga clic en los botones del 1 al 4 para ver cómo finaliza la conexión de TCP.

Nota: En esta explicación, los términos “cliente” y “servidor” se utilizan como referencia con fines de
simplificación, pero el proceso de finalización puede ser iniciado por dos hosts cualesquiera que tengan una
sesión abierta:

1. Cuando el cliente no tiene más datos para enviar en la transmisión, envía un segmento con el indicador FIN
establecido.

2. El servidor envía un ACK para acusar recibo del FIN para terminar la sesión de cliente a servidor.

3. El servidor envía un FIN al cliente para terminar la sesión de servidor a cliente.

4. El cliente responde con un ACK para dar acuse de recibo del FIN desde el servidor.

Una vez reconocidos todos los segmentos, la sesión se cierra.

Los seis bits del campo de bits de control del encabezado del segmento TCP también se conocen como
marcadores. Un marcador es un bit que se configura como “activado” o “desactivado”. Haga clic en el signo
más (+) junto al campo Bits de control en la Figura 3 para ver los seis marcadores. Ya hemos hablado de
SYN, ACK y FIN. El marcador RST se utiliza para restablecer una conexión cuando ocurre un error o se agota
el tiempo de espera. Haga clic aquí para obtener más información sobre los marcadores PSH y URG.

Vídeo de demostración: Comunicación tridireccional de TCP

Haga clic en Reproducir en la figura para ver un vídeo de demostración, con Wireshark, del enlace de tres
vías de TCP.

Haga clic aquí para descargar documentación que respalda el vídeo.

Haga clic aquí para leer la transcripción de este video.

Esta página contiene un vídeo titulado “Comunicación tridireccional de TCP”.

Práctica de laboratorio: Utilizar Wireshark para observar el Protocolo de

enlace TCP de 3 vías

En esta práctica de laboratorio se cumplirán los siguientes objetivos:

 Parte 1: Preparar los hosts para capturar el tráfico

 Parte 2: Analizar los paquetes con Wireshark

 Parte 3: Analizar los paquetes con tcpdump

Práctica de laboratorio: Utilizar Wireshark para observar el Protocolo de enlace TCP de 3 vías

Esta página contiene una actividad de laboratorio titulada “Utilizar Wireshark para observar la comunicación
tridireccional de TCP”.
Sesión de TCP, parte II: Transferencia de datos

Entrega ordenada de TCP

Los segmentos TCP pueden llegar a su destino desordenados. Para que el receptor comprenda el mensaje
original, los datos en estos segmentos se vuelven a ensamblar en el orden original. Para lograr esto, se
asignan números de secuencia en el encabezado de cada paquete. El número de secuencia representa el
primer byte de datos del segmento TCP.

Durante la configuración de la sesión, se establece un número de secuencia inicial (ISN). Este ISN representa
el valor inicial de los bytes para esta sesión que se transmite a la aplicación receptora. A medida que se
transmiten los datos durante la sesión, el número de secuencia se incrementa según el número de bytes que
se han transmitido. Este seguimiento de bytes de datos permite identificar y reconocer cada segmento de
manera exclusiva. A partir de esto, se pueden identificar segmentos perdidos.

Nota: El ISN no comienza en uno, sino que se trata de un número aleatorio. Esto permite evitar ciertos tipos
de ataques maliciosos. Para mayor simplicidad, usaremos un ISN de 1 para los ejemplos de este capítulo.

Los números de secuencia de segmento indican cómo rearmar y reordenar los segmentos recibidos, como se
ve en la Figura 1.

El proceso TCP receptor coloca los datos del segmento en un búfer de recepción. Los segmentos se colocan
en el orden de secuencia correcto y se pasan a la capa de aplicación cuando se vuelven a ensamblar. Todos
los segmentos que lleguen con números de secuencia desordenados se retienen para su posterior
procesamiento. A continuación, cuando llegan los segmentos con bytes faltantes, tales segmentos se
procesan en orden.

Control de flujo

TCP también ofrece mecanismos de control de flujo, es decir, la cantidad de datos que el destino puede
recibir y procesar con fiabilidad. El control de flujo permite mantener la confiabilidad de la transmisión de TCP
mediante el ajuste de la velocidad del flujo de datos entre el origen y el destino para una sesión dada. Para
lograr esto, el encabezado TCP incluye un campo de 16 bits llamado “tamaño de la ventana”.

En la Figura 2, se ve un ejemplo de tamaño de ventana y acuses de recibo. El tamaño de ventana es la

cantidad de bytes que el dispositivo de destino de una sesión TCP puede aceptar y procesar al mismo tiempo.
En este ejemplo, el tamaño de la ventana inicial para una sesión TCP de la PC B es 10 000 bytes. A partir del
primer byte, el byte 1, el último byte que la PC A puede enviar sin recibir un reconocimiento es el byte 10 000.
Esto se conoce como la “ventana de envío” de la PC A. El tamaño de ventana se incluye en cada segmento
TCP para que el destino pueda modificar el tamaño de ventana en cualquier momento, según la disponibilidad
del búfer.

Nota: En la figura, el origen está transmitiendo 1460 bytes de datos dentro de cada segmento TCP. Esto se
conoce como el MSS (tamaño de segmento máximo).

El tamaño inicial de la ventana se acuerda cuando se establece la sesión TCP durante la realización del
enlace de tres vías. El dispositivo de origen debe limitar la cantidad de bytes enviados al dispositivo de destino
en función del tamaño de la ventana de destino. El dispositivo de origen puede continuar enviando más datos
para la sesión solo cuando obtiene un reconocimiento de los bytes recibidos. Por lo general, el destino no
esperará que se reciban todos los bytes de su tamaño de ventana antes de contestar con un acuse de recibo.
A medida que se reciben y procesan los bytes, el destino envía reconocimientos para informar al origen que
puede continuar enviando bytes adicionales.

El proceso en el que el destino envía reconocimientos a medida que procesa los bytes recibidos y el ajuste
continuo de la ventana de envío del origen se conoce como ventanas deslizantes.

Si disminuye la disponibilidad de espacio de búfer del destino, puede reducir su tamaño de ventana e informar
al origen que reduzca el número de bytes que debe enviar sin recibir un acuse de recibo.
Es posible encontrar un análisis útil sobre números de secuencia y acuse de recibo de TCP aquí.

Vídeo de demostración: Números de secuencia y acuses de recibo

Una de las funciones de TCP es garantizar que cada segmento llegue a destino. Los servicios TCP en el host
de destino envían un reconocimiento de los datos que recibe la aplicación de origen.

Haga clic en Reproducir en la figura para ver una lección acerca de los reconocimientos y los números de
secuencia TCP.

Haga clic aquí para descargar la documentación complementaria del vídeo.

Haga clic aquí para leer la transcripción de este video.

Esta página contiene un vídeo titulado “Números de secuencia y acuses de recibo”.

Vídeo de demostración: pérdida y retransmisión de datos

La pérdida de datos se produce en ocasiones, sin importar qué tan bien diseñada esté la red; por lo tanto,
TCP proporciona métodos para administrar estas pérdidas de segmentos. Entre estos está un mecanismo
para retransmitir segmentos para los datos sin reconocimiento.

Haga clic en Reproducir en la figura para ver una lección acerca de la retransmisión TCP. Haga clic en el
enlace para descargar el archivo PDF. El vídeo y el archivo PDF examinan la pérdida y la retransmisión de
datos.

Haga clic aquí para descargar documentación que respalda el vídeo.

Haga clic aquí para leer la transcripción de este video.

Nota: en la actualidad, los hosts pueden emplear también una característica optativa llamada reconocimiento
selectivo (SACK). Si ambos hosts admiten SACK, es posible que el destino reconozca los bytes de segmentos
discontinuos, y el host solo necesitará volver a transmitir los datos perdidos.

Esta página contiene un vídeo titulado “Pérdida y retransmisión de datos”.

Una sesión de UDP

Tal como los segmentos con TCP, cuando se envían datagramas UDP a un destino, a menudo toman
diferentes rutas y llegan en el orden equivocado. UDP no realiza un seguimiento de los números de secuencia
de la manera en que lo hace TCP. UDP no puede reordenar los datagramas en el orden de la transmisión.

Por lo tanto, UDP simplemente rearma los datos en el orden en que se recibieron y los envía a la aplicación,
como se ve en la Figura 1. Si la secuencia de datos es importante para la aplicación, esta debe identificar la
secuencia adecuada y determinar cómo se deben procesar los datos.

Al igual que las aplicaciones basadas en TCP, a las aplicaciones de servidor basadas en UDP se les asignan
números de puerto conocidos o registrados, como se muestra en la Figura 2. Cuando estas aplicaciones o
estos procesos se ejecutan en un servidor, aceptan los datos que coinciden con el número de puerto
asignado. Cuando UDP recibe un datagrama destinado a uno de esos puertos, envía los datos de aplicación a
la aplicación adecuada en base a su número de puerto.

Nota: El servidor del servicio de usuario de acceso telefónico de autenticación remota (RADIUS) que se ve en
la figura proporciona servicios de autenticación, autorización y auditoría para administrar el acceso de usuario.
Como en TCP, la comunicación cliente-servidor es iniciada por una aplicación cliente que solicita datos de un
proceso de servidor. El proceso de cliente UDP selecciona dinámicamente un número de puerto del intervalo
de números de puerto y lo utiliza como puerto de origen para la conversación. Por lo general, el puerto de
destino es el número de puerto bien conocido o registrado que se asigna al proceso de servidor.

Una vez que el cliente selecciona los puertos de origen y de destino, este mismo par de puertos se utiliza en
el encabezado de todos los datagramas que se utilizan en la transacción. Para la devolución de datos del
servidor al cliente, se invierten los números de puerto de origen y destino en el encabezado del datagrama.

Práctica de laboratorio: Exploración de Nmap

El escaneo de puertos suele ser parte de un ataque de reconocimiento. Se pueden utilizar diversos métodos
de escaneo de puertos. Estudiaremos cómo se emplea la utilidad Nmap. Nmap es una poderosa utilidad de
red que se utiliza para detección de redes y auditorías de seguridad.

Práctica de laboratorio: Exploración de Nmap

Esta página contiene una práctica de laboratorio titulada “Exploración de Nmap”.

Descripción general de DHCP

El protocolo DHCP del servicio IPv4 automatiza la asignación de direcciones IPv4, máscaras de subred,
gateways y otros parámetros de redes IPv4. Esto se denomina “direccionamiento dinámico”. La alternativa al
direccionamiento dinámico es el direccionamiento estático. Al utilizar el direccionamiento estático, el
administrador de redes introduce manualmente la información de la dirección IP en los hosts. DHCPv6 (DHCP
para IPv6) proporciona servicios similares para los clientes IPv6.

Cuando un dispositivo configurado con DHCP e IPv4 se inicia o se conecta a la red, el cliente transmite un
mensaje de detección de DHCP (DHCPDISCOVER) para identificar cualquier servidor de DHCP disponible en
la red. Un servidor de DHCP responde con un mensaje de oferta de DHCP (DHCPOFFER), que ofrece una
concesión al cliente, como se ve en la Figura 1. El mensaje de oferta contiene la dirección IPv4 y la máscara
de subred que se deben asignar, la dirección IPv4 del servidor DNS y la dirección IPv4 del gateway
predeterminado. La oferta de concesión también incluye la duración de esta.

El cliente puede recibir varios mensajes DHCPOFFER si hay más de un servidor de DHCP en la red local. Por
lo tanto, debe elegir entre ellos y enviar un mensaje de solicitud de DHCP (DHCPREQUEST) que identifique
el servidor explícito y la oferta de concesión que el cliente acepta. Un cliente también puede optar por solicitar
una dirección previamente asignada por el servidor.

Suponiendo que la dirección IPv4 solicitada por el cliente, u ofrecida por el servidor, aún está disponible, el
servidor devuelve un mensaje de reconocimiento de DHCP (DHCPACK) que le informa al cliente que finalizó
la concesión. Si la oferta ya no es válida, el servidor seleccionado responde con un mensaje de
reconocimiento negativo de DHCP (DHCPNAK). Si se devuelve un mensaje DHCPNAK, entonces el proceso
de selección debe volver a comenzar con la transmisión de un nuevo mensaje DHCPDISCOVER. Una vez
que el cliente tiene la concesión, se debe renovar mediante otro mensaje DHCPREQUEST antes de que
expire. En las figuras de la 2 a la 8, se ejemplifican los pasos del funcionamiento de DHCPv4.

El servidor DHCP asegura que todas las direcciones IP sean únicas (no se puede asignar la misma dirección
IP a dos dispositivos de red diferentes de forma simultánea). La mayoría de los proveedores de Internet
utilizan DHCP para asignar direcciones a los clientes.

DHCPv6 tiene un conjunto similar de mensajes a los que se muestran en la figura de DHCP para IPv4. Los
mensajes de DHCPv6 son SOLICIT, ADVERTISE, INFORMATION REQUEST y REPLY.

En la figura uno, se ve el proceso de DHCP, que consta de un cliente configurado para DHCP que busca una
dirección IP y otra información, y un servidor DHCP que puede proporcionar esta información al cliente. En la
Figura 2, se ve el servidor hasta la parte superior y se muestra que puede proporcionar direcciones IP a
clientes DHCP. El cliente necesita arrendar una dirección IP del servidor DHCP. En la Figura 3, se ve el primer
paso del proceso en el que una computadora cliente envía un mensaje de difusión solicitando una dirección
IP. Este es el mensaje de detección de DHCP. En la Figura 4, se ve el paso dos del proceso en el que el
servidor se identificó a sí mismo como un servidor DHCP y ofrece una dirección IP al cliente. Este es un
mensaje de unidifusión y es el mensaje de oferta de DHCP. En la Figura 5, se ve el paso tres, en el que el
cliente envía un mensaje de difusión aceptando la dirección IP ofrecida. Este es el mensaje de solicitud de
DHCP. En la Figura 6, se ve el último paso, en el que el servidor envía un mensaje de unidifusión al cliente
confirmando que el cliente aceptó la dirección. Este es el mensaje ACK de DHCP. En la Figura 7, se ve cómo
el cliente envía un mensaje de unidifusión al servidor para solicitar la renovación del arrendamiento actual. En
la Figura 8, se ve el servidor confirmando la solicitud de renovación del arrendamiento.

Formato de mensajes DHCPv4

El formato del mensaje DHCPv4 se utiliza para todas las transacciones DHCPv4. Los mensajes DHCPv4 se
encapsulan dentro del protocolo de transporte UDP. Los mensajes DHCPv4 que se envían desde el cliente
utilizan el puerto de origen UDP 68 y el puerto de destino 67. Los mensajes DHCPv4 que se envían del
servidor al cliente utilizan el puerto de origen UDP 67 y el puerto de destino 68.

En la figura, se ve el formato de un mensaje DHCPv4 con los siguientes campos:

 Código de funcionamiento (OP): especifica el tipo general de mensaje. El valor 1 indica un mensaje
de solicitud y el valor 2 es un mensaje de respuesta.

 Tipo de hardware: identifica el tipo de hardware que se utiliza en la red. Por ejemplo, 1 es Ethernet, 15
es Frame Relay y 20 es una línea serial. Estos son los mismos códigos que se utilizan en mensajes
ARP.

 Longitud de dirección de hardware: especifica la longitud de la dirección.

 Saltos: controla el reenvío de mensajes. Un cliente lo establece en 0 antes de transmitir una solicitud.

 Identificador de transacción: lo utiliza el cliente para hacer coincidir la solicitud con las respuestas
recibidas de los servidores DHCPv4.

 Segundos: identifica la cantidad de segundos transcurridos desde que un cliente comenzó a intentar

adquirir o renovar un arrendamiento. Lo utilizan los servidores de DHCPv4 para priorizar respuestas
cuando hay varias solicitudes del cliente pendientes.

 Marcadores: los utiliza un cliente que no conoce su dirección IPv4 cuando envía una solicitud. Se utiliza
solo uno de los 16 bits, que es el indicador de difusión. El valor 1 en este campo le indica al servidor de
DHCPv4 o al agente de retransmisión que recibe la solicitud que la respuesta se debe enviar como una
difusión.

 Dirección IP del cliente: la utiliza un cliente durante la renovación del arrendamiento cuando la
dirección del cliente es válida y utilizable, no durante el proceso de adquisición de una dirección. El
cliente coloca su propia dirección IPv4 en este campo solamente si tiene una dirección IPv4 válida
mientras se encuentra en el estado vinculado. De lo contrario, establece el campo en 0.

 Su dirección IP: la utiliza el servidor para asignar una dirección IPv4 al cliente.

 Dirección IP del servidor: la utiliza el servidor para identificar la dirección del servidor que debe utilizar
el cliente para el próximo paso en el proceso bootstrap, que puede ser, o no, el servidor que envía esta
 respuesta. El servidor emisor siempre incluye su propia dirección IPv4 en un campo especial llamado
opción DHCPv4 Server Identifier (Identificador de servidores DHCPv4).

 Dirección IP del gateway: enruta los mensajes DHCPv4 cuando intervienen los agentes de
retransmisión DHCPv4. La dirección del gateway facilita las comunicaciones de las solicitudes y
respuestas de DHCPv4 entre el cliente y un servidor que se encuentran en distintas subredes o redes.

 Dirección de hardware del cliente: especifica la capa física del cliente.

 Nombre del servidor: lo utiliza el servidor que envía un mensaje DHCPOFFER o DHCPACK. El
servidor puede, de manera optativa, colocar su nombre en este campo. Puede tratarse de un simple
apodo de texto o un nombre de dominio DNS, como dhcpserver.netacad.net.

 Nombre del archivo de arranque: lo utiliza un cliente de manera optativa para solicitar un determinado
tipo de archivo de arranque en un mensaje DHCPDISCOVER. Lo utiliza un servidor en un DHCPOFFER
para especificar completamente un directorio de archivos y un nombre de archivo de arranque.

 Opciones de DHCP: contiene las opciones de DHCP, incluidos varios parámetros requeridos para el
funcionamiento básico de DHCP. Este campo es de longitud variable. Tanto el cliente como el servidor
pueden utilizarlo.

Descripción general de DNS

Cuando tan a menudo nos conectamos a servidores web usando nombres como www.cisco.com, esto ocurre
mediante la asignación de direcciones IP a los paquetes. En Internet, estos nombres de dominio son mucho
más fáciles de recordar para la gente que algo como 198.133.219.25, que es la dirección IP numérica real de
ese servidor. Si Cisco decide cambiar la dirección numérica de www.cisco.com, esto no afecta al usuario,
porque el nombre de dominio se mantiene. Simplemente se une la nueva dirección al nombre de dominio
existente y se mantiene la conectividad.

El sistema de nombres de dominio (DNS) se desarrolló para proporcionar un medio confiable de administrar y
proporcionar los nombres de dominio y sus direcciones IP asociadas. El sistema de DNS se compone de una
jerarquía global de servidores distribuidos que contienen bases de datos con asignaciones de nombre para las
direcciones IP. En la figura, la computadora cliente le enviará una solicitud al servidor DNS para obtener la
dirección IP de www.cisco.com.

En un análisis reciente de las amenazas de seguridad de red, se observó que más del 90 % del software
malicioso que se usa para atacar redes utiliza el sistema DNS para realizar campañas de ataque. Un analista
de ciberseguridad debe tener un conocimiento profundo del sistema DNS y las maneras en que se puede
detectar el tráfico malicioso de DNS mediante análisis de protocolo e inspección de información de monitoreo
del DNS.

La jerarquía del dominio del DNS

El DNS se compone de una jerarquía de dominios genéricos de nivel superior (gTLD) que consta
de .com, .net, .org, .gov, .edu y numerosos dominios de país, como .es (España), .uk (Reino Unido), .br
(Brasil), etc. En el siguiente nivel de la jerarquía de DNS, están los dominios de segundo nivel. Estos están
representados por un nombre de dominio seguido de un dominio de nivel superior. Los subdominios se
encuentran en el siguiente nivel de la jerarquía de DNS y representan una división del dominio de segundo
nivel. Por último, un cuarto nivel puede representar un host en un subdominio. Cada elemento de una
especificación de dominio suele denominarse etiqueta. Las etiquetas se mueven desde la parte superior de la
jerarquía hacia abajo, de derecha a izquierda. Un punto (.) al final de un nombre de dominio representa el
servidor de raíz de la parte superior de la jerarquía. En la figura, se ejemplifica esta jerarquía de dominio de
DNS.
El proceso de búsqueda de DNS

Para entender el DNS, los analistas de ciberseguridad deben estar familiarizados con los siguientes términos:

 Resolución: un cliente de DNS que envía mensajes de DNS para obtener información sobre el espacio
de nombre de dominio solicitado.

 Recursión: las medidas adoptadas cuando se le pide a un servidor DNS que realice una consulta en
nombre de una resolución de DNS.

 Servidor autorizado: un servidor de DNS que responde a los mensajes de consulta con información
almacenada en los registros de recursos (RR) para un espacio de nombres de dominio almacenado en
el servidor.

 Resolución recursiva: un servidor de DNS que realiza consultas de manera recursiva para obtener la
información solicitada en la consulta de DNS.

 FQDN: un nombre de dominio totalmente calificado es el nombre absoluto de un dispositivo dentro de la

base de datos distribuida de DNS.

 RR: un registro de recursos es un formato utilizado en los mensajes de DNS que se compone de los
siguientes campos: NAME, TYPE, CLASS, TTL, RDLENGTH Y RDATA.

 Zona: una base de datos que contiene información sobre el espacio de nombres de dominio
almacenado en un servidor autorizado.

Al intentar resolver la dirección IP de un nombre, un host del usuario, conocido en el sistema como una
resolución, primero comprobará su caché de DNS local. Como se ve en la figura, si la asignación no se
encuentra allí, se emitirá una consulta al servidor o a los servidores DNS que estén configurados en las
propiedades de direccionamiento de red de la resolución. Estos servidores pueden estar presentes en una
empresa o ISP. Si la asignación no se encuentra allí, el servidor DNS realiza la consulta en otros servidores
DNS de mayor nivel autorizados para el dominio de nivel superior a fin de encontrar la asignación. Este
proceso se denomina consulta recursiva.

Debido a la posible carga en los servidores de dominio de nivel superior autorizados, algunos servidores DNS
en la jerarquía mantienen cachés de todos los registros de DNS que han resuelto durante un período
específico. Estos servidores DNS de caché pueden resolver consultas recursivas sin reenviarlas a servidores
de nivel superior. Si un servidor requiere datos para una zona, solicitará una transferencia de datos de un
servidor autorizado para esa zona. El proceso de transferir bloques de datos de DNS entre servidores se
conoce como transferencia de zona.

En las figuras 2 a 6, se muestran los pasos relacionados con la resolución DNS.

Formato de mensaje DNS

DNS utiliza el puerto UDP 53 para las consultas y respuestas de DNS. Las consultas de DNS se originan en
un cliente y las respuestas se emiten desde servidores DNS. Si una respuesta de DNS excede los 512 bytes,
se usa el puerto TCP 53 para manipular el mensaje. Incluye el formato de consultas, respuestas y datos. Las
comunicaciones del protocolo DNS utilizan un único formato llamado “mensaje”. Este formato de mensaje que
se ve en la figura se utiliza para todos los tipos de solicitudes de clientes y respuestas del servidor, para los
mensajes de error y para la transferencia de información de registro de recursos entre servidores.

El servidor DNS almacena los diferentes tipos de RR utilizados para resolver nombres. Estos registros
contienen el nombre, la dirección y el tipo de registro. Esta es una lista de algunos de estos tipos de registros:
  A: una dirección IPv4 de terminal

 NS: un servidor de nombre autoritativo

 AAAA: una dirección IPv6 de terminal

 MX: un registro de intercambio de correo

Cuando un cliente realiza una consulta, el proceso DNS del servidor observa primero sus propios registros
para resolver el nombre. Si no puede resolverlo con los registros almacenados, contacta a otros servidores
para hacerlo. Una vez que se encuentra una coincidencia y se la devuelve al servidor solicitante original, este
almacena temporalmente la dirección numerada por si se vuelve a solicitar el mismo nombre.

El servicio del cliente DNS en los equipos Windows también almacena los nombres resueltos previamente en
la memoria. El comando ipconfig/displaydns muestra todas las entradas de DNS en caché.

DNS dinámico

DNS requiere que los registradores acepten y distribuyan las asignaciones de DNS de las organizaciones que
deseen registrar asignaciones de nombre de dominio y dirección IP. Después de crear la asignación inicial (un
proceso que puede demorar 24 horas o más), es posible realizar cambios en la dirección IP que se asigna al
nombre de dominio poniéndose en contacto con el registrador o usando un formulario en línea para efectuar el
cambio. Sin embargo, debido al tiempo que demora este proceso y la distribución de la nueva asignación en
el sistema de nombres de dominio, pueden transcurrir horas hasta que la nueva asignación esté disponible
para las resoluciones. En situaciones en las que un ISP utiliza DHCP para proporcionar direcciones a un
dominio, es posible que la dirección que se asigna al dominio caduque y el ISP otorgue una nueva. Esto daría
lugar a una interrupción de conectividad al dominio mediante DNS. Un nuevo enfoque era necesario para
permitir que las organizaciones realicen cambios rápidos en la dirección IP asignada a un dominio.

DNS dinámico (DDNS) le permite a un usuario u organización registrar una dirección IP con un nombre de
dominio, al igual que en DNS. Sin embargo, cuando cambia la dirección IP de la asignación, la nueva
asignación puede propagarse en el DNS casi instantáneamente. Para que esto ocurra, un usuario obtiene un
subdominio de un proveedor de DDNS. Ese subdominio se asigna a la dirección IP del servidor o la conexión
doméstica de router a Internet del usuario. El software cliente se ejecuta en el router o en una computadora
host que detecta un cambio en la dirección IP de Internet del usuario. Cuando se detecta un cambio, se
informa al proveedor de DDNS inmediatamente y la asignación entre el subdominio del usuario y la dirección
IP de Internet se actualiza inmediatamente, como se ve en la figura. DDNS no utiliza una verdadera entrada
de DNS para la dirección IP de un usuario. En cambio, actúa como intermediario. El dominio del proveedor de
DDNS está registrado con el DNS, pero el subdominio se asigna a una dirección IP completamente distinta. El
servicio del proveedor de DDNS suministra esa dirección IP al servidor DNS de segundo nivel de la
resolución. Ese servidor DNS, ya sea en la organización o en el ISP, proporciona la dirección IP de DDNS
para la resolución.

El protocolo WHOIS

WHOIS es un protocolo con base en TCP que se utiliza para identificar a los propietarios de dominios de
Internet a través del sistema de DNS. Cuando un dominio en Internet se registra y asigna a una dirección IP
para el sistema de DNS, el registrante debe proporcionar información sobre quién registra el dominio. La
aplicación de WHOIS utiliza una consulta en forma de FQDN. La consulta se emite a través de un servicio o
una aplicación de WHOIS. El registro oficial de propiedad se le devuelve al usuario mediante el servicio de
WHOIS. Esto puede resultar útil para la identificación de los destinos a los que han tenido acceso los hosts en
una red. WHOIS tiene limitaciones y los hackers tienen maneras de ocultar su identidad. Sin embargo, WHOIS
es un punto de partida para la identificación de ubicaciones de Internet potencialmente peligrosas a las que se
puede haber llegado mediante la red. ICANN mantiene un servicio de WHOIS con base en Internet y es
posible comunicarse con ellos en https://whois.icann.org/. Registradores de Internet regionales, como RIPE y
APNIC, también mantienen otros servicios de WHOIS.
Práctica de laboratorio: Utilizar Wireshark para examinar una captura
DNS de UDP

En esta práctica de laboratorio, establecerá comunicación con un servidor DNS enviando una consulta de
DNS mediante el protocolo de transporte UDP. Utilizará Wireshark para examinar los intercambios de consulta
y respuesta de DNS con el mismo servidor.

Práctica de laboratorio: Utilizar Wireshark para examinar una captura DNS de UDP

Esta página contiene una actividad de laboratorio titulada “Utilizar Wireshark para examinar una captura DNS
de UDP”.

Descripción general de NAT

No existen suficientes direcciones IPv4 públicas para asignar una dirección única a cada dispositivo
conectado a Internet. Las redes suelen implementarse mediante el uso de direcciones IPv4 privadas, según
se definen en RFC 1918. En la figura 1, se muestra el rango de direcciones incluidas en RFC 1918. Es muy
probable que la computadora que utiliza para ver este curso tenga asignada una dirección privada.

Estas direcciones privadas se utilizan dentro de una organización o un sitio para permitir que los dispositivos
se comuniquen localmente. Sin embargo, como estas direcciones no identifican empresas u organizaciones
individuales, las direcciones privadas IPv4 no se pueden enrutar a través de Internet. Para permitir que un
dispositivo con una dirección IPv4 privada tenga acceso a recursos y dispositivos fuera de la red local, primero
se debe traducir la dirección privada a una dirección pública, como se ve en la Figura 2.

Routers con NAT habilitada

Los routers con NAT habilitada se pueden configurar con una o más direcciones IPv4 públicas válidas. Estas
direcciones públicas se conocen como “conjunto de NAT”. Cuando un dispositivo interno envía tráfico fuera de
la red, el router con NAT habilitada traduce la dirección IPv4 interna del dispositivo a una dirección pública del
conjunto de NAT. Para los dispositivos externos, todo el tráfico entrante y saliente de la red parece tener una
dirección IPv4 pública del conjunto de direcciones proporcionado.

En general, los routers NAT funcionan en la frontera de una red de rutas internas. Una red de rutas internas
es aquella que tiene una única conexión a su red vecina, una entrada hacia la red y una salida desde ella. En
el ejemplo de la ilustración, el R2 es un router de frontera. Visto desde el ISP, el R2 forma una red de rutas
internas.

Cuando un dispositivo dentro de la red de rutas internas desea comunicarse con un dispositivo fuera de su
red, el paquete se reenvía al router de frontera. El router de frontera realiza el proceso de NAT, es decir,
traduce la dirección privada interna del dispositivo a una dirección pública, externa y enrutable.

Nota: la conexión al ISP puede utilizar una dirección privada o pública compartida entre clientes. A los fines
de este capítulo, se muestra una dirección pública.

Traducción de la dirección del puerto

NAT puede implementarse como asignaciones estáticas individuales de direcciones privadas a direcciones
públicas, o muchas direcciones internas pueden asignarse a una única dirección pública. Esto se conoce
como traducción de dirección de puerto (PAT). La PAT se utiliza muy comúnmente en redes domésticas
cuando un ISP le proporciona una dirección IP pública exclusiva a un router doméstico. En la mayoría de los
hogares, varios dispositivos requieren acceso a Internet. La PAT permite que todos los dispositivos de red
dentro de la red doméstica compartan la dirección IP exclusiva que proporciona el ISP. En redes de mayor
tamaño, la PAT también puede utilizarse para asignar muchas direcciones internas a varias direcciones
públicas.

Con PAT, se pueden asignar varias direcciones a una o más direcciones, debido a que cada dirección privada
también se rastrea con un número de puerto. Cuando un dispositivo inicia una sesión TCP/IP, genera un valor
de puerto de origen TCP o UDP o un ID de consulta asignado especialmente para ICMP, con el fin de
identificar la sesión sin posibilidad de ambigüedades. Cuando el router NAT recibe un paquete del cliente,
utiliza su número de puerto de origen para identificar de forma exclusiva la traducción NAT específica. El
proceso de PAT también valida que los paquetes entrantes se hayan solicitado, lo que añade un grado de
seguridad a la sesión.

Haga clic en los botones Reproducir y Pausa de la ilustración para controlar la animación. En la animación, se
muestra el proceso de PAT. PAT agrega números de puerto de origen únicos a la dirección global interna para
distinguir las traducciones.

A medida que el R2 procesa cada paquete, utiliza un número de puerto (1331 y 1555, en este ejemplo) para
identificar el dispositivo en el que se originó el paquete. La dirección de origen (SA) es la dirección local
interna a la que se agregó el número de puerto TCP/IP asignado. La dirección de destino (DA) es la dirección
local externa a la que se agregó el número de puerto de servicio. En este ejemplo, el puerto de servicio es 80,
que es HTTP.

Para la dirección de origen, el R2 traduce la dirección privada (conocida como dirección local interna) a una
dirección global interna pública con el número de puerto agregado. La dirección de destino no se modifica,
pero ahora se la denomina dirección IPv4 global externa. Cuando el servidor web responde, se invierte la ruta.

NAT y PAT pueden complicar las ciberoperaciones, ya que pueden ocultar información de direccionamiento
en los archivos de registro creados por dispositivos de seguridad de la red y de monitoreo.

FTP y TFTP

Protocolo de transferencia de archivos (FTP)

FTP es otro protocolo de capa de aplicación que se utiliza comúnmente. El protocolo FTP se desarrolló para
permitir las transferencias de datos entre un cliente y un servidor. Un cliente FTP es una aplicación que se
ejecuta en una computadora cliente y se utiliza para insertar y extraer datos en un servidor FTP.

Como se ve en la Figura 1, para transferir datos correctamente, el FTP requiere dos conexiones entre el
cliente y el servidor: una para los comandos y las respuestas y la otra para la transferencia de archivos
propiamente dicha:

1. El cliente establece la primera conexión al servidor para el tráfico de control por medio del puerto 21 de
TCP, que está constituido por comandos del cliente y respuestas del servidor.

2. El cliente establece la segunda conexión al servidor para la transferencia de datos propiamente dicha por
medio del puerto 20 de TCP. Esta conexión se crea cada vez que hay datos para transferir.

La transferencia de datos se puede producir en ambas direcciones. El cliente puede descargar (extraer) datos
del servidor o subir datos a él (insertarlos).

El FTP no se concibió como un protocolo de capa de aplicación seguro. Por este motivo, el protocolo de
transferencia de SSH, que es una forma segura de FTP que utiliza el protocolo Secure Shell para ofrecer un
canal protegido, es la opción preferida para la transferencia de archivos.

Protocolo trivial de transferencia de archivos (TFTP)

TFTP es un protocolo de transferencia de archivos simplificado que utiliza el conocido número de puerto UDP
69. Carece de muchas de las características del FTP, como las operaciones de gestión de archivos para
enumerar, eliminar o renombrar archivos. Debido a su sencillez, el TFTP tiene una sobrecarga de red muy
baja y es popular para aplicaciones de transferencia de archivos que no son fundamentales. Sin embargo, es
inseguro por naturaleza, porque no tiene ninguna característica de inicio de sesión ni de control de acceso.
Por este motivo, el TFTP debe implementarse cuidadosamente y solo cuando sea absolutamente necesario.

SMB

El bloque de mensajes del servidor (SMB) es un protocolo de intercambio de archivos entre cliente y servidor
que describe la estructura de los recursos de red compartidos, como directorios, archivos, impresoras y
puertos serie, como se ve en la Figura 1. Es un protocolo de solicitud-respuesta. Todos los mensajes SMB
comparten un mismo formato. Este formato utiliza un encabezado de tamaño fijo seguido de un parámetro de
tamaño variable y un componente de datos.

Los mensajes SMB pueden iniciar, autenticar y terminar sesiones, controlar el acceso a archivos e
impresoras, y permitir que una aplicación envíe mensajes a otro dispositivo o los reciba de él.

Los servicios de impresión y uso compartido de archivos de SMB se han convertido en el pilar de las redes de
Microsoft, como se ve en la Figura 2.

Práctica de laboratorio: Utilizar Wireshark para examinar capturas de

TCP y UDP

En esta práctica de laboratorio se cumplirán los siguientes objetivos:

 Identificar campos de encabezado y operación TCP mediante una captura de sesión FTP de Wireshark

 Identificar campos de encabezado y operación UDP mediante una captura de sesión TFTP de
Wireshark

Práctica de laboratorio: Utilizar Wireshark para examinar capturas de TCP y UDP

Esta página contiene una actividad de laboratorio titulada “Utilizar Wireshark para examinar capturas de TCP y
UDP”.

Descripción general del correo electrónico

El correo electrónico es una aplicación de red esencial. Para ejecutarse en una computadora o en otro
terminal, se requieren varios servicios y aplicaciones, como se ve en la figura. El correo electrónico es un
método de almacenamiento y envío que se utiliza para enviar, almacenar y recuperar mensajes electrónicos a
través de una red. Los mensajes de correo electrónico se guardan en bases de datos en servidores de correo.

Los clientes de correo electrónico se comunican con servidores de correo para enviar y recibir mensajes de
correo electrónico. Los servidores de correo se comunican con otros servidores de correo para transportar
mensajes desde un dominio a otro. Un cliente de correo electrónico no se comunica directamente con otro
cliente de correo electrónico cuando envía un mensaje. En cambio, ambos clientes dependen del servidor de
correo para el transporte de los mensajes.

El correo electrónico admite tres protocolos diferentes para su funcionamiento: el protocolo simple de
transferencia de correo (SMTP), el protocolo de oficina de correos versión 3 (POP3) e IMAP. El proceso de
capa de aplicación que envía correo utiliza SMTP. Sin embargo, un cliente recupera el correo electrónico
mediante uno de los dos protocolos de capa de aplicación: POP3 o IMAP.
SMTP

Los formatos de mensajes SMTP necesitan un encabezado y un cuerpo de mensaje. Mientras que el cuerpo
del mensaje puede contener la cantidad de texto que se desee, el encabezado debe contar con una dirección
de correo electrónico de destinatario correctamente formateada y una dirección de emisor.

Cuando un cliente envía correo electrónico, el proceso SMTP del cliente se conecta a un proceso SMTP del
servidor en el puerto bien conocido 25. Después de que se establece la conexión, el cliente intenta enviar el
correo electrónico al servidor a través de esta. Una vez que el servidor recibe el mensaje, lo ubica en una
cuenta local (si el destinatario es local) o lo reenvía a otro servidor de correo para su entrega, como se
muestra en la figura.

El servidor de correo electrónico de destino puede no estar en línea, o estar muy ocupado, cuando se envían
los mensajes. Por lo tanto, el SMTP pone los mensajes en cola para enviarlos posteriormente. El servidor
verifica periódicamente la cola en busca de mensajes e intenta enviarlos nuevamente. Si el mensaje aún no
se ha entregado después de un tiempo predeterminado de expiración, se devolverá al emisor como imposible
de entregar.

En la figura, se ve a un cliente enviando correo. El mensaje llega al servidor de correo electrónico y este
último decide si el mensaje es para uno de sus clientes. Si no lo es, reenvía el mensaje a otro servidor de
correo electrónico para que lo entregue.

POP3

Una aplicación usa POP3 para recuperar correo de un servidor de correo. Con POP3, el correo se descarga
del servidor al cliente y se elimina del servidor después, como se ve en la figura.

El servidor comienza el servicio POP3 escuchando de manera pasiva en el puerto TCP 110 las solicitudes de
conexión del cliente. Cuando un cliente desea utilizar el servicio, envía una solicitud para establecer una
conexión TCP con el servidor. Una vez establecida la conexión, el servidor POP3 envía un saludo. A
continuación, el cliente y el servidor POP3 intercambian comandos y respuestas hasta que la conexión se
cierra o cancela.

Con POP3, los mensajes de correo electrónico se descargan en el cliente y se eliminan del servidor, lo que
significa que no existe una ubicación centralizada donde se conserven los mensajes de correo electrónico.
Como el POP3 no almacena mensajes, no es una opción adecuada para una pequeña empresa que necesita
una solución de respaldo centralizada.

IMAP

IMAP es otro protocolo que describe un método para recuperar mensajes de correo electrónico, como se ve
en la figura. A diferencia de POP3, cuando el usuario se conecta a un servidor compatible con IMAP, se
descargan copias de los mensajes a la aplicación cliente. Los mensajes originales se mantienen en el servidor
hasta que se eliminen manualmente. Los usuarios ven copias de los mensajes en su software de cliente de
correo electrónico.

Los usuarios pueden crear una jerarquía de archivos en el servidor para organizar y guardar el correo. Dicha
estructura de archivos se duplica también en el cliente de correo electrónico. Cuando un usuario decide
eliminar un mensaje, el servidor sincroniza esa acción y elimina el mensaje del servidor.

Haga clic aquí para obtener más información sobre los protocolos de correo electrónico.

En la figura, se ve a un cliente enviando correo electrónico a un servidor mediante SMTP, que utiliza SMTP
para enviarlo a otro servidor. El segundo servidor usa IMAP para entregar el correo electrónico al destinatario.
Descripción general de HTTP

Para comprender mejor cómo interactúa el navegador web con el servidor web, podemos analizar cómo se
abre una página web en un navegador. Para este ejemplo, utilice la URL http://www.cisco.com, como se ve en
la Figura 1.

Primero, el explorador interpreta las tres partes del URL:

 http (el protocolo o esquema)

 www.cisco.com (el nombre del servidor)

 index.html (se solicita la página de inicio predeterminada)

Nota: Los servidores web suelen mostrar la página de inicio (index.html) como la página predeterminada si no
se especifica ninguna otra página. No es necesario escribir la ruta completa con /index.html incluido. De
hecho, basta con escribir cisco.com. Independientemente de que se escriba cisco.com, www.cisco.com o
www.cisco.com/index.html, el servidor web mostrará la misma página: index.html.

A continuación, el navegador se comunica con un servidor de nombres para convertir www.cisco.com en una
dirección IP numérica que utiliza para conectarse al servidor, como se muestra en la figura 2. Mediante los
requisitos de HTTP, el navegador envía una solicitud GET al servidor y pide el archivo index.html. El servidor
envía el código HTML para esta página web al navegador, como se muestra en la figura 3. Finalmente, el
navegador descifra el código HTML y da formato a la página para que se pueda visualizar en la ventana del
navegador, como se muestra en la figura 4.

La URL de HTTP

Las URL de HTTP también pueden especificar el puerto en el servidor que debe manejar los métodos de
HTTP. Además, puede especificar una cadena y un fragmento de la consulta. Normalmente, la cadena de la
consulta contiene información que no maneja el propio proceso del servidor HTTP, sino otro proceso que se
ejecuta en el servidor. Las cadenas de la consulta comienzan con un carácter “?” y, normalmente, constan de
una serie de pares de nombre y valor. Un fragmento comienza con un carácter “#”. Hace referencia a una
parte subordinada del recurso que se solicita en la URL. Por ejemplo, un fragmento puede hacer referencia a
un delimitador nombrado en un documento HTML. La URL tendrá acceso al documento y, luego, se dirigirá a
la parte del documento especificada por el fragmento si existe un enlace del delimitador nombrado que
coincida en el documento. En la figura, se ve una URL de HTTP que incluye estas partes.

El protocolo HTTP

HTTP es un protocolo de solicitud y respuesta que utiliza el puerto TCP 80, aunque se pueden utilizar otros
puertos. Cuando un cliente (normalmente, un navegador web) envía una solicitud a un servidor web, utiliza
uno de los seis métodos que especifica el protocolo HTTP.

 GET: solicitud de datos por parte del cliente. Un cliente (navegador web) envía el mensaje GET al
servidor web para solicitar las páginas HTML, como se ve en la figura.

 POST: envía datos para que los procese un recurso.

 PUT: carga los recursos o el contenido, como por ejemplo una imagen, en el servidor web.

 DELETE: borra el recurso especificado.

  OPTIONS: enumera los métodos HTTP que admite el servidor.

 CONNECT: solicita que un servidor proxy HTTP reenvíe la sesión TCP de HTTP al destino deseado.

Aunque HTTP es sumamente flexible, no es un protocolo seguro. Los mensajes de solicitud envían
información al servidor en texto sin formato que puede ser interceptado y leído. Las respuestas del servidor,
generalmente páginas HTML, también están sin cifrar.

Protección de HTTP

Para una comunicación segura a través de Internet, se utiliza el protocolo HTTP seguro (HTTPS). HTTPS
utiliza el puerto TCP 443. HTTPS utiliza autenticación y cifrado para proteger los datos mientras viajan entre el
cliente y el servidor. HTTPS utiliza el mismo proceso de solicitud del cliente y respuesta del servidor que
HTTP, pero el flujo de datos se encripta con la capa de sockets seguros (SSL) o la seguridad de la capa de
transporte (TLS) antes de transportarlo por la red. Aunque SSL es el predecesor de TLS, ambos protocolos
suelen denominarse SSL.

Mucha información confidencial se transmite por Internet usando HTTPS, como las contraseñas, los datos de
tarjetas de crédito y la información médica.

Códigos de estado de HTTP

Las respuestas del servidor HTTP se identifican con diversos códigos de estado que le informan a la
aplicación host el resultado de las solicitudes que el cliente le realiza al servidor. Los códigos se organizan en
cinco grupos. Los códigos son numéricos y el primer número del código indica el tipo de mensaje. Los cinco
grupos de códigos de estado son los siguientes:

 1xx: de información

 2xx: éxito

 3xx: redireccionamiento

 4xx: error de cliente

 5xx: error de servidor

En la figura, se ve una explicación de algunos códigos de estado comunes. Haga clic aquípara ver una lista
detallada de todos los códigos de estado con sus explicaciones.

Práctica de laboratorio: Utilizar Wireshark para examinar tráfico HTTP y

HTTPS

En esta práctica de laboratorio se cumplirán los siguientes objetivos:

 Capturar y ver tráfico HTTP

 Capturar y ver tráfico HTTPS

Práctica de laboratorio: Utilizar Wireshark para examinar tráfico HTTP y HTTPS

Esta página contiene una actividad de laboratorio titulada “Utilizar Wireshark para examinar tráfico HTTP y
HTTPS”.

Capítulo 4: Protocolos y servicios de red

En este capítulo, aprendió el funcionamiento básico de los protocolos y servicios de red. Las redes vienen en
todos los tamaños, desde pequeñas redes de oficina hasta Internet. Los protocolos son las reglas que rigen el
modo en que el tráfico se envía por las redes. Los ingenieros de redes utilizan dos modelos para entender y
comunicar el funcionamiento de protocolos: el modelo OSI y el modelo TCP/IP. Independientemente del
modelo utilizado, el proceso de encapsulamiento describe cómo los datos se formatean para transmitirlos por
toda la red a fin de que el destino pueda recibirlos y desencapsularlos.

Ethernet funciona en la capa 2 del modelo OSI. Ethernet es responsable de encapsular los datos de la capa
superior en una trama, que incluye las direcciones MAC de origen y de destino. Las direcciones MAC se
utilizan en la red LAN para localizar el destino o el gateway predeterminado.

IP funciona en la capa 3 del modelo OSI. IP viene en dos versiones: IPv4 e IPv6. Aunque IPv6 está
reemplazando a IPv4, este último todavía prevalece en las redes actuales. IPv4 utiliza un espacio de
direcciones de 32 bits en formato decimal con puntos, por ejemplo, 192.168.1.1. IPv6 utiliza un espacio de
direcciones de 128 bits representado en formato hexadecimal. En IPv6, es posible omitir los ceros en cada
hexteto y omitir un segmento completo de ceros. Por ejemplo, 2001:0DB8:0000:1111:0000:0000:0000:0200
se representa como 2001:DB8:0:1111::200.

ICMP se utiliza principalmente para probar la conectividad integral del origen al destino. ICMP para IPv4 es
diferente de ICMP para IPv6. ICMP para IPv6 incluye solicitación de router, anuncio de router y detección de
direcciones duplicadas. Las utilidades ping y traceroute utilizan ambas una función de ICMP. El comando ping
se usa para probar la conectividad entre dos hosts, pero no proporciona información sobre los detalles de los
dispositivos entre los hosts. Traceroute (tracert) es una utilidad que genera una lista de saltos que se
alcanzaron correctamente a lo largo de la ruta.

ARP funciona entre la capa 2 y la capa 3, y asigna direcciones MAC a direcciones IP. Antes de que un host
pueda enviar tráfico a una red remota, debe conocer la dirección MAC del gateway predeterminado. El host ya
conoce la dirección IP del gateway predeterminado. Por ejemplo, un host con una dirección IP 192.168.1.10
podría tener configurado un gateway predeterminado de 192.168.1.1. El host usa una solicitud de ARP para
preguntar “¿Quién es 192.168.1.1?”. El gateway predeterminado contesta con su propia dirección MAC. Para
ese momento, el host ya asignó la dirección IP a la dirección MAC del gateway predeterminado y ahora puede
crear el cuadro para enviar datos a una red remota.

La capa de transporte es responsable de separar los datos de la capa de aplicación en segmentos que
puedan enviarse a la capa de red. TCP es el protocolo de capa de transporte utilizado cuando todos los datos
deben llegar al destino en el orden correcto. UDP es el protocolo de capa de transporte utilizado cuando la
aplicación puede tolerar cierta pérdida de datos durante la transmisión.

En la aplicación, hay varios servicios de red importantes que los analistas de ciberseguridad deben conocer:

 DHCP: este servicio automatiza la asignación de direcciones IPv4, máscaras de subred, gateway y otros
parámetros de redes IPv4.

 DNS: este servicio proporciona un medio confiable para administrar y proporcionar los nombres de
dominio y sus direcciones IP asociadas.

 NAT: este servicio realiza traducciones entre las direcciones IPv4 públicas y privadas.

 Transferencia de archivos: es posible usar aplicaciones como FTP, TFTP y SMB para transferir
archivos de un host a otro.
  Correo electrónico: este servicio requiere varias aplicaciones y servicios, incluidos POP3, IMAP y
SMTP.

 HTTP: este protocolo se utiliza para enviar y recibir páginas web.

En la figura vemos un collage con las palabras Resumen capítulo 4.