CN100539586C - Method, system and equipment for supporting hierarchical mobile IP services - Google Patents

Abstract

Essential characteristic of the present invention is the HMIPv6 business that relies on AAA foundation structure next " guiding " mobile node (130) of " roaming " in visited network or in the home network.According to first-selected embodiment of the present invention, it is that the HMIPv6 business is to mobile node (130) authentication and mandate that guiding HMIPv6 business relates to based on AAA foundation structure.In important occasion, mobile node is roamed in visited network, and AAA foundation structure (110,120,122) links the home network of visited network with mobile node.The present invention also supports MAP (125) is located at possibility in other networks of home network or non-visited network.The dependence of AAA foundation structure preferably related to by AAA foundation structure be transmitted as the HMIPv6 business to the mobile node authentication with authorize required HMIPv6 relevant information.

Description

Method, system and equipment for supporting hierarchical mobile IP services

technical field

The present invention relates generally to mobile communications, and more particularly to the support of Mobile IP (Internet Protocol) services, and in particular Hierarchical Mobile IP Release 6 services.

Background technique

Mobile IP (MIP) enables a Mobile Node (MN) to change its point of attachment to the Internet with minimal service interruption. MIP itself does not provide any specific support for mobility across different administrative domains, which limits the applicability of MIP in large-scale commercial deployments.

The Mobile IP Version 6 (MIPv6) protocol [1] enables nodes to move within the Internet topology while maintaining reachability and ongoing connectivity with communicating nodes. In this case, each mobile node is always identified by its home address, regardless of its current point of attachment to the IPv6 Internet. When away from its home network, a mobile node is also associated with a care-of address (CoA), which provides information about the mobile node's current location. IPv6 packets addressed to the mobile node's home address are routed more or less transparently to its care-of-address. The MIPv6 protocol enables an IPv6 node to cache the binding of a mobile node's home address to its care-of address, and then send any packets destined for the mobile node to the care-of address. To this end, each time it moves, the mobile node sends said binding update to its home agent (HA) and to the correspondent nodes it is communicating with. Authentication binding updates require some round trips between the mobile node and each correspondent node. Furthermore, a round trip is required to update the home agent, although this can be done at the same time as the correspondent node is updated. These round-trip delays interrupt active connectivity each time a switchover to a new access router is performed.

For this and other reasons, the Hierarchical Mobile IPv6 (HMIPv6) protocol [2] was proposed to support local or hierarchical forms of mobility management. Hierarchical mobility management for Mobile IPv6 reduces the amount of signaling between a MN, its Correspondent Node (CN) and its HA by introducing so-called Mobility Anchor Points (MAPs) located in the visited network. The introduction of MAP can also be used to improve the performance of moving IPv6 in terms of switching speed.

Fig. 1 schematically shows an example of the HMIPv6 domain of the MAP in the visited network in the prior art. The overall system view includes a home network 10 with a generic home agent (HA) 15 , a visited network 20 with a MAP 25 and an access router (AR) 27 . A Mobile Node (MN) 30 entering the MAP domain will receive said Router Advertisements containing information about one or more home MAPs. The MN 30 may bind its current location (Link-relative Care-of-Address or LCoA) to an address on the subnet of the MAP called a Regional Care-of-Address (RCoA). As a local HA, the MAP 25 will receive all packets on behalf of the MN 30 it is serving, and will encapsulate them and forward them directly to the MN's LCoA.

MAP can help provide seamless mobility for a mobile node as it moves from Access Router 1 (AR1) 27-1 to Access Router 2 (AR2) 27-2 while communicating with a Correspondent Node (CN) 40 . When arriving at the visited network, the mobile node 30 will discover the global address of the MAP 25 . This address is stored in the access router and communicated to the mobile node via router advertisements. This procedure is called MAP discovery and needs to be performed to inform the mobile node that a MAP exists. A MAP domain is typically defined by an access router that advertises MAP information to connected mobile nodes. The MAP discovery process continues as the mobile node moves from one subnet to the next. Whenever the mobile node roams within the MAP domain, the access router is configured to advertise the same MAP address. If there is a change in the address of the MAP that received the advertisement, the mobile node must perform movement detection and send the necessary binding updates to its home agent and correspondent node.

If the mobile node is not HMIPv6 aware, MAP discovery will not be performed and Mobile IPv6 will be used for mobility management. On the other hand, if the mobile node is HMIPv6 aware, it should choose to use HMIPv6. If so, the mobile node registers with the MAP 25 by sending a Binding Update containing its home address and LCoA address. The home address used in the binding update is the RCoA address, and the MAP 25 stores this information in its binding cache so that it can forward packets as they are received from the correspondent node 40 or HA 15 to their final destination land.

Like MIP, HMIPv6 itself does not provide any specific support for mobility across different administrative domains, which limits the applicability of HMIPv6 in large-scale commercial deployments.

Generally, it can be expected that the MN needs to be authenticated first before being authorized to use HMIPv6 services. It is important that the security relationship between the mobile node and the MAP is of a strong nature; it should preferably involve mutual authentication, integrity protection and protection against replay attacks. To this end, the distribution of certificate-related data such as security keys between MNs and MAPs currently needs to rely on Public Key Infrastructure (PKI) and other complex protocols. The current HMIPv6 draft [2] also restricts the location of the MAP to the visited network.

Contents of the invention

The present invention overcomes these and other disadvantages of prior art arrangements.

A general object of the present invention is to provide improved support for HMIPv6 traffic to mobile nodes. The solution should preferably include mechanisms to facilitate the deployment of HMIPv6.

In particular, it is desirable to provide a streamlined but robust solution for authentication and authorization of HMIPv6 traffic, which does not need to rely on public key infrastructure (PKI) and other complex protocols.

Another object of the invention is to allow shortening of the overall HMIPv6 setup time.

Another object of the present invention is to provide a method and system for supporting HMIPv6 services.

Yet another object of the present invention is to provide individual network components that support streamlined authentication and/or authorization of HMIPv6 traffic.

These and other objects are met by the present invention, as defined by the appended patent claims.

An essential feature of the present invention is that it relies on the AAA infrastructure to "bootstrap" the HMIPv6 traffic of the mobile node. According to a preferred embodiment of the present invention, directing HMIPv6 traffic involves authenticating and authorizing mobile nodes for HMIPv6 traffic based on the AAA infrastructure. In important scenarios, the mobile node roams in a visited network, and the AAA infrastructure links the visited network with the mobile node's home network. However, the invention also supports the case when the mobile node is actually located in the home network. In this case, the AAA infrastructure components of the home network can use the MAP in the home network to provide the necessary support for HMIPv6 services.

The reliance on the AAA infrastructure preferably involves the transfer of HMIPv6 related information needed to authorize the mobile node for HMIPv6 traffic via the AAA infrastructure.

HMIPv6 bootstrapping is usually based on establishing security associations between appropriate MAPs and mobile nodes to make associated communications secure, eg HMIPv6 MAP bindings that allow authentication.

In a preferred embodiment of the invention, piggybacking the HMIPv6 mobility procedures in the same round trip as the HMIPv6 security association procedures makes it possible to reduce the overall setup time by optimizing authentication, authorization and mobility in common procedures.

The authorization phase naturally includes explicit authorization, but may also include configuration of the nodes involved. HMIPv6 related configurations, such as the configuration of the mobile node and/or the configuration of the MAP, can therefore generally be considered as part of the overall authorization process. This often means that HMIPv6 related information may be HMIPv6 authentication, authorization and/or configuration information.

Instead of the conventional MAP discovery process, the AAA infrastructure is preferably used to assign the appropriate MAP to the mobile node in response to a MAP assignment request initiated from the mobile node (Mobile Node Initiated MAP Assignment) or as a network initiated reassignment.

It is also recognized that there are situations where it is beneficial to have the MAP located in the home network or other network, eg where the visited network does not provide MAP support. The MAP located in the home network can be used to solve the HA scalability problem by offloading the HA by reducing the number of binding updates to the HA during intra-domain mobility of the MAP. Fast switching can be achieved by selecting a MAP that is topographically close to the MN's location.

In the case when the MAP is located in the home network, it may be appropriate to use the AAA Home Network Server (AAAh) as an AAA infrastructure component suitable for MAP assignment. On the other hand, when the MAP is located in the visited network, it may be appropriate to use an AAA visited network server (AAAv) for MAP assignment. Actually, the location of the MAP can be in the home network, the visited network or other networks. There is no longer any mandatory dependency on router advertisements containing information about MAPs within a predetermined MAP domain.

The reliance on the AAA infrastructure offers different possibilities for directing HMIPv6 traffic compared to using a PKI infrastructure. For example, it is possible to provide extensions to common authentication protocols carried over the AAA infrastructure and/or to enhance AAA frame protocol applications.

For example, it has proven to be very beneficial to transfer HMIPv6 related information within the authentication protocol in the end-to-end procedure between the mobile node and the AAA home network server. The authentication protocol can be an extended authentication protocol based on an existing protocol or a new protocol.

One possible authentication protocol to use as the basis for bootstrapping HMIPv6 is the Extensible Authentication Protocol (EAP), creating EAP extensions while preferably keeping the EAP lower layers intact. This usually means incorporating HMIPv6 related information as additional data in the EAP protocol stack, e.g. as EAP attributes in the EAP method layer of the EAP protocol stack or conveyed in a generic container on the EAP layer or EAP method layer.

Another way to use as a supplement or alternative to EAP extensions is to enhance EAP "lower layers", such as creating new or extended AAA frame protocol applications, such as Diameter applications or RADIUS protocol-based applications suitable for HMIPv6.

