domingo, 23 de noviembre de 2008

4.4.5 DNS

El DNS ( Domain Name System ) o Sistema de Nombres de Dominio es una base de datos jerárquica y distribuida que almacena informacion sobre los nombres de dominio de de redes cómo Internet. También llamamos DNS al protocolo de comunicación entre un cliente ( resolver ) y el servidor DNS.

La función más común de DNS es la traducción de nombres por direcciones IP, esto nos facilita recordar la dirección de una máquina haciendo una consulta DNS ( mejor recordar www.programacionweb.net que 62.149.130.140 ) y nos proporciona un modo de acceso más fiable ya que por multiples motivos la dirección IP puede variar manteniendo el mismo nombre de dominio.

La estructura jerárquica


Un nombre de dominio consiste en diferentes partes llamadas etiquetas y separadas por puntos. La parte situada más a la derecha es el llamado dominio de primer nivel ( Top Level Domain ) y cada una de las partes es un subdominio de la parte que tiene a su derecha.

De esta manera, si tenemos www.programacionweb.net:

net - Es el dominio de primer nivel
programacionweb - Es un subdominio de net
www - Es un subdominio de programacionweb

Cada dominio o subdominio tiene una o más zonas de autoridad que publican la información acerca del dominio y los nombres de servicios de cualquier dominio incluido.Al inicio de esa jerarquía se encuentra los servidores raíz, que responden cuando se busca resolver un dominio de primer nivel y delegan la autoridad a los servidores DNS autorizados para dominios de segundo nivel.


Tipos de consulta
Una consultas de un cliente (resolver) a un servidor DNS puede ser recursiva si el servidor al que consultamos consulta a su vez otro servidor o iterativa si responde a partir de los datos que tiene almacenados localmente.

Tipos de regístro
Hay diferentes tipos de regístro DNS que se pueden consultar:

A (Dirección) - Este registro se usa para traducir nombres de hosts a direcciones IP.
CNAME (Nombre Canónico) - Se usa para crear nombres de hosts adicionales, o alias, para los hosts de un dominio.
NS (Servidor de Nombres) - Define la asociación que existe entre un nombre de dominio y los servidores de nombres que almacenan la información de dicho dominio. Cada dominio se puede asociar a una cantidad cualquiera de servidores de nombres.
MX (Intercambiador de Correo) - Define el lugar donde se aloja el correo que recibe el dominio.
PTR (Indicador) - También conocido como 'registro inverso', funciona a la inversa del registro A, traduciendo IPs en nombres de dominio.

4.4.4 NFS

Puesto que uno de los objetivos de NFS es soportar un sistema heterogéneo, con clientes y servidores que tal vez ejecuten diferentes sistemas operativos con un hardware distinto, es esencial que la interfaz entre los clientes y los servidores esté bien definida. Sólo entonces es posible que cualquiera pueda escribir una nueva implantación cliente y espere que funcione de manera correcta con los servidores existentes y viceversa.

NFS logra este objetivo al definir dos protocolos cliente-servidor. Un protocolo es un conjunto de solicitudes enviadas por los clientes a los servidores, junto con las respuestas enviadas de regreso de los servidores a los clientes. Mientras un servidor reconozca y pueda controlar todas las solicitudes en los protocolos, no necesita saber nada de sus clientes. De manera análoga, los clientes pueden tratar a los servidores como "cajas negras" que aceptan y procesan un conjunto especifico de solicitudes. La forma en que lo hacen es asunto de ellos.

El primer protocolo NFS controla el anclaje. Un cliente puede enviar un nombre de ruta de acceso a un servidor y solicitar que monte ese directorio en alguna parte de su jerarquía de directorios. El lugar donde se montará no está contenido en el mensaje, ya que el servidor no se preocupa por dicho lugar. Si la ruta es válida y el directorio especificado ha sido exportado, el servidor regresa un identificador de archivo al cliente. El asa de archivo contiene campos que identifican de manera única al tipo de sistema de archivo, el disco, el número de inodo del directorio, e información de seguridad. Las llamadas posteriores para la lectura y escritura de archivos en el directorio montado utilizan el identificador del archivo.

Muchos clientes están configurados de modo que monten ciertos directorios remotos sin intervención manual. Por lo general, estos clientes contienen un archivo llamado /etc/rc, que es un shellscript que contiene las instrucciones para el montaje remoto. Este shellscript se ejecuta de manera automática cuando el cliente se arranca.

