ES2394930T3 - Procedimiento de direccionamiento privado en redes de IP movil apoderadas - Google Patents

Abstract

Un procedimiento para la realización de un Ancla de Movilidad Local, LMA, (90) que pertenece a una red de IPMóvil apoderada, que comprende:obtener el Identificador de Dirección de Red NAI, de un nodo móvil, MN, (10) que está:(I) operando como un anfitrión de IPv4 y (ii) buscando entrar en la red como su red doméstica;enviar una solicitud de Protocolo de Configuración de anfitrión Dinámico, DHCP, a un servidor de DHCP(120) que está: (i) ubicado en la red y (ii) dando servicio a por lo menos un Traductor de Direcciones deRed, NAT, (100), en el que la solicitud de DCHP contiene un campo ClientId, y el campo ClientId se ajustaigual al NAI, en el que el servidor de DHCP da servicio a un NAT particular determinado por el NAI;recibir una Dirección Doméstica privada, HoA, en un mensaje de Acuse de Recibo de DHCP a partir delservidor de DHCP; yenviar la HoA privada en un mensaje de Acuse de Recibo de Vinculación de Apoderado PBA, a unaPasarela de Acceso Móvil, MAG, (70) conectada al MN.

Description

Procedimiento de direccionamiento privado en redes de IP móvil apoderadas

Campo de la invención

La invención se refiere a redes de Protocolo de Internet (IP) y, más particularmente, a redes que soportan IP Móvil (MIP). Aún más particularmente, la invención se refiere a procedimientos para configurar Nodos Móviles (MN) en redes de MIP apoderadas.

Técnica anterior

Las redes conmutadas por paquetes usan el Protocolo de Internet (IP) para entregar paquetes desde un anfitrión de origen hasta un anfitrión de destino usando unas estructuras de direccionamiento que están basadas únicamente en las direcciones de anfitrión respectivas. Las estructuras de direccionamiento más ampliamente difundidas en el uso actual son la Versión 4 de IP (IPv4), y su sucesora, la Versión 6 de IP (IPv6). Mientras que IPv4 usa direcciones de 32 bits, IPv6 usa direcciones de 128 bits, divididas en un prefijo de 64 bits y un sufijo de 64 bits. Debido a que IP está diseñado para ser lo bastante flexible para su uso a través de redes con tecnologías diferentes para la implementación de enlace–capa, se prevé un protocolo para la resolución de direcciones de IP en direcciones de enlace de datos. En las redes de IPv4, este protocolo es el Protocolo de Resolución de Direcciones (ARP) y, en redes de IPv6, el mismo es el Protocolo de Descubrimiento de Vecinos (NDP).

A pesar de que las redes de IP más tempranas implicaban unos nodos fijos, ha existido una necesidad creciente de dar soporte a usuarios que deseen mantener sus conexiones de Internet mientras que se encuentran en movimiento y, de hecho, mientras que itineran entre subredes diferentes o sistemas inalámbricos diferentes. IP Móvil es un protocolo que permite que un Nodo Móvil (MN) mantenga una dirección de IP doméstica (HoA) inalterable a pesar de cambiar su punto de acoplamiento a Internet. En IP Móvil, un encaminador en la red doméstica del MN, asume la representación del MN mientras que el MN está acoplado a una red visitada.

Al MN, cuando se conecta a la red visitada, se le asigna una Dirección a Cargo (CoA). El MN informa a su Agente Propio de la CoA en un mensaje de actualización de vinculación. Esto da lugar a que un túnel bidireccional se configure entre el Agente Propio y el MN (en su CoA). A continuación, si un nodo correspondiente (es decir, cualquier nodo diferente del MN que se está analizando) desea enviar paquetes al MN, esté direccionará los paquetes hacia la HoA. Estos paquetes se entregarán al Agente Propio, el cual los encapsulará y los retransmitirá a través del túnel bidireccional al MN en su CoA. A la inversa, el MN puede usar el túnel bidireccional para enviar paquetes al nodo correspondiente. Como alternativa, el MN puede enviar paquetes directamente al nodo correspondiente, a pesar de que los procedimientos precisos para hacer tal cosa difieren entre IP Móvil v4 (Mobile IPv4) e IP Móvil v6 (Mobile IPv6).

