EJERCICIOS DE REDES
1. Averigua qué tarjeta de red hay instalada en tu ordenador del aula de informática, siguiendo los siguientes pasos:
a. Inicio -> Panel de control
b. Clica “Conexiones de red”
i. LAN o Internet de alta velocidad.
c. Clica dos veces el icono de la conexión:
d. Mira el dato que se te da en la pestaña “General” en el apartado “Conectar a usuario”
e. Identifica la parte visible de la tarjeta de red de tu ordenador en la parte trasera de esta.
f. Comprueba que tiene un cable conectado y que junto al cable hay una luz verde que parpadea periódicamente indicando actividad.
2. Todas las tarjetas de red (por ejemplo la de nuestro PC en el aula) están identificadas
unívocamente con una dirección MAC (Media Access Control) que sirve para identificar al equipo en la red (es decir la dirección MAC es única, viene dada por el fabricante de la tarjeta y no existe ninguna otra tarjeta de red en el mundo que tenga la misma dirección). Podemos saber cuál es la dirección MAC de nuestra tarjeta mediante el comando (en la pantalla de comandos):
C:\> getmac
a. Puede aparecer más de una dirección MAC si es que nuestro ordenador tiene más de una tarjeta de red.
b. La dirección MAC tienen un formato en hexadecimal del tipo: 00-C0-9F-5E-D3-7B.
c. Los tres primeros bytes, denominados OUI (en el ejemplo 00-C0-9F, son otorgados por el IEEE (Institute of Electrical and Electronic Engineers))
d. Y los otros 3 bytes (en nuestro ejemplo 5E-D3-7B), denominados NIC, son responsabilidad del fabricante de la tarjeta de red.
Incluye un pantallazo (tecla “Alt”+Impr Pant) del resultado del comando en el que se vea la dirección MAC de la(s) tarjeta(s) de red de tu ordenador en el aula: (* Ojo: La dirección MAC no tiene nada que ver con los ordenadores Mac de Apple)
3. En la página https://github.com/royhills/arp-scan/blob/master/ieee-oui.txt averigua el OUI que el IEEE ha asignado a los siguientes fabricantes de tarjetas de red.
4. Averigua ¿cuántas conexiones de red puede tener un ordenador?
5. Lee en https://www.noticias3d.com/articulo.asp?idarticulo=174&pag=2 la comparativa que hay
entre el HUB y el SWITCH. Indica con tus palabras los cuatro puntos o conclusiones que se
exponen:
1.
2.
3.
4.
6. Averigua si tu ordenador está conectado a la red mediante cable “de par trenzado” (con conector
RJ45) o cable coaxial u otro tipo de conexión.
7. Indica el código de colores de tu cable de red (de izquierda a derecha observándolo por el lado
que no tiene pestaña)
8. ¿Qué ventajas tiene el cable de par trenzado sobre el coaxial?
9. ¿A qué velocidad de transmisión funcionan las redes Ethernet?
a. ¿Y las Fast Ethernet?
b. ¿Hay otros estándares de Ethernet más veloces aún?
10. Los ROUTERS se encargan de que la información que enviamos a través de Internet llegue a su
destinatario. Investiga cuántos ROUTERS intervienen en la comunicación entre nuestro PC y el
servidor de google mediante el comando (en la pantalla de comandos CMD):
C:\> tracert www.google.es
(el comando también nos indica cuanto tiempo tarda el ROUTER en “pensar o decidir” cuál es el paso siguiente de la ruta). Incluye un pantallazo del resultado del comando
11. En el nivel 5 del protocolo TCP/IP tiene mucha importancia la aplicación DNS, averigua que
servicio proporcionan los servidores DNS
12. ¿En qué nivel de TCP/IP trabajan las aplicaciones HTTP, FTP ó TELNET?
13. Para conectarnos a Internet necesitamos disponer de una dirección IP que nos identifique en la
red, a la que se le puedan enviar datos y que pueda ser identificada como emisora de datos.
Averigua la dirección IP de tu PC mediante el comando (en la pantalla de comandos):
C:\>ipconfig
Incluye un pantallazo del resultado del comando
14. ¿Cuál es el significado de la máscara de subred (Subnet Mask) en el protocolo TCP/IP?
15. ¿Qué es la puerta de enlace (predeterminada) o “default gateway”?
16. Las direcciones IP están clasificadas en clases:
a. ¿qué indican esas clases?
b. ¿cuáles son?
c. ¿a qué clase corresponden las siguientes direcciones IP?:
IP
|
CLASE
|
214.258.28.37
|
|
47.25.34.17
|
|
3.21.28.53
|
|
125.369.66.21
|
|
45.69.68.25
|
|
192.168.8.28
|
|
17. Qué máscara de subred usaríamos para las siguientes direcciones?
IP
|
MÁSCARA DE SUBRED
|
11.25.36.54
|
|
192.168.24.58
|
|
210.25.36.84
|
|
18. El comando:
C:\>ipconfig /all
es más completo que “ipconfig”, nos da las direcciones MAC de todas las tarjetas de red de nuestro PC, las direcciones IP en la red local en la que estamos conectados, la puerta de enlace (o dirección IP (hacia la red local) del ROUTER que usamos para salir a Internet), las direcciones de los servidores DNS y si utilizamos o no servidores DHCP. Incluye un pantallazo (tecla “Alt”+Impr Pant) del resultado del comando
19. Observa que en el pantallaza del ejercicio anterior aparece la línea “DHCP habilitado”,
a. ¿lo tienes habilitado o deshabilitado?
b. ¿qué significa DHCP?
c. ¿qué quiere decir que esté deshabilitado?
20. ¿Qué tipo de servidor usarías si quisieras que cada vez que encendamos el ordenador se configuren los parámetros TCP/IP de forma automática?
21. Busca en Internet las ventajas o inconvenientes de usar una IP estática o dinámica.
22. La información del comando C:\>ipconfig /all, la podemos ver también siguiendo los siguientes pasos:
a. Inicio -> Panel de control
b. Clica “Conexiones de red”
i. LAN o Internet de alta velocidad.
c. Clica botón derecho del ratón en el icono de la conexión “Propiedades”:
d. Mira el dato que se te da en la pestaña “General” en la línea “Protocolo TCP/IP” (al final de la lista), clicando “Propiedades”,
https://elcodigoascii.com.ar/codigos-ascii/signo-equivalencia-tilde-virgulilla-codigo-ascii-126.html
f. Indica con un pantallazo los datos que aparecen en esa ventana de tu PC:
23. ¿Por qué nuestro proveedor de Internet (Telefónica, Jazztel, Orange, etc…) nos proporciona dos
direcciones DNS?
DNS
|
PROVEEDOR DE INTERNET
|
TELEFONICA
|
|
ORANGE
|
|
JAZZTEL
|
|
VODAFONE
|
|
MOVISTAR
|
|
ONO
|
|
………………………………
|
26. Hasta ahora hemos visto que:
a. Todo dispositivo (PC, impresora, router, …) que se quiera conectar una red necesita una tarjeta de red,
b. Además cualquier dispositivo conectado a una red, necesita una dirección IP a la que le llegarán datos y desde la que se podrán enviar datos (algo así como nuestra dirección de casa para el servicio de Correos),
c. Tiene que haber algún dispositivo switch o hub en el que confluyan todos los dispositivos (PCs, impresoras,...) de la red, para que éstos puedan verse entre sí:
d. En el Aula 1 de Informática el SWITCH está situado junto a la puerta en un armario de cristal (observa los cables que le llegan, los que salen de eél y hacia dónde).
e. Con todo esto ya tendríamos una “red local”.
f. Pero para salir a la “Red de Redes” o Internet, necesitamos de un dispositivo “más inteligente” llamado ROUTER, que será a través del que Internet nos verá a nosotros como dispositivo individual (por ejemplo nuestro ordenador de casa) o como grupo de ordenadores de una red local (por ejemplo Aula 1 de Informática). El ROUTER que nosotros estamos utilizando NO está situado en el Aula 1, pero nuestro SWITCH está conectado a él a través de un cable.
g. Navegamos a Internet a través de ese ROUTER, y lo que tenga que llegarnos de Internet, el ROUTER nos lo hará llegar porque él conoce nuestra dirección IP en la “red local”: si nos queremos conectar a YAHOO sabrá que los datos de la página nos tienen que llegar a nuestro PC, y no al de nuestro compañero (que se ha conectado a HOTMAIL). Esto es gracias a la tabla de dirección de todos los PCs del Aula que el Router conoce y actualiza periódicamente cuando estos arrancan sus conexiones de red.
h. Por tanto nuestra red tendría este aspecto (rellena en los huecos los datos que has ido obteniendo en el cuestionario):
27. Pero, según lo dicho en el ejercicio anterior, ¿con que dirección IP nos ve la red global (Internet) a través del Router (o lo que es lo mismo qué dirección IP tiene el router hacia la red global, Internet? Teclea http://www.cualesmiip.com/ en el navegador e indica aquí tu la IP con la que te ve Internet a través de tu ROUTER:
28. Con todos estos datos completa el esquema del ejercicio 25
29. Ejecuta el comando C:\> ping www.google.es
a. Verás que aparece la IP de Google, indícala:
b. Abre el navegador y escribe esa dirección IP en la barra de direcciones. Explica que ocurre:
c. Ahora ejecuta el comando ping con esa IP: C:\> ping IP
d. Incluye un pantallazo (tecla “Alt”+Impr Pant) del resultado del comando:
e. Ejecuta el comando ping con la dirección IP del PC de tus compañeros.
f. Incluye un pantallazo (tecla “Alt”+Impr Pant) del resultado del comando:
g. Ejecuta el comando ping con la dirección IP de tu propio PC.
h. ¿Qué ocurre?
i. Incluye un pantallazo (tecla “Alt”+Impr Pant) del resultado del comando:
j. Desconecta el cable de red y vuelve a dar el comando ping con la dirección IP de tus compañeros.
k. ¿Qué ocurre?
l. Incluye un pantallazo (tecla “Alt”+Impr Pant) del resultado del comando (con el cable quitado):
m. Con el cable desconectado ejecuta el comando ipconfig /all e incluye un pantallazo del resultado:
30. Abre dos ventanas de comandos y ejecuta el comando: C:\>tracert www.google.es en cada una de ellas.
a. Incluye los pantallazos (tecla “Alt”+Impr Pant) de cada una de ellas:
b. ¿hay diferencias?
c. ¿por qué?
31. Ejecuta el comando C:\>ipconfig /?
a. ¿para qué nos sirve?
b. ¿qué datos opciones nos da?
http://cuartoinformatica.tecnojulio.com/2016/01/12/la-tarjeta-de-red/ https://ledoestela4a.blogspot.com/2013/01/22-cuestiones-sobre-redes-informaticas-i.HTML
CAPA DE REDLa capa de red desempeña un papel primordial en la arquitectura TCP/IP, ya que todos los protocolos de las capas superiores utilizan su protocolo principal: el protocolo IP (Internet Protocol). De entre las funciones de esta capa destacan el direccionamiento y el encaminamiento, esenciales para el funcionamiento de Internet. Sin embargo, otras de sus funciones también tienen gran importancia. De entre ellas, podemos mencionar la fragmentación y re-ensamblado de paquetes, la movilidad, la seguridad o el control de la operación de la propia capa de red. En este capítulo se ofrece una visión general de los aspectos anteriores, presentando también una visión general de los dispositivos que basan su funcionamiento en esta capa. 1 El protocolo IPEl protocolo IP es un protocolo que no garantiza la transferencia fiable de paquetes y que proporciona un servicio de red en modo sin conexión (connectionless mode). El no garantizar la transferencia fiable de información significa que este protocolo no realiza ninguna operación de detección y/o recuperación de errores y que, por lo tanto, ofrece un servicio de entrega de paquetes siguiendo el criterio de mejor esfuerzo (best effort). El modo de operación sin conexión significa que no se mantiene información de estado acerca del flujo de datagramas, es decir, cada paquete IP se trata independientemente del modo en el que se trabajó con el anterior. Esto también significa que la capa de red (o capa IP) no realiza ninguna función de control de secuencia o control de flujo. Al optarse por dejar las funciones de control de secuencia, control de errores y control de flujo para los protocolos de los niveles superiores (transporte o aplicación), se pretende hacer que las funciones de esta capa sean lo más simples posible y que así se requieran pocos recursos por parte de los equipos encaminadores (routers). La Figura 2.1 representa un paquete IP (en la versión 4 de este protocolo, que se conoce como IPv4), siendo visibles sus diversos campos. Los paquetes contienen toda la información necesaria para que los routers los procesen y decidan su encaminamiento independientemente de los paquetes de datos procesados anteriormente.
Figuras 2.1 Formato de un paquete IPv4
Cada línea en la figura se corresponde con 32 bits, es decir, 4 bytes. Haciendo referencia a la figura, el orden de transmisión de los bytes en la red es de izquierda a derecha y de arriba a abajo. Este orden de transmisión de bytes se conoce como big endian o como orden de bytes de red (network byte order), y debe cumplirse sin importar el orden en que los bytes se almacenan en las máquinas de origen, tránsito o destino de los paquetes.
La cabecera de los paquetes IPv4 consta de 20 bytes (las cinco primeras líneas de la Figura 2.1) y se puede extender con un máximo de 40 bytes opcionales.
El campo ‘versión’ es un campo de 4 bits que tiene el valor 4, identificando de este modo la versión 4 del protocolo IP (antes lo denominamos IPv4).
El campo 'longitud de la cabecera' es un campo de 4 bits que contiene el número total de palabras de 32 bits que componen la cabecera, incluyendo los campos opcionales. Precisamente, el permitir campos opcionales es lo que provoca que la cabecera tenga una longitud variable que por lo tanto debe ser especificada para distinguirla de la zona de datos.
El campo ‘calidad de servicio’ (8 bits) está reservado para identificar la calidad de servicio asociada a este datagrama. La calidad de servicio determina la forma en que los paquetes se procesarán en los routers o en otros dispositivos de la red que se encuentran en el camino hacia el destino.
El campo ‘longitud total’ indica la longitud del paquete IP en bytes. Dado que este campo es de 16 bits, la longitud máxima de un paquete IP se limita a 65535 bytes.
El campo ‘identificación’ (16 bits) identifica de manera unívoca cada paquete enviado por cada sistema de terminal (host). Junto con los campos ‘flags’ (3 bits) y ‘desplazamiento de fragmento’ (13 bits), este campo se utiliza para las operaciones de fragmentación y re-ensamblado que se describen en la sección 2.4.
El campo ‘tiempo de vida’ (8 bits) establece un límite en el número de routers que el paquete IP puede atravesar, lo que constituye una protección contra los bucles de encaminamiento. El valor del campo se disminuye en una unidad en cada router que recibe el paquete. Si después de esta operación, el campo alcanza el valor 0, el paquete se descarta y se notifica al remitente sobre esta acción a través de un mensaje del protocolo ICMP (Internet Control Message Protocol) (ver
sección 2.5).
El campo ‘protocolo’ (8 bits) identifica el protocolo de capa de transporte a la que los paquetes de datos se entregarán.
El campo ‘suma de comprobación de cabecera’ (16 bits) es un código de detección de errores que cubre sólo los bytes que forman la cabecera del paquete. La suma de comprobación (también llamada suma de verificación o suma de control) es de la suma de los complemento a‘1’ de las palabras de 16 bits que componen la cabecera. (OJO: el complemento a ‘1’ de un número binario se obtiene cambiando sus bits ‘0’ a ‘1’ y sus bits ‘1’ a ‘0’. A esta operación también se llama negación lógica.) En la recepción, si la suma de comprobación es incorrecta el paquete se elimina. Este campo no
cubre el campo de datos del paquete, lo que significa que el control de errores de los datos se deja para los protocolos de nivel superior.
Cada uno de los campos ‘dirección IP de origen’ y ‘dirección IP de destino’ tiene 32 bits (en el caso del IPv4) e identifican al remitente y al destinatario del paquete, respectivamente. Esta cantidad de bits asignada a las direcciones ha resultado insuficiente debido al rápido crecimiento que ha experimentado Internet y al desperdicio de direcciones IP resultante del esquema de direccionamiento adoptado en IPv4 – que veremos en detalle en el Capítulo 3. Esta limitación es una de las razones principales para el desarrollo de la nueva versión del protocolo IP, llamada IPv6.
La Figura 2.2 muestra el formato de la cabecera de los paquetes IPv6. Puede apreciarse su simplicidad en comparación con IPv4. En IPv6, las direcciones son de 128 bits en lugar de los 32 bits de IPv4, lo que se corresponde con un espacio de direcciones que es 296 veces el de IPv4. Incluso teniendo en cuenta el desperdicio de direcciones inherente a una política de direccionamiento jerárquico, se estima que, en el peor de los casos, el espacio de direcciones IPv6 pueda acomodar más de 1.500 direcciones por metro cuadrado de la superficie de la tierra. El RFC 4291 define la arquitectura de direccionamiento IPv6.
Figura 2.2 Formato de la cabecera de los paquetes IPv6
El campo ‘versión’ (4 bits) identifica la versión del protocolo y tiene el valor fijo de 6. El campo ‘clase de tráfico’ (8 bits) se utiliza para identificar diferentes clases de tráfico, cada una con diferentes requisitos de calidad de servicio. El campo ‘etiqueta de flujo’ (20 bits) se utiliza para identificar los paquetes que pertenecen al mismo flujo de datos (por ejemplo, paquetes que pertenecen a la misma secuencia de vídeo). El campo ‘longitud del campo de datos’ (16 bits) indica el tamaño del campo de datos, en bytes, incluyendo las cabeceras de extensión opcionales. El campo ‘siguiente cabecera’ (8 bits) especifica el tipo de cabecera que se encuentra en el campo de datos. Puede ser, por ejemplo, la cabecera de un protocolo de transporte (en este caso, este campo es equivalente al campo ‘protocolo’ de la cabecera de los paquetes IPv4) o una cabecera de extensión. El campo ‘límite de saltos’ (8 bits) es equivalente al campo ‘tiempo de vida’ de los paquetes IPv4.
2 Direccionamiento
El direccionamiento es una de las principales funciones de la comunicación entre sistemas, ya que permite la identificación de los puntos que se conectan a la red, sus interfaces de red así como los
protocolos y las aplicaciones corriendo en ellos.. Utilizando como referencia el modelo OSI (Open Systems Interconnection) de la ISO (International Organization for Standardization), se puede afirmar que el direccionamiento puede existir en diversas capas, por ejemplo, en la capa de enlace de datos, en la capa de red, en la capa de transporte o en la capa de aplicación. Sin embargo, es en la capa de red donde estas funciones asumen un papel de importancia primordial, ya que permiten no sólo la identificación única de cualquier sistema de la red, sino también son esenciales para las funciones de
encaminamiento de la información. De hecho, el direccionamiento y el encaminamiento son las principales funciones de la capa de red. La Figura 2.3 identifica de forma breve las principales funciones de las diversas capas de la arquitectura TCP/IP.
La creación de cualquier red o conjunto de sistemas en red requiere la preparación previa de un esquema de direccionamiento por parte del administrador de redes, con el fin de satisfacer las necesidades de comunicación, tanto internas como externas, asegurando la conectividad total y la seguridad.
En Internet, y en general en todas las redes que utilizan los protocolos TCP/IP, las direcciones de red o direcciones IP son decisivas para la identificación/localización de las máquinas y, por lo tanto, para la determinación de las rutas a utilizar para la transmisión de los paquetes o de los flujos de paquetes.
En realidad, una dirección IP no identifica una máquina, sino una interfaz de la máquina. Por ejemplo, el router R1 de la Figura 2.3 tendrá dos direcciones IP, una para cada una de sus dos interfaces de red. Además, también tiene otras direcciones especiales, como son la dirección de loopback (es decir la dirección utilizada para enviarse un paquete a sí mismo) y las direcciones de grupo multicast necesarias para el funcionamiento de los protocolos de encaminamiento. En
resumen, cada interfaz de red de un host (ya sea un sistema final o un router) conectado a Internet se identifica por lo menos por una dirección de la capa de red.
Ahora bien, ¿cómo se asignan las direcciones IP? En general, las direcciones IP se organizan jerárquicamente. Los bits más significativos identifican a la red a la que pertenece el sistema (se
conocen como prefijo de red) y los menos significativos identifican al sistema dentro de la propia red. También se puede adoptar una jerarquía de tres niveles, conocida como sub-direccionamiento, en la
que la parte destinada a la identificación de los sistemas se divide en dos, una para identificar sub-redes dentro de la red y otra para la identificación de los sistemas. Esta organización se ilustra en la
Figura 2.4. El direccionamiento se tratará en detalle en el Capítulo 3.
Figura 2.4. Organización jerárquica de las direcciones IP
3. Encaminamiento
Además del direccionamiento, el encaminamiento (routing) es una de las funciones de importancia primordial para la comunicación entre sistemas, ya que permite determinar las rutas que se deben utilizar para transmitir los paquetes de datos. Las decisiones sobre la arquitectura y los tipos de encaminamiento a utilizar en una determinada red o en un conjunto de redes – que, por lo general, se
conocen como política de encaminamiento – son fundamentales para garantizar la conectividad, y deben ser objeto de especial atención por parte de los administradores de redes. Esta sección tiene como objetivo ofrecer una visión global de las principales cuestiones y opciones relacionadas con el encaminamiento en redes IP. Los mecanismos y protocolos de encaminamiento se tratarán en detalle
en el quinto libro de esta serie, titulado “Redes de ordenadores – Encaminamiento”.
Las funciones de encaminamiento pueden tener una complejidad considerable, ya que puede que sea necesario considerar el estado de la red (por ejemplo, saber si ciertas áreas de la red están operativas o no, el coste de ciertas rutas, la calidad del servicio de ciertos enlaces) en un momento dado. La adquisición de este tipo de información requerirá un intercambio continuo de mensajes entre los sistemas.
En general, el origen y el destino de los paquetes son sistemas finales (hosts) – aunque también hay paquetes enviados entre routers – y son conmutados y encaminados por los routers. Cuando un router recibe un paquete, determina el sistema al que debe enviar el paquete. El siguiente sistema será el host de destino si este se encuentra en la misma red que el router, o será otro router en el camino hacia el host de destino. El encaminamiento se lleva a cabo salto a salto y paquete a paquete, basado en tablas de encaminamiento almacenadas en los routers y actualizadas por un administrador de redes o bien por los protocolos de encaminamiento.
La Figura 2.5 ilustra la comunicación entre dos hosts usando dos routers conectados a través de una red de tránsito. En este ejemplo, cada sistema sólo conoce a sus sistemas vecinos por encontrarse
todos ellos en distintas redes. No hay, pues, necesidad de que cualquiera de los sistemas tenga información sobre la ruta completa que une los dos sistemas terminales.
Figura 2.5. Ejemplo de encaminamiento entre dos host
3.1 Principios de encaminamiento
Aunque hay casos para los que el encaminamiento es bastante simple, en la mayoría de los casos el encaminamiento toma un grado considerable de complejidad. Esto se debe a que el encaminamiento
abarca la definición de políticas, el uso de protocolos para el intercambio de información de encaminamiento, el cálculo de rutas o caminos en base a la información intercambiada por los protocolos, y, finalmente, la construcción y el mantenimiento de las tablas de encaminamiento que reflejan las rutas calculadas previamente. La Figura 2.6 ilustra la relación entre los elementos organizativos del encaminamiento.
Figura 2.6 – Relación entre los elementos organizativos del encaminamiento
La política de encaminamiento define el tipo de encaminamiento a usar: estático o dinámico, centralizado o distribuido (posteriormente se aborda la definición de estos aspectos). También establece los indicadores de calidad de servicio a utilizar y los parámetros de encaminamiento pertinentes (ya sean técnicos o no).
La política de encaminamiento condicionará los protocolos de encaminamiento que se utilizarán, así como la información de encaminamiento que ellos intercambian. Esa información se empleará para calcular las rutas de las que van a constar las tablas de encaminamiento. Una vez construidas las tablas de encaminamiento, el mecanismo de encaminamiento de los routers es trivial: cuando un
router recibe un paquete, consulta su tabla de encaminamiento para determinar el siguiente salto en el camino hacia el destino deseado.
3.2 Encaminamiento estático
En redes pequeñas, provistas de una única conexión al exterior, sin rutas redundantes ni sometidas a cambios frecuentes de topología, no hay necesidad de intercambiar constantemente información de
encaminamiento ni tampoco de estar siempre recalculando las rutas.
En este tipo de redes, las tablas de encaminamiento se cambian muy pocas veces y se establecen sobre la base de un conocimiento a priori de la red por parte del administrador. Es lo que se conoce como encaminamiento estático. Debido a que apenas varían, es común que las tablas de encaminamiento se introduzcan de forma manual en los routers.
El encaminamiento estático es a menudo un encaminamiento centralizado, es decir, las rutas se calculan centralmente y posteriormente se introducen en las tablas de encaminamiento.
A pesar de las limitaciones del encaminamiento estático - la falta de respuesta a los fallos o cambios de estado de la red, que requieren la configuración manual de los equipos, y la posibilidad de errores e inconsistencias entre las bases de datos de encaminamiento de los diferentes sistemas – se trata únicamente de un tipo de encaminamiento adecuado para redes simples.
3.3 Encaminamiento dinámico
El encaminamiento estático no puede utilizarse en redes grandes, donde las topologías cambian a menudo y/o son complejas, ni tampoco en redes con rutas redundantes de diferentes características y costes, que varían con el tiempo.
En tales casos, es necesario generalmente reaccionar a los cambios de la red y cambiar las tablas de encaminamiento de muchos dispositivos en un corto tiempo, lo que no se puede lograr con una intervención manual en dichas tablas. Por ello se recurre al encaminamiento dinámico.
El encaminamiento dinámico surgió como una forma de lidiar con la creciente complejidad y dinámica de las redes, permitiendo a los equipos que interconectan las redes – los routers, en particular - adaptarse rápidamente y de forma automática a aquellos cambios en la red que repercuten en las rutas. En redes complejas y dinámicas, el cálculo centralizado (realizado por una máquina para toda la red) de los caminos es poco práctico o imposible, por lo que se opta por que cada router contribuya en esta labor. Es lo que se conoce como encaminamiento distribuido.
Los protocolos de encaminamiento constituyen la base del encaminamiento dinámico. Estos protocolos se utilizan para intercambiar información sobre el estado de la red entre los routers. Dicha información se emplea para el cálculo de las rutas y la posterior actualización de las tablas de encaminamiento. La información que se intercambia utilizando los protocolos de encaminamiento
puede ser de distinto tipo: número de saltos a un destino, destinos alcanzables, calidad de servicio asociada a ciertas rutas, y los costes y estado de los enlaces.
La capacidad de adaptación a los cambios en la red, ya sea como consecuencia de cambios en la topología o en el estado (por ejemplo, la congestión de las líneas o la ocurrencia de fallos), es una de las principales ventajas que ofrece el encaminamiento dinámico. Esta adaptación permite una maximización del rendimiento de la red y, por lo tanto, la mejora de la calidad del servicio
proporcionado a las aplicaciones.
Por supuesto, hay un precio que pagar por los beneficios del encaminamiento dinámico. Por un lado, los protocolos de encaminamiento dinámico implican una sobrecarga en la red (overhead) como cualquier otro protocolo de señalización. Por otra parte, hay una mayor complejidad debido a la necesidad de procesar la información de encaminamiento - operación realizada por procesos especiales que se designan como routing daemons - y al cálculo de rutas y consecuente actualización de las tablas de encaminamiento.
Además, ya que el encaminamiento dinámico es, frecuentemente, distribuido, pueden existir problemas de coherencia en las tablas de encaminamiento de los diferentes routers. Hay que tener en cuenta que una tasa de mensajes de actualización elevada conduce a menores tiempos de reacción, pero también a una sobrecarga significativa y a la posibilidad de que ocurran fluctuaciones en las rutas. La distribución del cálculo de las rutas también puede dar lugar a bucles (loops) de encaminamientos, que hay que evitar.
3.4 Arquitectura de encaminamiento de Internet
Con el aumento de la complejidad y del tamaño de las redes, en particular de Internet, hubo que desarrollar, por un lado, soluciones de encaminamiento dinámico y, por otro lado, definir una arquitectura global de encaminamiento a fin de establecer los ámbitos de acción de los protocolos de encaminamiento.
La arquitectura de encaminamiento de Internet se representa en la Figura 2.7 y consta de los siguientes elementos: sistemas autónomos, núcleo de red, routers interiores, protocolos de encaminamiento interior, routers exteriores y protocolos de encaminamiento exterior. La siguiente enumeración describe cada uno de estos elementos arquitectónicos:
• Sistemas autónomos (Autonomous Systems, AS) – conjuntos de redes administradas por el mismo organismo en los que se utilizan los mismos mecanismos y protocolos de encaminamiento y gestión;
• Núcleo de red (Core Network, CN) – red troncal que conecta entre sí los distintos sistemas autónomos;
• Router interior (Interior Gateway, IG) – router utilizado dentro de un sistema autónomo;
• Protocolo de encaminamiento interior (Interior Gateway Protocol, IGP) – protocolo de encaminamiento utilizado dentro de un sistema autónomo;
• Router exterior (Exterior Gateway, EG) – router utilizado para conectar un sistema autónomo al núcleo de red;
• Protocolo de encaminamiento exterior (Exterior Gateway Protocol, EGP) – protocolo de encaminamiento utilizado entre sistemas autónomos, es decir, en el núcleo de red.
Figura 2.7 – Arquitectura de encaminamiento de Internet
Los protocolos de encaminamiento utilizados dentro de un mismo sistema autónomo, es decir, dentro de un conjunto de redes bajo una misma autoridad administrativa, son, en general, diferentes a los protocolos de encaminamiento utilizados entre dominios diferentes.
En el caso del encaminamiento interior, los protocolos transportan información que es esencialmente de naturaleza técnica. Además, se basan en una única métrica para el cálculo de caminos.
En el caso del encaminamiento entre diferentes sistemas autónomos no hay garantía de que los
parámetros utilizados en cada sistema sean los mismos. Por otra parte, las decisiones de encaminamiento exterior suelen basarse en criterios comerciales y/o administrativos, por lo que la
información transportada por los protocolos de encaminamiento exterior es generalmente de naturaleza diferente de la que se transporta en los protocolos de encaminamiento interior.
3.5 Encaminamiento y direccionamiento
Tal y como se mencionó anteriormente, el direccionamiento y el encaminamiento están fuertemente relacionados, ya que el primero es decisivo para el funcionamiento de este último. Con la excepción de los casos - infrecuentes y habitualmente utilizados para el diagnóstico y ensayo - en los que el encaminamiento está determinado por el sistema de origen (conocidos como source routing o encaminamiento de origen), las decisiones de encaminamiento se hacen salto a salto y se basan en la dirección de destino de los paquetes. Esto significa que cada sistema terminal (host) o router determina el próximo sistema al que se debe enviar cada paquete en función de la dirección de destino de dicho paquete.
Por ejemplo, si un host desea enviar un paquete a otro host residente en la misma red – es decir, a otro host con el mismo prefijo IP – entonces no debe enviar este paquete a un router y simplemente debe
encapsular el paquete en una trama cuya dirección MAC de origen es la suya y la dirección MAC de destino es la dirección MAC de la máquina a la que está destinado el paquete. Como se ha visto en el
Capítulo 2 del tercer libro de esta serie (Redes de ordenadores – Tecnologías), para determinar la dirección MAC de una máquina en la misma red con una dirección IP dada se puede utilizar el protocolo ARP o, lo que es equivalente, utilizar la caché de ARP que se construyó por vía de dicho protocolo.
En cambio, si un host desea enviar un paquete a otro host que se encuentra en otra red – es decir, a una máquina con un prefijo IP distinto del suyo – debe enviar el paquete a un router de la red en la
que el host de origen es encuentra. Este router se hará cargo, de manera sucesiva, de enviar el paquete al siguiente router en el camino hacia el host de destino. El envío del paquete desde el host de origen al router de su propia red se realiza encapsulando el paquete IP original en una trama cuya dirección MAC de origen es la suya y la dirección MAC de destino es la dirección MAC del router. Como en el caso anterior, esta dirección MAC se puede determinar utilizando el protocolo o la caché de ARP.
2.4 Fragmentación y re-ensamblado
Al tamaño máximo de las unidades protocolares de datos que una capa dada puede pasar a la capa inferior para su transmisión se llama unidad máxima de transmisión (Maximum Transmission Unit, MTU). En el caso de la capa de red, o capa IP, este valor depende de la tecnología de red utilizada. Por ejemplo, en el caso de Ethernet, este valor es de 1500 bytes.
Como se mencionó en la sección 2.1, los paquetes IP pueden alcanzar una longitud total de 65535 bytes. Puesto que los paquetes IP se pasan a la capa de acceso de red para su transmisión en el medio físico y dado también que pocas tecnologías tienen la capacidad de transmitir paquetes así de grandes, la capa IP debe llevar a cabo la fragmentación de los paquetes IP en paquetes cuyo tamaño no exceda el MTU de la tecnología de red utilizada.
La fragmentación debe llevarse a cabo de modo que los paquetes resultantes sean tan grandes como sea posible (es decir, todos los fragmentos tendrán MTU bytes excepto posiblemente el último
fragmento). De esta manera el protocolo será lo más eficiente posible en este aspecto. No hay que olvidar que el número de bytes de cabecera es fijo.
En el receptor, los fragmentos de los paquetes IP deben ser re-ensamblados, esto es, se reconstituyen o agrupan para obtener el paquete IP original.
El protocolo IP especifica que todas las implementaciones deben ser capaces de fragmentar y re-ensamblar datagramas. En la práctica, cualquier router que conecte dos o más redes con diferentes MTU tiene que fragmentar los datagramas.
4.1 Fragmentación de paquetes
La fragmentación se produce después de que la entidad de red haya decidido sobre la ruta a utilizar para enviar el paquete IP y antes de que se deposite en la cola asociada a la interfaz de salida. La entidad protocolar de la capa de red compara el tamaño del paquete con la MTU de la red a la que va a enviar el paquete, con el fin de determinar si se requiere o no la fragmentación. En el caso más simple, el tamaño del paquete IP es igual o menor que la MTU y de este modo no se ningún tipo de fragmentación. De lo contrario, el paquete será fragmentado.
En el caso del protocolo IPv4, para el control de las operaciones de fragmentación y re-ensamblado se utilizan varios campos de cabecera de los paquetes (Figura 2.1). En particular, se usan el campo
‘identificación’ (16 bits), el campo ‘flags’ (3 bits) y el campo ‘desplazamiento de fragmento’ (13 bits). En el caso del campo ‘flags’, el bit más significativo siempre tiene el valor lógico ‘0’ y no se utiliza, mientras que el bit central se corresponde con el flag ‘no fragmentar’ (don’t fragment, DF), y el bit menos significativo es el flag que indica que hay ‘más fragmentos’ (more fragments, MF).
El flag DF autoriza o no la fragmentación. Si es necesario fragmentar un paquete que tiene esta bandera activa (es decir, con el valor lógico ‘1’), el protocolo IP especifica que el paquete original se desecha y un mensaje de error del protocolo ICMP (ver sección 2.5) se envía al
sistema origen del datagrama.
Por otro lado, la bandera MF se utiliza para indicar si este datagrama es el último fragmento de una secuencia de fragmentos. Todos los fragmentos de un mismo paquete IP tienen este bit a ‘1’, excepto el último fragmento.
Cuando es necesario fragmentar un paquete, la entidad IP crea múltiples paquetes, cada uno (excepto el último) con su bit MF activo, tal y como se mencionó anteriormente, poniendo bloques consecutivos del campo de datos del paquete original en cada paquete fragmento. Cada fragmento resultante es un nuevo paquete IP con su propia cabecera construida a partir de la cabecera del paquete original.
Todos los fragmentos (paquetes IP) del mismo datagrama original tienen el mismo valor en el campo ‘identificación’. En cada fragmento, el campo ‘desplazamiento de fragmento’ indica la posición de los datos de ese fragmento en el campo de datos del datagrama original.
El desplazamiento de fragmento se mide en unidades de 8 bytes, de modo que los fragmentos tienen que tener una longitud que es un múltiplo de este número para poder indicar el desplazamiento en este tipo de unidades. Por supuesto, el desplazamiento del primer fragmento es 0.
4.2 Fragmentación de fragmentos
La fragmentación es un poco más compleja si el datagrama que debe ser fragmentado es en sí mismo un fragmento. Tales casos pueden ocurrir cuando un datagrama pasa entre dos o más routers entre
secciones de red con distintas MTUs. Después de que un router haya fragmentado un datagrama original, puede suceder que los fragmentos así generados sean todavía demasiado grandes para una
sección posterior de la red. En este caso, los fragmentos tienen, a su vez, que fragmentarse en el router de acceso a esa sección.
La distinción entre la fragmentación de datagramas y la fragmentación de fragmentos radica en cómo los routers manejan el bit MF. Cuando un router fragmenta un datagrama con el bit MF activo (es decir, un fragmento), pone el bit MF a ‘1’ en todos los fragmentos, incluyendo el último. Por otra parte, cuando fragmenta un datagrama con el bit MF a ‘0’ pone el bit MF a ‘1’ en todos los fragmentos excepto en el último.
4.3 Re-ensamblado de paquetes
Los sistemas finales de destino acumulan los fragmentos que reciben hasta que puedan reconstruir el datagrama original, esto es, hasta que pueden re-ensamblarlo. Sin embargo, los routers nunca realizan operaciones de re-ensamblado.
Puesto que el protocolo IP no garantiza el orden de llegada de los paquetes, los fragmentos pueden llegar desordenados. Es necesario, pues, que la capa de red esté preparada para aceptar fragmentos
retrasados y/o fuera de orden. Además, los fragmentos de un datagrama dado podrían llegar intercalados con fragmentos de otros datagramas.
Cada vez que un sistema terminal recibe un fragmento, debe verificar si el fragmento completa el datagrama original correspondiente y, si es así, debe re-ensamblarlo y pasarlo a la capa de transporte.
Debido a errores propios de la red, algunos fragmentos se pueden perder, sin llegar nunca a su destino. En este caso, el sistema de destino debe eliminar los fragmentos del datagrama incompleto. Para esta función, el protocolo IP utiliza un temporizador para determinar cuándo los fragmentos de un datagrama incompleto deben eliminarse. La mayoría de las implementaciones actuales utilizan el
valor de 60 segundos para este temporizador. Cada vez que llega un nuevo fragmento el temporizador se restablece. Periódicamente, el temporizador se decrementa (generalmente cada segundo). Cuando
el temporizador llega a cero se eliminan los fragmentos del datagrama incompleto y se envía un mensaje de error del protocolo ICMP (ver sección 2.5) al sistema de origen.
5 ICMP
El Internet Control Message Protocol (ICMP) es un protocolo de control que normalmente se utiliza para enviar información de error o de funcionamiento referente a la capa de red. Se ha definido en el RFC 792 en el caso de IPv4 y en el RFC 4443 para el caso de IPv6.
Es un protocolo que se posiciona en la capa de red, aunque utiliza al protocolo IP. La información que transmite se pasa, por regla general, a las capas superiores o incluso directamente a los procesos de
aplicación para que actúen consecuentemente. Algunos ejemplos de aplicaciones que se basan en este protocolo son el comando ‘ping’ y la aplicación ‘traceroute’, ampliamente utilizados tanto por los
administradores de red como por los usuarios.
La Figura 2.8 muestra el formato genérico de los mensajes del protocolo ICMP y también la encapsulación de estos mensajes en los paquetes IP.
Figura 2.8 – Formato genérico de los mensajes ICMP
La Tabla 2.1 presenta los principales valores para los campos ‘tipo’ (8 bits) y ‘código’ (8 bits) del mensaje ICMP. En esta tabla se optó por guardar las descripciones de los campos de tipo y código en inglés, con el fin de facilitar su reconocimiento en los documentos internacionales y en entornos reales de trabajo. Es importante señalar que hay dos grandes tipos de mensajes ICMP: mensajes de tipo pregunta/respuesta (query/response) y mensajes de error. El primero se utiliza cuando se quiere obtener información de otros sistemas. El segundo, en cambio, se genera por la capa de red y está destinado a informar sobre la aparición de un error.
Tabla 2.1 – Principales tipos y códigos de mensajes ICMP
El campo ‘checksum’ (suma de comprobación) (16 bits) se construye a partir de todo el mensaje ICMP. El contenido del campo de datos depende del tipo y código de mensaje ICMP. A continuación se presentan algunos ejemplos de mensajes ICMP y su respectiva utilización, para el caso del protocolo IPv4.
El mensaje ‘destination unreachable’ (destino inalcanzable) es uno de los principales mensajes del protocolo ICMP. Cuando un router recibe un paquete IP que no puede encaminar ni entregar a su destino, envía un mensaje de este tipo al sistema que envió el paquete IP en cuestión. El campo de código proporciona información adicional asociada al error, que puede tener que ver, por ejemplo, con la imposibilidad de fragmentar el paquete cuya transmisión requeriría esta fragmentación, o la falta de una ruta hacia la red o hacia el sistema de destino. El campo de datos de este tipo de mensaje se compone de 28 bytes, de los cuales los primeros 20 bytes son la cabecera del paquete IP que causó el error y los siguientes 8 bytes son los primeros bytes de la cabecera del protocolo de transporte. En el caso de que este protocolo sea el protocolo UDP, estos 8 bytes corresponden a la totalidad de la cabecera del segmento UDP. La Figura 2.9 ilustra la estructura del mensaje ‘destination unreachable’
del protocolo ICMP.
2.9 – Mensaje ‘destination unreachable’ (destino inalcanzable)
El mensaje ‘redirect’ (reorientar) lo envía un router al remitente de un paquete IP cuando el router determina que el paquete debería haber sido enviado a otro router. La Figura 2.10 ilustra esta situación, en la que el router R1, al detectar que el paquete que recibió debería haber sido enviado al router R2, notifica este hecho al sistema origen a través de un mensaje redirect, pero sin dejar de enviar el paquete IP al router R2. Gracias a este mensaje, los paquetes posteriores se enviarán directamente desde el host al router R2.
Figura 2.10 – Ejemplo de utilización del mensaje ‘redirect’
Con el fin de corregir la ruta, es decir, cambiar la entrada correspondiente de la tabla de encaminamiento, el destinatario de un redirect tiene que tener en cuenta la dirección IP que ha provocado el mensaje de reorientación (es decir, la dirección IP de destino del paquete original), la dirección IP del router que envió el redirect y, por supuesto, la dirección IP del router que se debería haber utilizado. Estos datos pueden extraerse del mensaje redirect, tal y como se puede ver en la Figura 2.11.
Figura 2.11 – Formato del mensaje ‘redirect’
Dado que este mensaje cambia las rutas de los paquetes, se puede utilizar para llevar a cabo algunos ataques si no se toman determinadas precauciones en el momento de generarlos y de procesarlos. En la mayoría de las implementaciones, un router sólo envía un redirect cuando se satisfacen todas las condiciones siguientes a la vez: la interfaz de salida del paquete IP que va a ser enviado es la misma
que la interfaz de llegada; la ruta a utilizar por el paquete no fue creada o modificada por un redirect y no es la ruta por defecto; el paquete no especifica que la ruta está definida por la origen (enrutamiento de origen, source routing); y el router está configurado para enviar redirects.
Por otro lado, en la mayoría de las implementaciones, un sistema terminal que recibe una reorientación realiza las siguientes comprobaciones antes de modificar su tabla de encaminamiento: la nueva ruta tiene que vincularse con una red conectada directamente; el redirect debe haberse recibido desde el router correspondiente a la ruta actual; el redirect no puede especificar que el sistema terminal se utilice a él mismo como router; y la ruta que va a ser modificada tiene que ser una ruta indirecta (es decir, el sistema destino tiene que estar en una red distinta a la suya).
Otro uso muy frecuente del protocolo ICMP es el del hallazgo de encaminadores en una red, de modo que, por ejemplo, los hosts puedan establecer rutas por defecto. Para ello, se hace uso de mensajes ‘router solicitation’ (solicitación de encaminador) y ‘router advertisement’ (anuncio de encaminador). Los primeros los envían los sistemas terminales – normalmente después de su puesta en marcha
– usando difusión (broadcast) o multidifusión (multicast). A su vez, los routers responden a estos mensajes con mensajes ‘router advertisement’ que, además, envían periódicamente como una manera de anunciar su presencia en la red.
El formato de los mensajes ‘router solicitation’ y ‘router advertisement’ se muestra en las Figuras 2.12 y 2.13, respectivamente.
Figura 2.12 – Formato del mensaje ‘router solicitation’
Como se puede ver en la Figura 2.13, cada encaminador puede anunciar más de una dirección IP, que son las direcciones IP del router que envía el mensaje. En una red con varios encaminadores, es el administrador de la red el que establece el nivel de preferencia (en términos de ruta por defecto) de cada router. Cada dirección IP anunciada tiene un tiempo de validez (o tiempo de vida). Por lo
general, ese tiempo es tres veces el intervalo de tiempo entre los mensajes ‘router advertisement’.
Figura 2.13 – Formato del mensaje ‘router advertisement’
6 Movilidad
El desarrollo de tecnologías inalámbricas, equipos pequeños y fáciles de transportar y de sensores y actuadores integrables en redes de área personal permitió la conexión a Internet en cualquier momento y desde cualquier lugar. También ha dado lugar al desarrollo de toda una nueva gama de aplicaciones muy atractivas en el ámbito de la salud, de los transportes urbanos, de los equipos de emergencia, de la educación y del turismo, entre otras. La movilidad de los sistemas en la capa de red, también designada movilidad IP, está subyacente a todos estos escenarios.
La movilidad IP - ya sea de sistemas individuales o de redes completas - tiene como objetivo permitir a los usuarios moverse entre redes IP de forma transparente, manteniendo sus conexiones activas.
Dado que el protocolo IP no fue diseñado para entornos móviles – de hecho, el protocolo IP fue diseñado para un Internet muy diferente de la de hoy en día, sin movilidad, sin tráfico multimedia, sin ataques de seguridad, sin comunicación entre pares y sin comunicación multipunto – fue necesario desarrollar una solución que tuviera en cuenta los requisitos de movilidad, que se resumen en un solo
requisito general: permitir que los sistemas móviles, es decir, sistemas que cambian de una red a otra red, puedan continuar comunicándose y que otros sistemas contacten con ellos como si
fueran fijos.
El mayor obstáculo de la movilidad IP viene del hecho de que las direcciones IP se utilizan para dos funciones distintas:
• Por una parte, las direcciones IP se utilizan como identificadores de los hosts (más específicamente, de sus interfaces) y, por lo tanto, forman parte del identificador de las conexiones. Se observa, por ejemplo, que el identificador de una conexión TCP se compone de las direcciones IP de origen y destino, así como de los puertos de origen y de destino;
• Por otra parte, las direcciones IP se utilizan para indicar la ubicación de los sistemas en Internet y, por lo tanto, se utilizan para el encaminamiento de los paquetes hacia su destino.
Así pues, si al cambiar de red un host mantiene su dirección IP original - es decir, su identificador - con el propósito de que las conexiones ya activas no se interrumpan, el encaminamiento dejará
de funcionar porque la dirección IP ya no es topológicamente correcta (su dirección IP pertenece a una red que no es la red en la que se encuentra). Si al cambiar de red el host adquiere una nueva dirección IP – es decir, un localizador topológicamente correcto – las conexiones se rompen porque el identificador (la dirección IP) ha cambiado.
El modelo de movilidad IP (Mobile IP) fue desarrollado por el IETF (Internet Engineering Task Force) para permitir que los nodos móviles (mobile node, MN) que se encuentran fuera de su red (home network, HN) puedan seguir comunicándose utilizando su dirección IP original (home address, HoA) y, por lo tanto, puedan mantener las conexiones TCP existentes. Para la versión 4 del protocolo IP, el IP móvil se define en el RFC 3344.
La solución se basa esencialmente en el uso de dos tipos de agentes de movilidad: el agente local (home agent, HA) y el agente extranjero (foreign agent, FA). Cuando el MN se encuentra en una red extranjera (foreign network, FN) se registra en el FA, que le da una segunda dirección IP (care-of address, CoA). El CoA es típicamente una dirección del FA que, en la fase de registro del MN, también se dará a conocer al HA. Los agentes HA y FA son routers que se encargan del mapeo (mobility binding) entre los HoA y los CoA, así como del reenvío de mensajes hacia y desde los nodos móviles.
Cada HA mantiene una tabla de mapeo de movilidad (mobility binding table, MBT), en la que cada entrada está asociada a un host que está en movilidad (es decir, que está fuera de su red) y tiene esencialmente tres campos: un campo que identifica el HoA, su CoA actual y el tiempo de vida de dicha asociación. Así, la tabla MBT permite al HA determinar la dirección a la que debe reenviar (a través de un túnel IP) los paquetes que están destinados a un nodo móvil que está fuera de su red. Más adelante describiremos qué es un túnel IP.
Por otro lado, cada FA mantiene una lista de los nodos móviles visitantes (visitor list, VL) que contiene información sobre los nodos móviles que se encuentran en su red y que llegaron cuando estaban conectados a otra. Cada entrada en esta lista tiene esencialmente cuatro campos: un campo que identifica el HoA del nodo móvil (MN), un campo que identifica el HA del MN, la dirección MAC del MN y la vida útil de dicha asociación. Así, la tabla VL permite que los paquetes recibidos desde el HA (a través de túnel IP entre el HA y el FA) se entreguen al MN, cuya dirección MAC se encuentra en la tabla.
Se entregan, por lo tanto, al MN al que se destinan. Hay cinco fases distintas en el protocolo IP móvil, que son:
1. Descubrimiento de agentes (agent discovery), que consta de las siguientes etapas:
i) Los agentes de movilidad anuncian su presencia periódicamente a través de mensajes de difusión denominados ‘agent advertisement’ (anuncio de agente). Estos mensajes contienen una o más
direcciones CoA disponibles para posibles nodos móviles que las necesiten y un flag que indica si el agente es un HA o un FA;
ii) Cuando un nodo móvil recibe un anuncio de agente comprueba si este mensaje fue generado por su HA (en cuyo caso se encuentra en su red original) o por otro agente (estaría entonces en una red
extranjera);
iii) Los nodos móviles pueden enviar mensajes del tipo ‘agent solicitation’ (solicitud de agente) en cualquier momento, a los que los agentes de movilidad responderán; por lo tanto, los nodos no
necesitan esperar a recibir los anuncios de agentes.
2. Registro (registration), que engloba las siguientes etapas, ilustradas en la Figura 2.14:
i) Los nodos móviles que se encuentran en su red original funcionan normalmente, sin utilizar los servicios de movilidad;
ii) Cuando un nodo móvil determina que está en una nueva red (red extranjera), se registra en el FA enviándole un mensaje ‘registration request’ (solicitud de registro) que incluye la dirección IP original del nodo móvil (HoA) y la dirección IP de su HA;
iii) El FA hace el registro del MN en el HA, enviando al HA un mensaje ‘registration request’ que incluye la dirección IP original del nodo móvil (HoA) y la dirección IP del FA (es decir, su propia
dirección IP, que será utilizada como CoA);
iv) Cuando el HA recibe la solicitud de registro, actualiza su MBT y envía una confirmación al FA;
v) Una vez recibida la confirmación del HA, el FA actualiza su VL y reenvía la confirmación al MN;
vi) Los registros de los agentes FA y HA tienen un tiempo de validez; cuando ese tiempo se agota, los agentes de movilidad dejan de reenviar paquetes hacia y desde el nodo móvil; los nodos móviles
deben actualizar sus registros periódicamente para evitar que caduquen.
Figura 2.14 – Proceso de registro, en el modelo Mobile IP
3. En servicio (in service), que consta de las siguientes etapas, ilustradas en la Figura 2.15:
i) Cuando un nodo correspondiente (corresponding node, CN) quiere comunicarse con un nodo móvil, envía un paquete IP a la dirección IP original de ese nodo (es decir, a su HoA); de hecho, el CN no sabe si el nodo correspondiente es un nodo móvil o no, pues utiliza simplemente la dirección IP del nodo con el que quiere comunicarse;
ii) El HA intercepta este paquete (Ojo: el HA es, normalmente, un router de acceso a la red) y consulta su MBT para determinar si el nodo móvil está en una red extranjera;
iii) Si el nodo móvil está en una red extranjera, el HA determina el CoA y encapsula el paquete IP original en un nuevo paquete IP (a esto se llama un túnel IP, o tunnelling). La dirección de destino del nuevo paquete IP es ahora el CoA. La encapsulación puede hacerse utilizando uno de los siguientes tres métodos: Generic Routing Encapsulation (RFC 1701), IP within IP (RFC 2003), o Minimal
Encapsulation (RFC 2004); La Figura 2.16 ilustra la encapsulación IP within IP (IP dentro de IP), también conocida como encapsulación básica;
iv) Cuando el paquete encapsulado llega a la red extranjera, el FA lo desencapsula y determina la dirección de destino original; a continuación, consulta su VL para determinar la dirección MAC a la
que se debe enviar el paquete;
v) El FA envía el paquete original al MN;
vi) Cuando el nodo móvil desea comunicarse con el nodo correspondiente envía los paquetes al FA que, a su vez, los envía al nodo correspondiente usando el encaminamiento IP estándar; opcionalmente, puede encapsularlos y enviarlos al HA, que los desencapsulará y los enviará al CN.
Figura 2.15 – Comunicación entre un CN e un MN, de acuerdo con el modelo Mobile IP
Figura 2.16 – Encapsulación básica (IP within IP, RFC 2003) en el modelo Mobile IP
4. Optimización de rutas – opcionalmente, después de recibir el primer paquete desde un CN a través del túnel HA-FA, el MN puede iniciar un proceso de optimización de ruta, enviando un paquete de
actualización de mapeo (binding update, BU) al CN. Dicho paquete contiene el CoA del MN. A su vez, el CN responderá enviando un paquete de confirmación de mapeo (binding acknowledgement, BA). A partir de ahí se producirá la comunicación con el CN sin que el tráfico tenga que pasar por el HA.
5. Cancelación del registro (deregistration) – cuando un nodo móvil vuelve a su red debe cancelar su inscripción en el HA mediante el envío de un paquete de solicitud de registro con un tiempo de validez de cero segundos; tras ese momento, la ruta se vuelve al estado normal; no hay necesidad de que el nodo móvil cancele el registro con el FA, ya que dicho registro expirará naturalmente. Sin embargo, si el nodo móvil se mueve a una nueva red extranjera y los registros en una red extranjera anterior no han caducado, puede que algunos paquetes se pierdan.
En el caso de IPv6, el modelo de movilidad – llamado Mobile IPv6 o, de manera abreviada, MIPv6 – es bastante similar. Sin embargo, se aprovecha de las nuevas funcionalidades de IPv6, en particular de la configuración automática, de la detección de sistemas en la red (descubrimiento de vecinos, neighbour discovery) y de cabeceras de extensión. Utilizando dichas funciones, los nodos móviles pueden asumir ellos mismos el papel de FA, por lo que el modelo MIPv6 no los contempla como entidades autónomas. Por otra parte, el túnel FA-HA es siempre bidireccional.
7 Seguridad
No hay comentarios:
Publicar un comentario