Otra alternativa a la versión de UNIX de Sun soporta también el automontaje. Esta característica permite asociar un conjunto de directorios con un directorio local. Ninguno de los directorios remotos se monta (ni se realiza el contacto con sus servidores) cuando arranca el cliente. En vez de esto, la primera vez que se abre un archivo remoto, el sistema operativo envía un mensaje a cada uno de los servidores. El primero en responder gana, y se monta su directorio.

El automontaje tiene dos ventajas principales sobre el montaje estático por medio del archivo /etc/rc. La primera es que si uno de los servidores NFS llamados en /etc/rc no está sirviendo peticiones, es imposible despertar al cliente, al menos no sin cierta dificultad, retraso y unos cuantos mensajes de error. Si el usuario ni siquiera necesita ese servidor por el momento, todo ese trabajo se desperdicia. En segundo lugar, al permitir que el cliente intente comunicarse con un conjunto de servidores en paralelo, se puede lograr cierto grado de tolerancia a fallos (puesto que sólo se necesita que uno de ellos esté activo) y se puede mejorar el desempeño (al elegir el primero que responda, que supuestamente tiene la menor carga).

Por otro lado, se supone de manera implícita que todos los sistemas de archivos especificados como alternativas para el automontaje son idénticos. Puesto que NFS no da soporte para la réplica de archivos o directorios, el usuario debe lograr que todos los sistemas de archivos sean iguales. En consecuencia, el automontaje se utiliza con más frecuencia para los sistemas de archivos exclusivos para lectura que contienen binarios del sistema y para otros archivos que rara vez cambian.

El segundo protocolo NFS es para el acceso a directorios y archivos. Los clientes pueden enviar mensajes a los servidores para que manejen los directorios y lean o escriban en archivos. Además, también pueden tener acceso a los atributos de un archivo, como el modo, tamaño y tiempo de su última modificación. La mayor parte de las llamadas al sistema UNIX son soportadas por NFS, con la probable sorpresa de OPEN y CLOSE.

La omisión de OPEN y CLOSE no es un accidente. Es por completo intencional. No es necesario abrir un archivo antes de leerlo, o cerrarlo al terminar. En vez de esto, para leer un archivo, un cliente envía al servidor un mensaje con el nombre del archivo, una solicitud para buscarlo y regresar un identificador de archivo, que es una estructura de identificación del archivo. A diferencia de una llamada OPEN,esta operación LOOKLJP no copia información a las tablas internas del sistema. La llamada READ contiene al identificador de archivo que se desea leer, el ajuste para determinar el punto de inicio de la lectura y el número de bytes deseados. Cada uno de estos mensajes está autocontenido. La ventaja de este esquema es que el servidor no tiene que recordar lo relativo a las conexiones abiertas entre las llamadas a él. Así, si un servidor falla y después se recupera, no se pierde información acerca de los archivos abiertos, puesto que no hay ninguno. Un servidor como éste, que no conserva información del estado de los archivos abiertos se denomina sin estado.

Por el contrario, en el sistema V de UNIX, el sistema de archivos remotos (RFS) requiere abrir un archivo antes de leerlo o escribir en él. El servidor crea entonces una entrada de tabla con un registro del hecho de que el archivo está abierto y la posición actual del lector, de modo que cada solicitud no necesita un ajuste. La desventaja de este esquema es que si un servidor falla y vuelve a arrancar rápidamente, se pierden todas las conexiones abiertas, y fallan los programas cliente. NFS no tiene esta característica.

Por desgracia, el método NFS dificulta el hecho de lograr la semántica de archivo propia de UNIX. Por ejemplo, en UNIX un archivo se puede abrir y bloquear para que otros procesos no tengan acceso a él. Al cerrar el archivo, se liberan los bloqueos. En un servidor sin estado como NFS, las cerraduras no se pueden asociar con los archivos abiertos, puesto que el servidor no sabe cuáles son los archivos están abiertos. Por lo tanto, NFS necesita un mecanismo independiente adicional para controlar los bloqueos.

