Mobile IP : una solución para proporcionar la movilidad de los terminales en Internet

MOBILE IP: UNA SOLUCIÓN PARA PROPORCIONAR LA MOVILIDAD DE LOS TERMINALES EN INTERNET Miquel Oli ver, Óscar Lauro Crup de Comunicacions Móbils i de Banda Ampl a Departame nr de Matemcllica Aplicada i Telemiitica (DMA T) Universitat Politecnica de Catalunya (UPC) INTRODUCCIÓN En los último s años se han ido produciendo numero os ava n ces en el ca mpo de las tecnol ogías de co munic ación. Dos de los más rel eva ntes son, sin dud a, el rápido de sa rrollo de la in formática portátil y la importante implantación de los sistemas de co municaciones móvile s. La conjunción de a mb os factores permite a los usua ri os acceder a una red en cualquier momento y en cualquier lu ga r, aún cuando se encu entren en movimiento . Sin e mb ar go, los ac tu al es protocolo s de internetwarking ( TCP / IP , IPX ó AppleTalk ) pre se ntan serias co mpli cac iones a la h ora de tratar co n n odos que disponen de un cierto gr ado de m ov ilidad entre redes. La m ayo ría de las versio nes del prot oco lo IP (Int erne t Prot oco l) asumen de manera implícit a que el punto al cual el n odo se conec ta a la red es f ij o. P or otra parte, la dirección IP del n odo identifica al mismo de manera uní voca en la red a la que se encue ntr a con ectado . P or co nsig ui ente, cualquier paquete de s tinado a ese n odo es en ca minado en función de la información co ntenida en la parte de su dirección IP que identifica la red en la que está co nectado. Esto implic a que un n odo móv il que se d esp l aza de una red a otra y que mantiene su dire cc ión IP no será l oca li zable en su nu eva situ ac ión ya que los p aquetes dirigido s hacia este nodo se rán en cami n ados a su antiguo punt o de co nexión a la red. Red IP @ 1 47 . 83 . 39 . XX ,-----, HA T unneJlfl g ~ ~ 11 ~ ~'-< 6 0 ----- R ed IP@ 156 . 29 . 51.VY Fig. 1: Escenario utilizado por el pr otocolo I P Móvil El proto co lo IP M óv il co nstitu ye una mejor a del prot oco lo IP cit ado ante ri ormente. Mobile IP permite a un n odo circ ul ar libr eme nte a través de Internet 8 siendo éste s iempre accesi ble mediante una única dir ecció n IP. La Il1l ernet Engineering Ta sk F ar ce ( lETF ) pr opone una a rquite c tur a Mobile-IP que funciona, a grand es r asgos , bajo el sig ui ente co ncepto: un age nte lo ca l, denomina do H am e Agent (HA) y un agente externo , también de nomin ado F areign Agen t (FA) co lab oran para permitir que el nodo móv il o M abile H ast (MH) pueda m ove r se co n se r va ndo su dir ecció n IP inicial (ve r fi g ur a 1 ). En los s iguiente s apa rtado s se pr ese nta el funcionamiento de este prot oco lo y se discute su utilidad. SOLUCIONES PARA PROPORCIONAR MOVILIDAD A LAS ESTACIONES EN REDES IP Para dotar de movilidad a un n odo de la red, a par ecen dif erentes alterna ti vas que son estudiadas co n m ás detalle par a ve r la via bilidad de su impl emen tación dentro de Int ernet. Algunas de las soluciones que a puntamo s son las sig ui entes: estab lecimiento de rutas específicas para terminales co n movi lidad, ca mbio de la direcci ón IP de los termin ales y solu cio nes b asadas en rea li zar cambios a ni vel de la capa de enl ace . Creación de rutas específicas para nodos con movilidad La utili zación de rutas específicas para los n odos a los que se les quiere d ota r de movilidad impli ca la r eco nfig ur ación de las tablas de encamina miento de los dispositivos de interconexión de red (rauters) para permitir co ntactar con el n odo móv il en su nu eva ubicación. Esta so lu ción es ex trem adamente cos to sa debido al gran incremento de tr áf ico que se ge neraría en la red para soport ar la m ov ilidad de los t er minales. Para e ll o sería n ecesa ri o actualizar las ta bl as de e ncamin amiento de co mo mínimo todos los rauters entre el e nl ace l oca l y el nu evo punt o de e nl ace. Si se tiene en cue nta el número de n odo s móviles en la red y la velocidad co n que éstos ca mbian de ubi cació n, estas actua li zaciones po drí an ll ega r a co l apsa r la red. Por lo tanto es importante minimizar el núm ero de rauters a actua li zar y esto a su vez limitará las posibilidades de e ncaminamient os alternativos propias del pr ot oco lo IP. BU RA N° 13 M AYO 1 999 Cambio de dirección IP Otra posible solución consiste en asignar al nodo móvil una nueva dirección IP acorde con su nuevo punto de conexión a la red. Esta solución no es en absoluto recomendable ya que requiere que la entrada del nodo móvil en el sistema de nombres de dominio sea actualizada cada vez que el nodo móvil cambia de dirección IP. Si esta operación no se realiza de forma instantánea, cualquier consulta de la dirección IP del nodo móvil puede ser errónea. Por otra parte, y dada la velocidad a la cual el nodo móvil puede cambiar de dirección IP, se hace necesario un mecanismo para verificar la actualidad de la dirección IP devuelta por el servidor de nombres de dominio (DNS). El resultado es un gran número de consultas y actualizaciones que generan, al igual que en el caso anterior, un alto nivel de tráfico inyectado a la red. Finalmente a nivel local un cambio de dirección IP, provoca generalmente el cierre inmediato de todas las aplicaciones abiertas asociadas a la antigua dirección IP. Soluciones a nivel de la capa de enlace Existen dos grandes soluciones a nivel de la capa de enlace que pretenden permitir la movilidad de los nodos. La primera de ellas se basa en el Cellular Digital Packet Data (CDPD), que se trata de un estándar diseñado para transmitir paquetes IP a través de canales de radio no utilizados por el servicio de vOz en el sistema de telefonía celular norteamericano. El CDPD asigna a cada nodo móvil una dirección IP fij a dentro de su área de cobertura. La segunda solución se basa en el estándar IEEE 802.11, realizado por el Institute of Electrical and Electronics Engineneers (IEEE) para la comunicación de redes de área local inalámbricas. Ambas soluciones presentan dos grandes inconvenientes. Por un lado, las soluciones a nivel de la capa de enlace proporcionan movilidad para un solo tipo de medio físico. Por lo tanto, para N tipos de medios físicos diferentes, se requieren N soluciones de movilidad diferentes. Por otro lado, estas soluciones proporcionan una movilidad más o menos limitada geográficamente, lo cual entra en directa contradicción con el afán expansionista de Internet. Como presentaremos en la siguiente sección, el protocolo IP Móvil es el único capaz de proporcionar movilidad en cualquier tipo de medio y en una extensa área geográfica. • RAMAS DE ESTUDIANTES DEL IEEE PROTOCOLO IP MÓVIL El protocolo IP Móvil fue creado para proporcionar movilidad a los nodos dentro de Internet. Su diseño se basó desde un comienzo sobre las siguientes premisas mínimas e indispensables: -El nodo móvil debe ser capaz de comunicarse con los demás nodos aún después de haber cambiado su punto de conexión a Internet. -Esta comunicación debe efectuarse siempre con una única dirección IP para el nodo móvil que deberá ser su dirección IP en la red de origen, se encuentre donde se encuentre. - El nodo móvil debe ser capaz de comunicarse con otros nodos que no implementen las funciones de movilidad del protocolo Mobile IP. - El nivel de seguridad y de privacidad de las comunicaciones de un nodo móvil no debe ser menor que el de cualquier otro nodo fijo. - El medio entre el nodo móvil y su punto de conexión a Internet será a menudo un enlace inalámbrico. Muy probablemente, el nodo móvil estará alimentado por pilas o baterías, lo que hace importante minimizar el consumo reduciendo al mínimo el número de mensajes de señalización. El principal objetivo del protocolo IP Móvil es sencillo: permitir el encaminamiento de paquetes IP hacia nodos móviles que pueden cambiar rápidamente su punto de conexión a Internet. Este objetivo implica la transmisión de actualizaciones de encaminamientos entre numerosos nodos de la red. Para permitir su uso a través un gran número de enlaces inalámbricos, es muy importante reducir el tamaño y la frecuencia de estas actualizaciones al mínimo posible. Por otra parte, para que el protocolo IP Móvil pueda ser soportado por el mayor número posible de nodos, se requiere que su implementación software sea lo más sencilla posible en términos de carga computacional y memoria. De esta manera, tanto ordenadores portátiles como otros instrumentos con prestaciones hardware reducidas, como por ejemplo buscapersonas, teléfonos celulares u organizadores personales puedan gozar de la funcionalidad del protocolo. Por último, cabe destacar el importante problema que supone la escasez de direcciones IP versión 4. El protocolo IP Móvil contribuye claramente a la no proliferación de nuevas direcciones IP ya que asigna a cada'Bó'do móvil una única dirección IP en todo momento . 9 Funcionamiento El funcionamiento del protocolo IP Móvil consiste en la consecución de la siguiente serie de operaciones: Los agentes local y externo (ver figura 1) anuncian su presencia al nodo móvil mediante mensajes de anunciamiento que se generan periódicamente en la red. Opcionalmente, el nodo móvil puede solicitar tales mensajes a un agente cercano a través de un mensaje de solicitud de agente. El nodo móvil recibe el mensaje de anunciamiento y determina si se encuentra en su red local o en una red externa. Si el nodo móvil deduce que se encuentra en su red local, opera sin funciones de movilidad. Por otro lado, si ha regresado tras haber sido registrado en otra red, procede a de registrarse a través de su agente local. Si el nodo móvil detecta que se encuentra en una red externa, obtiene su dirección de cuidado (care-ofaddress) en la nueva red. Esta dirección puede ser la del agente externo o una dirección de cuidado colocada (colocated care-of-address). Si el nodo móvil se encuentra fuera del alcance de ningún tipo de agente, el nodo móvil debe obtener su dirección de cuidado como una dirección IP local por algún método como, por ejemplo DHCP (Dynamic Host Configuration Protocol). En estos casos, se trata de una dirección de cuidado «colocada». El nodo móvil registra su dirección de cuidado con su agente local. Este proceso se realiza enviando una solicitud de registro al agente local y recibiendo de éste un mensaje de contestación. Todo paquete destinado al nodo móvil es interceptado por el agente local y enviado mediante tunneling por éste hacia la dirección de cuidado. Al otro lado del túnel, el agente extranjero recibe el paquete y lo envía al nodo móvil. Si el nodo móvil posee una dirección de cuidado colocada, el agente extranjero no interviene en la recepción del paquete. Por su parte, los paquetes originados por el nodo móvil pueden ser transportados hasta la dirección IP de destino sin pasar necesariamente por el agente local. Procedimientos . Descubrimiento de agente El descubrimiento de agente es un procedimiento utilizado en el protocolo IP Móvil mediante el cual 10 el nodo móvil determina si se encuentra conectado a su red local o a una red extranjera, si se ha desplazado de un enlace a otro, y también sirve para obtener una dirección de cuidado cuando se encuentra conectado a un red extranjera. El procedimiento mediante el cual se realiza el descubrimiento de agente es relativamente sencillo y precisa únicamente de dos tipos de mensaje: el de anunciamiento de agente y otro de solicitud de agente. . Anunciamiento de Agente La primera acción a realizar para permitir la movilidad de un nodo es la de anunciar por parte del agente local o externo de la disponibilidad para aceptar al nodo móvil en su red. El nodo móvil utiliza mensajes de anunciamiento 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 factible configurar múltiples agentes locales en una única red local, asignando a cada agente local una porción de la población de nodos móviles. Por otro lado, es plausible que un agente externo no tenga capacidad para servir a un nodo móvil no perteneciente a su red. Aún en ese caso, el agente externo debe continuar emitiendo mensajes de anunciamiento para que el nodo móvil sepa que se encuentra dentro de su área de cobertura o que no ha fallado. El mensaje de anunciamiento consiste en un mensaje ICMP de anunciamiento de router al cual se le ha añadido una extensión para permitir la gestión de los nodos móviles. Esta extensión tiene la forma que presentamos en la figura 2. Los campos de la extensión de anunciamiento de agente son los siguientes: -Type: 16 -Length: (6+4*N), donde N es el número de direcciones de cuidado anunciadas. Sequence number: Número total de mensajes de anunciamiento enviados desde que el agente fue inicializado. -Registration lifetime: Tiempo de vida máximo (s) que este agente acepta en una solicitud de registro. (65,535=( 00) -R: Registro solicitado. Es conveniente registrar con un agente extranjero en vez de usar una dirección de cuidado colocada. - B: El agente extranjero no puede aceptar nuevos registros, al estar ocupado (Busy) -H: Este agente ofrece servicios de agente local (Home Agent) en esta red. -F: Este agente ofrece servicios de agente extranjero (Foreign Agent) en esta 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. -Reserved: Reservado. -Care-of addresses: La dirección de cuidado anunciada por el agente extranjero. Para que un nodo móvil pueda averiguar si se encuentra en su red local o, por el contrario, se ha desplazado hacia una red extranjera, tan solo ha de verificar los bits F y H de alguno de los mensajes de anunciamiento que capture. De esta manera, sabrá si el agente está actuando como agente local o externo. La obtención de su dirección de cuidado se realiza a partir del campo de datos care-of address del mensaje de anunciamiento de agente. IP Ver-4 I IHL I IYQe QI Service 1 Total Le~g.th header Identification I~I Frª9iTleJlJ offset (RFC 791) Time to Liv!! I Protoco! = IGMP I Heªger Ghecksum Sourfe Address = homeancjlQl: !ºreilLn ~ addres.5.Sln this link Destination Address - 255.255.255.255 (boradcast) or 224.0.0.1 (multicas!) ICMP J.YIl!!- 9 I Gode I 9heksum Router Num Add[§ I M.IÍ[ ;ntrY §jze I Lifetime Advertis -;m-éñt Rp_u.ter address (1) -(RFCPrelerence .~eve! (1) 1256) Router address (2) Prelerence Leve!_ (2) MQQi!~ IYQ~ = 16 I ~.!!!l9!h I §~~~Jlce NUI1J.!?er ~~ (max.) Re9istration LiletLm~ IRIBIHIFIMIGIVI RESERVED Adverl "1XC Gare-ol addres~ (1) RFC Gare-ol addres~ (2) 2002 Prefix- ~=19 I LeM!~ I prefi~ Le~gth (1) I Prefix Lenat~ (2) hi"1J9ffi Ext _JEE.I!2!J) Fig. 2: Mensajes de Anunciamiento de Agente . Solicitud de agente Los mensajes de solicitud de agente son enviados por los nodos móviles que no desean, o pueden esperar hasta la siguiente transmisión periódica de mensajes de anunciamiento de agente. Por lo tanto, el único objetivo de un mensaje de solicitud de agente es forzar a cualquier agente ubicado en el mismo enlace a transmitir un mensaje de anunciamiento de agente de manera inmediata. Esto resulta especialmente útil en aquellos casos en los cuales la frecuencia de los mensajes de anunciamiento es demasiado baja para un nodo móvil que cambia rápidamente de enlace. El formato de los mensajes de solicitud de agente es exactamente idéntico al de los mensajes ICMP de solicitud de router (ver fig. 2). La única diferencia reside en que los mensajes de solicitud de agente deben • RAMAS DE ESTUDIANTES DEL IEEE tener su campo de tiempo de vida (Time To Live - TTL) a 1. . Registro El protocolo IP Móvil tipifica varias circunstancias bajo las cuales todo nodo móvil debe registrarse. La primera de ellas es cuando detecta que su punto de conexión a Internet ha variado respecto a un instante anterior. También deberá registrarse si, aún sin haber cambiado su punto de conexión a Internet, el registro anterior está a punto de caducar. Finalmente, cuando el nodo móvil en una red extranjera detecta que su agente extranjero se ha reiniciado. El procedimiento de registro sirve para solicitar los servicios de un agente externo. Acto seguido, el nodo móvil procede a informar a su agente local de su nueva dirección de cuidado en la red. Por el contrario, si el nodo móvil detecta que ha regresado a su red local tras haber permanecido fuera de ella, debe iniciar el procedimiento para desregistrarse con su nodo local para poder continuar funcionando como cualquier otro nodo fijo. El procedimiento de registro comprende los siguientes pasos: 1. El nodo móvil envía un mensaje de petición de registro. Según el caso, este mensaje se enviará directamente al agente local o vía el agente externo, previa aceptación del mismo. 2. El agente local recibe la petición de registro y envía a su vez al nodo móvil un mensaje de contestación de registro. Éste último informa al nodo móvil si su petición de registro ha sido o no aceptada . 3. Si el nodo móvil no recibe la contestación de registro en un período razonable de tiempo, procede a retransmitir las peticiones de registro con intervalos cada vez más largos entre ellos, hasta recibir contestación. Para poder llevar a cabo el procedimiento es necesaria la cooperación entre los agentes local y externo, intercambiando mensajes de petición de registro, de respuesta de registro además de datos opcionales. . Petición de registro Un nodo móvil se registra con su agente local mediante un mensaje de petición de registro. De esta manera, el agente local puede crear o modificar la entrada del nodo móvil en su lista de nodos con movi11 lidad. El mensaje de petición de registro presenta el formato mostrado en la figura 3. IP Ver=4 I IHl I TY!lE1dService I TotalloclJ!l!!! Header Identific;at~.J:l I f~l F@!lmentoffset (RFC TimelD,l~e I Protocol = uOP I Headec Cltecksum 791) Source Addres,s Oes!ination Adcress UDP Sourc!1~ 1 !le~tin¡¡tiOl! Port = 434 ~?L !,mJl!! 1 {:hecksu m OOQ I~=1 I I !,ifetime ~~ Mobil~ Node's Homa Address fu!]sm !:lome ~ent ~ddres~ m &rulJm Care-d Addre~ í.?Jl Identifícation &~I ~Extensions '" Mgb.ililt ~=32 I l~!h I Secu!ilY: Pammetec );jru¡J~ Index(SPI) I ~ B.EQ ~ 2002 º~~xtenM>~ Fig. 3: Mensaje de petición de registro. Los diferentes campos que conforman el mensaje de petición de registro son los siguientes: 12 -Type: 1 (Petición de registro) - S: El nodo móvil solicita que el agente local mantenga sus anteriores entradas de movilidad. - B: El nodo móvil pide solicita al agente local que tunele hacia él los paquetes de broadcast que se reciban en la red local. - D: El nodo móvil informa al agente local que desencapsulará los paquetes que le sean enviados a su dirección de cuidado. Esto implica que el nodo móvil esta utilizando una dirección de cuidado colocada. - M: El nodo móvil solicita que el agente local utilice encapsulado mínimo para los paquetes destinados a él. - G: El nodo móvil solicita que el agente local utilice encapsulado GRE para los paquetes destinados a él. - V: El nodo móvil solicita que el agente local que su agente de movilidad emplee la compresión de cabeceras de Van Jacobson. -Reserved: Reservado. -Lifetime: Número de segundos restantes antes de la caducidad del registro actual. -Home Address: Dirección IP del nodo móvil -Home Agent: Dirección IP del agente local del nodo móvil. -Care-of Address: Dirección de cuidado=dirección IP a la salida del túnel. -Identification Número de 64 bits creado por el nodo móvil para asociar peticiones de registro con contestaciones de registro. También sirve para proteger contra contestaciones de registro fraudulentas. -Extensions: Extensiones . Respuesta de registro Como ya se ha explicado anteriormente, tras la recepción de una petición de registro, el agente local devuelve al nodo móvil un mensaje de respuesta de registro. Si el nodo móvil solicita el servicio a través de un agente externo, será éste quien reciba la contestación de registro y la envíe a continuación al nodo móvil. Por otro lado, si el nodo móvil está utilizando una dirección de cuidado colocada, será él mismo quien reciba la el mensaje de respuesta de registro. Este mensaje informa al nodo móvil sobre el resultado de su petición de registro y del tiempo de vida del registro, que puede ser inferior o igual al solicitado por el nodo móvil. El agente externo no puede en ningún caso modificar el tiempo de vida asignado por el agente local. El formato del mensaje de respuesta de registro es el mostrado en la figura 4. 2 Eixed ImJ¡ = 3 J Code L Lifetime .lli.atl! Mobite ]'lode's !-lome address Portion 9.!B!9.. ,t!.or1Jl~~! Address Bm>Jy (RFC [ggQ!tf!f?j[Q!l 2002) Fig. 4: Mensaje de respuesta de registro. Los campos del mensaje son los siguientes: -Type: 3 (Contestación de registro) -Code: Código indicador del resultado de la petición de registro. -Lifetime: Tiempo de vida, en segundos, de la entrada del nodo móvil en la lista de movilidad del agente local. -Home Address: Dirección IP del nodo móvil. -Home Agent: Dirección IP del agente local del nodo móvil. -Identification: Número de 64 bits creado por el nodo móvil para asociar peticiones de registro con contestaciones de registro. También sirve para proteger contra contestaciones de registro fraudulentas. -Extensions: Extensiones. Posibilidades opcionales del procedimiento de registro Además de las acciones anteriormente descritas, el procedimiento de registro permite también llevar a cabo otras interesantes funciones que se enumeran a continuación: -Descubrir la dirección de un agente local si el nodo móvil no ha sido configurado con esta información. -Seleccionar diferentes tipos de encapsulado de los paquetes. -Utilizar la compresión de encabezados de Van Jacobson. -Mantener varios registros simultáneos para que cada dirección de cuidado activa reciba una copia de los paquetes destinados al nodo móvil. -Desregistrar ciertas direcciones de cuidado manteniendo otras activas. Tratamiento de los paquetes: Encaminamiento ytunneling Una vez analizados los procedimientos de descubrimiento de agente y de registro, presentamos los diferentes modos en que un paquete puede ser encaminado desde su dirección IP de origen hasta la dirección IP de destino en función de la situación del nodo móvil. Encaminamiento de los paquetes En primer lugar, cabe distinguir dos posibles escenarios: uno en el que el nodo móvil está conectado a su red local, o bien si éste se encuentra en una red externa. Nodo móvil en red local Si el nodo móvil se encuentra en su red local, actúa como si de cualquier otro nodo fijo se tratase. Por lo tanto, las reglas para el encaminamiento de paquetes en este caso son las mismas que para el encaminamiento de paquetes IP hacia cualquier nodo o router convencional. Extremos Cab.IP Datos IP del tunel ¿? D [l Cab.lPori¡jIvi i Cab.Aux I Cab.IP Datos IP I Figura 5: operación de encapsulamiento. Nodo móvil en red extranjera . Hacia el nodo móvil El protocolo IP Móvil requiere que los paquetes enviados desde la red local hasta el nodo móvil sean encapsulados. El encapsulado altera el encaminamiento habitual de los paquetes ya que éstos atraviesan un • RAMAS DE ESTUDIANTES DEL IEEE nodo intermedio antes de llegar a su destino. Una vez ha llegado al nodo intermedio, éste procede a desencapsularlo y enviar el paquete original al destinatario final. De manera general, las operaciones que comprende el envío de un paquete hacia un nodo móvil en una red extranjera son las siguientes: 1. Un router en la red local, generalmente el agente local, anuncia que existe conectividad hasta el prefijo de red equivalente al de la dirección local del nodo móvil. Por lo tanto, todo paquete destinado al nodo móvil es encaminado hacia su red local y, en concreto, es recibido por su agente local. 2. El agente local intercepta el paquete destinado al nodo móvil y consulta su entrada en su lista de movilidad para conocer las direcciones de cuidado registradas. 3. A continuación, el agente local envía una copia del paquete hacia cada dirección de cuidado a través de túneles (tunneling). En cada dirección de cuidado (la del agente externo o una dirección de cuidado colocada), se extrae el paquete original y es entregado al nodo móvil. Antes de enviar un paquete a través del túnel, el agente local realiza la operación de encapsulado dentro de un nuevo paquete cuya dirección de destino es la dirección de cuidado (ver figura 5). Si se trata de una dirección de cuidado de un agente externo, éste deshace el encapsulamiento exterior del paquete para recuperar el paquete original. A continuación consulta el campo de dirección IP de destino para comprobar si coincide con alguno de los nodos móviles a los que está prestando servicio. Si es este el caso, el agente externo envía el paquete al nodo móvil a través de la interfaz adecuada. Si la dirección de cuidado es colocada, el nodo móvil no recibe los servicios de ningún agente extranjero y, por lo tanto, efectúa él mismo las operaciones de desencapsulamiento . . Desde el nodo móvil Para poder enviar paquetes a otros nodos, un nodo móvil debe encontrar la dirección de un router que pueda dar salida a estos paquetes. Si el nodo móvil depende de un agente externo, existen dos alternativas a la hora de determinar un router adecuado: - El propio agente extranjero, según especifica el campo IP Source Address del mensaje de anunciamiento de agente . 13 -Cualquier router cuya dirección IP aparezca en los campos Router Address del mensaje de anunciamiento de router, porción del mensaje de anunciamiento de agente. Sin embargo, esta última alternativa tan solo es válida si el nodo móvil es capaz de determinar la dirección de la capa de enlace del router deseado, sin enviar peticiones de ARP (Address Resolution Protocol) que contengan su dirección IP local. Si el nodo móvil posee una dirección de cuidado colocada, es decir, no depende de ningún agente externo, también tiene dos alternativas a la hora de seleccionar un router: - Escoger algún router que esté enviando mensajes de anunciamiento de router (no de agente) en la red en la que se encuentra. • - Mediante el mismo mecanismo por el que obtuvo su dirección de cuidado colocada puede obtener la dirección de un router adecuado. Por ejemplo, el protocolo DHCP ofrece todo tipo de información al nodo móvil, incluida la dirección de un router. Contrariamente a los nodos móviles dependientes de un agente externo, los nodos móviles con una dirección de cuidado colocada pueden enviar peticiones ARP con su dirección local. Tunneling El término encapsulado es un equivalente al de tunelado o tunneling. Ello consiste en la inserción de un paquete IP dentro de otro paquete del mismo tipo u otro. El paquete resultante es, a continuación, enviado a un nodo intermedio entre el nodo origen y el nodo destino final. El escenario más habitual de utilización de túneles es el presentado en la figura 6. Figura 6: Escenario típico para acciones de tunneling El nodo encapsulador es generalmente considerado el punto de entrada al túnel y el nodo desencapsulador el punto de salida del túnel. 14 Actualmente las técnicas de encapsulado IP son especialmente útiles para realizar transmisiones multicast, e incluso llevar a cabo acciones de seguridad y privacidad en Internet. El protocolo IP Móvil requiere que los agentes locales, los agentes externos y los nodos móviles con una dirección de cuidado colocada soporten el encapsulado IP-in-IP. En esta sección se presentan éste y otros tipos de encapsulado que el agente local puede emplear para enviar los paquetes a través de túneles. Encapsulado IP-in-IP El encapsulado IP-in-IP consiste en insertar un una cabecera IP adicional antes de la cabecera propia del paquete inicial como se muestra en la figura 5. También es posible insertar otras cabeceras (como por ejemplo, requisitos de seguridad para proteger el paquete original durante el tunelado) entre las dos cabeceras anteriores. La cabecera exterior contiene información sobre los extremos del túnel. La cabecera interior contiene información sobre los nodos origen y destino del paquete inicial y no puede ser modificada en ningún caso, salvo para decrementar el tiempo de vida (TTL - Time To Live) del paquete, aunque tan solo una vez dentro del túnel, a pesar de que pueda atravesar varios routers. A simple vista podría parecer que resulta imposible saber si se ha producido algún problema con el paquete mientras éste se encuentra dentro del túnel. N o obstante, el punto de entrada al túnel mantiene una serie de informaciones, compuesto por un juego de variables que describen las características del túnel. Esta información consta de: - Máxima MTU (Maximum Transfer Unit) del túnel. -Longitud del túnel, contabilizada en hops. -Si el extremo final del túnel es alcanzable El punto de entrada al túnel actualiza estas variables mediante mensajes ICMP que recibe de los routers en el interior del túnel. Encapsulado mínimo El encapsulado suele conllevar el duplicado innecesario de numerosos campos de la cabecera IP interna. El encapsulado mínimo intenta minimizar al máximo la información de overhead de encapsulado para disminuir el tamaño del paquete resultante. Según puede o bservarse en la figura 7, la cabecera IP original es modificada y la cabecera de encapsulado mínimo es insertada entre la cabecera original modificada y la información. Extremos I I del tunel Cabecera IP Datos IP \) (l il :~~ Cab.lP externa I G.MJnha.1P I Datos IP Fig. 7: Encapsulado mínimo Al desencapsular un paquete con encapsulado mínimo, se deberán restaurar los campos modificados en la cabecera original con los datos de la cabecera de encapsulado mínimo, actualizando los campos que así lo requieran como por ejemplo el campo de longitud del paquete, y el de checksum. A pesar de todo, el encapsulado mínimo no está ampliamente difundido ya que presenta ciertas desventajas. Concretamente, no funciona con paquetes ya fragmentados. Además, este encapsulado fuerza que el valor TTL sea decrementado en cada router dentro del túnel por lo que, puede suceder que los paquetes caduquen antes de llegar a su destino. Encapsulado GRE El encapsulado GRE (Generic Record Encapsulation) es el más flexible los tres estudiados en este documento, ya que permite la encapsulación de cualquier tipo de paquete, incluidos los paquetes IP. El formato del paquete GRE es el que se presenta en la figura 8. L--I _cab_ecera_ext_erna_IL-CSIléI::eIa __ GAE------L-1 _D_ato_s IP_---'I I Fig. 8: Formato del paquete GRE Contrariamente a los encapsulados IP-in-IP y mínimo, el encapsulado GRE ha sido específicamente diseñado para prevenir encapsulamientos recursivos. Concretamente, el campo recur en la cabecera GRE es un contador que informa del número de encapsulados adicionales que son permitidos. En el protocolo IP versión 6 se está estudiando implementar un mecanismo similar a éste en su documento borrador sobre acciones de tunelado . • RAMAS DE ESTUDIANTES DEL IEEE CONCLUSIONES En este artículo se ha presentado el funcionamiento detallado del protocolo denominado IP Móvil. Este protocolo facilita la movilidad de terminales dentro de redes IP versión 4 sin tener que realizar ninguna modificación ni en el mismo protocolo IP, ni en los elementos de interconexión routers encargados de realizar el encaminamiento de los paquetes. De esta manera se permite que un ordenador portátil pueda moverse con total libertad y acceder a los servicios de red que le ofrece su entorno local desde cualquier parte del mundo sin tener que realizar ningún tipo de modificación en la configuración de sus aplicaciones ni del sistema operativo. En situaciones en las que la conexión física a la red se produce mediante técnicas inalámbricas, como por ejemplo utilizando redes de área local wireless, o bien a través de servicios de datos proporcionados por los sistemas celulares (GSM, GPRS, CDPD, etc.) es cuando se pone de relieve la importancia de poder acceder de forma transparente a cualquier aplicación. En la última edición del protocolo IP, la denominada versión 6, ya se prevén este tipo de acciones modificando de forma notable todos los aspectos relacionados con el formato de las direcciones de red. BIBLIOGRAFÍA [1] DOCUMENTO INTERNET ENGINEERING TASK FORCE: Request For Comments RFC 2002 «IP Mobility Support». [2] DOCUMENTO INTERNET ENGINEERING Request For Comments RFC Encapsulation within IP». TASK FORCE: 2003 «lP [3] DOCUMENTO INTERNET ENGINEERING TASK FORCE: Request For Comments RFC 2004 «Minimal encapsulation within IP». [4] DOCUMENTO INTERNET ENGINEERING T ASK FORCE: Request For Comments RFC 768 «User Datagram Protocol» [5] DOCUMENTO INTERNET ENGINEERING T ASK FORCE: Request For Comments RFC 791 «Internet Protocol» [6] DOCUMENTO INTERNET ENGINEERING TASK FORCE: Request For Comments RFC 1256 [7] James d. Solomon, Mobile IP: THE INTERNET UNPLUGGED, editorial Prentice Hall series in computer networking and distributed systems, 1996-97 15