IETF Mobile IP Working Group Hesham Soliman, Flarion INTERNET-DRAFT Claude Castelluccia, INRIA Karim El-Malki, Ericsson Ludovic Bellier, INRIA June, 2003 Hierarchical Mobile IPv6 mobility management (HMIPv6) Status of this memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@SUNROOF.ENG.SUN.COM mailing list. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that Other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/lid-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This draft introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 reduces the amount of signalling between the Mobile Node, its Correspondent Nodes and its Home Agent. The Mobility Anchor Point described in this document can also be used to improve the performance of Mobile IPv6 in terms of handoff speed. Soliman, Castelluccia, El-Malki, Bellier [Page 1] INTERNET-DRAFT HMIPv6 June,2002 TABLE OF CONTENTS 1. Terminology............................................ 3 2. Introduction and motivation............................ 4 3. Overview of HMIPv6..................................... 5 4. Mobile IPv6 extensions ................................ 7 5. Neighbour Discovery extension û MAP option ............ 9 6. Protocol operations ................................... 10 6.1 Mobile Node Operation.............................. 11 6.2 MAP operation...................................... 13 6.3 Home Agent operation............................... 14 6.4 Correspondent Node operation....................... 14 6.5 Local Mobility Management optimisation within a MAP domain................................. 14 6.6 Location Privacy................................... 14 7. MAP Discovery.......................................... 15 7.1 Dynamic MAP Discovery............................. 15 7.2 Using Router Renumbering for MAP Discovery........ 16 7.3 MN Operation...................................... 17 8. Updating previous Anchor Points......................... 19 9. Special optimisations for sending Binding Updates....... 19 10. Notes on MAP selection by the MN........................ 20 11. Detection and recovery from MAP failures................ 21 12. Security considerations................................. 22 13. Acknowledgements........................................ 24 14. Notice Regarding Intellectual Property Rights........... 24 15. References.............................................. 25 16. Authors' addresses...................................... 26 17. Appendix A: Future Mobile IPv6 and HMIPv6............... 27 Soliman, Castelluccia, El-Malki, Bellier [Page 2] INTERNET-DRAFT HMIPv6 June,2003 1. Terminology This memo uses the terminology described in [1]. In addition, new terms are defined below: Access Router (AR) The Mobile NodesÆ 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 a local binding updates (Binding Update with the M flag set). On-link CoA (LCoA) The LCoA is the on-link CoA configured on an 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. Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [KEYWORDS]. Soliman, Castelluccia, El-Malki, Bellier [Page 3] INTERNET-DRAFT HMIPv6 June,2003 2. Introduction and motivation This draft 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 losses). 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 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 that 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 in achieving seamless mobility (see Appendix A). Furthermore, HMIPv6 allows mobile nodes to hide their location from correspondent nodes and Home Agents while using Mobile IPv6 route optimisation. Soliman, Castelluccia, El-Malki, Bellier [Page 4] INTERNET-DRAFT HMIPv6 June,2003 2. Overview of HMIPv6 This Hierarchical Mobile IPv6 scheme introduces a new function, the Mobility Anchor Point(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 (including fast mobility [12]) within or between different types of access networks. Furthermore, a smooth architectural migration can be achieved from Hierarchical MIPv4 networks, since a dual operation of IPv4 and IPv6 Hierarchies will be possible making use of the similarity in architecture. 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. 2.1 HMIPv6 Operation The network architecture shown below illustrates an example of the use of the MAP in a (visited) network. Soliman, Castelluccia, El-Malki, Bellier [Page 5] INTERNET-DRAFT HMIPv6 June,2003 +-------+ | HA | +-------+ | | +----+ | | CN | | +----+ +-----+ | | | | +---+ | | +-------+ | MAP | RCoA +-------+ | | | +--------+ | | | | +-----+ +-----+ | AR1 | | AR2 | +-----+ +-----+ +----+ | MN | +----+ ------------> Movement Figure 1: Hierarchical Mobile IPv6 domain 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. 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 proposed 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 the same time also in AR1 and AR2. In this case the mobile node can choose the first hop MAP or one further 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. As the mobile node roams within a MAP domain, Soliman, Castelluccia, El-Malki, Bellier [Page 6] INTERNET-DRAFT HMIPv6 June,2003 ARs are configured to announce the same MAP address or addresses. If a change in the advertised MAP's address is received, the mobile node MUST act on the change by performing movement detection and sending the necessary 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 since 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 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 hence result in a 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]. 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. A Router Renumbering [5] extension is also proposed as an alternative for MAP discovery by ARs and MAPs. The same concept (of 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 and binding acknowledgement specified in [1]. 4.1 Local Binding Update A new flag is added: the M flag that indicates MAP registration. When a mobile node registers with the MAP, the M and A flags MUST be set Soliman, Castelluccia, El-Malki, Bellier [Page 7] INTERNET-DRAFT HMIPv6 June,2003 to distinguish this registration from a Home Registration or a BU being sent to 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Description of extensions to the binding update: M If set indicates a MAP registration. It should be noted that this Binding update uses the same Mobility Header type specified in [1]. 4.2 On-link Care-Of address Test option In this section a new option, the On-link Care-Of address Test (OCOT) option is being introduced. This option is included in the binding acknowledgement message. The inclusion of this option is OPTIONAL and SHOULD be configurable in the MAP. However, this option MUST be supported by the mobile node and MAP. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sequence no | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type Option type. TBA. Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. This field MUST be set to 1. Reserved 16-bit field. MUST be set to zero by the sender and ignored by the receiver. Soliman, Castelluccia, El-Malki, Bellier [Page 8] INTERNET-DRAFT HMIPv6 June,2003 Sequence no A 32-bit unsigned integer. This field is arbitrarily set by the MAP when sending a binding acknowledgement and incremented by 1 when sent from the mobile node to the MAP. 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|I|P|V| Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Global IP Address for MAP + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type ICMPv6 option type. TBA. Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. The value 0 is invalid. Nodes MUST silently discard an ND packet that contains an option with length zero. Dist A 4 bit unsigned integer showing the distance from the receiver of the advertisement. Its default value SHOULD be set to one if dynamic MAP discovery is used. The Distance MUST be set to one if the MAP is on the same link as the mobile node. This field need not be interpreted as the number of hops away from 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 indicates that the mobile node Soliman, Castelluccia, El-Malki, Bellier [Page 9] INTERNET-DRAFT HMIPv6 June,2003 MUST form an RCoA based on the prefix in the MAP option. I When set indicates that the mobile node MAY use its RCoA as source address of its outgoing packets P When set indicates that the mobile node MUST use its RCoA as source address of its outgoing packets V When set indicates that reverse tunnelling of outbound traffic, to the MAP, is required if RCoA is used as a source address in outgoing packets. 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 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. Hence the need for having 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 Soliman, Castelluccia, El-Malki, Bellier [Page 10] INTERNET-DRAFT HMIPv6 June,2003 and an on-link CoA (LCoA). These addresses are 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 MNÆ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 supported by the MN for this operation. The MN MUST silently ignore binding acknowledgements that do not contain a routing header type 2 which includes the mobile nodeÆs RCoA. The MAP MAY include an OCOT option in the binding acknowledgement. If this option is included, the mobile node MUST return the binding acknowledgement to the MAP with the OCOT option included, after incrementing the sequence number in the OCOT option by 1. This option is included to allow the MAP to ensure that mobile node is located on the link that it claims to be on and is not attempting a flooding attack directed towards another node on another link. 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 home address option is set to the Home Address, the care-of address (RCoA) can be found in the source address field or the alternate-CoA option. The MN may also send a similar BU (i.e. that specifies the binding between the Home Address and the RCoA) to its current correspondent nodes. If the I flag is set in the MAP option, the mobile node MAY use its RCoA as a source address for the BU. If the P flag is set in the MAP option, the mobile node MUST use RCoA as a source address. If the mobile node uses its RCoA as a source address, the alternate- CoA option will not be required. If both the P and V flags are set, the mobile node MUST use RCoA as a source address and tunnel all outgoing packets to the MAP. The source address in the outer header is the mobile nodeÆs LCoA and the destination address is the MAPÆs address. This is done to allow for cases where a network administrator wants mobile nodes to use RCoA as a source, while keeping ingress filter configurations in the ARs unchanged. 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, received in the Binding Acknowledgement. In order to speed up the handover between MAPs, a mobile node may send a local BU to its previous MAP specifying its new LCoA. Packets Soliman, Castelluccia, El-Malki, Bellier [Page 11] INTERNET-DRAFT HMIPv6 June,2003 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. 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 stays 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. A network operator may prefer to hide the mobile nodeÆs LCoA from nodes outside the MAP domain. To ensure this, a MAP option can be sent with the P flag set. In this case, the mobile node MUST use its RCoA as the source address of its BU (no alternate-CoA option is needed) to its HA and correspondent nodes. It MUST also use its RCoA as the source address for its outgoing packets. On the other hand, a mobile node may prefer to hide its location from the correspondent nodes it communicates with and the HA. To achieve this, the mobile node should ensure that it does not provide both its identity and location to any of the correspondent nodes. Since the implied identity of the mobile node is included in every route- optimised packet (a Home Address), the mobile node should ensure that it does not provide its exact location to the correspondent nodes and HA. Hence, the mobile node should use its RCoA as a source address for all its outgoing packets. This can be done if the I or P flags are set in the MAP option. Otherwise location privacy can not be provided in this manner. If the V flag is set (in addition to the P or I flags), the mobile node MUST tunnel all outgoing packets to the MAP. This is needed to allow for location privacy while keeping ingress filter configuration in the ARs unchanged. 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. However, the mobile node MUST select the source address in outgoing packets based on the content of the P, I and V flags in the MAP option. Soliman, Castelluccia, El-Malki, Bellier [Page 12] INTERNET-DRAFT HMIPv6 June,2003 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. Since RCoA is used as a source address for outgoing packets, the mobile node must consider the content of the P, I and V flags to decide whether packets should be sent directly with RCoA as a source, or tunnel packets to the MAP. When tunnelling outgoing packets to the MAP, the source address in the outer header is the mobile nodeÆs LCoA and the destination address is the MAPÆs 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. 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. When sending a binding acknowledgement to the mobile node, the MAP MAY include the OCOT option. This option is needed to confirm the mobile nodeÆs location on the claimed link. If this option is included, the MAP will expect the mobile node to return the binding acknowledgement message after incrementing the sequence number in the OCOT option by 1. Until the mobile node returns the binding acknowledgement, the MAP MUST tentatively store the binding in its binding cache. When the binding acknowledgement, containing the sequence number +1, is received from the mobile node, the MAP MUST confirm the binding cache entry and continue forwarding packets to the mobile nodeÆs LCoA for the lifetime of the binding. The inclusion of the OCOT option in the binding acknowledgement SHOULD be configurable, but MUST be supported by the MAP. 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. This is required independently of the settings of the P, I, or V flags. Soliman, Castelluccia, El-Malki, Bellier [Page 13] INTERNET-DRAFT HMIPv6 June,2003 The MAP acts as a HA for the RCoA. Packets addressed to the RCOA are intercepted by the MAP, using proxy Neighbour Advertisement, encapsulated and routed to the mobile nodeÆs LCoA. This operation is identical to that of the HA described in [1]. 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, if the I or P flags are set in the MAP option, a mobile node can use its RCoA as the source of its packets without using a Home Address option. It may also use the RCoA as source address for the local BU to register the binding between its LCoA and RCoA with the local MAP. As a result the mobile node is seen by the correspondent node as a fixed node while moving within a MAP domain. This use of the RCoA can be useful as it does not have the cost of Mobile IPv6 (i.e. no bindings or home address options are sent over the Internet) but still provides some 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) communicating with other nodes for some period of time depending on the size of a MAP domain and the speed of the mobile node. Furthermore, since 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. 6.6 Location Privacy In HMIPv6, a mobile node MAY choose to hide 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 Soliman, Castelluccia, El-Malki, Bellier [Page 14] INTERNET-DRAFT HMIPv6 June,2003 tracking of a mobile node by its corresponding nodes or its home agent is difficult since they only know its RCoA and not its LCoA. The MN may achieve such location privacy as described in section 6.1. 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 hierarchy of routers. This would require manual configuration of the MAP and the routers receiving the MAP option to 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 by AH or ESP. In the case where this authentication is not possible (e.g. third party routers between the MAP and ARs), a network operator may prefer to manually configure all the ARs to send the MAP option or use the router renumbering mechanism for MAP discovery, as shown in this document. Another method based on Router Renumbering [5] is also described in section 7.2. In this method, no manual configuration is required for routers within the domain. The MAP option is sent directly from a central node to all ARs within a MAP domain. This method is best suited to large networks where manually configuring all routers within a hierarchy can be a significantly tedious operation. On the other hand, when using this method, any subsequent changes in the MAP optionÆs parameters (e.g. preference) would require manual intervention. 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 either dynamic or Router Renumbering mechanisms for MAP Discovery. 7.1 Dynamic MAP Discovery The process of MAP discovery can be performed in many 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 the MAP's subnet prefix. In addition, the option contains some flags showing the MAPÆs mode of operation and other information. Soliman, Castelluccia, El-Malki, Bellier [Page 15] INTERNET-DRAFT HMIPv6 June,2003 7.1.2 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 one. 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 smaller distance field. In this manner, information about a MAP at a certain level in a hierarchy 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.3 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 that 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 down the hierarchy. Each router along the path to the access router 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 level in the hierarchy. 7.2 Using Router Renumbering for MAP discovery The Router Renumbering (RR) mechanism described in [2] defines a set of messages that can be used to renumber certain interfaces on a router without manual configuration of such router. RR messages are authenticated and protected against replay attacks. The same concept Soliman, Castelluccia, El-Malki, Bellier [Page 16] INTERNET-DRAFT HMIPv6 June,2003 can be used to configure a router to propagate the MAP option on certain interfaces. A new PCO command, PROPAGATE, is defined below. This command is part of the Prefix Code Operation (PCO) and is included in the Match Prefix part of the message. A PCO message sent to a router with the PROPAGATE command MUST contain one or more MAP options in the Use Prefix part of the message. Upon reception of this message, a router will propagate the MAP option on the designated interface. This mechanism can be used to configure ARs to advertise one or more MAP options. This is best suited to large networks or for cases where third party networks may exist between the MAP and ARs. Furthermore, unlike the Dynamic MAP discovery mechanism described earlier, this method does not require each router in the MAP domain to understand the MAP option. 7.2.1 Extension to the Match Prefix Part of RR 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode | OpLength | Ordinal | MatchLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MinLen | MaxLen | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + MatchPrefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extended Fields: OpCode An unsigned 8-bit field specifying the operation to be performed when the associated MatchPrefix matches an interface's prefix or address. Values are: 1 the ADD operation 2 the CHANGE operation 3 the SET-GLOBAL operation 4 the PROPAGATE operation (new code). Soliman, Castelluccia, El-Malki, Bellier [Page 17] INTERNET-DRAFT HMIPv6 June,2003 7.3 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 IP addresses or subnet prefixes. 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). A mobile node MAY however 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 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) and 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 move 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. If the I flag is set the mobile node MAY choose to use RCoA as a source address in its outgoing packets depending on whether location privacy (with respect to the correspondent nodes and HA) is required by the mobile node or user. This choice can be made by default policies in the mobile node or configurable options by the user. If the P flag is set, the mobile node MUST use RCoA as a source address. This can be due to the network operatorÆs requirements of not exposing certain prefixes to the external Internet. The V flag indicates that the mobile node MUST tunnel its outbound traffic to the MAP if its RCoA is used as a source address in outbound packets. This flag is only useful if the P or I flags are set. The aim of this flag is to avoid any potential ingress filtering Soliman, Castelluccia, El-Malki, Bellier [Page 18] INTERNET-DRAFT HMIPv6 June,2003 problems in the ARs (in cases where the ingress filter cannot be manually configured to allow an RCoA prefix). A mobile node MAY choose to register with more than one MAP simultaneously or use both MAP address and its own address as CoAs simultaneously with different correspondent nodes provided the setting of the P and I flags allow such choices. 8. Updating previous Anchor Points When a mobile host moves into a new MAP domain, the mobile node may send a BU to the previous MAP requesting to forward packets addressed to the mobile nodeÆs new CoA. An administrator MAY restrict the MAP from forwarded packets to LcoAs outside the MAPÆs 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. Special optimisations for sending Binding Updates In some link layers where the MAC acquisition time (before sending each frame) is significant, it maybe useful for mobile nodes to encapsulate the IP packet including a BU sent to the HA inside the IP packet including a BU sent to the MAP. The decision on whether this optimisation should be used or not is left to the mobile node implementation, depending on the type of underlying L2 used for transmission. It should be noted however, that the use of such encapsulation may cause extra signalling in case the Home registration was rejected by the HA or MAP (e.g. if DAD failed and the mobile node is required to provide a new Home address or if the MAP rejected the BU, forcing the mobile node to re-register with the HA). Furthermore, the mobile node might receive a binding acknowledgement from the MAP that contains a lower lifetime than that received from the Home Agent. Hence, mobile nodes should be careful when utilising this optimisation. Therefore by default the MN SHOULD only send a BU containing its RCoA to the HA and correspondent nodes after having received a positive local BU acknowledgement from the MAP. This may be changed if it is proven that the change will not impact the protocol behaviour. Soliman, Castelluccia, El-Malki, Bellier [Page 19] INTERNET-DRAFT HMIPv6 June,2003 10. 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 on any level in a hierarchy including the AR. Several MAPs can be located within a hierarchy 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 draft, 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 5. 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 would reduce the time it takes for a mobile node to inform its correspondent nodes and HA about its new COA. 10.1 MAP selection in a distributed-MAPs environment The MN needs to consider several factors to optimally select one or more MAPs, where several MAPs are available in the same domain. 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. Hence, 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 from 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 further MAP would reduce the probability of having to change a MAP and informing all correspondent nodes and the Soliman, Castelluccia, El-Malki, Bellier [Page 20] INTERNET-DRAFT HMIPv6 June,2003 HA. This specification does not provide an algorithm for the distance-based MAP selection. However, such 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 may not be available. The following algorithm is simply based on selecting the furthest possible MAP, 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 MAP (i.e. MAP option having largest Dist field) 3. Select first MAP in list 4. If the Preference value or the valid lifetime are set to zero, select the following MAP in the list. 5. Repeat step (4) while new MAP options still exist. Implementing the steps above would result in mobile nodes selecting by default the most distant or ôfurthestö available MAP by default. This will continue to take place, until the preference value reduces to zero. Following this, mobile nodes will start selecting another MAP. 10.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 movement is not frequent. 11. Detection and recovery from MAP failures This specification introduces a MAP which 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 with the use of more than one MAP on the same link and utilising some form of context transfer protocol between them. Alternatively, future versions of the Soliman, Castelluccia, El-Malki, Bellier [Page 21] INTERNET-DRAFT HMIPv6 June,2003 Virtual Router Redundancy Protocol [10] 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. It will also need to inform correspondent nodes and the Home Agent if its RCoA has changed. Note that 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. Dynamic detection of MAP failure can be done 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. 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 of strong nature; 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, 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 Soliman, Castelluccia, El-Malki, Bellier [Page 22] INTERNET-DRAFT HMIPv6 June,2003 3) The mobile node - correspondent node 12.1 Mobile node û MAP security 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, a LCoA and registers the binding between this two addresses with the new MAP. The MAP then verifies whether the RCoA has not been registered yet and if not creates a BCE with the RCoA and LCoA. Whenever the mobile node gets a new LCoA, it needs to send a new binding update that specifies the binding between RCoA and its new LCoA. This binding update 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 since the RCoA is temporary and is not bound to a particular node, a mobile node does not have to prove that it owns its RCoA (as in Mobile IPv6) when it establishes a Security Association with its MAP. A MAP only needs to make sure that when it receives a BU for a RCoA, this BU was issued by the same mobile node that established the Security Association. The MAP does not need to know the identity of the mobile node nor its Home Address. As a result the SA between the mobile node and the MAP can be simply 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 [6]. The mobile node uses its LCoA as source address but specifies that the RCoA should be used in the SA. This is achieved by using the RCoA as the client identity in IKE Phase 2 negotiation (Quick mode). 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 existing SA does not match the new SA which the MN is trying to establish, then a MAP MUST reject the new SA establishment request for such RCoA with an INVALID-ID-INFORMATION notification [6]. 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. 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 Soliman, Castelluccia, El-Malki, Bellier [Page 23] INTERNET-DRAFT HMIPv6 June,2003 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 RCoA. When sending this message, the mobile node need to be aware that the message may need to be tunnelled to the MAP, which will de-capsulate it and send it to the Home Agent (the destination address in the tunnelled HOTI message). The decision about whether such message should be tunnelled to the MAP or not, depends on the contents of the V, P and I flags included in the MAP option. If either the P or I flag is set, and the V flag is set, the mobile node must tunnel all outgoing packets to the MAP. For the HOTI message, this would mean that the message is tunnelled twice, once to the Home Agent, then tunnelled again to the MAP. If either the P or I flag is set, and the V flag is not set, the mobile node does not need to tunnel these packets to the MAP. The same conditions apply to the COTI message. If neither the P or I flag is set in the MAP option, the mobile node is not required to tunnel packets to the MAP. However, the HOTI and COTI messages MUST be tunnelled through the MAP. This is needed to avoid cases where ingress filtering in the AR is not configured to support the use of RCoA as a source address. The MAP is required to accept tunnelled packets from the mobile node independently of the settings of the P, I and V flags. 12.3 Mobile node û Home Agent security The security relationship between the mobile node and its Home Agent is not impacted by this specification. The tunnel end point for the Home Agent is the mobile nodeÆs RCOA. If either the P or I flag is set, and the V flag is set, the mobile node must encapsulate packets to the MAP. When applying this to the tunnel interface to the Home Agent, it would mean that double encapsulation is necessary for both: outgoing and incoming packets. 13. Acknowledgements The authors would like to thank Conny Larsson (Ericsson) and Mattias Pettersson (Ericsson) for their valuable input to this draft. 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. In addition, the authors would like to thank the following members of the working group in alphabetical order: Samita Chakrabarti (Sun), Greg Daley (Monash University), Francis Dupont (Ernst-Bretagne), Gopal Dommety (Cisco), Eva Gustaffson (Ericsson), Dave Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf (Docomo labs), Soliman, Castelluccia, El-Malki, Bellier [Page 24] INTERNET-DRAFT HMIPv6 June,2003 Martti Kuparinen (Ericsson) Fergal Ladley, Erik Nordmark (Sun), Basavaraj Patil (Nokia) and Alper Yegin (Docomo labs) for their comments on the draft. 14. Notice Regarding Intellectual Property Rights see http://www.ietf.org/ietf/IPR/ERICSSON-hmipv6.txt 15. References Normative [1] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-21.txt. [2] M. Crawford ôRouter Renumbering for IPv6ö. RFC 2984. [3] S. Thomson and T. Narten "IPv6 Stateless Address Autoconfiguration". RFC 2462. [4] T. Narten, E. Nordmark and W. Simpson ô Neighbour Discovery for IP version 6 ô. RFC 2461. [5] S. Deering and B. Hinden, ôInternet Protocol version 6 (IPv6) specificationö. RFC 2460 [6] D. Harkins and D. Carrel, ôThe Internet Key Exchange (IKE)ö. RFC 2409. [7] S. Kent and R. Atkinson, ôIP Authentication Headerö. RFC 2402 [8] S. Kent and R. Atkinson, ôIP Encapsulating Security Payloadö. RFC 2406 [9] S. Kent and R. Atkinson, ôSecurity Architecture for the Internetö. RFC 2401 [10] A. Conta and S. Deering, ôGeneric Packet Tunneling in IPv6 Specificationö RFC 2473. [11] S. Bradner, ôKeywords to use in RFCs to Indicate Requirement Levelsö. RFC2119 Non-Normative [10] S. Knight, et al, ôVirtual Router Redundancy Protocolö. RFC 2338. [11] K. ElMalki, Editor, et al, "Low latency Handoffs in Mobile IPv4". draft-ietf-mobileip-lowlatency-handoffs-v4-00. work in progress. Soliman, Castelluccia, El-Malki, Bellier [Page 25] INTERNET-DRAFT HMIPv6 June,2003 [12] R. Koodli, Editor, et al,"Fast Handovers for Mobile IPv6", draft-ietf-mobileip-fast-mipv6-05.txt. Work in progress. [13] K. ElMalki and H. Soliman, ôSimultaneous Bindings for Mobile IPv6 Fast Handoffsö. draft-elmalki-mobileip-bicasting-v6-03. Work in progress. [14] P. Ferguson and D. Senie, ôNetwork Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofingö. RFC2267 16. Authors' Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Megisto Systems,Inc 6000 Connection Drive 20251 Century Blvd Irving, TX 75039 Germantown, MD 20874 USA USA Phone: +1 972-894-6709 Phone: +1 301-444-1700 EMail: Raj.Patil@nokia.com EMail: proberts@megisto.com Fax : +1 972-894-5349 Fax: +1 301-515-3675 Questions about this memo can also be directed to: Hesham Soliman Flarion Technologies E-mail: 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 fax: +33 4 76 61 52 52 Karim El Malki Ericsson Radio Systems AB LM Ericssons Vag. 8 126 25 Stockholm SWEDEN Phone: +46 8 7195803 Fax: +46 8 7190170 Soliman, Castelluccia, El-Malki, Bellier [Page 26] INTERNET-DRAFT HMIPv6 June,2003 E-mail: Karim.El-Malki@era.ericsson.se Ludovic Bellier INRIA Rhone-Alpes 655 avenue de l'Europe 38330 Montbonnot Saint-Martin France email: ludovic.bellier@inria.fr phone: +33 4 76 61 52 15 fax: +33 4 76 61 52 52 17. 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 [12] 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 old Access Router (oAR) 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 oAR 2) New CoA to be used at nAR case: the mobile node to send a F-BU (Fast BU) to its old anchor point (i.e. oAR) to update its binding cache with the mobile nodeÆs new CoA while still attached to oAR 3) The old anchor point (i.e. oAR) 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 old anchor point (i.e. oAR), 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 oAR may initiate the Fast Handover procedure by using wireless link-layer information or link-layer ôtriggersö which inform that the mobile node will soon be handed off between two wireless access points respectively attached to oAR 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 oAR. Instead if the ôtriggerö is received at Soliman, Castelluccia, El-Malki, Bellier [Page 27] INTERNET-DRAFT HMIPv6 June,2003 oAR 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. +-----------+ 1a. HI +-----+ | | ---------------->| nAR | | oAR | 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 oAR by means of router advertisements containing information from the nAR (Proxy Router Advertisement which may be sent due to a Proxy Router Solicitation). The oAR 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 oAR 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, so 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 [12], 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. Such an aggregation router is therefore 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, [12] specifies forwarding of packets between oAR and nAR. This could be inefficient in terms of delay, bandwidth efficiency since packets will traverse the MAP-oAR link twice and packets arriving out of order at the Soliman, Castelluccia, El-Malki, Bellier [Page 28] INTERNET-DRAFT HMIPv6 June,2003 mobile node. Using the MAP in the aggregation 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 oAR. +---------+ | MAP | +-------------->| | | +---------+ | | ^ | 1a. HI | | | | | | | | 1b. HAck | v | +---------+ | +---------+ | | | | nAR | | oAR | | | | +---------+ | +---------+ ^ | | (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 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 oAR to the MAP. As in the previous Fast Handover procedure, in the network-determined case the layer-2 ôtriggersö at the oAR will cause the oAR 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 oAR in the network-determined case could be used to independently initiate Context Transfer (e.g. QoS) between oAR and nAR. In the mobile-determined case the trigger at oAR 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. The combination of Fast Handover and HMIPv6 allows the anticipation of the layer 3 handoff such that data traffic can be efficiently Soliman, Castelluccia, El-Malki, Bellier [Page 29] INTERNET-DRAFT HMIPv6 June,2003 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 arises in [12] with respect to when to start forwarding between oAR 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 oAR and attaches to nAR. Such packet loss is likely to occur if the MAP updates its binding cache upon receiving the ôanticipatedö F-BU, since it is not known when exactly 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 [13] provides a solution to these issues. In [13] a new Simultaneous Bindings Flag is added to the Fast Binding Update (F-BU) message and a new Simultaneous Bindings suboption is defined for 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 oAR 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, Castelluccia, El-Malki, Bellier [Page 30]