NFS utiliza el mecanismo de protección de UNIX, con los bits rwx para el propietario, grupo y demás personas. En un principio, cada mensaje de solicitud sólo contenía los identificadores del usuario y del grupo de quien realizó la llamada, lo que utilizaba el servidor NFS para validar el acceso. De hecho, confiaba en que los clientes no mintieran. Varios años de experiencia han demostrado ampliamente que tal hipótesis era un tanto ingenua. Actualmente, se puede utilizar la criptografía de claves públicas para establecer una clave segura y validar al cliente y al servidor en cada solicitud y respuesta. Cuando esta opción se activa, un cliente malicioso no puede personificar a otro cliente, pues no conoce la clave secreta del mismo. Por cierto, la criptografía sólo se utiliza para autenticar a las partes. Los datos nunca se encriptan.

Todas las claves utilizadas para la autenticación, así como la demás información, son mantenidas por el NIS (servicio de información de la red). NIS se conocía antes como el directorio de páginas amarillas (yellow pages). Su función es la de guardar parejas (clave, valor). Cuando se proporciona una clave, regresa el valor correspondiente. No sólo controla las claves de cifrado, sino también la asociación de los nombres de usuario con las contraseñas (cifradas), así como la asociación de los nombres de las máquinas con las direcciones de la red, y otros elementos.

Los servidores de información de la red se duplican mediante un orden maestro/esclavo. Para leer sus datos, un proceso puede utilizar al maestro o cualquiera de sus copias (esclavos). Sin embargo, todas las modificaciones deben ser realizadas únicamente en el maestro, que entonces las propaga a los esclavos. Existe un breve intervalo después de una actualización en el que la base de datos es inconsistente.

4.4.3 http

El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un sencillo protocolo cliente-servidor que articula los intercambios de información entre los clientes Web y los servidores HTTP. La especificación completa del protocolo HTTP 1/0 está recogida en el RFC 1945. Fue propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribución de información como el World Wide Web.

Desde el punto de vista de las comunicaciones, está soportado sobre los servicios de conexión TCP/IP, y funciona de la misma forma que el resto de los servicios comunes de los entornos UNIX: un proceso servidor escucha en un puerto de comunicaciones TCP (por defecto, el 80), y espera las solicitudes de conexión de los clientes Web. Una vez que se establece la conexión, el protocolo TCP se encarga de mantener la comunicación y garantizar un intercambio de datos libre de errores.

HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una conexión con un servidor y envía un mensaje con los datos de la solicitud. El servidor responde con un mensaje similar, que contiene el estado de la operación y su posible resultado. Todas las operaciones pueden adjuntar un objeto o recurso sobre el que actúan; cada objeto Web (documento HTML, fichero multimedia o aplicación CGI) es conocido por su URL.

Etapas de una transacción HTTP.

Para profundizar más en el funcionamiento de HTTP, veremos primero un caso particular de una transacción HTTP; en los siguientes apartados se analizarán las diferentes partes de este proceso.

Cada vez que un cliente realiza una petición a un servidor, se ejecutan los siguientes pasos:

  • Un usuario accede a una URL, seleccionando un enlace de un documento HTML o introduciéndola directamente en el campo Location del cliente Web.
  • El cliente Web descodifica la URL, separando sus diferentes partes. Así identifica el protocolo de acceso, la dirección DNS o IP del servidor, el posible puerto opcional (el valor por defecto es 80) y el objeto requerido del servidor.
  • Se abre una conexión TCP/IP con el servidor, llamando al puerto TCP correspondiente.
    Se realiza la petición. Para ello, se envía el comando necesario (GET, POST, HEAD,…), la dirección del objeto requerido (el contenido de la URL que sigue a la dirección del servidor), la versión del protocolo HTTP empleada (casi siempre HTTP/1.0) y un conjunto variable de información, que incluye datos sobre las capacidades del browser, datos opcionales para el servidor,…
  • El servidor devuelve la respuesta al cliente. Consiste en un código de estado y el tipo de dato MIME de la información de retorno, seguido de la propia información.
  • Se cierra la conexión TCP.
  • Este proceso se repite en cada acceso al servidor HTTP. Por ejemplo, si se recoge un documento HTML en cuyo interior están insertadas cuatro imágenes, el proceso anterior se repite cinco veces, una para el documento HTML y cuatro para las imágenes.

4.4.2 FTP

FTP (File Transfer Protocol) es un protocolo de transferencia de archivos entre sistemas conectados a una red TCP basado en la arquitectura cliente-servidor, de manera que desde un equipo cliente nos podemos conectar a un servidor para descargar archivos desde él o para enviarle nuestros propios archivos independientemente del sistema operativo utilizado en cada equipo.