IP Móvil de Apoderado (Proxy Mobile IP, PMIPv6) es una norma más reciente que proporciona una funcionalidad similar a IP Móvil, pero que obvia cualquier necesidad de que el anfitrión implementado en el MN incluya cualquier modificación de protocolo adaptada para soportar movilidad. En su lugar, todo el soporte de movilidad se implementa en el lado fijo de la red, incluyendo la realización del seguimiento de la ubicación del MN. En particular, el MN es capaz de mantener su HoA, y no necesita configurarse con una CoA adicional. (No obstante, la CoA se usa en cualquier otra parte en la red, tal como se explica a continuación).

PMIPv6 introduce dos funcionalidades especiales para el soporte de movilidad: Estas son la Pasarela de Acceso de Movilidad (MAG) y el Ancla de Movilidad Local (LMA). La Pasarela de Acceso de Movilidad (MAG), que está soportada en un encaminador de acceso, gestiona la señalización relacionada con la movilidad para un MN que está acoplado a su enlace de acceso. La MAG realiza un seguimiento de las idas y venidas del MN con respecto al enlace de acceso, y soporta la movilidad de un MN intercambiando mensajes de señalización con el Ancla de Movilidad Local (LMA) del MN. El LMA es el Agente Propio para el MN en un dominio de IP Móvil de Apoderado v6, es decir, en una red que implementa el protocolo PMIPv6.

El protocolo PMIPv6 se inicia cuando un anfitrión móvil, que se está ejecutando en un MN, entra en un dominio de PMIP y se acopla a un enlace de acceso. A continuación se presenta un breve resumen de las transacciones subsiguientes. Pueden encontrarse más detalles en S. Gundavalli, Ed., RFC 5213, “Proxy Mobile IPv6”, IETF Network Working Group (agosto de 2008), http://tools.ietf.org/html/rfc5213, en particular en la Sección 3, “Proxy Mobile IPv6 Protocol Overview”, págs. 9–15.

Después de que el MN se acople a un enlace de acceso, la MAG en ese enlace de acceso adquiere la identidad del MN y determina si el MN está autorizado para su entrada, es decir, si este está autorizado para el servicio de gestión de movilidad basado en red pertinente. Si se confirma la autorización, el MN será capaz de obtener una configuración de dirección en la interfaz conectada. Posteriormente, el soporte mediante la red asegurará que la totalidad del dominio de PMIP aparece para el MN como un único enlace.

La configuración de dirección que se obtiene mediante el MN incluye por lo menos una dirección doméstica (HoA) y la dirección de encaminador por defecto en el enlace conectado. El prefijo de red doméstica es un prefijo que se

asigna al enlace entre el MN y la MAG. La HoA es una dirección a partir del prefijo de red doméstica del MN. El MN será capaz de usar esta dirección mientras que este esté acoplado a la red de acceso que se encuentra dentro del alcance del dominio de PMIP.

Una diferencia entre IP Móvil v6 y PMIPv6 es que, en IP Móvil v6, el agente propio está al tanto de la dirección doméstica del MN. En PMIP, por el contrario, se requiere que las entidades de movilidad conozcan los prefijos de red doméstica del MN, pero no que conozcan necesariamente la dirección exacta que el MN configuró en su interfaz a partir de su prefijo de red doméstica. No obstante, existe un identificador estable del MN, al que se hace referencia como el Identificador de Nodo Móvil (MNIdentifier), que las entidades de movilidad de PMIP pueden adquirir y que pueden usar para identificar el MN. El Identificador de MN es, típicamente, el Identificador de Acceso de Red (NAI),

o algún otro identificador tal como la dirección del Control de Acceso a Medios (MAC).

Al igual que en IP ordinario y en IP Móvil, el protocolo usado para obtener la información de configuración de dirección es el Protocolo de Configuración de anfitrión Dinámico (DHCP). Los dispositivos de red, que actúan como clientes de DHCP, obtienen parámetros de red, incluyendo direcciones, a partir de los servidores de DHCP. Por lo tanto, por ejemplo, un cliente de DHCP en el MN puede obtener la información de dirección a partir de un servidor de DHCP implementado en la MAG o, como alternativa, este puede obtener la información de dirección a partir de un servidor de DHCP implementado en el LMA, el cual retransmite la información a través de un retransmisor de DHCP implementado en la MAG.

