HK1110448B - Dynamic assignment of home agent and home address in wireless communications - Google Patents

Description

Dynamic assignment of home agents and home addresses in wireless communications

Priority in accordance with 35 U.S.C. § 119 requirements

This patent application claims priority from provisional patent application No. 60/585,532 entitled "Network Access Identifier (NAI) and Method for" filed on 7/1/2004 and provisional patent application No. 60/585,269 entitled "MIPv 6 With Dynamic Home Address" filed on 7/2/2004, both of which are assigned to their assignee and hereby expressly incorporated herein by reference.

Technical Field

The present disclosure relates generally to wireless communications and mobile IP. More particularly, embodiments disclosed herein relate to providing dynamic assignment of home agents and home addresses to mobile nodes.

Background

Mobile Internet Protocol (IP) is a recommended internet protocol designed to support user mobility. Such mobility has become important due to the proliferation of portable computers and the resulting increased demand for continuous network connectivity wherever users happen to be.

The development of wireless communications has also created a variety of wireless communication devices (e.g., Personal Digital Assistants (PDAs), handsets, mobile phones, etc.) capable of accessing the internet and providing IP services, and thus has placed higher demands on the current internet infrastructure to provide seamless connectivity and robust support to mobile users.

Drawings

Fig. 1 shows a communication system configured to support MIPv 6;

FIG. 2 illustrates a communication system in which disclosed embodiments may be implemented;

FIG. 3 illustrates an embodiment of the steps involved in dynamic allocation of HA and HoA;

FIG. 4 illustrates a call flow diagram that may be used in an embodiment to implement dynamic assignment of HAs and HoAs;

FIG. 5 illustrates a call flow diagram that may be used in an embodiment to implement dynamic assignment of HAs and HoAs;

FIG. 6 illustrates a call flow diagram that may be used in an embodiment to implement dynamic assignment of HAs and HoAs;

FIG. 7 illustrates a flow diagram of a process that may be used in an embodiment to provide dynamic assignment of HAs and HoAs;

FIG. 8 illustrates a flow diagram of a process that may be used in an embodiment to provide dynamic assignment of HAs and HoAs;

FIG. 9 illustrates a block diagram of a device in which some disclosed embodiments may be implemented;

FIG. 10 illustrates a block diagram of a device in which some disclosed embodiments may be implemented.

Detailed Description

Embodiments disclosed herein relate to providing dynamic assignment of home agents and home addresses to mobile nodes in wireless communications.

For reference and clarity, various abbreviations and abbreviations used herein are summarized as follows:

AAA authentication, authorization and accounting

BA binding acknowledgement

BU binding update

CHAP challenge handshake authentication protocol

CoA care-of address

DAD duplicate address detection

DHCPv6 dynamic host configuration protocol version 6

Extensible authentication protocol for EAP

HA Home agent

HAAA home AAA

HMAC hashed message authentication code

HoA home address

HoT home test

HoTI home test initialization

IKE internet key exchange

IPsec internet protocol security

IPv6 Internet protocol version 6

IPv6CP IPv6 control protocol

ISAKMP Internet Security Association and Key management protocol

LCP link control protocol

MIPv6 Mobile IP version 6

MN mobile node

MS-MPPE Microsoft point-to-point encryption

NAI network access identifier

NAS network access server

NCP network control protocol

PANA protocol for supporting network access authentication

PEAPv2 protected EAP protocol version 2

PDSN packet data serving node

PPP point-to-point protocol

PRF pseudo-random function

RADIUS remote authentication dial-in user service

SA security association

SPD security policy database

TLS transport layer security

TTLS tunnel TLS

As used herein, a "node" may refer to a device configured to implement IP. A "link" may refer to a communication facility or medium through which nodes may communicate at the link layer. An "interface" may refer to a connection of a node to a link. A "subnet prefix" may refer to a bit string that includes several initial bits of an IP address. A "router" may comprise a node configured to forward IP packets that are not explicitly transmitted to itself. A "unicast routable IP address" may refer to an identifier that maps to a single interface such that packets sent to it from another IP subnet can be delivered to the mapped interface.

A "mobile node" (MN) may refer to a node that can change its point of attachment from one link to another while still being reachable via its home address. The MN can comprise various types of devices, including, but not limited to, a wired telephone, a wireless telephone, a cellular telephone, a laptop computer, a wireless communication Personal Computer (PC) card, a Personal Digital Assistant (PDA), an external or internal modem, and the like. In various applications, a MN can have different names, such as access unit, access terminal, subscriber unit, mobile station, mobile unit, mobile phone, mobile device, remote station, remote terminal, remote unit, user device, user equipment, handset, etc.