El Servicio FTP es ofrecido por la capa de Aplicación del modelo de capas de red TCP/IP al usuario, utilizando normalmente el puerto de red 20 y el 21. Un problema básico de FTP es que está pensado para ofrecer la máxima velocidad en la conexión, pero no la máxima seguridad, ya que todo el intercambio de información, desde el login y password del usuario en el servidor hasta la transferencia de cualquier archivo, se realiza en texto plano sin ningún tipo de cifrado, con lo que un posible atacante puede capturar este tráfico, acceder al servidor, o apropiarse de los archivos transferidos.

Para solucionar este problema son de gran utilidad aplicaciones como scp y sftp, incluidas en el paquete SSH, que permiten transferir archivos pero cifrando todo el tráfico.

4.4 Protocolos a nivel aplicación.4.4.1 SMTP

Abreviatura de Simple Mail Transfer Protocol, un protocolo utilizado para enviar mensajes de correo electrónico entre servidores. La mayoría de los servidores de correo que envían mensajes a través de Internet utilizan SMTP para tal efecto; los mensajes pueden luego ser descargados desde un cliente de correo usando protocolos como IMAP o POP3. SMTP es generalmente utilizado además, para enviar mensajes desde un cliente al servidor de correo. Debido a esto es la necesidad de especificar un servidor IMAP o POP3 y un servidor SMTP para configurar una aplicación cliente de correo.

4.3 Protocolos de transporte (UDP,TCP).

El grupo de protocolos de Internet también maneja un protocolo de transporte sin conexiones, el UDP (User Data Protocol, protocolo de datos de usuario). El UDP ofrece a las aplicaciones un mecanismo para enviar datagramas IP en bruto encapsulados sin tener que establecer una conexión. Muchas aplicaciones cliente-servidor que tienen una solicitud y una respuesta usan el UDP en lugar de tomarse la molestia de establecer y luego liberar una conexión. El UDP se describe en el RFC 768. Un segmento UDP consiste en una cabecera de 8 bytes seguida de los datos. La cabecera se muestra a continuación. Los dos puertos sirven para lo mismo que en el TCP: para identificar los puntos terminales de las máquinas origen y destino. El campo de longitud UDP incluye la cabecera de 8 bytes y los datos. La suma de comprobación UDP incluye la misma pseudocabecera de formato, la cabecera UDP, y los datos, rellenados con una cantidad par de bytes de ser necesario. UDP no admite numeración de los datagramas, factor que, sumado a que tampoco utiliza señales de confirmación de entrega, hace que la garantía de que un paquete llegue a su destino sea mucho menor que si se usa TCP. Esto también origina que los datagramas pueden llegar duplicados y/o desordenados a su destino. Por estos motivos el control de envío de datagramas, si existe, debe ser implementado por las aplicaciones que usan UDP como medio de transporte de datos, al igual que el reeensamble de los mensajes entrantes. Es por ello un protocolo del tipo best-effort (máximo esfuerzo), porque hace lo que puede para transmitir los datagramas hacia la aplicación, pero no puede garantizar que la aplicación los reciba.

Udp

El grupo de protocolos de Internet también maneja un protocolo de transporte sin conexiones, el UDP (User Data Protocol, protocolo de datos de usuario). El UDP ofrece a las aplicaciones un mecanismo para enviar datagramas IP en bruto encapsulados sin tener que establecer una conexión. Muchas aplicaciones cliente-servidor que tienen una solicitud y una respuesta usan el UDP en lugar de tomarse la molestia de establecer y luego liberar una conexión. El UDP se describe en el RFC 768. Un segmento UDP consiste en una cabecera de 8 bytes seguida de los datos. La cabecera se muestra a continuación. Los dos puertos sirven para lo mismo que en el TCP: para identificar los puntos terminales de las máquinas origen y destino. El campo de longitud UDP incluye la cabecera de 8 bytes y los datos. La suma de comprobación UDP incluye la misma pseudocabecera de formato, la cabecera UDP, y los datos, rellenados con una cantidad par de bytes de ser necesario. UDP no admite numeración de los datagramas, factor que, sumado a que tampoco utiliza señales de confirmación de entrega, hace que la garantía de que un paquete llegue a su destino sea mucho menor que si se usa TCP. Esto también origina que los datagramas pueden llegar duplicados y/o desordenados a su destino. Por estos motivos el control de envío de datagramas, si existe, debe ser implementado por las aplicaciones que usan UDP como medio de transporte de datos, al igual que el reeensamble de los mensajes entrantes. Es por ello un protocolo del tipo best-effort (máximo esfuerzo), porque hace lo que puede para transmitir los datagramas hacia la aplicación, pero no puede garantizar que la aplicación los reciba.