El nodo móvil en conexión con el dominio de PMIP puede ser un nodo de IPv4 o un nodo de IPv6, o este puede tener una capacidad doble. De acuerdo con qué Versión de IP sea aplicable, el MN se configurará con una dirección de IPv4 o de IPv6 (o incluso con direcciones dobles). En una red de transporte de IPv6, puede proporcionarse IPv4 en una tunelización IPv6 para entregar el tráfico de IPv4. Si una red de transporte de IPv4 se usa entre la MAG y el LMA, se implementa IPv6 en tunelización de IPv4.

Al igual que en IP Móvil, la red de PMIP también establece un túnel bidireccional entre el LMA y la MAG. Una dirección global, a la que se hace referencia como la Dirección de LMA (LMAA) se configura sobre la interfaz del LMA como un punto de extremo de transporte del túnel. Esta es la dirección a la que la MAG envía mensajes de Actualización de Vinculación de Apoderado (PBU), los cuales se analizan a continuación.

Otra dirección global, a la que se hace referencia como la Dirección a Cargo de Apoderado (CoA de Apoderado), se configura sobre la interfaz de egreso de la MAG. Esta dirección es el otro punto de extremo de transporte del túnel entre el LMA y la MAG. Para el LMA, esta es la dirección a cargo del MN. El LMA registra esta dirección en la entrada de Caché de Vinculación para el MN.

A este respecto, una “vinculación” asocia el prefijo de red doméstica del MN (tal como se asigna a una interfaz dada del MN) con la CoA de Apoderado actual del MN. Tales asociaciones tienen típicamente unos tiempos de vida limitados. El tiempo de vida restante de una asociación dada de este tipo puede estar incluido en la información a la que se hace referencia como la “vinculación”. Las vinculaciones se establecen a través de mensajes de Vinculación de Apoderado que se intercambian entre la MAG y el LMA. De forma más específica, la MAG solicita el establecimiento de una vinculación enviando una PBU al LMA. El LMA responde enviando un Acuse de Recibo de Vinculación de Apoderado (PBA) a la MAG.

Tal como se indica anteriormente, IPv6 usa direcciones de 128 bits, mientras que IPv4 usa direcciones de 32 bits. Debido a la elevada demanda de direcciones de IP, el espacio total de las direcciones de IPv4 públicas posibles es propenso a agotarse. Una forma de mitigar ese problema es compartir a nivel local las direcciones de IPv4 públicas. Es decir, una pluralidad de nodos dentro de, por ejemplo, una red privada, puede compartir una única dirección de IP pública que es visible para el mundo exterior, pero dentro de la red privada puede usar direcciones de IP privadas que no pueden encaminarse de forma global en Internet. Con una disposición de este tipo, las direcciones de IP públicas pueden guardarse sin confusión. En la interfaz entre las redes privada y pública, una entidad de red tal como una pasarela o caja de Traducción de Direcciones de Red (NAT) traduce entre el espacio de direcciones privado y público.

Por las razones anteriores, entre otras, será deseable por lo menos a veces asignar una o más direcciones domésticas privadas a un nodo móvil de IPv4 que se acopla a una red de IP Móvil de Apoderado v6. La especificación RFC 5213 de PMIPv6 no especifica un procedimiento para realizar una asignación de dirección de este tipo. Algunos escenarios de despliegue pueden solicitar, no obstante, este procedimiento.

H. Zhou y col. dan a conocer en el documento “GPMIP: A Proxy Mobile IPv6 Based Global Mobility Managemgent Architecture and Protocol” (The International conference on mobile technology, application and systems 2008; 12– 09–2008), en el que la gestión de movilidad se realiza mediante una entidad de red diferente del propio nodo móvil. El beneficio es la eliminación de la tara de túnel de entrega de datos de enlace inalámbrico entre el nodo móvil y el encaminador de acceso.

S. Lai y H. Deng dan a conocer, en el documento “Proxy Mobile IPv4 Traversal of Network Address Translation (NAT) Devices” (proyecto de normalización de trabajo de IETF, grupo de tareas especiales de ingeniería en Internet; 16–06–2006) un procedimiento para tratar el problema de travesía de NAT para IP Móvil de Apoderado v4.

Utilizando sólo entidades de red, se construye un Túnel de UPD de MIP para obtener la Travesía de NAT para un Cliente de IP Móvil que intercambia mensajes y datos con HA en nombre del nodo móvil.