A "home address" (HoA) may refer to a unicast routable IP address that is assigned to the MN for a long period of time. The "home subnet prefix" may refer to an IP subnet prefix corresponding to the HoA of the MN. The "home network" may refer to an IP network on which the home subnet prefix of the MN is configured.

The term "mobile" may refer to a change in the point of attachment of the MN to the internet such that it is no longer connected to the same network to which it was previously connected. If the MN is not currently connected to its home network, the MN is said to be "away from home".

A "care-of address" (CoA) may refer to a unicast routable IP address assigned to a MN when the MN is away from home and on a visited (or foreign) network; the subnet prefix of the CoA is a foreign subnet prefix. A "foreign subnet prefix" can refer to any IP subnet prefix that is different from the MN's home subnet prefix. A "visited network" may refer to any network that is different from the home network of the MN.

A "home agent" (HA) may refer to a router (or routing entity) with which the MN registers its HoA and current CoA. The HA may be configured to intercept packets destined for the HoA of the MN and forward them (e.g., by means of encapsulation and tunneling) to the registered CoA of the MN. A "visitor home agent" (visitor HA) as disclosed herein may refer to an HA on the visited network to which the MN is connected.

A "correspondent node" (CN) may comprise a peer node with which the MN is communicating. The CN may be mobile or stationary.

The term "binding" may refer to the association of the HoA and CoA of the MN, and the remaining lifetime of the association. A Binding Update (BU) may be used by the MN to register the binding of its CoA with its HoA. A Binding Acknowledgement (BA) may be used to acknowledge receipt of the BU.

The IP address makes it possible to route packets from a source endpoint to a destination by allowing the router to forward packets from an inbound network interface to an outbound interface according to a routing table. The routing table typically maintains next hop (outbound interface) information for each destination IP address, which carries information specifying the point connections of the IP node (e.g., network prefix). In order to maintain the existing transport layer connections as the MN moves from place to place, it is necessary to keep its IP address the same all the time. However, the current point of attachment for proper delivery of packets to the MN depends on the network prefix contained in the IP address of the MN, which changes at the new point of attachment. In other words, changing the route requires a new IP address associated with the new point of attachment.

Mobile IP (mip) has been designed to solve this problem by allowing the MN to use two IP addresses: static hoas and coas (see, e.g., MIP version 6(MIPv6) or MIP version 4(MIPv4) published by the Internet Engineering Task Force (IETF) in request for comments (RFC)3775 or RFC 3344). The HoA is static and is used, for example, to identify the MN's home network and/or other connection information (such as TCP connections). The CoA changes at each new connection point and can be seen as a topologically significant address (topologically significant addresses) for the MN; the CoA includes a network prefix and thus identifies the point of attachment of the MN with respect to the network topology. The HoA enables the MN to appear to be able to continuously receive data on the home network to which the MN is assigned the HA. When the MN is away from home and connected to a visited network, the HA obtains all packets destined to the HoA of the MN and arranges for them to be delivered to the MN's current point of attachment.

When away from home, the MN acquires a CoA from a visited network (e.g., advertised from a router or agent) that is connected to its current point of attachment. The MN then registers its new CoA with its HA by performing a BU. In order for packets to be transmitted from its home network to the MN, the HA passes the packets from the home network to the CoA. This involves modifying the packet so that the CoA appears as the destination IP address. When the packet reaches the CoA, the inverse transform is applied so that the packet again appears to have the HoA of the MN as the destination IP address.

Thus, MIP allows the MN to seamlessly move from one network to another without changing its HoA and continuously receive data by using the address regardless of the current point of attachment of the MN to the internet. As a result, the movement of the MN away from its home network is transparent to transport protocols, higher layer protocols, and applications.

In MIPv6, the allocation of HA and HoA is static. Although this is to avoid the MN performing BU towards the same HA on behalf of another MN using its IPsec SA, this may lead to some desirable results, as described below.

By way of example, fig. 1 illustrates a communication system 100 in which an MN110 having an HoA is away from a home network 120 and is connected to a visited network 130. The MN110 HAs acquired a CoA associated with the visited network 130 and registered its binding of the HoA and CoA with the HA 125 on the home network 120.

In one example, the home network 120 may be located in san diego, e.g., california, and the visited network 130 may be located in tokyo, japan, for example. (in other embodiments, home network 120 and visited network 130 may be located in the same country but in different cities, or may be other configurations.) MN110 may communicate with CN 140 (e.g., a local Internet service provider or mobile device) via visited network 130. In this case, packets from the CN 140 to the MN110 (e.g., both in tokyo) may have to be routed first to the HA 125 (e.g., in san diego), and then the HA 125 forwards the packets to the MN110 via the CoA (e.g., by way of satellite and/or submarine cable). In other words, when the MN110 is away from home, current MIPs provide remote access services via its home network, which in some cases may result in packet transmission inefficiencies and/or unreliability, such as described above. This would be desirable if the MN110 could receive local access services from the visited network 130 without having to pass through the home network 120 each time.