Tcp

Protocolo TCP/IP Una red es una configuración de computadora que intercambia información. Pueden proceder de una variedad de fabricantes y es probable que tenga diferencias tanto en hardware como en software, para posibilitar la comunicación entre estas es necesario un conjunto de reglas formales para su interacción. A estas reglas se les denominan protocolos.

Un protocolo es un conjunto de reglas establecidas entre dos dispositivos para permitir la comunicación entre ambos.

DEFINICION TCP / IP

Se han desarrollado diferentes familias de protocolos para comunicación por red de datos para los sistemas UNIX. El más ampliamente utilizado es el Internet Protocol Suite, comúnmente conocido como TCP / IP.

Es un protocolo DARPA que proporciona transmisión fiable de paquetes de datos sobre redes. El nombre TCP / IP Proviene de dos protocolos importantes de la familia, el Transmission Contorl Protocol (TCP) y el Internet Protocol (IP). Todos juntos llegan a ser más de 100 protocolos diferentes definidos en este conjunto.

El TCP / IP es la base del Internet que sirve para enlazar computadoras que utilizan diferentes sistemas operativos, incluyendo PC, minicomputadoras y computadoras centrales sobre redes de área local y área extensa. TCP / IP fue desarrollado y demostrado por primera vez en 1972 por el departamento de defensa de los Estados Unidos, ejecutándolo en el ARPANET una red de área extensa del departamento de

4.2 Protocolo de Internet, IP móvil.

El Protocolo IP Móvil define procedimientos por los cuales los paquetes pueden ser enrutados a un nodo móvil, independientemente de su ubicación actual y sin cambiar su dirección IP. Los paquetes destinados a un nodo móvil primeramente son dirigidos a su red local. Allí, un agente local los intercepta y mediante un túnel los reenvía a la dirección temporal recientemente informada por el nodo móvil. En el punto final del túnel un agente foráneo recibe los paquetes y los entrega al nodo móvil.

En los últimos años se han producido importantes avances en el campo de las tecnologías de las comunicaciones. Dos de ellos han sido, indudablemente, el rápido desarrollo de la informática portátil y la importante implantación de los sistemas de comunicaciones móviles. La conjunción de ambos factores permite a los usuarios acceder a una red en cualquier momento y en cualquier lugar, aún cuando se encuentren en movimiento.

Sin embargo, ciertas arquitecturas de protocolos, entre ellos TCP/IP presentan serias complicaciones al momento de tratar con terminales que requieren de cierto grado de movilidad entre redes. La mayoría de las versiones del protocolo IP (Internet Protocol) asumen de manera implícita que el punto al cual el nodo se conecta a la red es fijo. Por otra parte, la dirección IP del nodo o terminal, lo identifica de manera unívoca en la red a la que se encuentra conectado. Cualquier paquete destinado a ese nodo es encaminado en función de la información contenida en el prefijo de red de su dirección IP. Esto implica que un nodo móvil que se desplaza de una red a otra y que mantiene su dirección IP no será localizable en su nueva ubicación ya que los paquetes dirigidos hacia este nodo serán encaminados a su antiguo punto de conexión a la red.

“El protocolo IP Móvil (Mobile Internet Protocol) fue diseñado para soportar movilidad, en cualquier tipo de medio y en una extensa área geográfica. Su objetivo es dotar a los terminales con la capacidad de mantenerse conectados a Internet independientemente de su localización, permitiendo rastrear a un nodo móvil sin necesidad de cambiar su dirección IP”.

La distribución del presente documento es como se detalla: en primer lugar se exponen las características del protocolo IP Móvil y la definición de los términos que se utilizan a lo largo del documento, clasificados en entidades y servicios. A continuación se explica el funcionamiento del protocolo, contemplando los procesos de descubrimiento y registración de direcciones y de encaminamiento de paquetes hacia las direcciones. Posteriormente se mencionan problemas y posibles soluciones a cuestiones del protocolo, como así las diferencias entre las versiones 4 y 6.