Behcet Sarikaya describe, en el documento “Home agent placement and IP address management for integrating WLANs with cellular networks” (IEEE Wireless Communications, vol. 13, n.º 6, 1 de diciembre de 2006, páginas 77– 86, ISSN 1536–1284), una itinerancia sin discontinuidades entre redes celulares (3G o la próxima 4G) y redes de área local inalámbrica que pueden proporcionarse usando IP Móvil. IP Móvil requiere el despliegue de agentes propios y un protocolo entre los nodos móviles, agente propio y los nodos correspondientes. Se presentan esquemas de asignación de dirección doméstica de IPv4 para nodos móviles visitando el dominio de WLAN tal como travesía de NAT/NAPT, tunelización inversa y VPN móviles.

Sumario de la invención

Los inventores presentes han desarrollado un procedimiento mediante el cual el LMA puede realizar una asignación de direcciones para el nodo móvil en cooperación con la traducción de direcciones de red, de tal modo que el nodo móvil puede configurarse con una HoA privada.

La invención se lleva a cabo mediante el procedimiento de acuerdo con la reivindicación 1.

Breve descripción de lOS dibujoS

La figura 1 es un diagrama de bloques esquemático de una red ilustrativa en la que está soportado PMIPv6. En la red de la figura 1, la MAG implementa un servidor de DHCP. La figura 2 es un diagrama de bloques esquemático de una red alternativa en la que está soportado PMIPv6. En la red de la figura 2, la MAG implementa un retransmisor de DHCP. Los elementos comunes con la figura 1 se etiquetan con unos números de referencia similares. La figura 3 es un diagrama de flujo de mensajes que ilustra la invención en una realización. El procedimiento que se ilustra en la figura 3 se implementa en una red en la que el servidor de DHCP se encuentra en la MAG tal como se ilustra, por ejemplo, en la figura 1. Los elementos comunes con las figuras 1 y 2, a pesar de tener una representación gráfica diferente, se etiquetan con números de referencia similares.

Descripción detallada

El protocolo PMIPv6, tal como se define en la norma RFC 5213, permite que terminales móviles sin modificaciones de anfitrión cambien, de una forma no discontinua, su punto de acoplamiento a la red de acceso a la vez que se preservan sus direcciones de IP y se mantienen unas sesiones de IP en curso ininterrumpidas Tal como se explica anteriormente, PMIPv6 introduce dos bloques funcionales, la Pasarela de Acceso Móvil (MAG) y el Ancla de Movilidad Local (LMA). La MAG es el primer salto de encaminamiento al que se conecta el MN. La MAG ayuda a la configuración de dirección y la entrega de datos a/desde el MN. La MAG tuneliza los paquetes entre el MN y el LMA, que desempeña un papel similar al del Agente Propio tal como se especifica en MIPv4/6 (norma RFC 3775). El LMA es el ancla de movilidad. Esta asigna una dirección de IP doméstica al MN y es el punto de entrada para el tráfico de entrada enviado a partir de los nodos correspondientes que se encuentran en comunicación con el MN.

PMIPv6 usa un modelo de delegación de prefijos particular, al que se hace referencia como “prefijo por nodo móvil”. Es decir, a cada MN en conexión con el dominio de PMIPv6 se le asigna un prefijo único que será el mismo durante el tiempo de vida de una sesión de movilidad. El MN está virtualmente conectado por el enlace doméstico (en el LMA). La entrega adecuada de los datagramas a la ubicación actual del MN se obtiene a través de tunelización (por ejemplo, IPv6 en IPv6) entre el LMA y la MAG. El LMA puede entregar también una HoA de IPv4 al MN. También es posible la tunelización de los datagramas de IPv4 sobre IPv6.

Un anfitrión de IPv4 sin modificar puede, por lo tanto, conectarse con el dominio de PMIPv6 y conseguir soporte de movilidad. No obstante, no se hace provisión alguna en las normas existentes en lo que respecta a cómo se le asigna la HoA (Dirección Doméstica) al anfitrión móvil de IPv4, en particular en el caso de que el operador despliegue el LMA por detrás de una NAT de Grado de Portadora (CGN). Una CGN es un dispositivo de NAT colocado típicamente por los operadores de red entre el Equipo en las Instalaciones del Cliente (CPE) e Internet público para convertir las direcciones de IP, puertos e identificadores privados de CPE en direcciones de IP, puertos e identificadores externos. Cuando el LMA se encuentra por detrás de una CGN, la CGN permite que un operador asigne una HoA privada a un MN y comparta direcciones de IP públicas entre varios abonados móviles. Por consiguiente, sigue existiendo una necesidad de un procedimiento de asignación de la HoA privada correcta a un MN de IPv4 en conexión con un dominio de PMIPv6 en el que se despliega la CGN.

