diff options
Diffstat (limited to 'doc/rfc/rfc4140.txt')
| -rw-r--r-- | doc/rfc/rfc4140.txt | 1627 |
1 files changed, 1627 insertions, 0 deletions
diff --git a/doc/rfc/rfc4140.txt b/doc/rfc/rfc4140.txt new file mode 100644 index 0000000..fc505fa --- /dev/null +++ b/doc/rfc/rfc4140.txt @@ -0,0 +1,1627 @@ + + + + + + +Network Working Group H. Soliman +Request for Comments: 4140 Flarion +Category: Experimental C. Castelluccia + INRIA + K. El Malki + Ericsson + L. Bellier + INRIA + August 2005 + + + Hierarchical Mobile IPv6 Mobility Management (HMIPv6) + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document introduces extensions to Mobile IPv6 and IPv6 Neighbour + Discovery to allow for local mobility handling. Hierarchical + mobility management for Mobile IPv6 is designed to reduce the amount + of signalling between the Mobile Node, its Correspondent Nodes, and + its Home Agent. The Mobility Anchor Point (MAP) described in this + document can also be used to improve the performance of Mobile IPv6 + in terms of handover speed. + + + + + + + + + + + + + + + + + + +Soliman, et al. Experimental [Page 1] + +RFC 4140 HMIPv6 August 2005 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................4 + 3. Overview of HMIPv6 ..............................................5 + 3.1. HMIPv6 Operation ...........................................6 + 4. Mobile IPv6 Extensions ..........................................8 + 4.1. Local Binding Update .......................................8 + 5. Neighbour Discovery Extension: The MAP Option Message Format ....9 + 6. Protocol Operation .............................................10 + 6.1. Mobile Node Operation .....................................10 + 6.1.1. Sending Packets to Correspondent Nodes .............12 + 6.2. MAP Operations ............................................12 + 6.3. Home Agent Operations .....................................13 + 6.4. Correspondent Node Operations .............................13 + 6.5. Local Mobility Management Optimisation within a + MAP Domain ................................................13 + 6.6. Location Privacy ..........................................14 + 7. MAP Discovery ..................................................14 + 7.1. Dynamic MAP Discovery .....................................14 + 7.1.1. Router Operation for Dynamic MAP Discovery .........15 + 7.1.2. MAP Operation for Dynamic MAP Discovery ............15 + 7.2. Mobile Node Operation .....................................16 + 8. Updating Previous MAPs .........................................16 + 9. Notes on MAP Selection by the Mobile Node ......................17 + 9.1. MAP Selection in a Distributed-MAP Environment ............17 + 9.2. MAP Selection in a Flat Mobility Management Architecture ..19 + 10. Detection and Recovery from MAP Failures ......................19 + 11. IANA Considerations ...........................................20 + 12. Security Considerations .......................................20 + 12.1. Mobile Node-MAP Security ................................20 + 12.2. Mobile Node-Correspondent Node Security .................22 + 12.3. Mobile Node-Home Agent Security .........................22 + 13. Acknowledgments ...............................................22 + 14. References ....................................................23 + 14.1. Normative References ....................................23 + 14.2. Informative References ..................................23 + Appendix A: Fast Mobile IPv6 Handovers and HMIPv6 .................24 + + + + + + + + + + + + + +Soliman, et al. Experimental [Page 2] + +RFC 4140 HMIPv6 August 2005 + + +1. Introduction + + This memo introduces the concept of a Hierarchical Mobile IPv6 + network, utilising a new node called the Mobility Anchor Point (MAP). + + Mobile IPv6 [1] allows nodes to move within the Internet topology + while maintaining reachability and on-going connections between + mobile and correspondent nodes. To do this a mobile node sends + Binding Updates (BUs) to its Home Agent (HA) and all Correspondent + Nodes (CNs) it communicates with, every time it moves. + Authenticating binding updates requires approximately 1.5 round-trip + times between the mobile node and each correspondent node (for the + entire return routability procedure in a best case scenario, i.e., no + packet loss). In addition, one round-trip time is needed to update + the Home Agent; this can be done simultaneously while updating + correspondent nodes. The re-use of the home cookie (i.e., + eliminating HOTI/HOT) will not reduce the number of round trip times + needed to update correspondent nodes. These round trip delays will + disrupt active connections every time a handoff to a new AR is + performed. Eliminating this additional delay element from the time- + critical handover period will significantly improve the performance + of Mobile IPv6. Moreover, in the case of wireless links, such a + solution reduces the number of messages sent over the air interface + to all correspondent nodes and the Home Agent. A local anchor point + will also allow Mobile IPv6 to benefit from reduced mobility + signalling with external networks. + + For these reasons a new Mobile IPv6 node, called the Mobility Anchor + Point, is used and can be located at any level in a hierarchical + network of routers, including the Access Router (AR). Unlike Foreign + Agents in IPv4, a MAP is not required on each subnet. The MAP will + limit the amount of Mobile IPv6 signalling outside the local domain. + The introduction of the MAP provides a solution to the issues + outlined earlier in the following way: + + - The mobile node sends Binding Updates to the local MAP rather than + the HA (which is typically further away) and CNs + + - Only one Binding Update message needs to be transmitted by the MN + before traffic from the HA and all CNs is re-routed to its new + location. This is independent of the number of CNs that the MN is + communicating with. + + A MAP is essentially a local Home Agent. The aim of introducing the + hierarchical mobility management model in Mobile IPv6 is to enhance + the performance of Mobile IPv6 while minimising the impact on Mobile + IPv6 or other IPv6 protocols. It also supports Fast Mobile IPv6 + Handovers to help Mobile Nodes achieve seamless mobility (see + + + +Soliman, et al. Experimental [Page 3] + +RFC 4140 HMIPv6 August 2005 + + + Appendix A). Furthermore, HMIPv6 allows mobile nodes to hide their + location from correspondent nodes and Home Agents while using Mobile + IPv6 route optimisation. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [3]. + + In addition, new terms are defined below: + + Access Router (AR) The AR is the Mobile Node's default router. + The AR aggregates the outbound traffic of + mobile nodes. + + Mobility Anchor Point A Mobility Anchor Point is a router located + (MAP) in a network visited by the mobile node. The + MAP is used by the MN as a local HA. One or + more MAPs can exist within a visited network. + + Regional Care-of An RCoA is an address obtained by the + Address (RCoA) mobile node from the visited network. An RCoA + is an address on the MAP's subnet. It is + auto-configured by the mobile node when + receiving the MAP option. + + HMIPv6-aware An HMIPv6-aware mobile node is a mobile + Mobile Node node that can receive and process the MAP + option received from its default router. An + HMIPv6-aware Mobile Node must also be able to + send local binding updates (Binding Update + with the M flag set). + + On-link Care-of The LCoA is the on-link CoA configured on + Address (LCoA) a mobile node's interface based on the prefix + advertised by its default router. In [1], + this is simply referred to as the Care-of- + address. However, in this memo LCoA is used + to distinguish it from the RCoA. + + Local Binding Update The MN sends a Local Binding Update to the MAP + in order to establish a binding between the + RCoA and LCoA. + + + + + + + +Soliman, et al. Experimental [Page 4] + +RFC 4140 HMIPv6 August 2005 + + +3. Overview of HMIPv6 + + This Hierarchical Mobile IPv6 scheme introduces a new function, the + MAP, and minor extensions to the mobile node operation. The + correspondent node and Home Agent operation will not be affected. + + Just like Mobile IPv6, this solution is independent of the underlying + access technology, allowing mobility within or between different + types of access networks. + + A mobile node entering a MAP domain will receive Router + Advertisements containing information on one or more local MAPs. The + MN can bind its current location (on-link CoA) with an address on the + MAP's subnet (RCoA). Acting as a local HA, the MAP will receive all + packets on behalf of the mobile node it is serving and will + encapsulate and forward them directly to the mobile node's current + address. If the mobile node changes its current address within a + local MAP domain (LCoA), it only needs to register the new address + with the MAP. Hence, only the Regional CoA (RCoA) needs to be + registered with correspondent nodes and the HA. The RCoA does not + change as long as the MN moves within a MAP domain (see below for + definition). This makes the mobile node's mobility transparent to + the correspondent nodes it is communicating with. + + A MAP domain's boundaries are defined by the Access Routers (ARs) + advertising the MAP information to the attached Mobile Nodes. The + detailed extensions to Mobile IPv6 and operations of the different + nodes will be explained later in this document. + + It should be noted that the HMIPv6 concept is simply an extension to + the Mobile IPv6 protocol. An HMIPv6-aware mobile node with an + implementation of Mobile IPv6 SHOULD choose to use the MAP when + discovering such capability in a visited network. However, in some + cases the mobile node may prefer to simply use the standard Mobile + IPv6 implementation. For instance, the mobile node may be located in + a visited network within its home site. In this case, the HA is + located near the visited network and could be used instead of a MAP. + In this scenario, the mobile node would only update the HA whenever + it moves. The method to determine whether the HA is in the vicinity + of the MN (e.g., same site) is outside the scope of this document. + + + + + + + + + + + +Soliman, et al. Experimental [Page 5] + +RFC 4140 HMIPv6 August 2005 + + +3.1. HMIPv6 Operation + + The network architecture shown in Figure 1 illustrates an example of + the use of the MAP in a visited network. + + In Figure 1, the MAP can help in providing seamless mobility for the + mobile node as it moves from Access Router 1 (AR1) to Access Router 2 + (AR2), while communicating with the correspondent node. A multi- + level hierarchy is not required for a higher handover performance. + Hence, it is sufficient to locate one or more MAPs (possibly covering + the same domain) at any position in the operator's network. + + +-------+ + | HA | + +-------+ +----+ + | | CN | + | +----+ + | | + +-------+-----+ + | + |RCoA + +-------+ + | MAP | + +-------+ + | | + | +--------+ + | | + | | + +-----+ +-----+ + | AR1 | | AR2 | + +-----+ +-----+ + LCoA1 LCoA2 + + +----+ + | MN | + +----+ ------------> + Movement + + Figure 1: Hierarchical Mobile IPv6 domain + + Upon arrival in a visited network, the mobile node will discover the + global address of the MAP. This address is stored in the Access + Routers and communicated to the mobile node via Router Advertisements + (RAs). A new option for RAs is defined later in this specification. + This is needed to inform mobile nodes about the presence of the MAP + (MAP discovery). The discovery phase will also inform the mobile + node of the distance of the MAP from the mobile node. For example, + the MAP function could be implemented as shown in Figure 1, and, at + + + +Soliman, et al. Experimental [Page 6] + +RFC 4140 HMIPv6 August 2005 + + + the same time, also be implemented in AR1 and AR2. In this case the + mobile node can choose the first hop MAP or one further up in the + hierarchy of routers. The details on how to choose a MAP are + provided in section 10. + + The process of MAP discovery continues as the mobile node moves from + one subnet to the next. Every time the mobile node detects movement, + it will also detect whether it is still in the same MAP domain. The + router advertisement used to detect movement will also inform the + mobile node, through the MAP option, whether it is still in the same + MAP domain. As the mobile node roams within a MAP domain, it will + continue to receive the same MAP option included in router + advertisements from its AR. If a change in the advertised MAP's + address is received, the mobile node MUST act on the change by + sending Binding Updates to its HA and correspondent nodes. + + If the mobile node is not HMIPv6-aware, then no MAP Discovery will be + performed, resulting in the mobile node using the Mobile IPv6 [1] + protocol for its mobility management. On the other hand, if the + mobile node is HMIPv6-aware it SHOULD choose to use its HMIPv6 + implementation. If so, the mobile node will first need to register + with a MAP by sending it a BU containing its Home Address and on-link + address (LCoA). The Home address used in the BU is the RCoA. The + MAP MUST store this information in its Binding Cache to be able to + forward packets to their final destination when received from the + different correspondent nodes or HAs. + + The mobile node will always need to know the original sender of any + received packets to determine if route optimisation is required. + This information will be available to the mobile node because the MAP + does not modify the contents of the original packet. Normal + processing of the received packets (as described in [1]) will give + the mobile node the necessary information. + + To use the network bandwidth in a more efficient manner, a mobile + node may decide to register with more than one MAP simultaneously and + to use each MAP address for a specific group of correspondent nodes. + For example, in Fig 1, if the correspondent node happens to exist on + the same link as the mobile node, it would be more efficient to use + the first hop MAP (in this case assume it is AR1) for communication + between them. This will avoid sending all packets via the "highest" + MAP in the hierarchy and thus will result in more efficient usage of + network bandwidth. The mobile node can also use its current on-link + address (LCoA) as a CoA, as specified in [1]. Note that the mobile + node MUST NOT present an RCoA from a MAP's subnet as an LCoA in a + binding update sent to another MAP. The LCoA included in the binding + update MUST be the mobile node's address derived from the prefix + advertised on its link. + + + +Soliman, et al. Experimental [Page 7] + +RFC 4140 HMIPv6 August 2005 + + + If a router advertisement is used for MAP discovery, as described in + this document, all ARs belonging to the MAP domain MUST advertise the + MAP's IP address. The same concept (advertising the MAP's presence + within its domain) should be used if other methods of MAP discovery + are introduced in future. + +4. Mobile IPv6 Extensions + + This section outlines the extensions proposed to the binding update + specified in [1]. + +4.1. Local Binding Update + + A new flag is added: the M flag, which indicates MAP registration. + When a mobile node registers with the MAP, the M and A flags MUST be + set to distinguish this registration from a BU being sent to the HA + or a correspondent node. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence # | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |A|H|L|K|M| Reserved | Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Description of extensions to the binding update: + + M If set to 1 it indicates a MAP registration. + + It should be noted that this is an extension to the Binding update + specified in [1]. + + + + + + + + + + + + + + + + +Soliman, et al. Experimental [Page 8] + +RFC 4140 HMIPv6 August 2005 + + +5. Neighbour Discovery Extension: The MAP Option Message Format + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Dist | Pref |R| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Valid Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Global IP Address for MAP + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Fields: + + Type IPv6 Neighbor Discovery option. 23. + + Length 8-bit unsigned integer. The length of the option + and MUST be set to 3. + + Dist A 4-bit unsigned integer identifying the Distance + Between MAP and the receiver of the advertisement. + Its default value SHOULD be set to 1 if Dynamic + MAP discovery is used. The Distance MUST be set + to 1 if the MAP is on the same link as the mobile + node. This field need not be interpreted as the + number of hops between MAP and the mobile node. + The only requirement is that the meaning of the + Distance field is consistently interpreted within + one Domain. A Distance value of Zero MUST NOT be + used. + + Pref The preference of a MAP. A 4-bit unsigned + integer. A decimal value of 15 indicates the + highest availability. + + R When set to 1, it indicates that the mobile node + MUST form an RCoA based on the prefix in the MAP + option. + + + + + + + +Soliman, et al. Experimental [Page 9] + +RFC 4140 HMIPv6 August 2005 + + + Valid Lifetime The minimum value (in seconds) of both the + preferred and valid lifetimes of the prefix + assigned to the MAP's subnet. This value + indicates the validity of the MAP's address and + consequently the time for which the RCoA is valid. + + Global Address One of the MAP's global addresses. The 64-bit + prefix extracted from this address MUST be + configured in the MAP to be used for RCoA + construction by the mobile node. + + Although not explicitly included in the MAP option, the prefix length + of the MAP's Global IP address MUST be 64. This prefix is the one + used by the mobile node to form an RCoA, by appending a 64-bit + identifier to the prefix. Thus, it necessitates a static prefix + length for the MAP's subnet. + +6. Protocol Operation + + This section describes the HMIPv6 protocol. In HMIPv6, the mobile + node has two addresses, an RCoA on the MAP's link and an on-link CoA + (LCoA). This RCoA is formed in a stateless manner by combining the + mobile node's interface identifier and the subnet prefix received in + the MAP option. + + As illustrated in this section, this protocol requires updating the + mobile nodes' implementation only. The HA and correspondent node are + unchanged. The MAP performs the function of a "local" HA that binds + the mobile node's RCoA to an LCoA. + +6.1. Mobile Node Operation + + When a mobile node moves into a new MAP domain (i.e., its MAP + changes), it needs to configure two CoAs: an RCoA on the MAP's link + and an on-link CoA (LCoA). The RCoA is formed in a stateless manner. + After forming the RCoA based on the prefix received in the MAP + option, the mobile node sends a local BU to the MAP with the A and M + flags set. The local BU is a BU defined in [1] and includes the + mobile node's RCoA in the Home Address Option. No alternate-CoA + option is needed in this message. The LCoA is used as the source + address of the BU. This BU will bind the mobile node's RCoA (similar + to a Home Address) to its LCoA. The MAP (acting as a HA) will then + perform DAD (when a new binding is being created) for the mobile + node's RCoA on its link and return a Binding Acknowledgement to the + MN. This acknowledgement identifies the binding as successful or + contains the appropriate fault code. No new error codes need to be + + + + + +Soliman, et al. Experimental [Page 10] + +RFC 4140 HMIPv6 August 2005 + + + supported by the mobile node for this operation. The mobile node + MUST silently ignore binding acknowledgements that do not contain a + routing header type 2, which includes the mobile node's RCoA. + + Following a successful registration with the MAP, a bi-directional + tunnel between the mobile node and the MAP is established. All + packets sent by the mobile node are tunnelled to the MAP. The outer + header contains the mobile node's LCoA in the source address field + and the MAP's address in the destination address field. The inner + header contains the mobile node's RCoA in the source address field + and the peer's address in the destination address field. Similarly, + all packets addressed to the mobile node's RCoA are intercepted by + the MAP and tunnelled to the mobile node's LCoA. + + This specification allows a mobile node to use more than one RCoA if + it received more than one MAP option. In this case, the mobile node + MUST perform the binding update procedure for each RCoA. In + addition, the mobile node MUST NOT use one RCoA (e.g., RCoA1) derived + from a MAP's prefix (e.g., MAP1) as a care-of address in its binding + update to another MAP (e.g., MAP2). This would force packets to be + encapsulated several times (twice in this example) on their path to + the mobile node. This form of multi-level hierarchy will reduce the + protocol's efficiency and performance. + + After registering with the MAP, the mobile node MUST register its new + RCoA with its HA by sending a BU that specifies the binding (RCoA, + Home Address) as in Mobile IPv6. The mobile node's Home Address is + used in the home address option and the RCoA is used as the care-of + address in the source address field. The mobile node may also send a + similar BU (i.e., that specifies the binding between the Home Address + and the RCoA) to its current correspondent nodes. + + The mobile node SHOULD wait for the binding acknowledgement from the + MAP before registering with its HA. It should be noted that when + binding the RCoA with the HA and correspondent nodes, the binding + lifetime MUST NOT be larger than the mobile node's binding lifetime + with the MAP, which is received in the Binding Acknowledgement. + + In order to speed up the handover between MAPs and reduce packet + loss, a mobile node SHOULD send a local BU to its previous MAP, + specifying its new LCoA. Packets in transit that reach the previous + MAP are then forwarded to the new LCoA. + + The MAP will receive packets addressed to the mobile node's RCoA + (from the HA or correspondent nodes). Packets will be tunnelled from + the MAP to the mobile node's LCoA. The mobile node will de-capsulate + the packets and process them in the normal manner. + + + + +Soliman, et al. Experimental [Page 11] + +RFC 4140 HMIPv6 August 2005 + + + When the mobile node moves within the same MAP domain, it should only + register its new LCoA with its MAP. In this case, the RCoA remains + unchanged. + + Note that a mobile node may send a BU containing its LCoA (instead of + its RCoA) to correspondent nodes, which are connected to its same + link. Packets will then be routed directly without going through the + MAP. + +6.1.1. Sending Packets to Correspondent Nodes + + The mobile node can communicate with a correspondent node through the + HA, or in a route-optimised manner, as described in [1]. When + communicating through the HA, the message formats in [1] can be re- + used. + + If the mobile node communicates directly with the correspondent node + (i.e., the CN has a binding cache entry for the mobile node), the + mobile node MUST use the same care-of address used to create a + binding cache entry in the correspondent node (RCoA) as a source + address. According to [1], the mobile node MUST also include a Home + Address option in outgoing packets. The Home address option MUST + contain the mobile node's home address. + +6.2. MAP Operations + + The MAP acts like a HA; it intercepts all packets addressed to + registered mobile nodes and tunnels them to the corresponding LCoA, + which is stored in its binding cache. + + A MAP has no knowledge of the mobile node's Home address. The mobile + node will send a local BU to the MAP with the M and A flags set. The + aim of this BU is to inform the MAP that the mobile node has formed + an RCoA (contained in the BU as a Home address). If successful, the + MAP MUST return a binding acknowledgement to the mobile node, + indicating a successful registration. This is identical to the HA + operation in [1]. No new error codes are introduced for HMIPv6. The + binding acknowledgement MUST include a routing header type 2 that + contains the mobile node's RCoA. + + The MAP MUST be able to accept packets tunnelled from the mobile + node, with the mobile node being the tunnel entry point and the MAP + being the tunnel exit point. + + The MAP acts as a HA for the RCoA. Packets addressed to the RCOA are + intercepted by the MAP, using proxy Neighbour Advertisement, and then + encapsulated and routed to the mobile node's LCoA. This operation is + identical to that of the HA described in [1]. + + + +Soliman, et al. Experimental [Page 12] + +RFC 4140 HMIPv6 August 2005 + + + A MAP MAY be configured with the list of valid on-link prefixes that + mobile nodes can use to derive LCoAs. This is useful for network + operators to stop mobile nodes from continuing to use the MAP after + moving to a different administrative domain. If a mobile node sent a + binding update containing an LCoA that is not in the MAP's "valid + on-link prefixes" list, the MAP could reject the binding update using + existing error code 129 (administratively prohibited). + +6.3. Home Agent Operations + + The support of HMIPv6 is completely transparent to the HA's + operation. Packets addressed to a mobile node's Home Address will be + forwarded by the HA to its RCoA, as described in [1]. + +6.4. Correspondent Node Operations + + HMIPv6 is completely transparent to correspondent nodes. + +6.5. Local Mobility Management Optimisation within a MAP Domain + + In [1], it is stated that for short-term communication, particularly + communication that may easily be retried upon failure, the mobile + node MAY choose to directly use one of its care-of addresses as the + source of the packet, thus not requiring the use of a Home Address + option in the packet. Such use of the CoA will reduce the overhead + of sending each packet due to the absence of additional options. In + addition, it will provide an optimal route between the mobile node + and correspondent node. + + In HMIPv6, a mobile node can use its RCoA as the source address + without using a Home Address option. In other words, the RCoA can be + used as a potential source address for upper layers. Using this + feature, the mobile node will be seen by the correspondent node as a + fixed node while moving within a MAP domain. + + This usage of the RCoA does not have the cost of Mobile IPv6 (i.e., + no bindings or home address options are sent over the Internet), but + still provides local mobility management to the mobile nodes. + Although such use of RCoA does not provide global mobility (i.e., + communication is broken when a mobile host moves to a new MAP), it + would be useful for several applications (e.g., web browsing). The + validity of the RCoA as a source address used by applications will + depend on the size of a MAP domain and the speed of the mobile node. + Furthermore, because the support for BU processing in correspondent + nodes is not mandated in [1], this mechanism can provide a way of + obtaining route optimisation without sending BUs to the correspondent + nodes. + + + + +Soliman, et al. Experimental [Page 13] + +RFC 4140 HMIPv6 August 2005 + + + Enabling this mechanism can be done by presenting the RCoA as a + temporary home address for the mobile node. This may require an + implementation to augment its source address selection algorithm with + the knowledge of the RCoA in order to use it for the appropriate + applications. + +6.6. Location Privacy + + In HMIPv6, a mobile node hides its LCoA from its corresponding nodes + and its home agent by using its RCoA in the source field of the + packets that it sends. As a result, the location tracking of a + mobile node by its corresponding nodes or its home agent is difficult + because they only know its RCoA and not its LCoA. + +7. MAP Discovery + + This section describes how a mobile node obtains the MAP address and + subnet prefix, and how ARs in a domain discover MAPs. Two different + methods for MAP discovery are defined below. + + Dynamic MAP Discovery is based on propagating the MAP option in + Router Advertisements from the MAP to the mobile node through certain + (configured) router interfaces within the routers in an operator's + network. This requires manual configuration of the MAP and also that + the routers receiving the MAP option allow them to propagate the + option on certain interfaces. To ensure a secure communication + between routers, router advertisements that are sent between routers + for Dynamic MAP discovery SHOULD be authenticated (e.g., using AH, + ESP, or SEND). In the case where this authentication is not possible + (e.g., third party routers exist between the MAP and ARs), a network + operator may prefer to manually configure all the ARs to send the MAP + option, as described in this document. + + Manual configuration of the MAP option information in ARs and other + MAPs in the same domain is the default mechanism. It should also be + possible to configure ARs and MAPs to enable dynamic mechanisms for + MAP Discovery. + +7.1. Dynamic MAP Discovery + + The process of MAP discovery can be performed in different ways. + Router advertisements are used for Dynamic MAP Discovery by + introducing a new option. The access router is required to send the + MAP option in its router advertisements. This option includes the + distance vector from the mobile node (which may not imply the real + distance in terms of the number of hops), the preference for this + particular MAP, the MAP's global IP address and subnet prefix + + + + +Soliman, et al. Experimental [Page 14] + +RFC 4140 HMIPv6 August 2005 + + +7.1.1. Router Operation for Dynamic MAP Discovery + + The ARs within a MAP domain may be configured dynamically with the + information related to the MAP options. ARs may obtain this + information by listening for RAs with MAP options. Each MAP in the + network needs to be configured with a default preference, the right + interfaces to send this option on, and the IP address to be sent. + The initial value of the "Distance" field MAY be set to a default + value of 1 and MUST NOT be set to zero. Routers in the MAP domain + should be configured to re-send the MAP option on certain interfaces. + + Upon reception of a router advertisement with the MAP option, the + receiving router MUST copy the option and re-send it after + incrementing the Distance field by one. If the receiving router was + also a MAP, it MUST send its own option, together with the received + option, in the same advertisement. If a router receives more than + one MAP option for the same MAP (i.e., the same IP address in the MAP + option), from two different interfaces, it MUST choose the option + with the smallest distance field. + + In this manner, information about one or more MAPs can be dynamically + passed to a mobile node. Furthermore, by performing the discovery + phase in this way, different MAP nodes are able to change their + preferences dynamically based on the local policies, node overload or + other load-sharing protocols being used. + +7.1.2. MAP Operation for Dynamic MAP Discovery + + A MAP will be configured to send its option or relay MAP options + belonging to other MAPs onto certain interfaces. The choice of + interfaces is done by the network administrator (i.e., manual + configuration) and depends on the network topology. A default + preference value of 10 may be assigned to each MAP. It should be + noted that a MAP can change its preference value at any time due to + various reasons (e.g., node overload or load sharing). A preference + value of zero means the MAP SHOULD NOT be chosen by new mobile nodes. + This value could be reached in cases of node overload or partial node + failures. + + The MAP option is propagated towards ARs in its domain. Each router + along the path to an AR will increment the Distance field by one. If + a router that is also a MAP receives advertisements from other MAPs, + it MUST add its own MAP option and propagate both options to the next + router or to the AR (if it has direct connectivity with the AR). + + + + + + + +Soliman, et al. Experimental [Page 15] + +RFC 4140 HMIPv6 August 2005 + + +7.2. Mobile Node Operation + + When an HMIPv6-aware mobile node receives a router advertisement, it + should search for the MAP option. One or more options may be found + for different MAP IP addresses. + + A mobile node SHOULD register with the MAP having the highest + preference value. A MAP with a preference value of zero SHOULD NOT + be used for new local BUs (i.e., the mobile node can refresh existing + bindings but cannot create new ones). However, a mobile node MAY + choose to register with one MAP over another, depending on the value + received in the Distance field, provided that the preference value is + above zero. + + A MAP option containing a valid lifetime value of zero means that + this MAP MUST NOT be selected by the MN. A valid lifetime of zero + indicates a MAP failure. When this option is received, a mobile node + MUST choose another MAP and create new bindings. Any existing + bindings with this MAP can be assumed to be lost. If no other MAP is + available, the mobile node MUST revert to using the Mobile IPv6 + protocol, as specified in [1]. + + If a multihomed mobile node has access to several ARs simultaneously + (on different interfaces), it SHOULD use an LCoA on the link defined + by the AR that advertises its current MAP. + + A mobile node MUST store the received option(s) in order to choose at + least one MAP to register with. Storing the options is essential, as + they will be compared to other options received later for the purpose + of the movement detection algorithm. + + If no MAP options are found in the router advertisement, the mobile + node MUST use the Mobile IPv6 protocol, as specified in [1]. + + If the R flag is set, the mobile node MUST use its RCoA as the Home + Address when performing the MAP registration. RCoA is then bound to + the LCoA in the MAP's Binding Cache. + + A mobile node MAY choose to register with more than one MAP + simultaneously, or use both the RCoA and its LCoA as care-of + addresses simultaneously with different correspondent nodes. + +8. Updating Previous MAPs + + When a mobile node moves into a new MAP domain, the mobile node may + send a BU to the previous MAP requesting it to forward packets + addressed to the mobile node's new CoA. An administrator MAY + restrict the MAP from forwarding packets to LCoAs outside the MAP's + + + +Soliman, et al. Experimental [Page 16] + +RFC 4140 HMIPv6 August 2005 + + + domain. However, it is RECOMMENDED that MAPs be allowed to forward + packets to LCoAs associated with some of the ARs in neighbouring MAP + domains, provided that they are located within the same + administrative domain. + + For instance, a MAP could be configured to forward packets to LCoAs + associated with ARs that are geographically adjacent to ARs on the + boundary of its domain. This will allow for a smooth inter-MAP + handover as it allows the mobile node to continue to receive packets + while updating the new MAP, its HA and, potentially, correspondent + nodes. + +9. Notes on MAP Selection by the Mobile Node + + HMIPv6 provides a flexible mechanism for local mobility management + within a visited network. As explained earlier, a MAP can exist + anywhere in the operator's network (including the AR). Several MAPs + can be located within the same domain independently of each other. + In addition, overlapping MAP domains are also allowed and + recommended. Both static and dynamic hierarchies are supported. + + When the mobile node receives a router advertisement including a MAP + option, it should perform actions according to the following movement + detection mechanisms. In a Hierarchical Mobile IP network such as + the one described in this document, the mobile node should be: + + - "Eager" to perform new bindings + - "Lazy" in releasing existing bindings + + The above means that the mobile node should register with any "new" + MAP advertised by the AR (Eager). The method by which the mobile + node determines whether the MAP is a "new" MAP is described in + section 9.1. The mobile node should not release existing bindings + until it no longer receives the MAP option (or receives it with a + lifetime of zero) or the lifetime of its existing binding expires + (Lazy). This Eager-Lazy approach, described above, will assist in + providing a fallback mechanism in case of the failure of one of the + MAP routers, as it will reduce the time it takes for a mobile node to + inform its correspondent nodes and HA about its new care-of address. + +9.1. MAP Selection in a Distributed-MAP Environment + + The mobile node needs to consider several factors to optimally select + one or more MAPs, where several MAPs are available in the same + domain. + + + + + + +Soliman, et al. Experimental [Page 17] + +RFC 4140 HMIPv6 August 2005 + + + There are no benefits foreseen in selecting more than one MAP and + forcing packets to be sent from the higher MAP down through a + hierarchy of MAPs. This approach may add forwarding delays and + eliminate the robustness of IP routing between the highest MAP and + the mobile node; therefore, it is prohibited by this specification. + Allowing more than one MAP ("above" the AR) within a network should + not imply that the mobile node forces packets to be routed down the + hierarchy of MAPs. However, placing more than one MAP "above" the AR + can be used for redundancy and as an optimisation for the different + mobility scenarios experienced by mobile nodes. The MAPs are used + independently of each other by the MN (e.g., each MAP is used for + communication to a certain set of CNs). + + In terms of the Distance-based selection in a network with several + MAPs, a mobile node may choose to register with the furthest MAP to + avoid frequent re-registrations. This is particularly important for + fast mobile nodes that will perform frequent handoffs. In this + scenario, the choice of a more distant MAP would reduce the + probability of having to change a MAP and informing all correspondent + nodes and the HA. This specification does not provide an algorithm + for the distance-based MAP selection. However, such an algorithm may + be introduced in future extensions utilising information about the + speed of mobility from lower layers. + + In a scenario where several MAPs are discovered by the mobile node in + one domain, the mobile node may need some sophisticated algorithms to + be able to select the appropriate MAP. These algorithms would have + the mobile node speed as an input (for distance based selection) + combined with the preference field in the MAP option. However, this + specification proposes that the mobile node uses the following + algorithm as a default, where other optimised algorithms are not + available. The following algorithm is simply based on selecting the + MAP that is most distant, provided that its preference value did not + reach a value of zero. The mobile node operation is shown below: + + 1. Receive and parse all MAP options + 2. Arrange MAPs in a descending order, starting with the furthest + away MAP (i.e., MAP option having largest Dist field) + 3. Select first MAP in list + 4. If either the preference value or the valid lifetime fields are + set to zero, select the following MAP in the list. + 5. Repeat step (4) while new MAP options still exist, until a MAP is + found with a non-zero preference value and a non-zero valid + lifetime. + + + + + + + +Soliman, et al. Experimental [Page 18] + +RFC 4140 HMIPv6 August 2005 + + + Implementing the steps above would result in mobile nodes selecting, + by default, the most distant or furthest available MAP. This will + continue until the preference value reduces to zero. Following this, + mobile nodes will start selecting another MAP. + +9.2. MAP Selection in a Flat Mobility Management Architecture + + Network operators may choose a flat architecture in some cases where + a Mobile IPv6 handover may be considered a rare event. In these + scenarios, operators may choose to include the MAP function in ARs + only. The inclusion of the MAP function in ARs can still be useful + to reduce the time required to update all correspondent nodes and the + HA. In this scenario, a mobile node may choose a MAP (in the AR) as + an anchor point when performing a handoff. This kind of dynamic + hierarchy (or anchoring) is only recommended for cases where inter-AR + u0movement is not frequent. + +10. Detection and Recovery from MAP Failures + + This specification introduces a MAP that can be seen as a local Home + Agent in a visited network. A MAP, like a Home Agent, is a single + point of failure. If a MAP fails, its binding cache content will be + lost, resulting in loss of communication between mobile and + correspondent nodes. This situation may be avoided by using more + than one MAP on the same link and by utilising some form of context + transfer protocol between them. Alternatively, future versions of + the Virtual Router Redundancy Protocol [4] or HA redundancy protocols + may allow networks to recover from MAP failures. + + In cases where such protocols are not supported, the mobile node + would need to detect MAP failures. The mobile node can detect this + situation when it receives a router advertisement containing a MAP + option with a lifetime of zero. The mobile node should start the MAP + discovery process and attempt to register with another MAP. After it + has selected and registered with another MAP, it will also need to + inform correspondent nodes and the Home Agent if its RCoA has + changed. Note that in the presence of a protocol that transfers + binding cache entries between MAPs for redundancy purposes, a new MAP + may be able to provide the same RCoA to the mobile node (e.g., if + both MAPs advertise the same prefix in the MAP option). This would + save the mobile node from updating correspondent nodes and the Home + Agent. + + Access routers can be triggered to advertise a MAP option with a + lifetime of zero (indicating MAP failure) in different ways: + + - By manual intervention. + - In a dynamic manner. + + + +Soliman, et al. Experimental [Page 19] + +RFC 4140 HMIPv6 August 2005 + + + ARs can perform Dynamic detection of MAP failure by sending ICMP Echo + request messages to the MAP regularly (e.g., every ten seconds). If + no response is received, an AR may try to aggressively send echo + requests to the MAP for a short period of time (e.g., once every 5 + seconds for 15 seconds); if no reply is received, a MAP option may be + sent with a valid lifetime value of zero. + + This specification does not mandate a particular recovery mechanism. + However, any similar mechanism between the MAP and an AR SHOULD be + secure to allow for message authentication, integrity protection, and + protection against replay attacks. + +11. IANA Considerations + + Section 4 introduces a new flag (M) to the Binding Update specified + in RFC 3775. + + Section 5 introduces a new IPv6 Neighbour Discovery Option called the + MAP Option. IANA has assigned the Option Type value 23 for the MAP + Option within the option numbering space for IPv6 Neighbour Discovery + messages. + +12. Security Considerations + + This specification introduces a new concept to Mobile IPv6, namely, a + Mobility Anchor Point that acts as a local Home Agent. It is crucial + that the security relationship between the mobile node and the MAP is + strong; it MUST involve mutual authentication, integrity protection, + and protection against replay attacks. Confidentiality may be needed + for payload traffic, but is not required for binding updates to the + MAP. The absence of any of these protections may lead to malicious + mobile nodes impersonating other legitimate ones or impersonating a + MAP. Any of these attacks will undoubtedly cause undesirable impacts + to the mobile node's communication with all correspondent nodes + having knowledge of the mobile node's RCoA. + + Three different relationships (related to securing binding updates) + need to be considered: + + 1) The mobile node - MAP + 2) The mobile node - Home Agent + 3) The mobile node - correspondent node + +12.1. Mobile Node-MAP Security + + In order to allow a mobile node to use the MAP's forwarding service, + initial authorisation (specifically for the service, not for the + RCoA) MAY be needed. Authorising a mobile node to use the MAP + + + +Soliman, et al. Experimental [Page 20] + +RFC 4140 HMIPv6 August 2005 + + + service can be done based on the identity of the mobile node + exchanged during the SA negotiation process. The authorisation may + be granted based on the mobile node's identity, or based on the + identity of a Certificate Authority (CA) that the MAP trusts. For + instance, if the mobile node presents a certificate signed by a + trusted entity (e.g., a CA that belongs to the same administrative + domain, or another trusted roaming partner), it would be sufficient + for the MAP to authorise the use of its service. Note that this + level of authorisation is independent of authorising the use of a + particular RCoA. Similarly, the mobile node would trust the MAP if + it presents a certificate signed by the same CA or by another CA that + the mobile node is configured to trust (e.g., a roaming partner). + + HMIPv6 uses an additional registration between the mobile node and + its current MAP. As explained in this document, when a mobile node + moves into a new domain (i.e., served by a new MAP), it obtains an + RCoA, an LCoA and registers the binding between these two addresses + with the new MAP. The MAP then verifies whether the RCoA has not + been registered yet and, if so, it creates a binding cache entry with + the RCoA and LCoA. Whenever the mobile node gets a new LCoA, it + needs to send a new BU that specifies the binding between RCoA and + its new LCoA. This BU needs to be authenticated, otherwise any host + could send a BU for the mobile node's RCoA and hijack the mobile + node's packets. However, because the RCoA is temporary and is not + bound to a particular node, a mobile node does not have to initially + (before the first binding update) prove that it owns its RCoA (unlike + the requirement on home addresses in Mobile IPv6) when it establishes + a Security Association with its MAP. A MAP only needs to ensure that + a BU for a particular RCoA was issued by the same mobile node that + established the Security Association for that RCoA. + + The MAP does not need to have prior knowledge of the identity of the + mobile node nor its Home Address. As a result the SA between the + mobile node and the MAP can be established using any key + establishment protocols such as IKE. A return routability test is + not necessary. + + The MAP needs to set the SA for the RCoA (not the LCoA). This can be + performed with IKE [2]. The mobile node uses its LCoA as the source + address, but specifies that the RCoA should be used in the SA. This + is achieved by using the RCoA as the identity in IKE Phase 2 + negotiation. This step is identical to the use of the home address + in IKE phase 2. + + If a binding cache entry exists for a given RCoA, the MAP's IKE + policy check MUST point to the SA used to install the entry. If the + mobile node's credentials stored in the existing SA do not match the + ones provided in the current negotiation, the MAP MUST reject the new + + + +Soliman, et al. Experimental [Page 21] + +RFC 4140 HMIPv6 August 2005 + + + SA establishment request for such RCoA with an INVALID-ID-INFORMATION + notification [2]. This is to prevent two different mobile nodes from + registering (intentionally or not) the same RCoA. Upon receiving + this notification, the mobile node SHOULD generate a new RCoA and + restart the IKE negotiation. Alternatively, a MAP may decide that, + if a binding cache entry already exists for a particular RCoA, no new + security association should be established for such RCoA; this is + independent of the mobile node credentials. This prevents the mobile + node from being able to re-establish a security association for the + same RCoA (i.e., to change session keys). However, this is not a + major problem because the SA will typically only be used to protect + signalling traffic when a MN moves, and not for the actual data + traffic sent to arbitrary nodes. + + Binding updates between the MAP and the mobile node MUST be protected + with either AH or ESP in transport mode. When ESP is used, a non- + null authentication algorithm MUST be used. + +12.2. Mobile Node-Correspondent Node Security + + Mobile IPv6 [1] defines a return routability procedure that allows + mobile and correspondent nodes to authenticate binding updates and + acknowledgements. This specification does not impact the return + routability test defined in [1]. However, it is important to note + that mobile node implementers need to be careful when selecting the + source address of the HOTI and COTI messages, defined in [1]. The + source address used in HOTI messages MUST be the mobile node's home + address. The packet containing the HOTI message is encapsulated + twice. The inner encapsulating header contains the RCoA in the + source address field and the home agent's address in the destination + address field. The outer encapsulating header contains the mobile + node's LCoA in the source address field and the MAP's address in the + destination field. + +12.3. Mobile Node-Home Agent Security + + The security relationship between the mobile node and its Home Agent, + as discussed in [1], is not impacted by this specification. + +13. Acknowledgments + + The authors would like to thank Conny Larsson (Ericsson) and Mattias + Pettersson (Ericsson) for their valuable input to this document. The + authors would also like to thank the members of the French RNRT + MobiSecV6 project (BULL, France Telecom and INRIA) for testing the + first implementation and for their valuable feedback. The INRIA + HMIPv6 project is partially funded by the French Government. + + + + +Soliman, et al. Experimental [Page 22] + +RFC 4140 HMIPv6 August 2005 + + + In addition, the authors would like to thank the following members of + the working group in alphabetical order: Samita Chakrabarti (Sun), + Gregory Daley (Monash University), Francis Dupont (GET/Enst + Bretagne), Gopal Dommety (Cisco), Eva Gustaffson (Ericsson), Dave + Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf + (Docomo labs), Martti Kuparinen (Ericsson) Fergal Ladley, Gabriel + Montenegro (Sun), Nick "Sharkey" Moore (Monash University) Erik + Nordmark (Sun), Basavaraj Patil (Nokia), Brett Pentland (Monash + University), and Alper Yegin (Samsung) for their comments on the + document. + +14. References + +14.1. Normative References + + [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in + IPv6", RFC 3775, June 2004. + + [2] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, + November 1998. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + +14.2. Informative References + + [4] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July + 2005. + + [5] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating + Denial of Service Attacks which employ IP Source Address + Spoofing", BCP 38, RFC 2827, May 2000. + + [6] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure + Neighbor Discovery (SEND)", RFC 3971, March 2005. + + + + + + + + + + + + + + + + +Soliman, et al. Experimental [Page 23] + +RFC 4140 HMIPv6 August 2005 + + +Appendix A: Fast Mobile IPv6 Handovers and HMIPv6 + + Fast Handovers are required to ensure that the layer 3 (Mobile IP) + handover delay is minimised, thus also minimising, and possibly + eliminating, the period of service disruption which normally occurs + when a mobile node moves between two ARs. This period of service + disruption usually occurs due to the time required by the mobile node + to update its HA using Binding Updates after it moves between ARs. + During this time period the mobile node cannot resume or continue + communications. The mechanism to achieve Fast Handovers with Mobile + IPv6 is described in [5] and is briefly summarised here. This + mechanism allows the anticipation of the layer 3 handover, such that + data traffic can be redirected to the mobile node's new location + before it moves there. + + While the mobile node is connected to its previous Access Router + (PAR) and is about to move to a new Access Router (NAR), the Fast + Handovers in Mobile IPv6 requires in sequence: + + 1) The mobile node to obtain a new care-of address at the NAR while + connected to the PAR. + + 2) New CoA to be used at NAR case: the mobile node to send a F-BU + (Fast BU) to its previous anchor point (i.e., PAR) to update its + binding cache with the mobile node's new CoA while still attached + to PAR. + + 3) The previous anchor point (i.e., PAR) to start forwarding packets + destined for the mobile node to the mobile node's new CoA at NAR + (or old CoA tunnelled to NAR, if new CoA is not applicable). + + 4) Old CoA to be used at NAR case: the mobile node to send a F-BU + (Fast BU) to its previous anchor point (i.e., PAR), after it has + moved and attached to NAR, in order to update its binding cache + with the mobile node's new CoA. + + The mobile node or PAR may initiate the Fast Handover procedure by + using wireless link-layer information or link-layer triggers that + inform that the mobile node will soon be handed off between two + wireless access points respectively attached to PAR and NAR. If the + "trigger" is received at the mobile node, the mobile node will + initiate the layer-3 handover process by sending a Proxy Router + Solicitation message to PAR. Instead, if the "trigger" is received + at PAR, then it will transmit a Proxy Router Advertisement to the + appropriate mobile node, without the need for solicitations. The + basic Fast Handover message exchanges are illustrated in Figure A.1. + + + + + +Soliman, et al. Experimental [Page 24] + +RFC 4140 HMIPv6 August 2005 + + + +-----------+ 1a. HI +-----+ + | | ---------------->| NAR | + | PAR | 1b. HAck | | + +-----------+ <--------------- +-----+ + ^ | ^ + (2a. RtSolPr) | | 2b | + | | Pr | 3. Fast BU (F-BU) + | | RtAdv | 4. Fast BA (F-BACK) + | v v + +------------+ + | MN | + +------------+ - - - - - -> + Movement + + Figure A.1: Fast Mobile IPv6 Handover Protocol + + The mobile node obtains a new care-of address while connected to PAR + by means of router advertisements containing information from the NAR + (Proxy Router Advertisement, which may be sent due to a Proxy Router + Solicitation). The PAR will validate the mobile node's new CoA by + sending a Handover Initiate (HI) message to the NAR. The new CoA + sent in the HI message is formed by appending the mobile node's + current interface identifier to the NAR's prefix. Based on the + response generated in the Handover Acknowledge (HAck) message, the + PAR will either generate a tunnel to the mobile node's new CoA (if + the address was valid) or generate a tunnel to the NAR's address (if + the address was already in use on the new subnet). If the address + was already in use on the new subnet, it is assumed that there will + be no time to perform another attempt to configure the mobile node + with a CoA on the new link. Therefore, the NAR will generate a host + route for the mobile node using its old CoA. Note that message 1a + may precede message 2b or occur at the same time. + + In [5], the ARs act as local Home Agents, which hold binding caches + for the mobile nodes and receive Binding Updates. This makes these + ARs function like the MAP specified in this document. Also, it is + quite possible that the ARs are not directly connected, but + communicate through an aggregation router. Therefore, such an + aggregation router is also an ideal position for the MAP + functionality. These are two ways of integrating the HMIPv6 and Fast + Handover mechanisms. The first involves placing MAPs in place of the + ARs, which is a natural step. The second scenario involves placing + the MAP in an aggregation router "above" the ARs. In this case, [5] + specifies forwarding of packets between PAR and NAR. This could be + inefficient in terms of delay and bandwidth efficiency because + packets will traverse the MAP-PAR link twice and packets will arrive + out of order at the mobile node. Using the MAP in the aggregation + + + + +Soliman, et al. Experimental [Page 25] + +RFC 4140 HMIPv6 August 2005 + + + router would improve the efficiency of Fast Handovers, which could + make use of the MAP to redirect traffic, thus saving delay and + bandwidth between the aggregation router and the PAR. + + +---------+ + | MAP | + +-------------->| | + | +---------+ + | | ^ + | 1a. HI | | + | | | + | | | 1b. HAck + | v | + +---------+ | +---------+ + | | | | NAR | + | PAR | | | | + +---------+ | +---------+ + ^ | | + (2a. RtSolPr) | | 2b | + | | Pr | 3. Fast BU (F-BU) from mobile node to + | | MAP + | | RtAdv | 4. Fast BA (F-BACK) from MAP to + | | | mobile node + | v v + +------------+ + | MN | Movement + +------------+ - - - - - -> + + Figure A.2: Fast Mobile IPv6 Handover Protocol using HMIPv6 + + In Figure A.2, the HI/HAck messages now occur between the MAP and NAR + in order to check the validity of the newly requested care-of address + and to establish a temporary tunnel should the new care-of address + not be valid. Therefore, the same functionality of the Fast Handover + procedure is kept, but the anchor point is moved from the PAR to the + MAP. + + As in the previous Fast Handover procedure, in the network-determined + case the layer-2 "triggers" at the PAR will cause the PAR to send a + Proxy Router Advertisement to the mobile node with the MAP option. + In the mobile-determined case, this is preceded by a Proxy Router + Solicitation from the mobile node. The same layer-2 trigger at PAR + in the network-determined case could be used to independently + initiate Context Transfer (e.g., QoS) between PAR and NAR. In the + mobile-determined case, the trigger at PAR could be replaced by the + reception of a Proxy Router Solicitation or F-BU. Context Transfer + is being worked on in the IETF Seamoby WG. + + + + +Soliman, et al. Experimental [Page 26] + +RFC 4140 HMIPv6 August 2005 + + + The combination of Fast Handover and HMIPv6 allows the anticipation + of the layer 3 handoff, such that data traffic can be efficiently + redirected to the mobile node's new location before it moves there. + However, it is not easy to determine the correct time to start + forwarding traffic from the MAP to the mobile node's new location, + which has an impact on how smooth the handoff will be. The same + issues arise in [5] with respect to when to start forwarding between + PAR and NAR. Packet loss will occur if this is performed too late or + too early with respect to the time in which the mobile node detaches + from PAR and attaches to NAR. Such packet loss is likely to occur if + the MAP updates its binding cache upon receiving the anticipated + F-BU, because it is not known exactly when the mobile node will + perform or complete the layer-2 handover to NAR, relative to when the + mobile node transmits the F-BU. Also, some measure is needed to + support the case in which the mobile node's layer-2 handover + unexpectedly fails (after Fast Handover has been initiated) or when + the mobile node moves quickly back-and-forth between ARs (ping-pong). + Simultaneous bindings [6] provide a solution to these issues. In + [6], a new Simultaneous Bindings Flag is added to the Fast Binding + Update (F-BU) message and a new Simultaneous Bindings suboption is + defined for the Fast Binding Acknowledgement (F-BAck) message. Using + this enhanced mechanism, upon layer-3 handover, traffic for the + mobile node will be sent from the MAP to both PAR and NAR for a + certain period, thus isolating the mobile node from layer-2 effects + such as handover timing, ping-pong, or handover failure and providing + the mobile node with uninterrupted layer-3 connectivity. + + + + + + + + + + + + + + + + + + + + + + + + + +Soliman, et al. Experimental [Page 27] + +RFC 4140 HMIPv6 August 2005 + + +Authors' Addresses + + Hesham Soliman + Flarion Technologies + + EMail: h.soliman@flarion.com + + + Claude Castelluccia + INRIA Rhone-Alpes + 655 avenue de l'Europe + 38330 Montbonnot Saint-Martin + France + + EMail: claude.castelluccia@inria.fr + Phone: +33 4 76 61 52 15 + + + Karim El Malki + Ericsson AB + LM Ericssons Vag. 8 + 126 25 Stockholm + Sweden + + EMail: karim@elmalki.homeip.net + + + Ludovic Bellier + INRIA Rhone-Alpes + 655 avenue de l'Europe + 38330 Montbonnot Saint-Martin + France + + EMail: ludovic.bellier@inria.fr + + + + + + + + + + + + + + + + + +Soliman, et al. Experimental [Page 28] + +RFC 4140 HMIPv6 August 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Soliman, et al. Experimental [Page 29] + |