Características de IP Móvil

  • No posee limitaciones geográficas: un usuario podría usar su computadora portátil (laptop, notebook, palmtop, etc.) en cualquier lugar sin perder conexión a su red.
  • No requiere conexión física: IP Móvil encuentra enrutadores (routers) y se conecta automáticamente, sin necesidad de fichas telefónicas ni cables.
  • No requiere modificar enrutadores ni terminales: a excepción del nodo o enrutador móvil, los demás enrutadores y terminales permanecen usando su dirección IP actual. IP Móvil no afecta a los protocolos de transporte ni a los protocolos de más alto nivel.
  • No requiere modificar las direcciones IP actuales ni su formato: las direcciones IP actuales y sus formatos no varían.
  • Soporta seguridad: utiliza mecanismos de autenticación para garantizar la protección de los usuarios.

Entidades

Nodo Móvil (Mobile Nodo)

Terminal o enrutador que puede cambiar su punto de unión desde una red o subred a otra. Esta entidad tiene pre-asignada una dirección IP fija sobre una red local o de base (Home Network) que es utilizada por otros nodos para dirigir paquetes destinados al nodo móvil independientemente de su ubicación actual.

Agente Local (Home Agent)

Enrutador que mantiene una lista de visitas con información de nodos móviles registrados, los que temporalmente no se encuentran en su red local. Esta lista es usada para reenviar a la red apropiada los paquetes destinados al nodo móvil.

Agente Foráneo (Foreign Agent)

Enrutador que asiste a un nodo móvil localmente alcanzable mientras el nodo móvil está lejos de su red local. Este agente entrega información entre el nodo móvil y el agente local.

IP Móvil

Figura 1: relación entre las principales entidades de IP Móvil

Dirección de auxilio (Care-of-Address)

Dirección IP que identifica la ubicación del nodo móvil en un momento determinado.

Nodo Correspondiente (Correspondent Node)

Nodo que envía paquetes destinados al nodo móvil.

Dirección Local (Home Address)

Dirección IP fija asignada al nodo móvil. Permanece invariable independientemente de la ubicación actual de dicho nodo. Por ejemplo, la dirección IP asignado por un ISP -Internet Service Provider-.

Agente de Movilidad (Mobility Agent)

Agente que soporta movilidad. Este podría ser tanto un agente local como uno foráneo.

Túnel (Tunnel)

Camino que toman los paquetes desde el agente local hasta el agente foráneo.

Servicios

Descubrimiento de Agente (Agent Discover)

Los agentes locales y foráneos emiten mensajes de difusión (broadcast), llamados avisos de agente (agent advertisements), advirtiendo periódicamente su presencia en cada enlace en donde pueden proveer servicios. Los nodos móviles escuchan estos avisos y determinan si están conectados o no a su red local. Además, un nodo móvil recientemente arribado a una red podría enviar una solicitud para saber si un agente de movilidad está presente y forzarlo a que inmediatamente envíe un aviso de agente. Si un nodo móvil determina que se encuentra conectado a un enlace foráneo, adquiere una dirección de auxilio.

Registración (Registration)

Una vez que el nodo móvil adquiere una dirección de auxilio, debe registrarla con su agente local, para que el agente local sepa a dónde reenviar sus paquetes o proveerle servicio. Dependiendo de la configuración de la red, el nodo móvil podría registrarse directamente con su agente local o indirectamente mediante la ayuda de un agente foráneo.

Encapsulamiento (Encapsulation)

Proceso de encerrar a un paquete IP dentro de otro encabezado IP, el cual contiene la dirección de auxilio del nodo móvil. Durante el proceso de encapsulación el paquete IP no es modificado.

Desencapsulamiento

Proceso de despojar el encabezado IP de más afuera del paquete entrante para que el paquete encerrado dentro de él pueda ser accedido y entregado al destino apropiado. Es el proceso inverso al de encapsulación.

El funcionamiento del protocolo IP Móvil consiste de varias operaciones:

Cuando un nodo móvil se encuentra lejos de su red local debe encontrar algún agente para no perder conectividad a Internet. Existen dos caminos para encontrar agentes: uno de ellos es seleccionando a un agente de movilidad captado a través de mensajes de difusión que éstos emiten periódicamente advirtiendo su disponibilidad en cada enlace en donde pueden proveer servicios; el otro camino es mediante la emisión de solicitudes sobre el enlace, por parte del nodo móvil recientemente arribado, hasta obtener respuesta de algún agente de movilidad que esté presente. Una vez encontrado el agente, el nodo móvil deduce si se encuentra en su red local o en una red externa. Si se encuentra en su red local opera sin servicios de movilidad, mientras que si se encuentra en una red externa obtiene su dirección de auxilio que puede ser asignada dinámicamente o asociada con su agente foráneo.

Una vez obtenida la dirección de auxilio, el nodo móvil debe registrarla con su agente local para obtener servicios. El proceso de registración puede ser realizado a través de una solicitud de registro enviada directamente desde el nodo móvil al agente local y recibiendo de éste un mensaje de contestación, o indirectamente reenviada por el agente foráneo al local, dependiendo de si la dirección de auxilio fue asignada dinámicamente o asociada con su agente foráneo. Después del proceso de registración el nodo móvil permanece en el área de servicio hasta que expire el tiempo de servicio otorgado o hasta que cambie su punto de enlace a la red. Durante este tiempo el nodo móvil obtiene paquetes reenviados por el agente foráneo, los cuales fueron originalmente enviados desde el agente local. El método túnel (tunneling) es usado para reenviar los mensajes desde el agente local al agente foráneo y finalmente al nodo móvil.

Después de que el nodo móvil regresa a su red, se desregistra con su agente local para dejar sin efecto su dirección de auxilio, enviando un requerimiento de registración con tiempo de vida igual a cero. El nodo móvil no necesita desregistrarse del agente foráneo dado que el servicio expira automáticamente cuando finalizar el tiempo de servicio.

“El protocolo Mobile IP es entendido mejor como la cooperación de tres mecanismos separables: Discovering the care-of address, Registering the care-of address, Tunneling to the care-of address.”.

Proceso de descubrimiento - Discovering the care-of address

El proceso de descubrimiento utilizado por el protocolo IP Móvil permite a un nodo móvil determinar si se encuentra conectado o no a su red local, detectar si se ha desplazado de un enlace a otro y, dado el caso en que el nodo móvil se encuentre conectado a una red externa, obtener su dirección de auxilio.

El protocolo IP móvil provee dos modos alternativos para la adquisición de una dirección de auxilio: Foreign Agent care-of address y co-located care-of address.

Foreign Agent care-of address

Es una dirección de auxilio temporaria provista por un agente foráneo a través de mensajes avisos de agente. La dirección de auxilio, en este caso, es la dirección IP de un agente foráneo. El agente foráneo está en el punto final del túnel donde recibe los paquetes, los desencapsula y entrega el paquete original al nodo móvil. Este modo de adquisición permite que algunos nodos compartan la misma dirección de auxilio y en consecuencia, evita que se produzca una demanda innecesaria del limitado espacio de direcciones, en IPv4.

Co-located care-of address

Es una dirección de auxilio adquirida por el nodo móvil como una dirección IP fija mediante algún medio externo, al cual el nodo móvil luego se asocia con una de sus propias interfaces de red. La dirección puede ser adquirida dinámicamente como una dirección transitoria, como por ejemplo a través de un DHCP (Dynamic Host Configuration Protocol), o puede ser apropiada por el nodo móvil como una dirección perdurable para su uso, solamente, mientras se encuentre visitando una red distinta a su red local. Usando una co-located care-of address el nodo móvil actúa como punto final del túnel y él mismo realiza la desencapsulación de los paquetes. La ventaja de usar una co-located care-of address radica en que permite al nodo móvil funcionar sin un agente foráneo.

El proceso de descubrimiento no modifica los campos originales de los avisos de ruteo existentes, simplemente los extiende para asociarle funciones de movilidad. Así, un aviso de ruteo puede llevar información de ruteo por defecto, como antes, e información adicional sobre una o más dirección de auxilio. Cuando los avisos de ruteo son extendidos para que contengan la dirección de auxilio necesaria se denominan avisos de agente. Si un nodo móvil necesita obtener una dirección de auxilio, pero no desea esperar por un aviso de agente, podría emitir una solicitud de agente.

Avisos de Agente -Agent Advertisements-