Pasando a continuación a la figura 1, en la que una red ilustrativa incluye un nodo móvil 10 conectado mediante un enlace R1 a la Red de Servicios de Acceso (ASN) 30, la cual se conecta mediante un enlace R3 a la Red de Servicios de Conectividad Doméstica (HCSN) 40. El enlace R2, que se muestra como una línea de trazo discontinuo, es un enlace lógico que se usa para configurar las relaciones de autenticación entre el MN y la H_AAA (la Autoridad de Autenticación Doméstica). Este se usa durante la entrada en red. Fuera de la caja de NAT 100, la HCSN 40 está conectada a Internet externo.

En el nodo móvil, existe una implementación del cliente de DHCP 20 orientada hacia la MAG, la cual permite, entre otras cosas, la configuración del MN con su HoA.

La ASN 30 incluye una estación base 60, conectada mediante un enlace R6 a la MAG 70. Tal como se muestra, la MAG está ubicada conjuntamente con un Encaminador de Acceso (AR) y con el servidor de DHCP 80, el cual está orientado hacia el cliente de DHCP en el nodo móvil.

La HCSN 40 incluye el LMA 90, la caja de NAT 100 y el servidor de AAA 130. El LMA está ubicado conjuntamente con el cliente de DHCP 110, el cual está orientado hacia la caja de NAT, y la caja de NAT está ubicada conjuntamente con el servidor de DHCP 120, el cual está orientado hacia el cliente de DHCP 110.

Pasando a continuación a la figura 2, la red que se muestra en esta es similar a la red de la figura 1, excepto en que un retransmisor de DHCP (en lugar de un servidor de DHCP) está ubicado conjuntamente con la MAG, y el LMA está ubicado conjuntamente tanto con un cliente de DHCP orientado hacia la caja de NAT como con un servidor de DHCP orientado hacia el retransmisor de DHCP en la ASN.

El procedimiento de los inventores de la presente invención hace posible que el LMA 90 realice la asignación de direcciones para el MN 10 de acuerdo con la topología de NAT. Cuando el LMA 90 reciba una PBU de la MAG 70, el LMA seleccionará una HoA (el LMA puede, de hecho, seleccionar sólo un prefijo de red doméstica) para su asignación al MN. Tal como se usa a este respecto, en el presente documento la expresión HoA significará o bien la totalidad de la HoA o bien el prefijo de red doméstica. Esta HoA se recupera a través del cliente de DHCP 110 en el LMA, el cual está orientado, tal como se indica anteriormente, hacia el servidor de DHCP 120. El servidor de DHCP 120 puede implementarse en la caja de NAT 100.

El LMA 90 usará el NAI de MN 10 como el valor de ClientID que va a incluirse en la solicitud de DHCP. En el caso de que el LMA 90 esté conectada a varias NAT, esta puede usar el NAI recibido en la PBU para seleccionar la NAT más apropiada para dar servicio a la solicitud de dirección. Diferentes cajas de NAT podrían seleccionarse en base a cualquiera de los siguientes factores, entre otros: el perfil de MN, los requisitos de servicio y las cargas actuales de las cajas de NAT respectivas disponibles. Sujeto a los factores de selección aplicables, el LMA puede, por ejemplo, solicitar una dirección a partir de una caja de NAT que permite una clase especificada de aplicaciones.

En la red de la figura 1, el servidor de DHCP 80 (el cual está ubicado, tal como se indica, conjuntamente con la MAG 70 y está orientado hacia el cliente de DHCP en el MN) obtiene la dirección doméstica privada (HoA–priv) que está asociada con el NAI de un nodo móvil implicándose en un intercambio de PBU/PBA con el LMA 90. El servidor de DHCP 80 devuelve la HoA–priv durante posteriores intercambios de DHCP con el nodo móvil identificado por el NAI.