Embodiments described herein relate to providing dynamic allocation of HA and HoA for a MN with respect to the MN's current point of attachment in order to allow the MN to receive local access services.

Fig. 2 illustrates a communication system 200 in which various disclosed embodiments may be implemented. For example, MN 210 is away from home network 220 and connected to visited network 230. The visitor HA235 and HoA on the visited network 230 are assigned to the MN 210. MN 210 may also acquire a CoA associated with visited network 230 and register its binding of HoA and CoA with visitor HA235 by performing a BU. In this manner, MN 210 benefits from receiving local access services from visited network 230. For example, packets communicated between the MN 210 and the CN 240 may be routed via the visitor HA235, which is "local" (or close) to both the MN 210 and the CN 240, thus making packet transmission more efficient and reliable. In some embodiments, the use or selection of visited network 230 by MN 210 and CN 240 may be based on, for example, the location of MN 210 and CN 240, network loading status, or other conditions/criteria, etc.

Fig. 3 illustrates an embodiment 300 of the steps involved in dynamically allocating an HA and an HoA for an MN (e.g., in the communication system 200 of fig. 2). At step 310, the MN accesses the visited network (which may require, for example, configuring the data link and negotiating a protocol with the visited network for authentication). At step 320, the visited network performs authentication with the MN's home network (e.g., a home AAA server in the home network). The visited network assigns the MN a visitor HA and an HoA (or a portion of an HoA) at step 330. The MN performs a security binding with the visitor HA at step 340 (which may also include negotiating a security association with the visitor HA). At step 350, the MN communicates with the HoA using the visitor HA. The embodiments described hereinafter provide some examples.

Fig. 4 illustrates a call flow diagram 400 that may be used in an embodiment to implement dynamic assignment of HA and HoA for a MN (e.g., in the embodiment of fig. 3). For example, call flow diagram 400 illustrates negotiations that occur between MN410, Network Access Server (NAS)420 on the visited network (not explicitly shown), and home AAA server 440 on the home network (not explicitly shown) to assign MN410 visitor HA430 and HoA on the visited network. In one embodiment, NAS420 may include a PSDN that works in conjunction with a stateless DHCP server, such as a stateless DHCPv6 server (e.g., as detailed in IETF RFC 3315 and 3736). It should be noted that the stateless DHCP server is shown collocated with NAS420 for simplicity and illustration. In other embodiments, they may be provided separately.

At step 451, MN410 configures the data link, e.g., by executing PPP LCP (such as specified in IETF RFC 1661), and negotiates the use of authentication protocols, such as PAP (e.g., as specified in IETF RFC 1661) or CHAP (e.g., as specified in IETF RFC 1994).

At step 452, the MN authenticates with NAS via PAP or CHAP. NAS may authenticate MN410 with home AAA server 440 via an access-request message specified by the RADIUS protocol (e.g., as detailed in IETF RFC 2865 and 3162). In other embodiments, diameter protocols (e.g., as detailed in IETF RFC 3588) may also be used.

At step 453, home AAA server 440 authenticates MN410 and responds to NAS420 via an access-accept message specified by the RADIUS protocol. The access-accept message may include an MS-MPPE-Recv-Key vendor specific attribute (e.g., as detailed in IETF RFC 2548) that contains the pre-shared Key of MN 410. The pre-shared key may be used by the MN410 and the visitor HA430 (e.g., see step 459, infra) during IKE/ISAKMP (e.g., as detailed in IETF RFCs 2408 and 2409). If MN 420 authenticates with CHAP (such as described above at step 451), the pre-shared key for MN410 may be calculated as follows: PRF (MN-HAAA _ Shared _ Secret, CHAP _ Challenge, NAI). The pseudo-random function (PRF) may be HMAC. The NAI may be the network access identifier of MN 410. "MN-HAAA Shared Secret" may be pre-provisioned in the MN410 and the home AAA server 440.

At step 454, MN410 executes PPP IPv6CP (e.g., as specified in IETF RFC 2472) to negotiate a 64-bit interface ID that MN410 can use to configure its IPv6 link-local address and CoA (e.g., as specified in IETF RFC 3775) via stateless address autoconfiguration (e.g., as specified in IETF RFC 2462) as specified in IETF RFC 2462.