Los agentes de movilidad anuncian su disponibilidad para brindar servicios al nodo móvil mediante mensajes de difusión de avisos de agente a intervalos regulares (por ejemplo cada un segundo). El nodo móvil utiliza estos mensajes para determinar su punto de conexión actual a Internet.

El agente local deberá estar siempre listo para servir a sus nodos móviles. Para evitar una posible saturación, debida al exceso de nodos móviles en una determinada red, es posible configurar múltiples agente locales en una única red, asignando a cada agente local una porción de la población de nodos móviles. Los agentes locales usan avisos de agente para darse a conocer a sí mismos aunque no ofrezcan alguna dirección de auxilio. Por otro lado, es posible que un agente foráneo no tenga capacidad para servir a un nodo móvil no perteneciente a su red. Aún en ese caso, el agente foráneo debe continuar emitiendo avisos de agente para que el nodo móvil sepa que se encuentra dentro de su área de cobertura o que no ha fallado.

Los avisos de agente cumplen las siguientes funciones:

  • permiten la detección de agentes de movilidad.
  • listan una o más dirección de auxilio disponibles.
  • informan al nodo móvil sobre características especiales para agentes foráneos, por ejemplo, técnicas alternativas de encapsulación.
  • permiten al nodo móvil determinar el número de red y el estado de su enlace a Internet.
  • permiten al nodo móvil conocer si el agente es local y/o externo y en consecuencia determinar si se encuentra en su red o en una red externa.

El mensaje avisos de agente consiste en un mensaje ICMP (Internet Control Message Protocol) al cual se le ha añadido una extensión para permitir la gestión de los nodos móviles. Dicha extensión (Figura 2) consta de los campos:

  • Tipo: 16
  • Longitud: (6+4*n), donde n es el número de dirección de auxilio anunciadas.
  • Número de secuencia: número total de mensajes avisos de agente enviados desde que el agente fue inicializado.
  • Tiempo de vida de registración: tiempo de vida máximo que el agente acepta en una solicitud de registro.
  • R: registro solicitado.
  • B: el agente foráneo no puede aceptar nuevos registros, al estar ocupado
  • H: este agente ofrece servicios de agente local en la red.
  • F: este agente ofrece servicios de agente foráneo en la red.
  • M: el agente soporta encapsulado mínimo.
  • G: el agente soporta encapsulado GRE.
  • V: el agente soporta la compresión de cabecera Van Jacobson.
  • Reservado.
  • Dirección de auxilio: la/s dirección de auxilio anunciadas por el agente foráneo.

Para que un nodo móvil pueda averiguar si se encuentra en su red local o si se ha desplazado a otra red debe verificar los bits F y H de alguno de los mensajes avisos de agente que capture.

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

Vers.

HL

Tipo de Servicio

Total Leng

Identificación

Banderas

Fragmentación

Tiempo de vida

Protocolo = ICMP

Suma de Comprobación de encabezado

Dirección fuente = dirección del agente local o foráneo sobre este enlace

Dirección destino = difusión o multidifusión

Tipo

Código

Suma de Comprobación

Nro. de direcciones

Asoc. Tamaño entrada

Tiempo de vida

Dirección enrutador

Nivel de preferencia

……

Tipo

Longitud

Número de secuencia

Registration Lifetime

R

B

H

F

M

G

V

Reservado

Direcciones de auxilio
……

Tipo

Longitud

Longitud Prefijo

…….

Encabezado IP

ICMP

Extensiones

Extension Longitud-Prefijo

Figura 2 Extensión del mensaje avisos de agente

Solicitud de Agente -Agent Solicitation

Los nodos móviles podrían emitir solicitudes mediante mensajes de difusión, con el objetivo de forzar a cualquier agente de movilidad ubicado en el mismo enlace a transmitir un aviso de agente de manera inmediata. Esto resulta muy útil en aquellos casos en los cuales la frecuencia de los avisos de agente es demasiado baja para un nodo móvil que cambia rápidamente de enlace. El formato de los mensajes solicitud de agente es similar al de los mensajes ICMP usados para avisos de agente (Figura 2), con la diferencia de que deben tener su campo de tiempo de vida igualado a 1.

Si el nodo móvil conoce de ante mano la dirección de red de un agente de movilidad, podría insertarla en el encabezado de un mensaje de requerimiento de registración y enviarlo a dicho agente para obtener servicios.