En la red de la figura 2, por el contrario, el retransmisor de DHCP 85 (el cual está ubicado, tal como se indica, conjuntamente con la MAG 70 y está orientado tanto hacia el cliente de DHCP 20 en el MN como hacia el servidor de DHCP 115 en el LMA) retransmite los intercambios de DHCP con el móvil hacia LMA 90. El LMA, a su vez, realiza la asignación de la HoA–priv de acuerdo con el intercambio de PBU/PBA en base al NAI del nodo móvil.

Con referencia a la figura 3, se describirá a continuación un flujo de mensajes de acuerdo con una realización de la presente invención, según se pone en práctica en una red tal como la red de la figura 1. Como apreciarán los expertos en la técnica, las redes WiMax y WiFi, entre otras, son ejemplos de tipos de redes que pueden ser útiles a este respecto.

En el elemento 200, el MN 10 ha activado la interfaz de red y está realizando una entrada en red. En el elemento 210, han tenido lugar un acoplamiento de capa dos y una detección de MN, y la MAG 70 está enviando al LMA 90 el mensaje de PBU que contiene el NAI como el identificador de nodo móvil. El mismo mensaje de PBU contiene el identificador de capa de enlace de MN, la Indicación de Traspaso y el Tipo de Tecnología de Acceso.

Tras la recepción de la PBU, el LMA verifica que se permite al MN 10 la obtención de un servicio de PMIPv6, y asigna la HoA.

De forma más específica, el LMA 90 adquiere una HoA privada (HoA–priv) interrogando a un servidor de DHCP, tal como el servidor 120, que se encuentra en la red doméstica y da servicio a una o más NAT. El ClientID que se usa para la toma de contacto de DHCP (los elementos 221–224 de la figura) es el NAI. (El NAI puede usarse por sí solo o, por ejemplo, en combinación con unos parámetros tales como el identificador de capa de enlace y el tipo de tecnología de acceso).

La sintaxis convencional para un NAI es “usuario@ dominio”. Por lo tanto, el dominio particular contenido en el NAI puede usarse para enviar una solicitud de DHCP a unos servidores de DHCP específicos. Como consecuencia, la selección de NAT puede realizarse de una forma que sea sensible al valor particular del NAI.

La fase de descubrimiento de DHCP, que se muestra en la figura como el elemento 221 (descubrimiento de DHCP) y el elemento 222 (ofrecimiento de DHCP), se invoca si la dirección del servidor de DHCP es desconocida. De otro modo, la toma de contacto de DHCP consiste en el elemento 223 (solicitud de DHCP, incluyendo ClientID ajustado igual al NAI de nodo móvil), y el elemento 224 (acuse de recibo de DHCP, incluyendo la HoA–priv).

En el elemento 230, el LMA 90 ha recibido la HoA–priv en el acuse de recibo de DHCP a partir del servidor de DHCP 120, y el LMA, a su vez, envía un mensaje de PBA a la MAG 70. Este mensaje de PBA contiene la HoA–priv, la cual se ancla en el LMA y se encamina a través de la CGN correcta usando unos mecanismos de apoderado de ARP ordinarios. En otras palabras, el LMA 90 está realizando el papel de apoderado de ARP para el par de direcciones (HoA–priv, LMAmac@). Desde el punto de vista de la CGN, la dirección de IP móvil (HoA–priv) está vinculada a la Dirección MAC de LMA (LMAmac@). El resultado de este comportamiento apoderado por el LMA es que, para la CGN, el móvil parece encontrarse en su red doméstica, y los paquetes destinados al móvil se retransmiten mientras tanto por la CGN a la dirección mac del LMA. El LMA tuneliza a continuación los paquetes hacia la MAG. Para la red externa de IP, el MN se ve usando una dirección de IP pública asignada por la CGN en un momento dado.

Volviendo a la figura 3, se observará en los elementos 241–244 que, después de que se reciba por la MAG 70 el PBA que contiene la HoA–priv, el nodo móvil realiza el intercambio de mensajes de DHCP convencional para configurar la dirección de IPv4 en la interfaz inalámbrica. Este intercambio de mensajes podría incluir mensajes de descubrimiento (el elemento 241) y de ofrecimiento (el elemento 242) de DHCP y siempre incluye mensajes de solicitud (el elemento 243) y de acuse de recibo (el elemento 244). Tal como se muestra en la figura, los mensajes de ofrecimiento, de solicitud y de acuse de recibo incluyen la HoA–priv como un argumento.