At step 455, NAS420 sends a router advertisement message containing a/64 prefix (e.g., as specified in IETF RFC 2461) to MN410, which MN410 can use to construct its CoA using the/64 prefix by appending the 64-bit interface ID negotiated at step 454 to the/64 prefix. In one embodiment, the router advertisement message may include "M-flag-0, O-flag-1, router age, a-flag-1, L-flag-0" (e.g., as detailed in IETF RFC 2461). M-flag may be set to '0' indicating that MN410 may configure its CoA using stateless address auto-configuration. The O-flag may be set to '1' indicating that MN410 may use the stateless DHCPv6 server to configure other parameters including, but not limited to, the address of visitor HA430 and the HoA of MN410, as described further below.

At step 456, NAS420 assigns MN410 the address and HoA of visitor HA 430. NAS420 may store such information on the stateless DHCPv6 server.

At step 457, MN410 uses the stateless DHCPv6 server to obtain the address of visitor HA430 and the HoA of MN 410. In some embodiments, the address and HoA of visitor HA430 of MN410 may be saved on the stateless DHCPv6 server as a vendor specific information option (such as detailed in IETF RFC 3315).

At step 458, NAS420 creates an SPD entry (such as specified in IETF RFC 2401) in visitor HA430 for purposes of, for example, BU, BA, HoTI, HoT, and other messages (e.g., as specified in IETF RFC 3775). In some embodiments, NAS420 may perform such operations using an interface provided by the visitor HA430 vendor (e.g., as detailed in IETF RFC 2570).

In step 459, MN410 (e.g., as detailed in IETF RFC 2409 and 2460) performs IKEv1 Phase1 with visitor HA430 using an aggressive mode using pre-shared keys to negotiate ISAKMP SA and generate keys for IKEv1 Phase2 ISAKMP messages.

At step 460, MN410 (e.g., as specified in IETF RFC 2409 and 2460) performs IKEv1 Phase2 with visitor HA430 using fast mode to negotiate IPsec SAs (e.g., as specified in IETF RFC 2401) and generate keys for non-ISAKMP messages to protect BU, BA, HoTI, HoT, and other messages (e.g., as specified in IETF RFC 3775).

In step 461, MN410 registers the binding of HoA and CoA with visitor HA430 by performing BU. This may be protected by IPsec (see, e.g., step 460 above).

At step 462, visitor HA430 performs a proxy DAD (e.g., as detailed in IETF RFC2462 and 3775) on behalf of MN410 to ensure that no other node on the link of visitor HA430 is using the HoA of MN 410.

In step 463, MN410 receives a BA from visitor HA430 in response to the BU of step 461. This may also be protected by IPsec (see, e.g., step 460 above).

Fig. 5 illustrates a call flow diagram 500 that may be used in an embodiment to implement dynamic assignment of HA and HoA for a MN. For purposes of illustration and clarity, like elements are labeled with like reference numbers in fig. 4 and 5. Call flow diagram 500 may also share some of the features used in call flow diagram 400 of fig. 4, as described further below.

At step 551, MN410 executes PPPLCP (such as specified in IETF RFC 1661) to configure the data link and negotiate the use of EAP for authentication (e.g., as specified in IETF RFC 3487).

