Abstract:
The present application relates to network mobility (e.g., mobility in an IPv6 network). More specifically, the present application discloses systems and methods for enabling mobile nodes to switch to a routing optimization mode using a minimum of mobility messages.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application claims the benefit of U.S. Provisional Patent App. No. 61/224,610, filed on Jul. 10, 2009, and U.S. Provisional Patent App. No. 61/221,219, filed on Jun. 29, 2009. The above identified applications are incorporated by reference herein. 
    
    
     TECHNICAL FIELD 
     The present invention relates to the field of communications, and more particularly, to an enhancement for mobile IP route optimization. 
     BACKGROUND 
     Request for Comment (RFC) 3775, which is incorporated by reference herein, specifies a protocol which allows mobile nodes to remain reachable while moving around in the IPv6 Internet. Without specific support for mobility in IPv6, packets destined to a mobile node would not be able to reach the node while it is away from its home link. Mobility support is particularly important, as mobile computers are likely to account for at least a substantial fraction of the population of the Internet during the lifetime of IPv6. 
     The protocol defined in RFC 3775, which is known as Mobile IPv6, allows a mobile node to move from a home link to another link without changing the mobile node&#39;s “home address” (HoA). Packets may be routed to the mobile node using this address regardless of the mobile node&#39;s current point of attachment to the Internet. Accordingly, a mobile node is always expected to be reachable at its home address, whether it is currently attached to its home link or is away from home. The “home address” is an IP address assigned to the mobile node within its home subnet prefix on its home link. While a mobile node is at home, packets addressed to its home address are routed to the mobile node&#39;s home link, using conventional Internet routing mechanisms. 
     While a mobile node is attached to some foreign link away from home, it is also addressable at one or more “care-of addresses.” A care-of address (“CoA”) is an IP address associated with a mobile node that has the subnet prefix of a particular foreign link. The mobile node can acquire its care-of address through conventional IPv6 mechanisms, such as stateless or stateful auto-configuration. As long as the mobile node stays in this location, packets addressed to this care-of address will be routed to the mobile node. 
     The association between a mobile node&#39;s home address and care-of address is known as a “binding” for the mobile node. While away from home, a mobile node registers its primary care-of address with a “home agent” (e.g., a router or other node) on its home link. The mobile node performs this binding registration by sending a “Binding Update” message to the home agent. The home agent may reply to the mobile node by returning a “Binding Acknowledgement” message. 
     Any node communicating with a mobile node is referred to in this document as a “correspondent node”, and may itself be either a stationary node or a mobile node. 
     When a mobile node is away from its home (i.e., connected to a foreign link), there are two possible modes for communications between the mobile node and a correspondent node. The first mode is referred to as the “bidirectional tunneling” mode. In the bidirectional tunneling mode, packets from the correspondent node to the mobile node are routed to the mobile node&#39;s home agent and then tunneled by the home agent to the mobile node. Similarly, packets from the mobile node to the correspondent node are tunneled from the mobile node to the home agent (“reverse tunneled”) and then routed normally from the home agent to the correspondent node. 
     The second mode is referred to as the “route optimization” (RO) mode. In the route optimization mode, packets from the correspondent node to the mobile node can be routed directly to the care-of address of the mobile node. Routing packets directly to the mobile node&#39;s care-of address allows the shortest communications path to be used. It also may reduce congestion at the mobile node&#39;s home agent and home link. When routing packets directly to the mobile node, the correspondent node sets the Destination Address in the IPv6 header to the care-of address of the mobile node. A new type of IPv6 routing header is also added to the packet to carry the mobile nodes home address. Similarly, the mobile node sets the Source Address in the packet&#39;s IPv6 header to its current care-of addresses. The mobile node adds a new IPv6 “Home Address” destination option to carry its home address. The inclusion of home addresses in these packets makes the use of the care-of address transparent at the transport layer. 
     In order for a mobile node and a corresponding node to enter the RO mode, the correspondent node must have an association between the mobile node&#39;s home address and CoA and the mobile node and corresponding node must perform a “return routability” (RR) procedure. The RR procedure consists of exchanging four mobility signaling messages between the mobile node (MN) and correspondent node (CN) in order to test the MN&#39;s reachability on the claimed care-of address (CoA) and its home address and to generate a shared secret between the two nodes which is then used to authenticate a binding update (BU) and binding acknowledgment (BA) messages. It follows that successfully entering the RO mode requires in total six mobility messages, and, if we take into consideration that the MN needs first to update its home agent (HA) prior to triggering the RR procedure, then the total number of signaling messages would reach eight. 
     It becomes clear from the above that exchanging eight signaling messages each time the MN and a CN enter the RO mode may incur a significant data packet loss and/or delay. A further drawback is that the MN must repeat the RR procedure every 420 seconds due to security concerns. Furthermore, if the MN is having multiple sessions with different CNs then it has to repeat the RR which each CN, which in turn may severely impact the MN&#39;s power consumption. 
     SUMMARY 
     An objective of the invention is to overcome at least some of the above described RO mode disadvantages. In one aspect, this is achieved by providing an improved procedure for entering the RO mode that requires fewer signaling messages than the conventional RO mode procedures. Because fewer signaling messages are used, handoff latency decreases as well as mobile node power consumption. 
     Accordingly, in one aspect, the present invention provides a method for route optimization that does not require a return routability procedure. In one embodiment, the method begins with a mobile node&#39;s home agent (HA) receiving an update message transmitted from the mobile node. This update message includes a care-of-address (CoA) associated with the mobile node. In response to receiving the update message from the mobile node, the home agent binds the CoA associated with the mobile node with a home address (HoA) assigned to the mobile node. After receiving the update message, the home agent transmits a second update message to: (a) a correspondent node or (b) the correspondent node&#39;s home agent. The update message transmitted from the home agent includes the CoA associated with the mobile node and the HoA assigned to the mobile node. In this manner, a correspondent node can obtain the mobile node&#39;s CoA without the mobile node and the correspondent node having to perform the RR procedure. 
     In some embodiments, the correspondent node is a mobile node and the correspondent node has the same home agent as the first recited mobile node (MN). In such an embodiment, the method may also include the step of receiving, at the home agent, an update message transmitted from the correspondent node. This update message includes a CoA associated with the correspondent node. In response to receiving this update message, the home agent binds the CoA associated with the correspondent node with a HoA assigned to the correspondent node (CN). Preferably, the home agent does not transmit the second recited update message until after it receives the update message transmitted from the CN. 
     In some embodiments, the home agent (HA) determines whether there is a relationship between the MN and the CN after receiving the update message transmitted from the CN. In response to determining that there is a relationship between the MN and CN, the HA transmits to the MN the CoA associated with the CN and transmits to the CN the CoA associated with the MN. In some embodiments, the step of determining whether there is a relationship between the MN and the CN comprises determining whether there is a cryptographic relationship between the MN and the CN. 
     In some embodiments, the update message transmitted from the MN comprises a modifier value obtained from the CN and an address generated by the CN. The modifier value may be calculated by the CN by hashing a public key belonging to the MN with a random number. The update message transmitted from the CN may include a modifier value obtained from the MN and an address generated by the MN. The modifier value may be calculated by the MN by hashing a public key belonging to the CN with a random number. 
     In other embodiments, the CN is a mobile node but has a different HA than the first recited mobile node and the second recited update message is transmitted from the MN&#39;s HA to the CN&#39;s HA. In this embodiments, the method may also include receiving at the MN&#39;s HA a message comprising a CoA associated with the CN, wherein the message including the CoA associated with the CN was transmitted to the MN&#39;s HA from the CN&#39;s HA. In some embodiments, the MN&#39;s HA transmits to the MN a message comprising the CoA associated with the CN in response to receiving the message containing the CoA associated with the CN. In response to receiving the message from the MN&#39;s HA, the MN may add to its binding update list a record comprising the CoA associated with the CN. 
     In some embodiments, the HA, prior to transmitting the update message to the CN, transmits to the CN a message (e.g., a Neighbor Solicitation message). In response, the CN transmits a message back to the HA. Preferably, at least some of the information included in the message sent back to the HA from the CN depends on whether the CN has a relationship with the MN. The HA, upon receiving the message from the CN, uses information contained in the message to determine whether there is a trusted relationship between the MN and the CN. The HA is configured such that the HA will transmit the update message to the CN if and only if the HA determines that there is a trusted relationship between the MN and the CN. The information contained in the message transmitted from the CN to the HA in response to the solicitation message may include (i) parameters associated with the mobile node (e.g., an encrypted shared secret, the MN&#39;s public key, information signed using the MN&#39;s private key) and (ii) a secret that is used by the HA to encrypt information included in the update message transmitted from the HA to the CN. 
     In some embodiments, the mobile node has a home link, the correspondent node is a node with which the mobile node is communicating, and the home agent comprises a router on the mobile node&#39;s home link. After the mobile node connects to a foreign link and provides a CoA to the router, the router may (a) intercept packets on the home link destined to the mobile node&#39;s home address, and tunnel the intercepted packets to the mobile node&#39;s CoA. 
     In another aspect, the present invention provides an apparatus for facilitating mobile IP route optimization (RO). In some embodiments, the apparatus includes a network interface operable to receive from a mobile node an update message comprising a care-of-address (CoA) associated with the mobile node. The apparatus also includes a data processing system configured to (1) bind the CoA associated with the mobile node with a home address (HoA) assigned to the mobile node in response to receiving the update message and (2) transmit to (i) a correspondent node or (ii) the correspondent node&#39;s home agent a second update message comprising the CoA associated with the mobile node and the home address assigned to the mobile node after receiving the first update message. In this manner, the apparatus facilitates mobile IP route optimization by informing the correspondent node of the mobile node&#39;s CoA. 
     The above and other aspects and embodiments are described below with reference to the accompanying drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments of the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the pertinent art to make and use the invention. In the drawings, like reference numbers indicate identical or functionally similar elements. 
         FIG. 1  illustrates a MN in communicate with a CN while the MN is connected to an internet via its home link. 
         FIG. 2  illustrates the MN in communicate with the CN while the MN is connected to the internet via a foreign link. 
         FIG. 3  is a flow chart illustrating a process, according to a first embodiment of the invention, for performing an RO procedure. 
         FIG. 4  is a message flow diagram illustrating the RO procedure of  FIG. 3 . 
         FIG. 5  is a flow chart illustrating a process, according to a second embodiment of the invention, for performing an RO procedure. 
         FIG. 6  is a message flow diagram illustrating the RO procedure of  FIG. 5 . 
         FIG. 7  is a flow chart illustrating a process, according to a third embodiment of the invention, for performing an RO procedure. 
         FIG. 8  is a message flow diagram illustrating the RO procedure of  FIG. 7 . 
         FIG. 9  is a flow chart illustrating a process, according to a fourth embodiment of the invention, for performing an RO procedure. 
         FIG. 10  is a message flow diagram illustrating the RO procedure of  FIG. 9 . 
         FIG. 11  is a flow chart illustrating a process, according to a fifth embodiment of the invention, for performing an RO procedure. 
         FIG. 12  is a message flow diagram illustrating the RO procedure of  FIG. 11 . 
         FIG. 13  is a functional block diagram of a home agent according to some embodiments of the invention. 
         FIG. 14  is a functional block diagram of a mobile node according to some embodiments of the invention. 
     
    
    
     DETAILED DESCRIPTION 
     Referring now to  FIG. 1 ,  FIG. 1  illustrates a communication system  100 . System  100  includes a mobile node (MN)  102 , a home network  110  (a.k.a, “home link”), a home agent  104 , and a foreign network (a.k.a, “foreign link”)  112 . To illustrate the various embodiments of the invention, we shall assume MN  102  has established a session (e.g., a TCP session or other session) with a correspondent node (CN)  106 . We shall also assume that, as shown in  FIG. 2 , MN  102  moves away from its home network  110  without ending the session established with CN  106 . That is, while the session with CN  106  is ongoing, MN  102  attaches to a foreign network and is assigned a care-of-address (CoA). 
     As discussed above, when MN  102  is away from its home, there are at least two possible modes in which MN  102  may communicate with CN  106 : (1) the bidirectional tunneling mode and (2) the RO mode. As also discussed above, there are advantages for MN  102  and CN  106  to communicate in the RO mode. For example, when MN  102  and CN  106  communicate using the RO mode, packets from CN  106  to MN  102  can be routed directly to the CoA of the mobile node. Routing packets directly to the mobile node&#39;s CoA allows the shortest communications path to be used and reduces congestion at the mobile node&#39;s home agent and home link. Because the RO mode enables a more efficient data packet exchange than the bidirectional tunneling, the RO mode should be used whenever possible unless the mobile node is not interested in disclosing its topological location, i.e., care-of address, to the CN (e.g., for privacy reasons). 
     Referring now to  FIG. 3 ,  FIG. 3  is a flow chart illustrating a process  300 , according to a first embodiment, for enabling MN  102  and CN  106  to enter (i.e., “switch on”) the RO mode using fewer signaling messages than is required by the return routability (RR) procedure described in RFC 3775. Being able to enter the RO mode using fewer signaling message has several advantages: For example, it results in a lower handoff latency, thereby increasing communication efficiency. It also results in an improved power efficiency in the mobile node. 
     Process  300  assumes that CN  106  is a mobile node using the same HA (or cluster) as MN  102 . For simplicity, MN  102  shall be referred to as MN 1  and CN  106  shall be referred to as MN 2 . Process  300  may begin in step  302 , where MN 1  and MN 2  each (a) auto-configure their IPv6 home address using the “cryptographically generated addresses (CGA)” technique (see RFC 3792, March 2005) and (b) establish a mutual relationship with the other. This mutual relationship is referred to as a “trusted relationship” or “symbiotic relationship.” Establishing the trusted relationship can be achieved using the “Secure Neighbor Discovery” protocol (see RFC 3971, March 2005). Additionally, other methods for establishing a relationship are known in the art (see e.g., WO2009065923, having an international filing date of 21 Nov. 2008, which publication is incorporated by reference herein). In some embodiments, the trusted relationship between MN 1  and MN 2  is of a cryptographic nature and may be established as a consequence of a mutual social relationship between the respective owners of MN 1  and MN 2 . In some embodiments, establishing a trusted relationship between MN 1  and MN 2  requires MN 1  to establish a unidirectional relationship with MN 2  and requires MN 2  to establish a unidirectional relationship with MN 1 . In some embodiments, when MN 2  establishes a unidirectional relationship with MN 1 , MN 2  receives MN 1 &#39;s public key and generates a 128-bit modifier from hashing MN 1 &#39;s public key together with a 128-bit random number (RAN) (Modifier=First [128, SHA-2(PK(MN 1 )|RAN)]). MN 2  then confidentially notifies MN 1  about the 128 bit modifier. Likewise, when MN 1  establishes a unidirectional relationship with MN 2 , MN 1  receives MN 2 &#39;s public key and generates a 128-bit modifier from hashing MN 2 &#39;s public key together with a 128-bit random number (RAN). MN 1  then confidentially notifies MN 2  about the 128 bit modifier. 
     In step  304 , MN 1  establishes a session (e.g., a TCP session) with MN 2  (or vice-versa). In step  306 , MN 1  moves outside its home network and is associated with and obtains a CoA. In step  308 , MN 1  sends to HA  104  a Binding Update (BU) message  402  (see the message flow diagram  400  shown in  FIG. 4 ). As used herein, a BU message is a message containing a “Mobility Header” (defined in section 6.1 of RFC 3775) where the MH type field of the Mobility Header is set to a value of 5. The BU message  402  transmitted in step  308  includes (a) the CoA obtained my MN 1  in step  306  and (b) information disclosing the relationship between MN 1  and MN 2 . This information is referred to as “proof of relationship” information. The proof of relationship information that is contained in BU message  402  may include: (a) information identifying MN 2  (e.g., an address generated by MN 2 ), (b) MN 2 &#39;s public key, and (c) a shared secret (e.g., the 128 bit modifier received from MN 2 ). Preferably, for security, BU message  402  is transmitted to HA  104  using an IPsec tunnel established between MN 1  and HA  104 . 
     In step  310 , HA  104  associates the CoA included in message  402  with MN 1 &#39;s home address (e.g., HA  104  creates a Binding Cache entry), stores the proof of relationship information, and sends an acknowledgement message  404  (see  FIG. 4 ) to MN 1 . The proof of relationship information may be stored in the Binding Cache entry or otherwise associated with MN 1 &#39;s home address and/or CoA. Message  404  may be a Binding Acknowledgment (BA) message (see RFC 3775). 
     In step  312 , MN 2  moves outside its home network and obtains a CoA. In step  314 , MN 2  sends to HA  104  a Binding Update (BU) message  406  (see  FIG. 4 ). The BU message  406  transmitted in step  314  includes (a) the CoA obtained by MN 2  in step  312  and (b) information disclosing the relationship between MN 2  and MN 1 . This information is referred to as “proof of relationship” information. The relationship information that is contained in BU message  406  may include: (a) information identifying MN 1  (e.g., a home address generated by MN 1 ), (b) MN 1 &#39;s public key, and (c) the 128 bit modifier received from MN 1 . Preferably, for security, BU message  406  is transmitted to HA  104  using an IPsec tunnel established between MN 2  and HA  104 . 
     In step  316 , HA  104  determines, based on the information in BU messages  402  and  406 , whether MN 1  and MN 2  have a trusted relationship. For example, in some embodiments, in response to receiving and validating BU message  406 , which message indicates that MN 2  asserts to have a trusted relationship with MN 1 , HA  104  retrieves the proof of relationship information stored in step  310  to determine whether MN 1  also asserts that it has a relationship with MN 2 . In this way, HA  104  can determine whether there is a trusted relationship between MN 1  and MN 2  (i.e., HA  104  can determine that MN 1  asserts to have a relationship with MN 2  and MN 2  asserts to have a relationship with MN 1 ). If HA  104  determines, that MN 1  and MN 2  do not have a trusted relationship, then process  300  proceeds to step  318 , otherwise process  300  proceeds to step  320 . In step  318 , HA  104  may send to MN 2  a conventional BA message (i.e., a BA message that does not include MN 1 &#39;s CoA). 
     In step  320 , HA  104  sends to MN 2  a BA message  408  that includes MN 1 &#39;s CoA. Message  408  may also include information that notifies MN 2  that HA  104  will send (or has sent) MN 2 &#39;s CoA to MN 1 . This information can be encoded in a single bit referred to as a “buddy” bit. In response to message  408 , MN 2  may create a Binding Cache entry (i.e., store information associating MN 1 &#39;s HoA with MN 1 &#39;s CoA) and may update its Binding Update list to indicate that MN 1  has received (or will soon receive) a “binding update” concerning MN 2 &#39;s CoA. 
     At the same time that message  408  is transmitted, HA  104  sends a message  410  to MN 1  (step  322 ). Message  410  includes MN 2 &#39;s CoA. Message  410  may be referred to as a “Neighbor Binding Update (NBU)” message. In response to receiving NBU message  410 , MN 1  may send to HA  104  a Neighbor Binding Ack (NBA) message  412 . In order to increase the overall performance, HA  104  can send multiple copies of the NBU message  410  until it receives the NBA message  412 . Also, in response to message  410 , MN 1  may create a Binding Cache entry (i.e., store information associating MN 2 &#39;s HoA with MN 2 &#39;s CoA) and may update its Binding Update list to indicate that MN 2  has received a “binding update” concerning MN 1 &#39;s CoA. 
     In step  324 , MN 1  and MN 2  can switch to RO mode because each has the other&#39;s CoA. 
     In this manner, the RO mode can be entered without MN 1  having to send any mobility message to MN 2  and vice-versa. That is, the inclusion of MN  1 &#39;s CoA in BA message  408  together with sending the NBU message  410  to MN 1  allow both mobile nodes MN 1  and MN 2  to quickly learn each other&#39;s current topological location from a trusted source and to create the necessary binding in order to redirect their data packets on the optimized path. This produces the following advantages: (1) the return routability (RR) procedure is entirely removed which means the number of signaling messages is reduced to zero and the two MNs won&#39;t need to share secrets and refresh them (thus helping increase the service provider&#39;s available bandwidth instead of being consumed by signaling messages); (2) removes the need to upgrade CNs to understand RR signaling, as such, it can be seen as a first step towards deploying the RO mode between nodes belonging to the same home network with zero signaling on the direct path; (3) significantly reduces IP handoff latency; and (4) reduces mobile node power consumption. 
     It should be noted that steps  314 - 324  may be repeated whenever MN 2  obtains a new CoA. Additionally, process  300  can be extended to include multiple mobile nodes. That is, MN 2  may have a trusted relationship not only with MN 1 , but also with MN 3 , in which case HA  104 , in step  320 , will send an NBU message to each mobile with which MN 2  has a trusted relationship. Process  300  also applies to the case where MN 1  or MN 2  has multiple interfaces (e.g., multiple home addresses). In this case, HA  104  can also notify the mobile node about using a CoA which is configured on another interface attached to the mobile node&#39;s device and/or about a CoA configured on another interface attached to the other endpoint&#39;s device. 
     Referring now to  FIG. 5 ,  FIG. 5  is a flow chart illustrating a process  500 , according to a second embodiment, for enabling MN  102  and CN  106  to enter the RO mode using few mobility messages. 
     Process  500  assumes that CN  106  is a mobile node using a different HA (or cluster) than MN  102 . For simplicity, MN  102  shall be referred to as MN 1 , CN  106  shall be referred to as MN 2 , MN 1 &#39;s home agent shall be referred to as HA 1 , and MN 2 &#39;s home agent shall be referred to as HA 2 . Process  500  also assumes that HA 1  has HA 2 &#39;s IP address and well as HA 2 &#39;s advertised prefixes) and public key(s) and vice-versa. For example, HA 1  and HA 2  may each have a list of other HAs&#39; and their corresponding IP addresses, prefixes and keys. Preferably, for security purposes, HA 1  and HA 2  can set up and IPsec tunnel between them. 
     Process  500  may begin in step  502 , where MN 1  and MN 2  each (a) auto-configure their IPv6 home address using the CGA technique and (b) establish a relationship with the other, as described above with reference to process  300 . 
     In step  504 , MN 1  establishes a session with MN 2  (or vice-versa). In step  506 , MN 1  moves outside its home network and is associated with and obtains a CoA. 
     In step  508 , MN 1  sends to HA 1  a BU message  602  (see the message flow diagram  600  shown in  FIG. 6 ). The BU message  602  transmitted in step  508  includes (a) the CoA obtained by MN 1  in step  506  and (b) information disclosing the relationship between MN 1  and MN 2 . This information is referred to as “proof of relationship” information, examples of which are provided above in the description of process  300 . 
     In step  510 , in response to message  602 , HA 1  creates a binding cache entry for MN 1 , sends to MN 1  a BA message  604  (see  FIG. 6 ), uses at least some of the proof of relationship information (e.g., MN 2 &#39;s IP address) to obtain HA 2 &#39;s corresponding parameters (e.g., HA 2 &#39;s IP address and public key) and sends to HA 2  an update message  606  (a.k.a., a “RO Neighbor Solicitation (RNS)” message). Message  606  includes MN 1 &#39;s CoA and information indicating that MN 1  has disclosed in message  602  that MN 1  has a relationship with MN 2 . Thus, message  606  may include information identifying MN 1  (e.g., MN 1 ′ home address) and may also include at least some of the proof of relationship information included in message  602  (e.g., MN 2 &#39;s home address). Assuming that MN 2  is still attached to its home network at the time message  606  is received, HA 2  simply stores information included in message  606  for later use, as described below. Additionally, HA 2  may send to HA 1  a RO Neighbor Present (RNP) message  608  (see  FIG. 6 ). Message  608  is used to inform HA 1  of MN 2 &#39;s status. 
     In step  512 , MN 2  moves outside its home network and obtains a CoA. In step  514 , MN 2  sends to HA 2  a BU message  610  (see  FIG. 6 ). The BU message  610  transmitted in step  514  includes (a) the CoA obtained by MN 2  in step  512  and (b) information disclosing the relationship between MN 2  and MN 1  (e.g., MN 1 &#39;s IP address). 
     In step  516 , HA 2  determines, based on the information in BU message  610  and RNS message  606 , whether MN 1  and MN 2  have a trusted relationship. For example, in step  516 , in response to receiving BU message  610 , which may include MN 1 &#39;s home address, HA 2  uses MN 1 &#39;s home address to determine whether HA 2  has received from HA 1  an RNS message indicating that MN 1  has disclosed a relationship with MN 2  and, if such an RNS message was received from HA 1 , then HA 2  retrieves MN 1 &#39;s CoA, which was included in the RNS message. 
     If HA  104  determines, that MN 1  and MN 2  do not have a trusted relationship, then process  500  proceeds to step  518 , otherwise process  500  proceeds to step  520 . In step  518 , HA 2  may send to MN 2  a conventional BA message  613  (i.e., a BA message  613  that does not include MN 1 &#39;s CoA). 
     In step  520 , HA 2  sends to HA 1  MN 2 &#39;s CoA. For example, in step  520 , HA 2  may send to HA 1  an RO Neighbor Update (RNU) message  614  that includes MN 2 &#39;s CoA. In step  522 , in response to message  614 , HA 1  sends to MN 1  MN 2 &#39;s CoA. For example, in step  522 , HA 1  sends to MN 1  a NBU message  616  containing MN 2 &#39;s CoA. In response to message  616 , MN 1  may create a Binding Cache entry (i.e., store information associating MN 2 &#39;s HoA with MN 2 &#39;s CoA) and may update its Binding Update list to indicate that MN 2  has received (or will soon receive) a “binding update” message concerning MN 1 &#39;s CoA. 
     In step  524 , HA 2  sends to MN 2  a BA message  613 ′ that includes MN 1 &#39;s CoA. Message  613 ′ may also include information that notifies MN 2  that HA 2  will send (or has sent) MN 2 &#39;s CoA to HA 1 . In some embodiments, after HA 2  sends the RNU  614  to HA 1 , HA 2  waits for an acknowledgement from HA 1  before performing step  524 . In response to message  613 ′, MN 2  should create a Binding Cache entry (i.e., store information associating MN 1 &#39;s HoA with MN 1 &#39;s CoA) and should update its Binding Update list to indicate that MN 1  has received a “binding update” concerning MN 2 &#39;s CoA. 
     In response to receiving NBU message  616 , MN 1  may send to HA 1  a Neighbor Binding Ack (NBA) message  618 . In step  526 , MN 1  and MN 2  can both switch to RO mode because each has the other&#39;s CoA. 
     Referring now to  FIG. 7 ,  FIG. 7  is a flow chart illustrating a process  700 , according to a third embodiment, for enabling MN  102  and CN  106  to enter the RO mode using few mobility messages. Process  700  may begin in step  702 , where MN  102  and CN  106  each establish a relationship with the other (e.g., as described above with reference to process  300 ). In step  704 , MN  102  establishes a session with CN  106  (or vice-versa). In step  706 , MN  102  moves outside its home network and obtains a CoA. In step  708 , MN  102  sends to HA  104  a BU message  802  (see the message flow diagram  800  shown in  FIG. 8 ). The BU message  802  transmitted in step  708  includes (a) the CoA obtained by MN  102  in step  706  and (b) information disclosing the relationship between MN  102  and CN  106 . This information is referred to as “proof of relationship” information, examples of which are provided above in the description of process  300 . 
     In step  710 , in response to message  802 , HA  104  creates a binding cache entry for MN  102 , sends to MN  102  a BA message  804  (see  FIG. 8 ), and sends a message  806  to CN  106 . Message  806  seeks confirmation from CN  106  that CN  106  and MN  102  have a trusted relationship. Message  806  may be a “Neighbor Discovery” protocol message (see RFC 2461) that is used to convey MN  102 &#39;s HoA and public key to CN  106 . For this purpose, two parameters may be added in two new options in the “neighbor solicitation (NS)” message. Preferably, the Neighbor solicitation message is be signed by HA  104 . The most convenient way to implement the security requirement is to use “Secure Neighbor Discovery (SeND)” (see RFC 3971). 
     If CN  106  has a relationship with MN  102 , then it should reply to HA  104  by disclosing parameters related to the “proof-of relationship” with MN  102 . These parameters may be carried in a “Neighbor Advertisement (NA)” message  808  which is sent back to HA  104 . Preferably, the “proof-of-relationship” parameters are encrypted. For this purpose, CN  106  may encrypt these parameters with HA  104 &#39;s public key before signing the entire message. If, however, CN  106  is not interested in disclosing the proof of relationship parameters or does not have such a relationship, then CN  106  should return a simple NA message to HA. In either case, an NA message  808  (or other message) is returned to HA  104  in response to message  806  (step  712 ). 
     In step  714 , HA  104  determines, based on the response from CN  106  (or lack thereof) to message  806 , whether CN  106  and MN  102  have a relationship. If HA  104  determines, that MN  102  and CN  106  do not have a relationship, then process  700  may end, otherwise process  700  proceeds to step  716 . 
     In step  716 , HA  104  sends to CN  106  an update message  810  (e.g., Binding Update message) containing, among other things, MN  102 &#39;s HoA and current CoA. CN  106  may include a secret in message  808  that enables HA  104  to encrypt and authenticate update message  810 . In response to message  810 , CN  106  creates a Binding Cache entry that associates MN  102 &#39;s HoA with MN  102 &#39;s CoA. In step  718 , CN  106  transmits an IPv6 packet with MN  102 &#39;s CoA in the destination address field and MN  102 &#39;s HoA in an extended header of the packet (e.g., in a type  2  routing header). This packet is routed to MN  102 . In step  720 , MN  102  receives the packet and, in response to receiving the packet, updates its Binding Update list to indicate that CN  106  has received an “update” concerning MN  102 &#39;s CoA. In step  722 , MN  102  switches to the RO mode. 
     Referring now to  FIG. 9 ,  FIG. 9  is a flow chart illustrating a process  900 , according to a fourth embodiment, for enabling MN  102  and CN  106  to enter the RO mode using few mobility messages. Process  900  may begin in step  902 , where MN  102  establishes a session with CN  106  (or vice-versa). In step  904 , MN  102  moves outside its home network and is associated with and obtains a CoA. In step  906 , MN  102  sends to HA  104  a BU message  1002  (see the message flow diagram  1000  shown in  FIG. 10 ). The BU message  1002  transmitted in step  908  includes (a) the CoA obtained by MN  102  in step  906 . 
     In step  908 , in response to message  1002 , HA  104  creates a binding cache entry for MN  102 , sends to MN  102  a BA message  1004  (see  FIG. 10 ), and sends to CN  106  an update message  1006  (e.g., a Binding Update message) containing, among other things, MN  102 &#39;s HoA and current CoA. In response to message  1006 , CN  106  creates a Binding Cache entry that associates MN  102 &#39;s HoA with MN  102 &#39;s CoA. In step  910 , CN  106  transmits an IPv6 packet with MN  102 &#39;s CoA in the destination address field and MN  102 &#39;s HoA in an extended header of the packet (e.g., in a type  2  routing header). This packet is routed to MN  102 . In step  912 , MN  102  receives the packet and, in response to receiving the packet, updates its Binding Update list to indicate that CN  106  has received an “update” concerning MN  102 &#39;s CoA. In step  914 , MN  102  switches to the RO mode. 
     Referring now to  FIG. 11 ,  FIG. 11  is a flow chart illustrating a process  1100 , according to a fifth embodiment, for enabling MN  102  and CN  106  to enter the RO mode using few mobility messages. Process  1100  assumes that CN  106  is a mobile node using a different HA (or cluster) than MN  102 . For simplicity, MN  102  shall be referred to as MN 1 , CN  106  shall be referred to as MN 2 , MN 1 &#39;s home agent shall be referred to as HA 1 , and MN 2 &#39;s home agent shall be referred to as HA 2 . Process  1100  also assumes that HA 1  has HA 2 &#39;s IP address as well as HA 2 &#39;s advertised prefixes) and public key(s) and vice-versa. For example, HA 1  and HA 2  may each have a list of other HAs&#39; and their corresponding IP addresses, prefixes and keys. Preferably, for security purposes, HA 1  and HA 2  can set up and IPsec tunnel between them. 
     Process  1100  may begin in step  1102 , where MN 1  and MN 2  each (a) auto-configure their IPv6 home address using the CGA technique and (b) establish a relationship with the other, as described above with reference to process  300 . 
     In step  1104 , MN 1  establishes a session with MN 2  (or vice-versa). In step  1106 , MN 1  moves outside its home network and is associated with and obtains a CoA. 
     In step  1108 , MN 1  sends to HA 1  a BU message  1202  (see the message flow diagram  1200  shown in  FIG. 12 ). The BU message  1202  transmitted in step  1108  includes (a) the CoA obtained by MN 1  in step  1106  and (b) information disclosing the relationship between MN 1  and MN 2 . This information is referred to as “proof of relationship” information, examples of which are provided above in the description of process  300 . 
     In step  1110 , in response to message  1202 , HA 1  creates a binding cache entry for MN 1 , sends to MN 1  a BA message  1204  (see  FIG. 12 ), uses at least some of the proof of relationship information (e.g., MN 2 &#39;s IP address) to obtain HA 2 &#39;s corresponding parameters (e.g., HA 2 &#39;s IP address and public key) and sends to HA 2  an update message  1206  (a.k.a., a “RO Neighbor Solicitation (RNS)” message). Message  1206  includes MN 1 &#39;s CoA and information indicating that MN 1  has disclosed in message  1202  that MN 1  has a relationship with MN 2 . Thus, message  1206  may include information identifying MN 1  (e.g., MN 1 ′ home address) and may also include at least some of the proof of relationship information included in message  1202  (e.g., MN 2 &#39;s home address). 
     In step  1111 , in response to message  1206 , HA 2  sends a message  1210  to MN 2 . Message  1210  seeks confirmation from MN 2  that MN 2  and MN 1  have a trusted relationship. Message  1210  may be a “Neighbor Discovery” protocol message that is used to convey MN 1 &#39;s HoA and public key to MN 2 . 
     If MN 2  has a relationship with MN 1 , then it should reply to HA 2  by disclosing parameters related to the “proof-of relationship” with MN 1 . These parameters may be carried in a “Neighbor Advertisement (NA)” message  1212  which is sent back to HA 2 . If, however, MN 2  is not interested in disclosing the proof of relationship parameters or does not have such a relationship, then MN 2  should return a simple NA message to HA 2 . In either case, an NA message  1212  (or other message) is returned to HA 2  in response to message  1210  (step  1112 ). 
     In step  1114 , HA 2  determines, based on the response from MN 2  (or lack thereof) to message  1210 , whether MN 2  and MN 1  have a relationship. If HA 2  determines, that MN 1  and MN 2  do not have a relationship, then process  1100  may end, otherwise process  1100  proceeds to step  1116 . 
     In step  1116 , HA 2  sends to MN 2  an update message  1214  (e.g., Binding Update message) containing, among other things, MN 1 &#39;s HoA and current CoA. MN 2  may include a secret in message  1212  that enables HA 2  to encrypt and authenticate update message  1214 . In response to message  1214 , MN 2  creates a Binding Cache entry that associates MN 1 &#39;s HoA with MN 1 &#39;s CoA. In step  1118 , MN 2  transmits an IPv6 packet with MN 1 &#39;s CoA in the destination address field and MN 1 &#39;s HoA in an extended header of the packet (e.g., in a type  2  routing header). This packet is routed to MN 1 . In step  1120 , MN 1  receives the packet and, in response to receiving the packet, updates its Binding Update list to indicate that MN 2  has received an “update” concerning MN 1 &#39;s CoA. In step  1122 , MN 1  switches to the RO mode. 
     Referring now to  FIG. 13 ,  FIG. 13  is a functional block diagram of HA  104  according to some embodiments of the invention. As shown, HA  104  may comprise a data processing system  1302  (e.g. one or more microprocessors, one or more integrated circuits, such as an application specific integrated circuit (ASIC), Field-programmable gate arrays (FPGAs), etc. and any combination of these), a data storage system  1306  (e.g. one or more non-volatile storage devices) and computer software  1308  stored on the storage system  1306 . Configuration parameters  1310  may also be stored in storage system  1306 . HA  104  may also include one or more network interfaces  1304  for communicating with MN  102  and CN  106 . In some embodiments, software  1308  is configured such that when processing system  1302  executes software  1308 , HA  104  performs steps described above (e.g., steps described above with reference to the flow charts shown in  FIGS. 3 ,  5 ,  7 ,  9  and/or  11 ). In other embodiments, data processing system  1302  is configured to perform steps described above with reference to the flow charts without the need for software  1308 . That is, for example, data processing system may consist merely of one or more ASICs. Hence, the features of the present invention described above may be implemented in hardware and/or software. 
     Referring now to  FIG. 14 ,  FIG. 14  is a functional block diagram of MN  102  according to some embodiments of the invention. As shown, MN  102  may comprise a data processing system  1402  (e.g. one or more microprocessors, one or more integrated circuits, such as an application specific integrated circuit (ASIC), Field-programmable gate arrays (FPGAs), etc. and any combination of these), a data storage system  1406  (e.g. one or more non-volatile storage devices) and computer software  1408  stored on the storage system  1406 . Configuration parameters  1410  may also be stored in storage system  1406 . MN  102  may also include a network interface  1404  for communicating with HA  104  and CN  106 . In some embodiments, software  1408  is configured such that when processing system  1402  executes software  1408 , HA  104  performs steps described above (e.g., steps described above with reference to the flow charts shown in  FIGS. 3 ,  5 ,  7 ,  9  and/or  11 ). In other embodiments, data processing system  1402  is configured to perform steps described above with reference to the flow charts without the need for software  1408 . That is, for example, data processing system may consist merely of one or more ASICs. Hence, the features of the present invention described above may be implemented in hardware and/or software. 
     While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the invention unless otherwise indicated herein or otherwise clearly contradicted by context. 
     Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.