Ha de observarse que, de acuerdo con los protocolos establecidos, la HoA–priv que se entrega al LMA en el elemento 224 de la figura 3 se asigna durante una duración temporal definida, a la que se hace referencia como el tiempo de concesión. La duración temporal podría ser finita o infinita (es decir, ilimitada). La vinculación enviada por el LMA 90 a la MAG 70 en el PBA en el elemento 230 de la figura tiene un tiempo de vida ajustado igual al tiempo de concesión de la dirección doméstica. Entonces, cuando la dirección doméstica se configura en el nodo móvil, esta se configura con el mismo tiempo de concesión.

Tal como se muestra en la parte inferior de la figura 3, las operaciones que se describen anteriormente dan como resultado el establecimiento de un túnel 260 entre la MAG 70 y el LMA 90. Dependiendo de la estructura de direccionamiento de la red subyacente, el transporte en este túnel puede ser, por ejemplo, GRE de IPv4 o IPv4 en IPv6. No obstante, los paquetes sobre el último enlace entre el nodo móvil y la MAG no se tunelizan. (En el caso que se describe en la presente, estos son paquetes de IPv4 nativos). En su lugar, estos se entregan usando unos mecanismos de Capa 2 ordinarios, implementados por la red de acceso entre la MAG y el MN, tal como se indica en el elemento 250. Tal como se indica en el elemento 280 de la figura, la caja de NAT (la cual puede ser, por ejemplo, una CGN) realiza la traducción de direcciones entre el lado público 290 y el lado privado 270 de la red.

Ha de observarse que el MN no es consciente de operación de PMIPv6/NAT alguna que tenga lugar en la red. Si fuera necesario, el MN puede realizar operaciones convencionales (tal como STUN) para el descubrimiento de NAT. Es decir, el MN podría necesitar, en algunos casos, tratar con su dirección de IP en el nivel de aplicación, debido a que existen algunas aplicaciones que usan direcciones de IP en sus intercambios de datos. En el caso de que la dirección de IP sea del tipo privado, tales aplicaciones no serán autosuficientes y, en su lugar, dependerán de otros servidores públicos en Internet para descubrir la dirección de IP pública que está asignada actualmente por una CGN a la dirección privada. Por ejemplo, los protocolos y servidores de STUN son, a menudo, útiles para este fin. El enfoque que se describe en el presente caso es transparente para el uso de tales protocolos y es, por lo tanto, compatible con tales aplicaciones.

Claims (4)

1. REIVINDICACIONES

   1. Un procedimiento para la realización de un Ancla de Movilidad Local, LMA, (90) que pertenece a una red de IP Móvil apoderada, que comprende:

   obtener el Identificador de Dirección de Red NAI, de un nodo móvil, MN, (10) que está: 5 (I) operando como un anfitrión de IPv4 y (ii) buscando entrar en la red como su red doméstica; enviar una solicitud de Protocolo de Configuración de anfitrión Dinámico, DHCP, a un servidor de DHCP

   (120) que está: (i) ubicado en la red y (ii) dando servicio a por lo menos un Traductor de Direcciones de Red, NAT, (100), en el que la solicitud de DCHP contiene un campo ClientId, y el campo ClientId se ajusta igual al NAI, en el que el servidor de DHCP da servicio a un NAT particular determinado por el NAI;

   10 recibir una Dirección Doméstica privada, HoA, en un mensaje de Acuse de Recibo de DHCP a partir del servidor de DHCP; y enviar la HoA privada en un mensaje de Acuse de Recibo de Vinculación de Apoderado PBA, a una Pasarela de Acceso Móvil, MAG, (70) conectada al MN.
2. 2. El procedimiento de acuerdo con la reivindicación 1, en el que el LMA obtiene el NAI del nodo móvil MN en un 15 mensaje de actualización de vinculación de apoderado PBU a partir de la MAG.

3. 3.

   El procedimiento de acuerdo con la reivindicación 1, que además comprende establecer un túnel de GRE de IPv4 con la MAG para retransmitir paquetes a y desde el nodo móvil MN.

4. 4.

   El procedimiento de acuerdo con la reivindicación 1, que además comprende establecer un Ipv4 en túnel de IPv6 con la MAG para retransmitir paquetes a y desde el nodo móvil MN.

   20 5. El procedimiento de acuerdo con la reivindicación 1, en el que la HoA privada es un prefijo de red doméstica privado.