At step 552, MN410 authenticates with home AAA server 440 via EAP-TTLS (e.g., as detailed in "EAP Tunneled tlsauuthentication Protocol (EAP-TTLS)", "IETF draft, July 2004) or PEAPv2 (e.g., as detailed in" Protected EAP Protocol (PEAP) Version 2, "IETF draft, October 2004). EAP communications between MN410 and home AAA server 440 can be via PPP between MN410 and NAS420, and via RADIUS protocol (such as specified in IETF RFC 2865) between NAS420 and home AAA server 440. In other embodiments, a diameter protocol (such as that detailed in IETF RFC 3588) may be used between NAS420 and home AAA server 440. As part of this overall process, NAS420 sends an access-request message (e.g., specified by the RADIUS protocol) to home AAA server 440 in order to obtain MN 410's pre-shared key (e.g., for use during IKE/ISAKMP by MN410 and visitor HA430 below) and keying material (keying material) for encryption and authentication (as part of EAP-TTLS or PEAPv2 functionality) of data between MN410 and NAS 420. Home AAA server 440 responds to NAS420 with an access-accept message (e.g., specified by the RADIUS protocol). The access-accept message includes a MS-MPPE-Recv-Key vendor specific attribute (e.g., as detailed in IETF RFC 2548) that contains the pre-shared Key of MN 410.

At step 553, MN410 executes PPP IPv6CP (e.g., as specified in IETF RFC 2472) to negotiate a 64-bit interface ID that MN410 can use to configure its IPv6 link-local address (e.g., as specified in IETF RFC 2460) and CoA (such as specified in IETF RFC 3775) via stateless address autoconfiguration (such as specified in IETF RFC 2462).

At step 554, NAS420 transmits a router advertisement containing a/64 prefix (e.g., as detailed in IETF RFC 2461) to MN410, which MN410 can use to construct its CoA using the/64 prefix by appending the 64-bit interface ID negotiated at step 553 above to the/64 prefix. In one embodiment, the router advertisement may include "M-flag-0, O-flag-1, router lifetime, a-flag-1, L-flag-0" (e.g., as detailed in IETF RFC 2461). The M-flag may be set to '0' indicating that MN410 may be automatically configured using the stateless address to configure its CoA. The O-flag may be set to '1' indicating that MN410 may use the stateless DHCPv6 server to configure other parameters, including (but not limited to) the address of visitor HA430 and the HoA of MN410, as described further below.

At step 555, NAS420 assigns the address of visitor HA430 and the HoA of MN 410. NAS420 may store such information on the stateless DHCPv6 server.

At step 556, MN410 uses the stateless DHCPv6 server to obtain the address of visitor HA430 and its HoA. In some embodiments, the address of visitor HA430 and the HoA of MN410 may be stored in the stateless DHCPv6 server as vendor specific information options (such as those detailed in IETF RFC 3315).

At step 557, NAS420 creates an SPD entry in visitor HA430 for purposes such as BU, BA, HoTI, HoT, and other messages (e.g., as detailed in IETF RFC 3775). In some embodiments, NAS420 may perform such operations using an interface provided by the visitor HA430 vendor (e.g., as detailed in IETF RFC 2570).

At step 558, MN410 (e.g., as detailed in IETF RFCs 2409 and 2460) performs IKEv1 Phase1 with visitor HA430 using an aggressive mode using pre-shared keys to negotiate ISAKMP SA and generate keys for IKEv1 Phase2 ISAKMP messages.

In step 559, MN410 performs IKEv1 Phase2 with visitor HA430 (e.g., as specified in IETF RFC 2409 and 2460) using fast mode to negotiate an ipseccsa and generate keys for non-ISAKMP messages to protect BU, BA, HoTI, HoT, and other messages (e.g., as specified in IETF RFC 3775).

At step 560, MN410 registers the binding of HoA and CoA with visitor HA430 by performing BU. This may be protected by IPsec (see, e.g., step 559 above).

At step 561, visitor HA430 performs a proxy DAD (e.g., as detailed in IETF RFC2462 and 3775) on behalf of MN410 to ensure that no other node on the link of visitor HA430 is using the HoA of MN 410.

In step 562, MN410 receives a BA from visitor HA430 in response to the BU of step 560. This may also be protected by IPsec (see, e.g., step 560 above).

Fig. 6 illustrates a call flow diagram 600 that may be used in an embodiment to implement dynamic assignment of HA and HoA for a MN. For purposes of illustration and clarity, like elements in fig. 4, 5 and 6 are labeled with like reference numerals. Call flow diagram 600 may also share some of the features used in call flow diagrams 400 and 500, as described further below.

At step 651, MN410 executes a PPPLCP (such as specified in IETF RFC 1661) to configure the data link and negotiate the use of PAP (such as specified in IETF RFC 1661) or CHAP (such as specified in IETF RFC 1994) for authentication.

At step 652, MN410 authenticates with NAS420 via PAP or CHAP. NAS420 may employ home AAA server 440 to authenticate MN410 via an access-request message specified by the RADIUS protocol (such as specified in IETF RFC 2865) or the diameter protocol (such as specified in IETF RFC 3588), as described above.

Home AAA server 440 authenticates MN410 and responds to NAS420 via an access-accept message specified by the RADIUS protocol at step 653. The access-accept message may include an MS-MPPE-Recv-key vendor specific attribute (e.g., as detailed in IETF RFC 2548) that contains the pre-shared key of the MN 410. The pre-shared key may be used by MN410 and visitor HA430 during non-IPsec protected BU and BA, as described further below. If MN410 authenticates with CHAP (such as described above at step 651), the pre-shared key for MN410 may be calculated as follows: PRF (MN-HAAA _ Shared _ Secret, CHAP _ Challenge, NAI). The pseudo-random function (PRF) may be HMAC. The NAI may be the network access identifier of MN 410. "MN-HAAA Shared Secret" may be pre-provisioned in the MN410 and the home AAA server 440.

In an alternative embodiment, step 552 in call flow diagram 500 of FIG. 5 may be performed in place of, for example, steps 652 and 653 above.

At step 654, MN410 executes PPPIPv6CP (such as specified in IETF RFC 2472) to negotiate a 64-bit interface ID that MN410 can use to configure its IPv6 link-local address (such as specified in IETF RFC 2460) and CoA (such as specified in IETF RFC 3775) via stateless address autoconfiguration (such as specified in IETF RFC 2462).

At step 655, NAS420 sends a router advertisement containing a/64 prefix (e.g., as specified in IETF RFC 2461) to MN410, which MN410 can use to construct its CoA using the/64 prefix by appending the 64-bit interface ID negotiated at step 654 to the/64 prefix. In one embodiment, the router advertisement further includes "M-flag-0, O-flag-1, router lifetime, a-flag-1, L-flag-0" (e.g., as detailed in IETF RFC 2461). M-flag may be set to '0' indicating that MN410 may configure its CoA using stateless address auto-configuration. The O-flag may be set to '1' indicating that MN410 may use the stateless DHCPv6 server to configure other parameters including, but not limited to, the address of visitor HA430 and the HoA of MN410, as described further below.

At step 656, NAS420 selects the address of visitor HA430 and the/64 HoA prefix of MN410 (e.g., as detailed in IETF RFC 3775). NAS420 may store such information in the stateless DHCPv6 server.

In step 657, MN410 uses the stateless DHCPv6 server to obtain the address and/64 HoA prefix of visitor HA 430. In some embodiments, the address and/64 HoA prefix of visitor HA430 may be stored in the stateless DHCPv6 server as a vendor specific information option (such as detailed in IETF RFC 3315). MN410 then dynamically creates its HoA using the/64 HoA prefix and its 64-bit interface ID (negotiated in step 655 above). It should be noted that in this case MN410 dynamically builds its HoA, in contrast to the case of being assigned an HoA in the embodiments of fig. 4 or 5 above.

At step 658, NAS420 creates an entry in visitor HA430 that may include the NAI of MN410 (such as detailed in IETF RFC 2486) and the pre-shared key for non-IPsec protected BU and BA messages (e.g., as detailed in Authentication for Mobile IPv6, "IETF draft, January 2005, and" Mobile Node Identifier Option for Mobile IPv6, "IETF draft, December 2004). NAS420 may perform such operations using an interface provided by the visitor HA430 vendor (e.g., as detailed in IETF RFC 2570).

At step 659, MN410 registers its binding of HoA and CoA with visitor HA430 by performing BU. As noted above, the BU may not be protected by IPsec. Alternatively, it may be protected by MN-HA authenticated mobility options (such as detailed in "Authentication for Mobile IPv6," IETF draft, January 2005) and NAI mobility options (such as detailed in "Mobile Node Identifier options for Mobile IPv6," IETF draft, December 2004). Visitor HA430 may check its cache (e.g., populated by NAS 420) to ensure that the HoA being registered by MN410 HAs not been used (e.g., by another MN). Once this is confirmed, registration of the MN can be permitted.

At step 660, visitor HA430 performs a proxy DAD (e.g., as detailed in IETF RFC2462 and 3775) on behalf of MN410 to ensure that no other node on the link of visitor HA430 is using the HoA of MN 410.

In step 661, MN410 receives a BA from visitor HA430 in response to the BU of step 659. As noted above, this BA may not be protected by IPsec. Alternatively, it may be protected by MN-HA authenticated mobility options (such as detailed in "Authentication for Mobile IPv6," IETF draft, January 2005) and NAI mobility options (such as detailed in "Mobile Node Identifier options for Mobile IPv6," IETF draft, December 2004).

Embodiments disclosed herein (such as described above in fig. 2-5) provide some embodiments for dynamically allocating HA and HoA for a MN. Other embodiments and implementations exist. In alternative embodiments, for example, the various steps described above (e.g., data link configuration, authentication, configuring hoas and coas, negotiating security associations, etc.) may be performed according to other suitable protocols. Furthermore, for stateless address autoconfiguration detailed in IETF RFC2462 and 2461, the subnet prefix for the HoA is/64, such as described above. In other embodiments, the subnet prefix of the HoA may be of a different length (or form).

Fig. 7 illustrates a flow diagram of a process 700 that may be used in an embodiment to provide dynamic assignment of HA and HoA for a MN. Step 710 assigns an address of a visitor HA and at least a portion of the HoA of the MN, where the visitor HA is associated with a visited network to which the MN is connected. The term "at least a portion of the HoA" may include the HoA of the MN (such as in the embodiments of fig. 4-5 above), the HoA prefix (such as in the embodiment of fig. 6 above), or other information related to the HoA. Step 720 stores the address of the visitor HA and at least a portion of the HoA of the MN on a server associated with the visited network (e.g., a stateless DHCPv6 server). Step 730 creates an entry in the visitor HA associated with the MN. In one embodiment, the entry may be associated with an SPD entry for storing BU, BA and other messages. In other embodiments, the entry may include the NAI and the pre-shared key associated with the MN.

Process 700 may also include performing authentication with a home network of the MN (e.g., a home AAA server), for example, to obtain a pre-shared key associated with the MN. Process 700 may also include transmitting a router advertisement to the MN, based on which the MN may configure the CoA.

Fig. 8 illustrates a flow diagram of a process 800 that may be used in an embodiment to provide dynamic assignment of HA and HoA for a MN. Step 810 obtains from the visited network an address of a visitor HA and at least a portion of the HoA of the MN, where the visitor HA is associated with the visited network to which the MN is connected. Step 820 sends a BU to the visitor HA, the BU including the HoA and CoA associated with the MN. Step 830 receives a BA from the visitor HA in response to the BU.

Process 800 may also include configuring the CoA based in part on, for example, a router advertisement received from the visited network. Process 800 may also include configuring the HoA based in part on a portion of the HoA (e.g., the HoA prefix) obtained from the visited network. Process 800 may also include negotiating a security association (e.g., IPsec) with the visitor HA.

Fig. 9 illustrates a block diagram of a device 900 that may be used to implement some disclosed embodiments, such as those described above. For example, the apparatus 900 may include a HA assignment unit (or module) 910 configured to assign an address of a visitor HA and at least a portion of an HoA of the MN, wherein the visitor HA is associated with a visited network to which the MN is connected; and an address storage unit 920 configured to store an address of the visitor HA and at least a portion of the HoA of the MN. In some embodiments, the address store 920 may be associated with a server in the visited network (e.g., a stateless DHCPv6 server). The apparatus 900 may also include an authentication unit 930 configured to perform authentication with a home network (e.g., home AAA) of the MN. The device 900 may also include a transmitting unit 940 configured to transmit the router advertisement.

In the device 900, the HA assigning unit 910, the address storing unit 920, the authenticating unit 930, and the transmitting unit 940 may be connected to a communication bus 950. A processing unit 960 and a memory unit 970 may also be connected to the communication bus 950. Processing unit 960 may be configured to control and/or coordinate the operation of the various units. Storage unit 970 may include instructions that are executed by processing unit 960, for example.

In some embodiments, the apparatus 900 may be implemented in a NAS or other network infrastructure device.

Fig. 10 illustrates a block diagram of a device 1000 that may be used to implement some disclosed embodiments, such as those described above. For example, the apparatus 1000 may include an address receiving unit (or module) 1010 configured to obtain, from a visited network, an address of a visitor HA and at least a portion of an HoA of an MN, wherein the visitor HA is associated with the visited network to which the MN is connected; and a HA binding unit 1020 configured to send a BU to the visitor HA, the BU including a HoA and a CoA associated with the MN. The device 1000 may also include an address configuration unit 1030 operable to configure the CoA, e.g., based in part on router advertisements received from the visited network. In some embodiments, the address configuration unit 1030 is further operable to configure the HoA based in part on a portion of the HoA (e.g., the HoA prefix) obtained from the visited network. The device 1000 may further comprise an authentication unit 1040 configured to perform authentication with the visited network.

In the device 1000, the address receiving unit 1010, the HA binding unit 1020, the address configuring unit 1030, and the authenticating unit 1040 may be connected to a communication bus 1050. A processing unit 1060 and a memory unit 1070 may also be connected to communication bus 1050. Processing unit 1060 may be configured to control and/or coordinate the operation of the various units. Memory unit 1070 may contain instructions that are executed by processing unit 1060, for example.

In some embodiments, apparatus 1000 may be implemented in a MN or other data receiving device.

The various units/modules in fig. 9-10 and other embodiments may be implemented in hardware, software, firmware, or a combination thereof. In a hardware implementation, the various units may be implemented in one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Field Programmable Gate Arrays (FPGAs), processors, microprocessors, controllers, micro-controllers, Programmable Logic Devices (PLDs), other electronic units, or any combinations thereof. In a software implementation, the various units may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in memory units and executed by processors (e.g., processor units). The memory unit may be implemented within the processor or external to the processor, in which case it can be communicatively coupled to the processor via various means as is known in the art.

Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in Random Access Memory (RAM), flash memory, Read Only Memory (ROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in the MN. In the alternative, the processor and the storage medium may reside as discrete components in the MN.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (31)

1. A method for wireless communication, comprising:

assigning an address of a visitor home agent associated with a visited network to which the mobile node is connected;

assigning a prefix of a home address of the mobile node; and

the home address for the mobile node is generated using the prefix of the home address.

2. The method of claim 1, further comprising storing the address of the visitor home agent and the prefix of the home address of the mobile node on a server associated with the visited network.

3. The method of claim 1, further comprising employing a home network associated with the mobile node to perform authentication.

4. The method of claim 1 further comprising transmitting a router advertisement that provides information for the mobile node to configure a care-of address.

5. The method of claim 1, further comprising creating an entry in the visitor home agent associated with the mobile node.

6. A method for wireless communication, comprising:

obtaining from a visited network a prefix of an address of a visitor home agent and a home address of a mobile node, the visitor home agent being associated with the visited network to which the mobile node is connected;

generating a home address for the mobile node using a prefix of the home address; and

sending a binding update to the visitor home agent, the binding update including a home address and a care-of address associated with the mobile node.

7. The method of claim 6, further comprising receiving a binding acknowledgement from the visitor home agent in response to the binding update.

8. The method of claim 6, further comprising configuring the care-of address based in part on a router advertisement received from the visited network.

9. The method of claim 6, further comprising configuring the home address based in part on a prefix of the home address obtained from the visited network.

10. The method of claim 6, further comprising negotiating a security association with the visitor home agent.

11. The method of claim 6, further comprising performing authentication with the visited network.

12. An apparatus adapted for wireless communication, comprising:

means for assigning an address of a visitor home agent associated with a visited network to which the mobile node is connected;

means for assigning a prefix of a home address of the mobile node; and

means for generating a home address for the mobile node using the prefix of the home address.

13. The apparatus of claim 12, further comprising means for storing the address of the visitor home agent and the prefix of the home address of the mobile node on a server associated with the visited network.

14. The apparatus of claim 13, wherein the server comprises a stateless Dynamic Host Configuration Protocol (DHCP) server.

15. The apparatus of claim 12, further comprising means for performing authentication with a home network associated with the mobile node.

16. The apparatus of claim 12 further comprising means for transmitting a router advertisement that provides information for the mobile node to configure a care-of address.

17. The apparatus of claim 12, further comprising means for creating an entry in the visitor home agent associated with the mobile node.

18. An apparatus adapted for wireless communication, comprising:

means for obtaining from a visited network an address of a visitor home agent and a prefix of a home address of a mobile node, the visitor home agent being associated with the visited network to which the mobile node is connected;

means for generating a home address for the mobile node using a prefix of the home address; and

means for sending a binding update to the visitor home agent, the binding update including a home address and a care-of address associated with the mobile node.

19. The apparatus of claim 18, further comprising means for receiving a binding acknowledgement from the visitor home agent in response to the binding update.

20. The apparatus of claim 18, further comprising means for configuring the care-of address based in part on a router advertisement received from the visited network.

21. The apparatus of claim 18, further comprising means for configuring the home address based in part on a prefix of the home address obtained from the visited network.

22. The apparatus of claim 18, further comprising means for negotiating a security association with the visitor home agent.

23. The apparatus of claim 18, further comprising means for performing authentication with the visited network.

24. An apparatus adapted for wireless communication, comprising:

a home address allocation unit configured to allocate an address of a visitor home agent and a prefix of a home address of a mobile node, the visitor home agent being associated with a visited network to which the mobile node is connected; and

an address storage unit configured to store in the visited network an address of the visitor home agent and a prefix of the home address of the mobile node, wherein the home address for the mobile node is generated using the prefix of the home address.

25. The apparatus of claim 24, further comprising an authentication unit configured to perform authentication with a home network associated with the mobile node.

26. The apparatus of claim 24 further comprising a transmitting unit configured to transmit a router advertisement providing information for the mobile node to configure a care-of address.

27. The apparatus of claim 24, wherein the address storage unit is associated with a stateless dynamic host configuration protocol, DHCP, server.

28. An apparatus adapted for wireless communication, comprising:

an address receiving unit configured to obtain from a visited network an address of a visitor home agent associated with the visited network to which the mobile node is connected and a prefix of a home address of the mobile node, wherein the home address for the mobile node is generated using the prefix of the home address; and

a home address binding unit configured to send a binding update to the visitor home agent, the binding update including a home address and a care-of address associated with the mobile node.

29. The apparatus of claim 28, further comprising an address configuration unit operable to configure the care-of address based in part on router advertisements received from the visited network.

30. The apparatus of claim 29, wherein address configuration unit is further operable to configure the home address based in part on a prefix of the home address obtained from the visited network.

31. The apparatus of claim 28, further comprising an authentication unit configured to perform authentication with the visited network.