When the MAP is located in the home network, it is possible, for example, to use extended authentication protocols or enhanced AAA frame protocol applications carried over the AAA infrastructure. However, when the MAP is located in the visited network, the extended EAP protocol is preferably used in conjunction with the enhanced AAA frame protocol application, or alternatively the enhanced AAA frame protocol application is used without supporting any EAP extensions.

For example, between the mobile node and the AAA client in the visited network, the extended EAP protocol can be implemented by PANA (Protocol for Bearer Network Access Authentication), PPP (Point-to-Point Protocol), IEEE 802.1X or even through GPRS/UMTS interface, and within the AAA infrastructure by Diameter or RADIUS applications.

Specifically, relying on EAP extensions provides a streamlined solution that is manageable and classy with minimal backward compatibility issues. The use of EAP enables AAA clients (and AAAv) to be agnostic to HMIPv6 procedures at least while the MAP is in the home network (i.e. this removes the reliance on the visited network's HMIPv6 support) and act only as a pass-through through) proxy. This is one of the main advantages of using EAP.

By including MIPv6 related information also in the extended authentication protocol stack or in the enhanced AAA framework protocol application, it is possible to accommodate both HMIPv6 and MIPv6 authentication and authorization in the same round trip through the AAA infrastructure. It is of course possible to use such a MIPv6/HMIPv6-enabled network and perform only HMIPv6 authentication and/or authorization without MIPv6 authentication and/or authorization, and vice versa, depending on the specific circumstances of the MN in a particular case. need. This enables a single extended authentication protocol and/or enhanced AAA framework protocol application to be flexibly used in various use cases.

The present invention provides the following advantages:

·Effectively guide HMIPv6 business;

Effectively transmit HMIPv6-related information used to authorize HMIPv6 services;

A streamlined solution based on EAP extensions for HMIPv6 support, which is easy to manage and best-in-class with minimal backward compatibility issues;

Shorten the entire HMIPv6 establishment time;

· Optimize authentication, authorization and mobility in common procedures;

AAA-based MAP designation;

The MAP location is not limited to the visited network;

MAPs can be located in the home network to address HA scalability issues, offloading HA by reducing the number of binding updates to HA during intra-domain mobility of the MAP; and

• Accommodates both HMIPv6 and MIPv6 authentication and authorization in the same round trip.

Other advantages offered by the invention will be understood when reading the following description of the embodiments of the invention.

Brief introduction to the drawings

The present invention, together with other objects and advantages thereof, may be best understood by reference to the following description taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a schematic diagram showing an example of an HMIPv6 domain of a MAP in a visited network in the prior art;

2 is a schematic diagram illustrating an innovative architecture of HMIPv6 support for a mobile node roaming in a visited network according to an exemplary embodiment of the present invention;

3 is a schematic diagram illustrating an innovative architecture of HMIPv6 support for a mobile node roaming in a visited network according to another exemplary embodiment of the present invention;

4 is a schematic diagram illustrating an innovative architecture of HMIPv6 support for a mobile node operating in its own home network according to an exemplary embodiment of the present invention;

5 is a schematic block diagram of an AAA home network server according to a preferred exemplary embodiment of the present invention;

Figure 6 is a schematic block diagram of a MAP node according to a preferred exemplary embodiment of the present invention;

Figure 7 shows an exemplary signaling flow for HMIPv6 AAA using Diameter/EAP/HMIPv6 for the case when the MAP is located in the home network;

Figure 8 shows an exemplary signaling flow for HMIPv6 AAA using Diameter/EAP/HMIPv6 in conjunction with Diameter HMIPv6 applications for the case when the MAP is located in the visited network;

Figure 9 shows an exemplary signaling flow for HMIPv6 AAA using Diameter HMIPv6 applications for the case when the MAP is located in the home network;

Figure 10 shows an exemplary signaling flow for HMIPv6 AAA using Diameter HMIPv6 applications for the case when the MAP is located in the visited network; and

Figure 11 is a schematic flow diagram of an illustrative example of a method for supporting HMIPv6 traffic for a mobile node.

Detailed ways

Throughout the drawings, the same reference signs will be used for corresponding or analogous parts.

The basic idea according to the invention is to "bootstrap" the HMIPv6 traffic of a mobile node for HMIPv6 authentication and authorization based on an AAA infrastructure instead of relying on a complex PKI infrastructure. HMIPv6 bootstrapping is valid for both a mobile node operating in a home network and a mobile node roaming in a visited network, in the former case using the home network AAA infrastructure and in the latter case using the visited The entire AAA infrastructure where the network is linked with the home network.

Instead of establishing a security association and distributing security keys between the MN and the MAP by employing a public key infrastructure (PKI), it is preferable to perform authentication and authorization of HMIPv6 services based on the AAA infrastructure, for example conveyed as HMIPv6 via the AAA infrastructure HMIPv6-related information required by services for mobile node authentication and authorization.

Instead of the conventional MAP discovery process, the AAA infrastructure is also preferably used to assign the appropriate MAP to the mobile node in response to a MAP assignment request initiated from the mobile node (Mobile Node Initiated MAP Assignment) or as a network initiated reassignment, It will be described in more detail later. There is no longer any mandatory dependency on router advertisements containing information about MAPs within a predetermined MAP domain.

AAA HMIPv6 bootstrapping is usually based on the establishment of a security association, i.e., a security relationship, between the appropriate MAP and the mobile node through the AAA infrastructure to secure the associated communication, such as HMIPv6 MAP binding that allows authentication.

In a preferred embodiment, the HMIPv6 mobility procedure including the binding update is piggybacked in the same round trip as the HMIPv6 security association procedure, thus making it possible to reduce the overall setup time by optimizing authentication, authorization and mobility in common procedures .

The term "AAA" should be taken in its ordinary meaning in Internet-Drafts, RFCs, and other standardization documents. Typically, the authentication and security key agreement of the AAA (Authorization, Authentication, Accounting) infrastructure is based on symmetric cryptography, meaning that there is a shared initial secret between the mobile node and the home network operator or trusted party. In some scenarios and applications, for example, the accounting features of the AAA infrastructure may be disabled or not implemented. The AAA infrastructure typically includes one or more AAA servers, and may also include one or more AAA clients, in the home network, intermediate network (if any) and/or visited network.

In general, AAA protocols like Diameter precisely enable mobile users to roam and obtain service in networks not necessarily owned by their home service provider. Therefore, in order to deploy Mobile IP in commercial networks, AAA support for this agreement is required. For the special case of Mobile IPv6 (MIPv6) without any hierarchical mobility management, an Internet-Draft [3] is proposed, which specifies a new application of Diameter that enables roaming in networks other than those managed by the home operator . In our US provisional patent application 60/479156 filed on June 18, 2003 and also in a later Internet-Draft [4], an architecture for performing Mobile IPv6 authorization and configuration based on an AAA infrastructure is proposed and related agreements. The necessary interaction for MIPv6 between the home provider's AAA server and the mobile node is achieved using EAP (Extensible Authentication Protocol), which transfers information for Mobile IPv6 negotiation together with the authentication data.

Fig. 2 is a schematic diagram showing an innovative architecture supported by HMIPv6 according to an exemplary embodiment of the present invention. The mobile node 130 roams in the visited network and performs HMIPv6 authentication and authorization by using the AAA infrastructure linking the visited network with the mobile node's home network. In this example, the AAA infrastructure basically involves the AAA Home Network Server 110, the AAA Visited Network Server 120 and the AAA Client 122 in the visited network.

Preferably, an AAA Visited Network Server (AAAv) 120 may be used as an AAA infrastructure component suitable for MAP assignment, taking into account the visited operator's policy when selecting a MAP. The selection of the MAP may eg be based on the current load of available MAPs, the location of the mobile node and/or preferences possibly given by the mobile node.

The main component of the AAA infrastructure is the AAAh server 110, which preferably forwards any requests for MAP assignments from the mobile node to the AAAv server 120, and also generates the Security keys or similar credentials for immediate or future security associations. The security key is then communicated from AAAh 110 to MAP 125, typically via AAAv 120, and MAP 125 responds to AAAh 110, preferably via AAAv 120, with information for completing the security association. Finally, the AAAh server 110 sends the generated and collected HMIPv6 authorization information to the mobile node 130 through the AAA infrastructure. Sensitive information such as security keys are assumed to be transmitted using secure tunneling of the AAA infrastructure or other security measures such as encryption and source integrity protection.

The reliance on the AAA infrastructure offers different possibilities for directing HMIPv6 traffic. For example, it is possible to provide a new authentication protocol or provide an extension of the authentication protocol carried by the AAA infrastructure and/or enhance the application of the AAA framework protocol to carry HMIPv6 related information, as schematically shown in FIG. 2 .

Preferably, an extended authentication protocol is used, such as an extended EAP (Extensible Authentication Protocol) protocol suitable for HMIPv6, and an enhanced AAA framework protocol application, such as for the via between the AAAh server and the visited network MAP The HMIPv6-diameter or RADIUS application for the interface of the AAAv server.

For example, between the mobile node and the AAA client in the visited network, a new or extended authentication protocol can be composed of PANA (protocol for bearer network access authentication), PPP (point-to-point protocol), IEEE 802.1X or even carried over the GPRS/UMTS interface, and within the AAA infrastructure by Diameter or similar AAA frame or bearer protocols.

Alternatively, an enhanced AAA profile application, such as a new or extended Diameter or RADIUS application, is used without supporting any EAP extensions. For the path between the mobile node and the AAA client, Diameter or RADIUS applications can be carried eg by ICMP (Internet Control Message Protocol).

It is also recognized that there are situations where it is beneficial to have the MAP located in the home network or other network, eg where the visited network does not provide MAP support. Figure 3 shows an exemplary architecture supported by HMIPv6 when the MAP is located in the home network.

It is beneficial here to use the AAA Home Network Server (AAAh) 110 for MAP assignment. Preferably, the AAA home network server (AAAh) 110 also generates a security key or similar security parameters or certificates for the security association between the mobile node and the designated MAP 125, and sends the security key to the MAP 125. MAP 125 responds to AAAh 110 with information to complete the security association, and AAAh 110 then sends MIPv6 authorization information to mobile node 130 through the AAA infrastructure.

Since the MAP 125 is located in the home network, the AAAv120 does not need to see the transaction, and it is possible to have an "end-to-end process" for HMIPv6 authentication and authorization. This is preferably achieved by using an extended authentication protocol, such as the extended EAP (Extensible Authentication Protocol) protocol for HMIPv6. Alternatively, enhanced AAA frame protocol applications such as HMIPv6 Diameter or RADIUS applications can be utilized. The MAP 125 located in the home network can also be used to solve the HA scalability problem by offloading the HA by reducing the number of binding updates to the HA 115 during intra-domain mobility of the MAP. Fast switching can be achieved by selecting a MAP that is topographically close to the MN's location.

It should be appreciated that the present invention removes the prior art limitation of requiring the MAP 125 to be located in the visited network. Now, the location of the MAP can be in the home network, the visited network or other networks. Technically, it is possible for the MN to bind with any MAP, as long as the RCoA on the MAP can be obtained by using AAA support, if the operator allows it.

Reassignment of a MAP can occur during the following exemplary situations:

• Expiration of security keys between MN and MAP - For this case, the MN initiates HMIPv6 re-authentication/authorization and the network can assign a different more appropriate MAP based eg on the current topological location of the MN.

• On mobile node request (MN initiated) - For this case, the MN initiates HMIPv6 re-authentication/authorization, requesting reassignment of the MAP.

· At network request (network-initiated) - for this case, AAAh or AAAv initiates the reassignment of the MAP and "pushes" it when the need arises, for example when the MN moves to an AR that is better covered by the new MAP. "To MN.

Referring again to Figures 2 and 3, several possible examples of different protocol combinations between segments AAA Client-AAAh and AAAh-(AAAv)-MAP are summarized below:

AAA Client<->AAAh AAAh<->(AAAv)<->MAP (i) AAA HMIPv6 Application AAA HMIPv6 Application (ii) Extended authentication protocol AAA HMIPv6 application (iii) Extended authentication protocol Extended authentication protocol

Combination (iii) is especially applicable when the MAP is located in the home network. When the MAP is located in the visited network, AAAv may be involved in selecting the MAP based on the visited network policy.

In another situation schematically shown in FIG. 4 , the mobile node 130 is actually located in the home network, and the AAA infrastructure components of the home network, such as the AAAh server 110 , provide necessary support for HMIPv6 services using the MAP 125 in the home network. This means that only the relevant parts of the extended authentication HMIPv6 protocol and the AAA HMIPv6 application need to be used to exchange the necessary authentication and authorization information.

Fig. 5 is a schematic block diagram of an AAA home network server according to a preferred exemplary embodiment of the present invention. In this example, the AAAh server 110 basically includes an optional MAP specification module 111 , a security association module 112 , an authorization information manager 113 and an input/output (I/O) interface 114 . For the case where the MAP is in the home network, the AAAh server 110 includes a MAP assignment module 111 operable to assign and/or reassign an appropriate MAP to the mobile node. For the case where the MAP is in the visited network, the AAAh server 110 typically receives the necessary MAP specifying information on its I/O interface 114 . The AAAh server typically also receives key seeds and binding updates (BUs) from the mobile node. Alternatively, the AAAh server generates the key seed itself and sends it to the mobile node. The security association module 112 preferably generates the required security key in response to the seed and securely sends the key to the MAP (either directly to the MAP in the home network or via the AAAv server to the MAP in the visited network). Binding Updates (BU) are also forwarded to the MAP. The AAAh server 110 receives the RCoA address from the MAP and stores this data in the authorization information manager 113 along with other relevant authorization (and/or configuration) information. The AAAh server may also receive information such as IPSec information from the MAP to complete the security association. Finally, the collected authorization (and/or configuration) information is transferred to the mobile node.

The AAAh Server may also be responsible for Home Address Assignment (unless the Home Address is configured by the MN itself) and/or Home Agent Assignment.

Fig. 6 is a schematic block diagram of a MAP node according to a preferred exemplary embodiment of the present invention. In this example, MAP 125 basically includes RCoA specification module 126 , security association module 127 and input/output (I/O) interface 128 . The MAP preferably interacts with the AAA Home Network Server to support establishing a security association with the mobile node. The MAP receives the security key from the AAA home network server through the I/O interface 128 for safe storage in the security association module 127 . The MAP also prepares the information necessary to complete the security association with the mobile node and sends it back to the AAA home network server, which in turn forwards it to the mobile node through the AAA infrastructure. For binding in the MAP, the RCoA module 126 preferably assigns the RCoA address to the mobile node, and stores the address together with the mobile node's LCoA address in the MAP's binding cache (not shown), and also assigns the assigned RCoA The address is sent to the AAA Home Network Server for subsequent forwarding to the Mobile Node.

In order to better understand the present invention, some more detailed examples of the extended authentication protocol of HMIPv6 and the application of the AAA framework protocol suitable for HMIPv6 will be described shortly.

Extended Authentication Protocol of HMIPv6

In the preferred exemplary embodiment, an extended authentication protocol of HMIPv6 is defined. This paper takes the new or extended EAP authentication protocol (referred to as "HMIPv6 authentication method" or "EAP/HMIPv6") as an example, which is convenient for carrying Such as discovery of MAP, dynamic allocation of MAP, dynamic allocation of RCoA, distribution of security keys between MN and MAP, and/or possible piggybacking of HMIPv6 related information for the HMIPv6 mobility process.

If desired, HMIPv6 and MIPv6 authentication and/or authorization can be integrated in the same protocol, e.g. EAP/HMIPv6 is defined as a superset of the EAP/MIPv6 protocol, in addition to the MIPv6 specific type-length-value (TLV), it also Defines new HMIP-specific TLV attributes. By including the EAP/MIPv6 TLV attributes as part of EAP/HMIPv6, it is possible to accommodate simultaneous performance of MIPv6 and HMIPv6 authentication and/or authorization in a single pass, which allows for shorter setup times. It is also possible to perform only HMIPv6 authentication and/or authorization without MIPv6 authentication and/or authorization, and vice versa, depending on the specific needs of the MN in a particular case. This enables a single EAP authentication protocol, EAP/HMIPv6, to be used flexibly in various use cases.

Specifically, relying on EAP extensions provides a streamlined solution that is manageable and classy with minimal backward compatibility issues. The use of EAP allows the AAA client (and AAAv) to be agnostic of the HMIPv6 process at least while the MAP is in the home network (ie this removes the dependency on the visited network's HMIPv6 support) and just act as a pass-through proxy. This is one of the main advantages of using EAP.

As previously indicated, between the mobile node and the AAA client in the visited network, EAP/HMIPv6 can be carried eg by PANA, PPP, ICMP, IEEE 802.1X or even over the GPRS/UMTS interface. Although, PANA may be preferred in some cases, other bearer protocols such as PPP [6] and IEEE 802.1X [7] that meet the EAP requirements for lower layer ordering guarantees can be used to carry between MNs and AAA clients EAP/MIPv6. Specifically for the case of 3GPP2 CDMA2000, between the MN and the AAA client, it is possible to use the PPP data link layer protocol encapsulation with the value of the EAP [6] protocol field set to C227 (Hex) to carry EAP/HMIPv6.

The preferred embodiment uses Diameter, RADIUS or similar AAA framework or bearer protocol for communication between the AAA client and the AAAh server. For example, the Diameter EAP application [5] can be used to encapsulate EAP/HMIPv6 within the Diameter, outside the AAA client towards the AAA infrastructure and within the AAA infrastructure, ie between the PAA/AAA client and AAAh. The Diameter protocol can also be used by AAAh to optionally assign MIP packet filters to PAA/EP and HA via MIP filter rules, which correspond to filter enhancement points. For PAA security, the Diameter protocol can also be used by the AAAh to distribute security keys to the PAA, and optionally signal QoS parameters.

It should be noted that while Diameter is preferred, sometimes it may be appropriate to use another AAA protocol like RADIUS with modifications obvious to those skilled in the art instead.

Furthermore, piggybacking HMIPv6 mobility procedures in EAP/HMIPv6 makes it possible to shorten the overall setup time by optimizing authentication, authorization and mobility in common procedures.

Demonstrate details of EAP/HMIPv6 protocol

In the following, details of the exemplary EAP/HMIPv6 protocol are provided to illustrate an example of the overall flow and the viability of concept.

EAP TLV attributes

In a first implementation example, a new set of EAP TLV attributes is defined according to EAP/HMIPv6. With these properties, besides the main IPv6 authentication information, the EAP protocol can also carry HMIPv6 related information and optionally MIPv6 related information.

For EAP/HMIPv6 different authentication protocols are possible. In the preferred embodiment, the present invention proposes the implementation of authentication via MD5 challenge, but other protocols are also within the scope of the present invention.

An exemplary summary matrix of EAP/HMIPv6 TLVs is given in Table 1 below:

EAP/HMIPv6 type-length-value source destination Purpose note HMIPv6-specific TLVs: RCoA Request EAP-TLV Attributes RCoA Response EAP-TLV Attributes RCoA EAP-TLV Attributes MAP Address Request EAP-TLV Attributes MAP Address Response EAP-TLV Attributes MAP-MN Pre-Shared Key Generation Noncurrent value EAP-TLV attribute MAP-MN pre-shared key EAP-TLV attribute MAP IKE KeyID EAP-TLV attribute MAP-MNIPScc SPI EAP-TLV attribute MAP-MNIPSec protocol EAP-TLV attribute MAP-MN IPSec Password EAP-TLV Attributes MAP-MN IPSec Key Validity EAP-TLV Attributes HMIP-Bind-Update EAP-TLV Attributes HMIP-Bind-Confirm EAP-TLV Attributes MNAAAhAAAhAAAhMNAAAhAAAhMNAAAhAAAhMAPAAAhMAPAAAhMAPAAAhMAPAAAhMNMNMAPAAAh AAAhMNMNMAPAAAhMNMNAAAhMAPMNMN via AAAhMNMN via AAAhMNMN via AAAhMNMN via AAAhMNMAP via AAAhAAAhMN via AAAhMN Request RCoA Specify RCoA Forward from AAAv RCoA Specify RCoA Request MAP Address Specify MAP Address Forward MAP Address from AAAv Seed of MN-MAP Key Specify MN-MAP Key Specify IKEKeyID Specify SPI Forward from MAP Specify IPSec Protocol Forward from MAP Specify IPSec Password Forwarding from MAP specifying IPsec key validity period Forwarding from MAP Piggybacking HMIP binding update Piggybacking HMIP binding update Piggybacking HMIP binding confirmation MAP is located in home networkMAP is located in visited networkMAP is located in home networkMAP is located in home networkMAP is located in visited networkMAP is located in home networkMAP is located in home networkMAP is located in home networkMAP is located in visited networkMAP is located in home networkMAP is located in visited networkMAP is located in visited network The MAP of the home network is located in the visited network The MAP of the home network is located in the visited network The MAP of the home network is located in the visited network The MAP of the home network is located in the visited network MIPv6-specific TLV (optional): MIPv6 home address EAP-TLV attribute HA-MN pre-shared key EAP-TLV attribute HA-MNIPSec protocol EAP-TLV attribute HA-MNIPSec password EAP-TLV attribute MIP- Bind-Update EAP-TLV Attributes MIP-Bind-Confirm EAP-TLV Attributes AAAhAAAhHAHAMNHA HAHAMN via AAAhMN via AAAhHA via AAAhMN via AAAh Specify MN home address Specify HA-MN key Specify IPSec protocol Specify IPSec password Piggyback MIP binding update Piggyback MIP binding confirmation Basic MIPv6 TLV (optional): MD5 query EAP-TLV attribute AAAh MN post inquiry

EAP/HMIPv6 type-length-value source destination Purpose note MD5 response EAP-TLV attribute MIPv6 home address request EAP-TLV attribute MIPv6 home address response EAP-TLV attribute MIPv6 home agent address request EAP-TLV attribute MIPv6 home agent address response EAP-TLV attribute HA-MN Shared key generation value EAP-TLV attribute IKE KeyID EAP-TLV attribute HA-MN IPSec SPI EAP-TLV attribute HA-MN IPSec key validity period EAP-TLV attribute PAC-PAA pre-shared key generation value EAP-TLV attribute with value MNMNAAAhMNAAAhMNAAAhHAHAMN AAAhAAAhMNAAAhMNAAAhMNMN via AAAhMN via AAAhAAAh Provide Response to Inquiry Request MN Home Address Specify MN Home Address Request HA Address Specify HA Address HA-MN Key Seed Information for Obtaining HA-MN Pre-Shared Key from AAAh Specify SPI Specify IPSec Key Validity Period PAC-PAA key seed

NOTE: IKE KeyID includes octets that tell HA/MAP how to retrieve (or generate) HA-MN pre-shared key/MAP-MN pre-shared key from AAA.

One or more of the following exemplary EAP-TLV attributes may be defined for HMIPv6:

· RCoA requests EAP-TLV attributes:

This represents a request for a dynamically assigned RCoA address for an authenticated MN. When the MN requests to be authenticated and given HMIPv6 service, it is requested by the MN from the AAAH.

RCoA response EAP-TLV attributes:

This represents the dynamically assigned RCoA address of the authenticated MN. Upon successful authentication of, for example, a MN that has requested, this is notified to the MN from the AAAh.

RCoA EAP-TLV attributes:

This represents the dynamically assigned RCoA address of the authenticated MN. Upon successful authentication of, for example, a MN that has requested, it is notified from the AAAh to the MAP to specify the RCoA address in the MAP.

MAP Address Request EAP-TLV Attributes:

This represents a request for the address of the MN's dynamically allocated MAP upon successful authentication. When the MN requests to be authenticated and given HMIPv6 service, it is requested by the MN from the AAAH. Since the HMIPv6 protocol has a dynamic MAP discovery method to allocate MAPs, this attribute is optional.

MAP address response EAP-TLV attribute:

This represents the dynamically assigned MAP address of the authenticated MN. When a MN requests to be authenticated and given HMIPv6 service, it is notified to the MN from AAAh. Since the HMIPv6 protocol has a dynamic MAP discovery method to allocate MAPs, this attribute is optional.

· MAP-MN pre-shared key generation present value EAP-TLV attribute:

This indicates an octet string randomly generated by the MN as a seed for generating a pre-shared key between MAP-MNs. By using an appropriate hashing algorithm on the combination of this nonce and the shared key between the MN and AAAh, the MN can internally generate a MAP-MN pre-shared key. This attribute is optional when a valid MAP-MN pre-shared key already exists.

· MAP-MN pre-shared key EAP-TLV attributes:

This means MAP—a dynamically generated pre-shared key between MNs. When the MN requests to be authenticated and given HMIPv6 service, it is notified to the MAP from AAAh. AAAh can internally generate a MAP-MN by using an appropriate hashing algorithm on the combination of the nonce given by the MAP-MN pre-shared key generation nonce EAP-TLV attribute and the shared key between the MN and AAAh pre-shared key. This attribute is optional when a valid MAP-MN pre-shared key already exists.

MAP IKE KeyID EAP-TLV attributes:

This represents the ID payload as defined in [8]. KeyID is generated by AAAh and sent to MN upon successful authentication. KeyID consists of octets that tell the MAP how to retrieve (or generate) the MAP-MN pre-shared key from the AAAh. This attribute is optional and is generally not required when the MN has not submitted a MAP-MN pre-shared key generation nonce, ie a valid MAP-MN pre-shared key already exists, such as during MIPv6 handover. This attribute is also not required for the case when the MAP-MN pre-shared key is transmitted by AAAh to the MAP.

MAP-MN IPSec SPI EAP-TLV attributes:

This indicates the security parameter index of IPSec between MAP-MN. For the case when the MAP-MN pre-shared key is transferred to the MAP by AAAh, this is preferably generated by the MAP and notified to the MN. This attribute is optional, and when the MN has not submitted the MAP-MN pre-shared secret to generate the nonce, that is, there is already a valid MAP--MN pre-shared key, such as during MIPv6 handover, this attribute is generally not required.

MAP-MN IPSec protocol EAP-TLV attributes:

This represents an IPSec protocol (eg ESP or AH) between MAP-MN. This is notified to the MN for the case when the MAP-MN pre-shared key is transferred by AAAh to the MAP. This attribute is optional and is generally not required when the MN has not submitted a MAP-MN pre-shared key generation nonce, ie a valid MAP-MN pre-shared key already exists, such as during MIPv6 handover.

MAP-MN IPSec password EAP-TLV attribute:

This indicates the encryption algorithm of IPSec between MAP-MN. This is notified to the MN for the case when the MAP-MN pre-shared key is transferred by AAAh to the MAP. This attribute is optional and is generally not required when the MN has not submitted a MAP-MN pre-shared key generation nonce, ie a valid MAP-MN pre-shared key already exists, such as during MIPv6 handover.

MAP--MN IPSec key validity period EAP-TLV attribute:

This indicates the key validity period of IPSec between MAP-MN. This is notified to the MN for the case when the MAP-MN pre-shared key is transferred by AAAh to the MAP. This attribute is optional, and is generally not required when the MN has not submitted the MAP--MN pre-shared key generation nonce, ie there is already a valid MAP-MN pre-shared key, such as during MIPv6 handover.

HMIP-bind-update EAP-TLV attributes:

This represents the MAP Binding Update packet generated by the MN. This is forwarded from the MN to the MAP via the AAAh in an authentication and authorization exchange. This attribute is optional and generally not required when the MN sends MAP Binding Update packets directly to the MAP.

HMIP-Binding-Confirm EAP-TLV Attributes:

This represents the MAP Binding Ack packet generated by the MAP. This is forwarded from the MAP to the MN via the AAAh in an authentication and authorization exchange. This attribute is optional and generally not required when the MAP sends the MAP Binding Ack Update packet directly to the MN.

For MIPv6-specific, the following optional EAP-TLV attributes may be defined:

· MIPv6 home address EAP-TLV attribute:

This represents the dynamically assigned MIPv6 home address of the authenticated MN. The HA is notified from the AAAh upon successful authentication of, for example, the MN that has requested, to specify the MIPv6 home address in the HA.

HA-MN pre-shared key EAP-TLV attributes:

This represents a dynamically generated pre-shared key between HA-MN. When MN requests to be authenticated and given MIPv6 service, it is notified to HA from AAAh. AAAh can internally generate the HA-MN by using an appropriate hashing algorithm on the combination of the nonce given by the HA-MN pre-shared key generation nonce EAP-TLV attribute and the shared key between the MN and AAAh pre-shared key. This attribute is optional when a valid HA-MN pre-shared key already exists.

HA-MN IPSec protocol EAP-TLV attributes:

This represents an IPSec protocol (eg ESP or AH) between HA-MNs. This is notified to the MN for the case when the HA-MN pre-shared key is transferred to the HA by AAAh. This attribute is optional, and when the MN has not submitted the HA-MN pre-shared key to generate the present value, that is, there is already a valid HA-MN pre-shared key, such as during MIPv6 handover, this attribute is generally not required.

HA-MN IPSec password EAP-TLV attribute:

This indicates the encryption algorithm of IPSec between HA-MN. This is notified to the MN for the case when the HA-MN pre-shared key is transferred to the HA by AAAh. This attribute is optional, and when the MN has not submitted the HA-MN pre-shared key to generate the present value, that is, there is already a valid HA-MN pre-shared key, such as during MIPv6 handover, this attribute is generally not required.

MIP-Binding-Update EAP-TLV Attributes:

This represents the Binding Update packet generated by the MN. This is forwarded from the MN to the HA via the AAAh in an authentication and authorization exchange. This attribute is optional and generally not required when the MN sends Binding Update packets directly to the HA.

MIP-Binding-Confirm EAP-TLV Attributes:

This represents the Binding Ack packet generated by the HA. This is forwarded from the HA to the MN via the AAAh in an authentication and authorization exchange. This attribute is optional and generally not required when the HA sends the Binding Ack packet directly to the MN.

The following EAP-TLV attributes for HMIPv6/MIPv6 authentication can be defined:

MD5 query EAP-TLV attributes:

This represents the octet string that the AAAh randomly generates and sends to the MN to implement the MD5 challenge.

MD5 response EAP-TLV attributes:

This represents the octet string generated as a result of the MD5 hash function together with the pre-shared secret key between AAAh and the MN.

For dynamic MN home address assignment, the following optional EAP-TLV attributes may be defined:

· MIPv6 home address request EAP-TLV attribute:

This represents a request for a dynamically assigned MIPv6 home address of the authenticated MN. It is requested from AAAh by the MN when it initially requests to be authenticated and given MIPv6 service. This attribute is optional when the MN already has a previously assigned home address, eg during MIPv6 handover.

MIPv6 home address response EAP-TLV attribute:

This represents the dynamically assigned MIPv6 home address of the authenticated MN. Upon successful authentication of, for example, a MN that has requested, this is notified to the MN from the AAAh. This attribute is optional when the MN already has a previously assigned home address, eg during MIPv6 handover.

For dynamic HA allocation, the following optional EAP-TLV attributes may be defined:

·MIPv6 Home Agent Address Request EAP-TLV Attributes:

This represents a request for the address of the MN's dynamically assigned HA upon successful authentication. When the MN initially requests to be authenticated and given MIPv6 service, it is requested from the AAAH by the MN. This attribute is optional when the MIPv6 protocol has a dynamic HA discovery method to assign HAs. This attribute is also optional when the MN already has a previously assigned HA, eg during MIPv6 handover.

MIPv6 Home Agent Address Response EAP-TLV Attribute:

This represents the dynamically assigned HA address of the authenticated MN. When the MN initially requests to be authenticated and given MIPv6 service, it is notified to the MN from AAAh. This attribute is optional because the MIPv6 protocol has a dynamic home agent discovery method to assign a home agent. This attribute is also optional when the MN already has a previously assigned HA, eg during MIPv6 handover.

The following optional EAP-TLV attributes may be defined to distribute security keys between HA and MN:

HA-MN pre-shared key generation present value EAP-TLV attribute:

This indicates an octet string randomly generated by the MN as a seed for generating an inter-HA-MN pre-shared key. By using an appropriate hashing algorithm on the combination of the nonce and the shared key between the MN and AAAh, the MN can internally generate the HA-MN pre-shared key. This attribute is often optional when a valid HA-MN pre-shared key already exists, eg during MIPv6 handover.

IKE KeyID EAP-TLV attribute:

This represents the ID payload as defined in [8]. KeyID is generated by AAAh and sent to MN upon successful authentication. KeyID consists of octets that tell the HA how to retrieve (or generate) the HA-MN pre-shared key from the AAAh. This attribute is optional, and when the MN has not submitted the HA-MN pre-shared key to generate the present value, that is, there is already a valid HA-MN pre-shared key, such as during MIPv6 handover, this attribute is generally not required. This attribute is also not required in the case when the HA-MN pre-shared key is transferred by AAAh to the HA via the AAAh-HA interface defined in [9].

HA-MN IPSec SPI EAP-TLV attributes:

This indicates the security parameter index of IPSec between HA and MN. For the case when the HA-MN pre-shared key is delivered by AAAh to the HA via the AAAh-HA interface defined in [9], this is generated by the HA and notified to the MN. This attribute is optional and is generally not needed when the MN has not submitted the HA-MN pre-shared key generation nonce, ie there is already a valid HA-MN pre-shared key, eg during MIPv6 handover. It is also not required when the AAAh--HA interface defined in [9] is not used.

HA-MN IPSec key validity period EAP-TLV attribute:

This indicates the key validity period of IPSec between HA and MN. For the case when the HA-MN pre-shared key is delivered by AAAh to the HA via the AAAh-HA interface defined in [9], this is generated by the HA and notified to the MN. This attribute is optional, and when the MN has not submitted the HA-MN pre-shared key to generate the present value, that is, there is already a valid HA-MN pre-shared key, such as during MIPv6 handover, this attribute is generally not required. It is also not required when the AAAh-HA interface defined in [9] is not used.

Finally, the following optional EAP-TLV attributes can be defined to distribute security keys between the PAC and PAA for PANA security:

· PAC-PAA pre-shared key generation present value EAP-TLV attribute:

This represents an octet string randomly generated by the MN/PAC as a seed for generating a pre-shared key between PAC-PAA. By using an appropriate hashing algorithm on the combination of this nonce and the shared key between the MN and AAAh, the MN/PAC can internally generate the PAC-PAA pre-shared key. This attribute is required for PANA security.

Alternatively, the AAAh server can be configured to generate not only the MN-MAP security key, but also the information needed to complete the security association.

As can be seen from the above examples, HMIPv6-related configurations are generally considered part of the entire authorization process.

EAP Generic Container Attributes (EAP GCA)

In an alternative EAP implementation, EAP is used as the bearer of HMIPv6 related information (and optionally MIPv6 information), where no new said EAP method is created, but is passed in the The implementation is carried out by carrying the information in the EAP attributes of the generic container.

In this exemplary implementation based on AAA support in the access network, EAP is supplemented with generic container attributes that can be used to carry any (perhaps non-EAP related) data, such as HMIPv6 specific data and optionally also MIPv6 specific data (if MIPv6 bootstrap is also desired). This enables the MN and AAAh to communicate in a manner transparent to the visited domain, including the access network, the AAA client and the AAAv, at least for the case of the MAP in the home network. Between the AAA client and AAA, EAP is preferably carried in an AAA protocol, eg Diameter EAP application or even RADIUS [10], [11].

This new attribute should preferably be available for all EAP methods, and can be included in any EAP message, including EAP success/failure messages. In this solution, this new generic container attribute is used to transfer HMIPv6 specific data (optionally also MIPv6 data) between the MN and the AAAh. The solution may also include a Diameter or RADIUS application for exchanging AAA and related data between the AAAh and the HA.

In the following, possible implementations of Generic Container Attributes (GCA) are discussed according to the current EAP protocol [12]. As stated, common container attributes should preferably be available to all methods, and should be possible to include in any EAP message, including EAP success/failure messages. This means it should be part of the EAP layer and not the EAP method layer [12]. The important issue is backward compatibility (this means backward compatibility in terms of MN and EAP authenticator (usually located at NAS). MN and EAP authentication server (ie AAA) are assumed to be always compatible). In these given examples, the use of GCA generally assumes that this new attribute is introduced in EAP in a backward compatible and transparent manner to the EAP authenticator. Introducing a GCA with these features requires some special considerations, discussed below.

For example, the format of a GCA may be a two-byte GCA length indicator followed by a GCA recipient indicator and a GCA payload. The GCA recipient indicator instructs the EAP module to what internal entity the received GCA's payload should be sent (ie the indicator corresponds to the protocol/next header field in the IP header or the port number in the UDP and TCP headers). The GCA payload is a generic data block that is not interpreted by the EAP layer. No GCA may preferably be indicated by setting the GCA length indicator to zero.

For backward compatibility, the GCA should preferably be included in the EAP packet in a manner transparent to the pass-through EAP authenticator. A pass-through EAP authenticator is an EAP authenticator that relays (almost all) EAP packets between the MN and the backend EAP authentication server (AAA server) (resides in the NAS; usually a WLAN AP or access router) . According to [12], the pass-through behavior of the EAP authenticator is to relay the EAP packet based on the EAP layer header, ie the code, identifier and length fields in the start position of the EAP packet. This means that if the GCA is placed after the EAP layer header (ie after the code, identifier and length fields), it is possible to achieve the desired transparency (and thus backward compatibility).

However, the EAP authenticator generally also needs to check the type field of the EAP response packet (after the EAP layer header) to identify the EAP identity response packet, and extract the NAI required for AAA routing accordingly. When the EAP authenticator recognizes the EAP Identity Response packet, it extracts the NAI from the Type-Data field following the Type field. Therefore, placing the GCA immediately after the EAP layer header (in a manner transparent to the EAP authenticator) is only possible in EAP request packets. Therefore, it is generally preferred to arrange the GCA after the type field or even after the (possibly null-terminated) type-data field.

Placing GCA immediately after the Type field allows the use of GCA in all EAP Response packets except EAP Identity Response packets. The use of GCA in EAP Identity Response packets is prohibited because from these packets the EAP authenticator needs to extract the NAI from the Type-Data field, whereas legacy EAP authenticators are expected to look for it immediately after the Type field. Considering that EAP generally has relatively few round trips, this may limit the use of GCA. Possibly, the GCA could be placed after the null-terminated Type-Data field in the EAP Identity Response packet, while maintaining its position after the Type field in other EAP packets.

It will often be desirable to have a GCA position that can be used consistently across all EAP packets. From the above discussion it appears that the place where the GCA can be placed in all EAP packets in a backward compatible manner is at the end of the packet, more or less as the tail. However, this GCA location may cause problems for those EAP packets that do not have an explicit length indicator for the type-data parameter but instead rely on the length field in the EAP layer header. In these packets, the GCA cannot be distinguished from the type-data field.

To solve this problem, the order of the GCA length indicator, GCA recipient indicator and GCA payload should be reversed so that the GCA length indicator appears last. Thus, when a GCA is placed at the end of an EAP packet, the last two octets of the EAP packet (whose length is indicated by the length field in the EAP layer header) will always be the GCA length indicator. Unless the GCA length indicator is zero, the GCA recipient indicator will appear before the GCA length indicator and the GCA payload (whose size is determined by the GCA length indicator) will precede the GCA recipient indicator. By this principle it is always possible to identify the GCA in the EAP packet and to distinguish the GCA from the type-data field. The use of GCA is still transparent to the pass-through EAP authenticator.

Backwards compatibility with this GCA solution also requires that the EAP authenticator does not attempt to extract information from the EAP request/response packet (except the EAP layer header and the NAI), and that it accepts length fields in success/failure packets indicating values greater than 4 value.

An alternative way to handle backward compatibility issues is to use EAP GCA test request/response packets (ie new EAP packets with newly defined values for the Type field) to determine whether the MN supports GCA.

Before or after the initial EAP Identity Request/Response packet exchange, the EAP Authenticator supporting GCA sends an EAP GCA Test Request packet (i.e., an EAP Request packet with a dedicated Type value) to the MN. (The EAP peer state machine in [13] indicates that both alternative send times are feasible). If the MN supports GCA, it responds with an EAP GCA Test Response packet. Otherwise, the MN interprets the EAP GCA Test-Request packet as a request to use an unknown EAP method, and thus the MN responds with an EAP Nak packet. Based on the response from the MN, the EAP authenticator can determine whether the MN supports GCA.

The MN that supports GCA can judge whether the EAP authenticator supports GCA according to whether there is an EAP GCA test request packet. The EAP authenticator supports GCA if an EAP GCA Test-Request packet is received when expected (i.e. before or after the EAP Identity Request/Response exchange). Otherwise, the EAP authenticator does not support GCA.

If both the MN and the EAP authenticator support GCA, it can be placed after the EAP layer header in all subsequent EAP packets (GCA components in original order). Otherwise, the GCA may still be included in the EAP packets that enable it to be included in a backward compatible manner (as described above).

The described alternative ways of dealing with backward compatibility issues have some limitations. First, one MN-EAP authenticator round trip is wasted. Furthermore, if the EAP GCA test request/response packets are exchanged after the initial EAP Identity Request/Response packet exchange, GCA cannot be used in the EAP Identity Response packet. This embodiment may also require the EAP authenticator (possibly the NAS) to use a modified version of EAP, such as EAPv2. Therefore, although other alternatives are possible, the preferred way of arranging the GCA in the EAP packet will generally be at the end of the packet as a trailer, with the GCA length indicator at the end, after the GCA payload and the GCA recipient indicator.

If the number of EAP round trips is not enough for the data exchanged in GCA, AAAh may increase the number of EAP round trips by EAP Notification Request/Response exchange in order to convey GCA.

Another variant actually introduces GCA in the EAP method on the method layer of the EAP protocol stack. If the GCA is made method-specific, the GCA won't introduce any backward compatibility issues, since it will normally be part of the type-data field.

Demonstration signaling flow of EAP/HMIPv6

Figure 7 shows an exemplary EAP/HMIPv6 (diameter) signaling flow for the case when the MAP is located in the home network.

The AAA client requests the MN to authenticate using the EAP (request identity), and the MN responds with the EAP (response identity).

The MN response is sent to AAAh via the AAA infrastructure. AAAh determines that the EAP/HMIPv6 method is suitable for the authentication and authorization of the MN according to the identity of the MN and based on the operator's policy (that is, AAAh knows the capabilities of the MN). The AAAh sends an indication of the proposed EAP method (eg EAP/HMIPv6) along with a query to the MN via the AAA infrastructure. The indication of the EAP method or scheme can be implemented by specifying a new EAP type number for the extended EAP scheme (eg EAP/HMIPv6). In this way, the mobile node will know which EAP scheme AAAh proposes. Alternatively, a specially formatted challenge is sent to the mobile node, which the mobile node recognizes indicates a given EAP scheme.

The MN wishes to bootstrap HMIPv6, and replies to the AAAh Proposal and Challenge with a Challenge Response with the appropriate EAP Attributes (TLV) conveying a request to specify the appropriate MAP along with the necessary information for security association with the specified MAP . During this process, the MN can also bootstrap MIPv6, if it has not been performed previously. The MN response is sent to AAAh via the AAA infrastructure. Although MAP-specific requests can actually be implicit, it is generally recommended to utilize explicit MAP-specific requests. For the case where the mobile node already knows the MAP address and can eg just update the security association with the MAP, there will be no MAP assignment request but only re-authentication and/or re-authorization.

The AAAh verifies the MN's challenge response, and if successful, this means the MN is authentic, and the AAAh then proceeds to process other requests of the MN.

First, the AAAh selects a MAP in the home network and sends an enhanced EAP (note that this is an EAP session different from an already ongoing EAP session between the MN and AAAh) message to the MAP, and the MAP preferably Respond to the AAAh by providing information (if needed or otherwise appropriate) for completing the security association with the MN. For example, for IPSec security associations, it may be necessary to utilize EAP attributes such as the IPSec protocol, IPSec cipher, IPSec key validity period EAP TLV attributes defined in Table 1 above.

In this and the following illustrative examples, it is assumed that the mobile node (MN) and AAAh have a common shared secret. This could eg be a symmetric key shared between the identity module installed in the mobile node and the home network operator. The identity module can be any tamper-resistant identity module known in the art, including standard SIM cards used in GSM (Global System for Mobile Communications) mobile phones, Universal SIM (USIM), WAP (Wireless Application Protocol) SIM also known as WIM , ISIM (IP Multimedia Subsystem Identity Module) and more generally UICC (Universal Integrated Circuit Card) module. For the MN-MAP (MN-HA) security association, the MN can transmit the seed or nonce to the AAA (or from the opposite direction, that is, the AAAh initiates the seed and transmits it to the MN), and the AAAh can create the MN based on the shared secret - MAP (MN-HA) security key. The mobile node can generate the same security key on its own, since it originates the seed/nonce (or receives the seed from AAAh) and also has the shared secret. Alternatively, the AAAh can generate the security information itself and transmit it securely to the relevant nodes.

Second, if MIPv6 bootstrap is requested, AAAh selects an HA to continue servicing this MIPv6 bootstrap request by using another enhanced EAP session, and the HA responds to AAAh by providing the information required to create a security association with the MN. Optionally, it is possible to piggyback "MAP Binding Update" and "HA Binding Update" in the authentication and authorization exchange. This means that the HMIPv6 binding is integrated in the same round trip as the MN-MAP security association (only LCoA is required in the binding update from the mobile node). For this case, the HMIPv6 RCoA obtained by the AAAh in the first operation with the MAP is automatically the updated MIPv6 binding in the second operation with the HA.

After AAAh communicates with MAP and HA as described above, AAAh sends authorization (and/or configuration) information such as MAP address, RCoA, HA address, MN home address and security association information and authentication success indication back to MN via extended EAP . The extra last round trip exchanged in Figure 7 is to ensure a smooth implementation of the EAP protocol according to the current EAP protocol specification.

Figure 8 shows an exemplary EAP/HMIPv6 (diameter) signaling flow for the case when the MAP is located in the visited network.

The AAA client requests the MN to authenticate using the EAP (request identity), and the MN responds with the EAP (response identity).

The MN response is sent to AAAh via the AAA infrastructure. AAAh determines that the EAP/HMIPv6 method is suitable for the authentication and authorization of the MN according to the identity of the MN and based on the operator's policy (that is, AAAh knows the capabilities of the MN). AAAh sends an indication of the proposed EAP method (ie EAP/HMIPv6) to the MN along with a query via the AAA infrastructure.

The MN wishes to bootstrap HMIPv6, and replies to the AAAh Proposal and Challenge with a Challenge Response and appropriate EAP Attributes (eg TLV) that convey a request to specify the appropriate MAP along with the necessary information for security association with the specified MAP. During this process, the MN can also bootstrap MIPv6, if it has not been performed previously. The MN response is sent to AAAh via the AAA infrastructure.

The AAAh verifies the MN's challenge response, and if successful, this means the MN is authentic, and the AAAh proceeds to process other requests of the MN.

First, the AAAh forwards the request for the MAP in the visited network to the appropriate AAAv, preferably via the Diameter application (referred to simply as the Diameter HMIPv6 application). The reason for this is that the visited operator's policy needs to be taken into account when choosing a MAP in the visited network, and thus the AAAv needs to be able to see the transaction (in the EAP case these exchanges are end-to-end, so this is not possible ). The AAAv selects a MAP in the visited network and forwards the Diameter HMIPv6 Application message containing eg a security key to the MAP. The MAP preferably responds to the AAAh by providing information (if needed or otherwise appropriate) to complete the security association with the MN. Second, if such a request exists, the AAAh selects an HA to continue servicing this MIPv6 bootstrap request by using another enhanced EAP session, and the HA responds to the AAAh by providing the information needed to create a security association with the MN. Note that it is possible to piggyback "MAP Binding Updates" as well as "HA Binding Updates" in the authentication and authorization exchanges. For this case, the HMIPv6 RCoA obtained by the AAAh in the first operation with the MAP is automatically the updated MIPv6 binding in the second operation with the HA.

After AAAh communicates with MAP and HA as described above, AAAh sends authorization (and/or configuration) information such as MAP address, RCoA, HA address, MN home address and security association information and authentication success indication back to MN via extended EAP . The extra last round trip exchanged in Figure 8 is to ensure a smooth implementation of the EAP protocol according to the current EAP protocol specification.

Although some detailed exemplary embodiments are primarily discussed with reference to the current EAP version, it should be understood that the present invention is well suited to other EAP versions, such as EAPv2, and other authentication protocols extended or configured in the manner described. EAP is only an example of possible implementations, and the invention is generally not limited thereto, but may alternatively relate to non-EAP schemes.

Application of AAA Framework Protocol in HMIPv6

In another exemplary embodiment, a new AAA framework protocol application is created. This paper takes the diameter application suitable for HMIPv6 (referred to as "diameter HMIPv6 application") as an example. Distribute security keys and/or possibly piggyback HMIPv6 related information for HMIPv6 mobility procedures among RCoA, MN and MAP. Although diameter is referred to below, it should be understood that RADIUS or other similar AAA framework protocols can also be used as the basis for new or extended HMIPv6 applications.

HMIPv6 and MIPv6 authentication and/or authorization can be integrated in the same AAA frame protocol application if desired. This can be achieved by adopting the Diameter MIPv6 application described in [3] and additionally defining new HMIP-specific command codes, AVPs and/or flags. By including the command codes, AVPs and flags of the Diameter MIPv6 application as part of the Diameter HMIPv6 application, simultaneous execution of MIPv6 and HMIPv6 authentication and/or authorization is accommodated in a single pass allowing for shorter setup times. It is also possible to perform only HMIPv6 authentication and/or authorization without MIPv6 authentication and/or authorization, and vice versa, depending on the specific needs of the MN in a particular situation. This enables a single application (diameter HMIPv6 application) to be used flexibly in various use case scenarios.

Furthermore, piggybacking HMIPv6 mobility procedures in Diameter HMIPv6 applications makes it possible to shorten the overall setup time by optimizing authentication, authorization and mobility in common procedures.

Diameter HMIPv6 Application Details

In the following, details of a demonstration diameter HMIPv6 application are provided to illustrate an example of the overall flow and the feasibility of the concept. Preferably, new HMIP-specific command codes, AVPs and/or flags are defined which carry HMIPv6 to facilitate e.g. discovery of MAPs, dynamic allocation of MAPs, dynamic allocation of RCoA, distribution of security keys between MNs and MAPs and/or possible piggybacking of HMIPv6 Information on the mobility process. The command codes, AVPs and flags of the Diameter MIPv6 Application [3] may optionally be included as part of the Diameter HMIPv6 Application.

An exemplary summary matrix of Diameter HMIPv6 application command codes and AVPs is given in Table 2 below:

Diameter HMIPv6 Application Command Codes and AVPs source destination Purpose note HMIPv6 specific command codes: MAP-HMIPv6-Request Command (MAR)MAP-HMIPv6-Answer Command (MAA) AAAhAAAhMAPMAP MAPMAP via AAAvAAAhAAAh via AAAv Exchange of HMIP AVP Exchange of HMIP AVP Exchange of HMIP AVP Exchange of HMIP AVP The MAP is located on the home network The MAP is located on the visited network The MAP is located on the home network The MAP is located on the visited network HMIPv6-specific AVPs: HMIP-bind-update AVPHMIP-bind-confirm AVPRCoAAVPMAP-address AVPHMIPv6-features-vector AVPMAP-request-flags AVPMAP-MNIPSec SPI AVPMAP-MN IPSec Protocol AVPMAP-MN IPSec Password AVPMAP-MN IPSec Key Validity AVP HMIP binding update message sent by MN to MAP HMIP binding confirmation sent by MAP to MN RCoAMAP address pair dynamic MAP specified request MN-MAP key seed specified MN-MAP key specified IKEKeyID specified SP1 specified IPSec protocol specified IPSec password specifies the validity period of the IPSec key Existing Diameter MIPv6 Application Command Codes: AA-Registration-Request Command (ARR) AA-Registration-Response Command (ARA) Home-Proxy-MIPv6-Request Command (HOR) Home-Proxy-MIPv6 Answer Command (HOA) AAA Client AAAhAAAhHA AAAh (via AAAv) AAA client (via AAAv) HAAAAh Existing Diameter MIPv6 Application AVP: mip-binding-update avpmip-binding-confirm-avpmipv6-mobile-node-address avpmipv6-home-proxy-address avpmipv6-feature-vector AVP home-proxy-request-flags Mobile IP Binding Update message sent by MN to HA Mobile IP Binding Acknowledgment message sent by HA to MN Home Address of Mobile Node Home Agent Address of Mobile Node Request for Dynamic Home Agent Assignment

For additional information, Internet-Draft [5] defines the command codes and AVPs required to carry EAP packets between a Network Access Server (NAS) and a backend authentication server.

Demonstration signaling flow for Diameter HMIPv6 application

Figure 9 shows an exemplary Diameter HMIPv6 application signaling flow for the case when the MAP is located in the home network.

The AAA client issues a challenge to the MN to be authenticated via a protocol such as Internet Control Message Protocol (ICMP), PANA, and the like. The MN responds with a Challenge Response and possibly a MIPv6 Bootstrap Request.

The AAA Client understands HMIPv6 and MIPv6 Bootstrap Requests and forwards MN responses to AAAh via the AAA infrastructure using the Diameter HMIPv6 Application Command Code (ARR). In this process, the AAA client also includes a query that allows the AAAh to verify the authenticity of the MN.

The AAAh verifies the MN's challenge response, and if successful, this means the MN is authentic, and the AAAh then proceeds to process other requests of the MN.

First, the AAAh selects the MAP in the home network and sends the appropriate Diameter HMIPv6 Application Command Code (MAR) containing e.g. Security Association information (if required or otherwise appropriate) in response to the AAAh. Second, if MIPv6 bootstrapping is requested, the AAAh selects the HA to continue servicing the MIPv6 bootstrap request by using the Diameter HMIPv6 Application command code ((HOR)), and the HA passes the command code (HOA) by providing the HA required to create a security association with the MN. information to respond to AAAh. Note that it is possible to piggyback "MAP Binding Updates" as well as "HA Binding Updates" in the authentication and authorization exchanges. For this case, the HMIPv6 RCoA obtained by the AAAh in the first operation with the MAP is automatically the updated MIPv6 binding in the second operation with the HA.

After AAAh communicates with MAP and HA as described above, AAAh will authorize (and/or configure) information such as MAP address, RCoA, HA address, MN home address and The security association information and the successful authentication indication are sent back to the MN.

Figure 10 shows an exemplary Diameter HMIPv6 application signaling flow for the case when the MAP is located in the visited network.

The AAA client issues a challenge to the MN to be authenticated via eg ICMP or PANA. The MN responds with a Challenge Response and possibly a MIPv6 Bootstrap Request.

The AAA Client understands HMIPv6 and MIPv6 Bootstrap Requests and forwards MN responses to AAAh via the AAA infrastructure using the Diameter HMIPv6 Application Command Code (ARR). In this process, the AAA client also includes a query that allows the AAAh to verify the authenticity of the MN.

The AAAh verifies the MN's challenge response, and if successful, this means the MN is authentic, and the AAAh then proceeds to process other requests of the MN.

First, the AAAh forwards the request for the MAP in the visited network to the appropriate AAAv, preferably via the Diameter HMIPv6 Application Order Code (MAR). AAAv selects a MAP in the visited network and forwards to the MAP a command code (MAR) including, for example, a security key, and the MAP preferably uses the command code (MAA) by providing information for completing a security association with the MN (if is required or otherwise appropriate) to respond to AAAh via AAAv. Second, if requested, the AAAh selects an HA to continue servicing this MIPv6 Bootstrap Request by using the Diameter HMIPv6 Application Order Code (HOR), and the HA proceeds via the order code (HOA) by providing the information required to create a Security Association with the MN Respond to AAAh. Note that it is possible to piggyback "MAP Binding Updates" as well as "HA Binding Updates" in the authentication and authorization exchanges. For this case, the HMIPv6 RCoA obtained by the AAAh in the first operation with the MAP is automatically the updated MIPv6 binding in the second operation with the HA.

After AAAh communicates with MAP and HA as described above, AAAh will authorize (and/or configure) information such as MAP address, RCoA, HA address, MN home address via Diameter HMIPv6 Application Command Code (ARA) and protocols such as ICMP or PANA and the security association information and the successful authentication indication are sent back to the MN.

Summarizing some of the above aspects, it can be seen that the reliance on the AAA infrastructure provides several possibilities for directing HMIPv6 traffic. For example, it is possible to provide extensions and/or enhancements to common authentication protocols carried over the AAA infrastructure (such as current or future EAP versions) and/or enhancements to AAA frame protocol applications such as DIAMETER and RADIUS applications.

Fig. 11 is a schematic flowchart of a basic example of a method for supporting HMIPv6 services of a mobile node. In this example, the information transfer and operations shown in steps S1-S4 involve authentication of the mobile node (S1), establishment of MN-MAP security association (S2), HMIPv6 configuration (S3) and HMIPv6 binding (S4). Steps S2-S3 are collectively referred to as the authorization phase. If desired, steps S1-S4 can be performed in a more or less parallel manner, eg piggybacking the HMIPv6 binding in the same round trip as the HMIPv6 security association process, so that the overall setup time can be shortened. In step S1, information is transmitted through the AAA infrastructure to authenticate the mobile node at the home network side. In step S2, HMIPv6-related information is transmitted to immediately establish or allow future establishment of a security association between the MN and the MAP. In step S3, additional HMIPv6 configuration is performed, for example by transferring configuration parameters to the mobile node for suitable storage therein. In step S4, the mobile node sends a binding update and establishes HMIPv6 binding in the MAP.

In other fields of application, the invention is applicable to all access networks such as WLAN, CDMA2000, WCDMA, etc., where HMIPv6 and optionally also MIPv6 can be used, including technologies such as AAA and IPv6 mobility, such as CMS11, WCDMA and GSM systems, subsystems such as service/application subsystems and terminals, and products such as AAA servers, home agent servers, and terminal nodes.

As an alternative to the above example procedure of MN-HA key distribution, a mechanism similar to the current 3GPP2 solution combined with the IKE framework can be used to distribute the dynamic pre-shared keys of the MN and HA.

The above-mentioned embodiments are given as examples only, and it should be understood that the present invention is not limited thereto. Furthermore, other modifications, changes and improvements which retain the basic underlying principles disclosed and claimed herein are within the scope of the invention.

references

[1] "Mobility Support in IPv6", D.Johnson, C.Perkins, J.Arkko, June 30, 2003, <draft-ietf-mobileip-ipv6-24.txt> .

[2] "Hierarchical Mobile IPv6 mobility management (HMIPv6)", Hesham Soliman, Claude Castelluccia, Karim El-Malki, Ludovic Bellier, June 2003, <draft-ietf-mobileip-hmipv6-08 .txt>.

[3] "Diameter Mobile IPv6 Application", Stefano M.Faccin, Franck Le, Basavaraj Patil, Charles E.Perkins, April 2003, <draft-le-aaa-diameter-mobileipv6-03. txt>.

[4] "EAP-based MIPv6 authorization and configuration (MIPv6 Authorization and Configuration based on EAP)", G.Giaretta, I.Guardini, E.Demaria, February 2004, <draft-giaretta-mip6-authorization-eap-00 .txt>.

[5] "Diameter Extensible Authentication Protocol (EAP) application", P.Eronen, T.Hiller, G.Zorn, February 16, 2004, <draft-ietf-aaa-eap-04 .txt>.

[6] "PPP Extensible Authentication Protocol (EAP)", RFC2284, L.Blunk, J.Vollbrecht, March 1998.

[7] IEEE Standard 802.1X, Local and Metropolitan Area Networks - Port-Based Network Access Control.

[8] "Internet Security Association and Key Management Protocol (Internet SecurityASSociation and Key Management Protocol) (ISAKMP)", RFC2408, D.Maughan, M.Schertler, M.Schneider, J.Turner, November 1998.

[9] "Diameter Mobile IPv4 Application", P.Calhoun, T.Johansson, C.Perkins, 2003, <draft-ietf-aaa-diameter-mobileip-14.txt>.

[10] "Remote Authentication Dial In UserService (RADIUS)" - RFC2865, C. Rigney, S. Willens, A. Rubens, W. Simpson, June 2000.

[11] "RADIUS Extensions" - RFC2869, C. Rigney, W. Willats, P. Calhoun, June 2000.

[12] "Extensible Authentication Protocol (EAP)" - RFC2284, L.Blunk, J.Vollbrecht, B.Aboba, J.Carlson, H.Levkowetz, September 2003, <draft-ietf -eap-rfc2284bis-06.txt>.

[13] "State Machines for EAP Peer and Authenticator", J.Vollbrecht, P.Eronen, N.Petroni, Y.Ohba, October 2003 <draft-ietf-eap -statemachine-01.pdf>.

Claims (20)

1. A method for supporting mobile nodes' hierarchical mobile IP 6th edition (HMIPv6) service, characterized in that, using the AAA infrastructure to guide the HMIPv6 service, comprising: assigning an appropriate Mobility Anchor Point (MAP) to the mobile node by the AAA infrastructure for the HMIPv6 service; and transmitting HMIPv6-related information required for authenticating and authorizing the mobile node for the HMIPv6 service by using the specified MAP through the AAA infrastructure, It is characterized in that the AAA infrastructure component of the home network generates certificate-related data of the security association between the mobile node and the specified MAP, and sends the certificate-related data to the MAP, and the AAA infrastructure belongs to The network component generates the information for completing the security association or the MAP responds to the AAA infrastructure home network component with the information for completing the security association, wherein the AAA infrastructure home network component passes the HMIPv6 authorization information through The AAA infrastructure is sent to the mobile node. 2. The method of claim 1, wherein, for the HMIPv6 service, an AAA server of the AAA infrastructure assigns an appropriate MAP to the mobile node. 3. The method of claim 2, wherein the mobile node roams in a visited network, and an AAA visited network server (AAAv) in the visited network based on the policy of the visited network operator A MAP is assigned to the mobile node. 4. The method of claim 1, wherein the AAA infrastructure for establishing an HMIPv6 security association between the mobile node and the specified MAP and for establishing an HMIPv6 security association for the mobile node are transmitted through the AAA infrastructure. HMIPv6 related information for the binding, and the HMIPv6 related information for the HMIPv6 binding is transmitted in the same round trip as the HMIPv6 related information for the HMIPv6 security association. 5. The method according to claim 1, characterized in that said mobile node roams in a visited network, and in that said mobile node is transparent to said visited network between said mobile node and an AAA home network server (AAAh). HMIPv6-related authentication and authorization information is transmitted in the authentication protocol during the end-to-end process. 6. The method according to claim 5, wherein the authentication protocol is an extended Extensible Authentication Protocol (EAP), and the HMIPv6 related information is incorporated in the EAP protocol stack as additional data. 7. The method according to claim 6, wherein the HMIPv6 related information is transmitted in a general container in the EAP protocol stack. 8. The method of claim 5, wherein the designated MAP is located in the visited network, and the authentication is performed between the mobile node and the AAA home network server (AAAh). The HMIPv6-related information is transmitted within the protocol, and the HMIPv6-related information is transmitted within the application of the AAA framework protocol between the AAAh and the designated MAP in the visited network. 9. A system for supporting the Hierarchical Mobile IP version 6 (HMIPv6) service of a mobile node, characterized in that: an AAA infrastructure component operable to assign an appropriate Mobility Anchor Point (MAP) to said mobile node for said HMIPv6 traffic; and means for transmitting HMIPv6-related information required to authenticate and authorize the mobile node for HMIPv6 services via the AAA infrastructure using the specified MAP, The AAA infrastructure components of the home network include: means for generating certificate-related data for a security association between said mobile node and a designated MAP; and means for sending said credential-related data to a designated MAP; means for receiving information from the MAP to complete the security association; and means for sending HMIPv6 authorization information to the mobile node through the AAA infrastructure. 10. The system of claim 9, wherein the AAA infrastructure component is an AAA server operable to assign an appropriate MAP for the HMIPv6 traffic to the mobile node. 11. The system of claim 10, wherein the mobile node is roaming in a visited network, and the AAA visited network server (AAAv) is operable to operate in the visited network based on a policy of the visited network operator. A MAP is assigned to the mobile node in the visited network. 12. The system according to claim 9, characterized in that, for transmitting through the AAA infrastructure for establishing a HMIPv6 security association between the mobile node and the designated MAP and for the mobile node means for establishing the HMIPv6-related information for the HMIPv6 binding, and transmitting the HMIPv6-related information for the HMIPv6 binding in the same round trip as the HMIPv6-related information for the HMIPv6 security association. 13. The system of claim 9, wherein the mobile node roams in a visited network, and the communication between the mobile node and an AAA home network server (AAAh) is transparent to the visited network HMIPv6-related authentication and authorization information is transmitted in the authentication protocol during the end-to-end process. 14. The system of claim 13, wherein the authentication protocol is an extended Extensible Authentication Protocol (EAP), and the HMIPv6 related information is incorporated as additional data in the EAP protocol stack. 15. The system according to claim 14, wherein the HMIPv6-related information is transmitted in a general container in the EAP protocol stack. 16. The system of claim 13, wherein the designated MAP is located in the visited network and in the authentication protocol between the mobile node and an AAA home network server (AAAh) Transmitting HMIPv6-related information, and transmitting HMIPv6-related information within an AAA framework protocol application between the AAAh and the designated MAP in the visited network. 17. A AAA home network server (AAAh) for supporting the hierarchical mobile IP version 6 (HMIPv6) service of a mobile node, characterized in that: means for generating certificate-related data for a security association between said mobile node and a Mobility Anchor Point (MAP) specified by an AAA infrastructure component; and means for sending said credential-related data to a designated MAP; means for receiving information from the MAP to complete the security association; and Means for sending HMIPv6 authorization information including security association information to the mobile node. 18. The AAA home network server according to claim 17, wherein said mobile node roams in a visited network, and said means for sending HMIPv6 authorization information is operable to pass said visited The AAA infrastructure of the network linked to the mobile node's home network sends the HMIPv6 authorization information. 19. The AAA home network server according to claim 18, wherein the AAA home network server is configured to receive information and binding address information for completing the security association from the specified MAP, and the The means for sending HMIPv6 authorization information through the AAA infrastructure is configured to send HMIPv6 authorization information including MAP specification information, binding address information and security association information to the mobile node. 20. A system for supporting Hierarchical Mobile IP Version 6 (HMIPv6) services of a mobile node, characterized in that it is used for extensible authentication between the mobile node and the AAA home network server through the AAA infrastructure The protocol (EAP) transmits HMIPv6-related authentication and authorization information to authenticate and authorize the mobile node for HMIPv6 services, and the HMIPv6-related information is combined in the EAP protocol stack as additional data.

Images