IETF Mobile IP Working Group Hesham Soliman, Ericsson INTERNET-DRAFT Claude Castelluccia, INRIA Karim El-Malki, Ericsson Ludovic Bellier, INRIA September, 2000 Hierarchical MIPv6 mobility management Status of this memo 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/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This draft introduces some extensions for MIPv6 and neighbour discovery to allow for the introduction of a hierarchical MIPv6 mobility management model. The proposed hierarchical mobility management for MIPv6 will reduce the amount of signalling to CNs and the HA and may also improve the performance of MIPv6 in terms of handoff speed. Moreover, HMIPv6 is well-suited to implement access control and handoffs between different access technologies. Soliman, Castelluccia, El-Malki, Bellier [Page 1] INTERNET-DRAFT HMIPv6 ****,2000 TABLE OF CONTENTS 1. Introduction.............................................3 2. Overview of HMIPv6.......................................3 3. Neighbour Discovery extension - MAP option message ......7 4. MIPv6 extension - BU extension ..........................8 5. Basic mode: Supporting MNs with a Regional COA (RCOA)....8 5.1 MN Operations........................................9 5.2 MAP operations.......................................9 5.3 HA operations.......................................10 5.4 CN operations.......................................10 6. Extended mode: Using the MAP COA as an alternate-COA....10 6.1 MN Operations.......................................11 6.2 MAP operations......................................12 6.3 HA operations.......................................12 6.4 CN operations.......................................13 7. Comparison between the two MAP modes....................13 8. MAP Discovery...........................................14 8.1 Dynamic MAP discovery ............................15 8.2 Using Router Renumbering for MAP discovery........15 8.3 New Destination option for MAP discovery..........16 8.4 MN operations.....................................17 9. Smooth Handoffs.........................................18 10. Notes on MAP selection by the MN........................19 11. Security Considerations.................................19 12. AAA Considerations for IPv6.............................19 13. Acknowledgements........................................20 14. Notice Regarding Intellectual Property Rights...........20 15. References..............................................20 16. Appendix A: Future additions............................21 17. Authors' addresses......................................21 Soliman, Castelluccia, El-Malki, Bellier [Page 2] INTERNET-DRAFT HMIPv6 ****,2000 1. Introduction This draft introduces the concept of a Hierarchical Mobile IPv6 network, utilizing a new node called the Mobility Anchor Point (MAP). In Mobile IPv6 there are no Foreign Agents, but there is still the need to provide a central point to assist with MIP handoffs. Similarly to MIPv4, Mobile IPv6 can benefit from reduced mobility signalling with external networks by employing a local hierarchical structure. For this reason a new Mobile IPv6 node, called the Mobility Anchor Point (MAP), is used and can be located at any level in a hierarchical Mobile IPv6 network including the Access Router (AR). Unlike FAs in IPv4, a MAP is not required on each subnet. Two different MAP modes are proposed in this memo. A MN may use a MAP's address as an alternate-care-of address (COA) (Extended mode) or form a Regional COA (RCOA) on the MAP's subnet (Basic mode) while roaming within a hierarchical (MAP) domain, where such a domain involves all access routers advertising that MAP. The two options are described in detail in chapters 5 and 6. The MAP will limit the amount of Mobile IPv6 signalling outside the domain and will support Fast Handoffs to help Mobile Nodes in achieving seamless mobility. Other advantages of the introduction of the MAP functionality are covered in chapter 2. The aim of introducing the hierarchical mobility management model in MIPv6 is to enhance the network performance while minimising the impact on MIPv6 or other IPv6 protocols. This draft assumes the generic case of a scaleable multi-level hierarchy. 2. Overview of HMIPv6 This hierarchical MIPv6 scheme introduces a new function, the Mobility Anchor Point(MAP), and minor extensions to the MN and the Home Agent operations. The CN operation will not be affected. The introduction of the MAP concept minimises the latency due to handoffs between access routers. Furthermore, the addition of bicasting to a MAP allows for Fast Handoffs [4] which will minimise the packet losses due to handoffs and consequently improve the throughput of best effort services and performance of real time data services over a radio interface. Just like MIPv6, this solution is independent of the underlying access technology, allowing Fast Handoffs 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. Soliman, Castelluccia, El-Malki, Bellier [Page 3] INTERNET-DRAFT HMIPv6 ****,2000 The introduction of the MAP concept will further diminish signalling generated by MIPv6 over a radio interface. This is due to the fact that a MN only needs to perform one local BU (MAP) when changing its layer 3 access point within the MAP domain. The advantage can be easily seen when compared to other scenarios (no MAP) where at least two BUs (Binding Updates) will be sent (to one CN and HA). A MAP may also interact with the AAA protocol to perform key distribution during handoffs and eliminate the need for re-authentication as explained in chapter 11. The MAP will receive all packets on behalf of the MN it is serving and will encapsulate and forward them directly to the MN's current address. If the MN changes its current address within a local MAP domain, it only needs to register the new address with the MAP (since the global CoA does not change). This makes the MN's mobility transparent to the CNs it is communicating with. The MAP can also be used to execute a Fast Handoff between ARs as explained in [4]. When the MN uses a RCoA, a MAP acts essentially as a local Home Agent (HA) for the MN. A MAP domain's boundaries are defined by the Access Routers (ARs) advertising the MAP information to the attached Mobile Nodes. The control of a MAP's mode of operation (as an alternate-CoA or a local HA) is left to the network administrator's discretion. The detailed extensions to MIPv6 and operations of the different nodes will be explained later in this document. It should be noted that the MAP concept is simply an extension to the MIPv6 protocol. Hence an HMIPv6-aware MN with an implementation of MIPv6 MAY choose to use the MAP or simply use the standard MIPv6 implementation as it sees fit. Furthermore, a MN can at any time stop using the MAP. This provides great flexibility, both from a MN or a network operations point of view. The network architecture shown below illustrates an example of the use of the MAP in a foreign network. Soliman, Castelluccia, El-Malki, Bellier [Page 4] INTERNET-DRAFT HMIPv6 ****,2000 _______ | HA | |_______| _______ \ | CN | \ |_______| \___ | \ | \ ____| _\___|_ | | | MAP | |_______| / \ / \ / \ / \ ____/____ \_________ | | | | | AR1/MAP | | AR2/MAP | |_________| |_________| | | | | __\/____ \/ | | | MN | |________| __________________\ Movement / Figure 1: Hierarchical MIPv6 domain In Figure 1, the MAP can help in providing seamless mobility for the MN as it moves from Access Router 1 (AR1) to Access Router 2 (AR2), while communicating with the CN. It is possible to use multi-level hierarchies of routers and implement the MAP functionality in AR1 and AR2 if needed. It should be noted that AR1 and AR2 could be two points of attachment in the same RAN (Radio Access Network) or in different RANs. Upon arrival in a foreign domain, the MN will discover the global address of the MAP. This address is stored in the Access Routers and communicated to the MN via Router Advertisements. The discovery phase will also inform the MN of the distance of the MAP from the MN. For example, the MAP could also be implemented in AR1 and AR2, in which case the MN can choose the first hop MAP, second hop MAP, or both. A Router advertisement extension is proposed later in this document for MAP discovery.Router Renumbering [5] is also proposed for MAP discovery as shown below. If a router advertisement is used for MAP Soliman, Castelluccia, El-Malki, Bellier [Page 5] INTERNET-DRAFT HMIPv6 ****,2000 discovery, as described in this document, all ARs belonging to the MAP domain MUST advertise the MAP's IP address. The same concept should be used if other methods of MAP discovery are introduced in future. The MAP option in the router advertisement should inform the MN about the chosen mode of operation for the MAP. The process of MAP discovery continues as the MN moves from one subnet to the next. As the MN roams within a MAP's domain, the same information announcing the MAP should be received. If a change in the advertised MAP's address is received, the MN should act on the change by sending the necessary Binding Updates to its HA and CNs. If the MN is not HMIPv6-aware then the discovery phase will fail resulting in the MN using the MIPv6 [1] protocol for its mobility management. On the other hand, if the MN is HMIPv6-aware it MAY choose to use its HMIPv6 implementation. If so, the MN will first need to register with a MAP by sending it a BU containing its Home Address and on-link address (LCOA). In the case where the MN uses the MAP as an alternate-COA, the Home address used in the BU is the MNs Home Address on its home subnet. On the other hand, if the MN is using a Regional COA (RCOA), 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 CNs or HAs. The MN will always need to know the original sender of any received packets. In the case where the MAP is used as an alternate-COA, all packets will be tunnelled by the MAP, hence the MN is not always able to determine whether the packets were originally tunnelled from the Home Agent or received directly from a CN. This knowledge is needed by the MN to decide whether a BU needs to be sent to a CN in order to initiate route optimisation. For this purpose a check needs to be performed on the internal packet's routing header to find out whether the packet was tunnelled by the HA or originated from a CN using route optimisation instead. If a routing header exists in the internal packet, containing its alternate-COA (MAP address or RCOA) and the MN's Home Address as the final destination, then route optimisation was used. Otherwise, triangular routing through the HA was used. This check on the routing header (as opposed to the check on the source of the tunnelled packets in [1]) can be used for both modes of operation as well as the standard operation described in [1]. To use the network bandwidth in a more efficient manner, a MN may decide to register with more than one MAP simultaneously and use each MAP address for a specific group of CNs. For example, in Fig 1, if the CN happens to exist on the same link as the MN, 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 MN can also use its current Soliman, Castelluccia, El-Malki, Bellier [Page 6] INTERNET-DRAFT HMIPv6 ****,2000 on-link address (LCOA) as a COA. 3. Neighbour Discovery extension - The MAP option message format The following figure illustrates the new MAP option. 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 | Distance | Pref | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Plen |R|M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Global IP Address for MAP + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The alignment requirements for this option is 8n. Fields: Type Message 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. Distance An 8 bit unsigned integer showing the distance from the receiver of the advertisement. It MUST be set to one in the initial advertisement, if dynamic MAP discovery is used. Pref The preference of a MAP. An 8 bit unsigned integer. A value of 255 means lowest preference. Plen The prefix length in this option. The prefix length in this option. A prefix length value of 128 indicates that the MAP address should be used as an alternate-COA. A prefix length Soliman, Castelluccia, El-Malki, Bellier [Page 7] INTERNET-DRAFT HMIPv6 ****,2000 value different from 128 indicates that the MN should configure its RCoA using the prefix lenght and the MAP address. R Indicates that the MN MUST form a RCOA. If this flag is set the Plen value MUST be less than 128. M Indicates that the MN MUST use the MAP's Own IP address as an alternate-COA Global Address One of the MAP's global addresses. To ensure a secure communication between routers, router advertisements containing the MAP option SHOULD be authenticated by AH. In the case where this authentication is not possible, a network operator may prefer to manually configure all the ARs to send the MAP option. 4. MIPv6 extension - Binding Update This section outlines the extensions proposed to the BU option used by the MN in MIPv6. A new flag is added: the M flag that indicates MAP registration. When a MN registers with the MAP, the M flag MUST be set to distinguish this registration from a Home Registration or a BU being sent to a CN. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|R|D|M|B|Res| Prefix Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- Description of extensions to the BU option: M If set indicates a MAP registration. B When set indicates a request for bicasting all packets to both COAs of the MN. This BU will add another COA to the MAP's Binding Cache. This flag MUST only be set if the M flag is set. Res 2 bit reserved field Soliman, Castelluccia, El-Malki, Bellier [Page 8] INTERNET-DRAFT HMIPv6 ****,2000 5. Basic Mode: Supporting Mobile Nodes with a Regional COA (RCOA) This section defines a basic mode of HMIPv6 that is required to support Mobile Nodes. In the basic mode, the MN would have two addresses, a RCOA on the MAP's subnet and an on-link COA (LCOA). This RCOA is formed in a stateless manner by combining the MAP's subnet prefix received in the MAP option with the MNs interface identifier. As illustrated in this section, the basic mode is very simple in the sense that it only requires special treatment at the Mobile Nodes. The HA is unchanged. The MAP is merely a "local" HA that maps the MN's RCoA to an LCoA. 5.1 MN Operations When a MN moves into a new MAP domain (i.e. its MAP changes), it needs to get 2 COAs: A global address in the MAP's subnet and an on-link one (LCoA). These addresses maybe formed in a stateless or stateful manner. After forming the RCOA, the MN sends a regular MIPv6 BU to the MAP (it specifies its RCoA in the Home Address field. No alternate CoA sub-option is used. The LCoA is used as the source address of the BU). This BU will bind the MN's RCOA (similar to a Home Address) to its LCOA. The MAP (acting as a HA) will then perform DAD for the MN's RCOA on its subnet. If successful, the MAP will return a Binding Acknowlegement (BAck) to the MN indicating a successful registration. Otherwise, the MAP MUST return a BAck with the appropriate fault code. No new error codes are needed for this operation. The MN MUST also register its new RCoA with its HA by sending a BU that specifies the binding (RCoA, HomeAddress) as in MIPv6 (The home address field of the BU is set to the Home Address. An alternate-CoA suboption is used and set to the RCoA). It can also send a similar BU (i.e. that specifies the binding between the Home Address and the RCoA) to its current CNs. The MN should wait for the BAck from the MAP before registering with its HA. In order to speed up handoff between MAPs, a MN may send a 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 MN's RCOA (from the HA or CNs). Packets will be tunnelled from the MAP to the MN's LCOA. The MN will decapsulate the packets and process the packet in the normal manner. Soliman, Castelluccia, El-Malki, Bellier [Page 9] INTERNET-DRAFT HMIPv6 ****,2000 When the MN moves locally (i.e. its MAP does not change), it MUST only register its new LCoA with its MAP. In this case, the RCoA stays unchanged. Note a MN can send a BU containing its LCoA (instead of its RCoA) with CNs who share the same link. Packets will then be routed directly without going through the MAP. 5.2 MAP Operations In this mode, a MAP acts exactly like a HA. It intercepts all the packets addressed to the Mobile Nodes it serves and tunnelled them to the corresponding LCoA. In this scenario, a MAP would have no knowledge of the MN's Home address. The MN will send a BU to the MAP with the M, A and D flags set. The aim of this BU is to inform the MAP that the MN has formed a RCOA (contained in the BU as a Home address) and request that a MAP performs DAD on its behalf. This is identical to the HA operation in [1]. If the operation was successful, the MAP MUST respond with a BAck to the MN indicating a successful operation. Otherwise a BAck is sent with the appropriate error code. No new error codes are introduced for HMIPv6. The MAP then acts as a proxy between the RCoA and the LCoA. Packets addressed to the RCOA are then intercepted by the MAP, using proxy NDP, encapsulated and routed to the MN position (LCoA). 5.3 HA Operations The support of basic mode in HMIPv6 is completly transparent to the HA operation. Packets addressed to a MN's Home Address will be forwarded by the HA to its RCoA as described in [1]. 5.4 CN Operations Both HMIPv6 modes are completely transparent to CNs. 6. Extended mode: Using the MAP's advertised address as an alternate-CoA In some mobility scenarios it may not be possible for a MN to get a RCOA on the MAP's subnet. One example for these scenarios is shown in this chapter. However, network operators may have other reasons for choosing this HMIPv6 mode of operation. A comparison between the two modes of operation will be shown below. In the case where a MN is also a router to which several MN's may be connected (eg. a Personal Area Network), it would not be possible for such router to obtain a new network prefix within a visited network. Hence, MNs connected to such router will end up with topologically incorrect addresses. By having the Mobile Router (MR) act as a MAP Soliman, Castelluccia, El-Malki, Bellier [Page 10] INTERNET-DRAFT HMIPv6 ****,2000 within the visited network, MNs connected to it may use it as an alternate-COA when registering with their HA and other CNs. Hence, maintaining the IPv6 powerful aggregation of routes within the backbone, while receiving route-optimised packets sent to the MNs attached to the Mobile Router (MAP). In this case the MAP option will be advertised by the MR that the MN is connected to. The MN MUST send a BU to the HA and CNs including the MAP's address as an alternate-COA. Hence all packets addressed to the MN will be sent through the MAP's address as specified by the MN in its BU. The MAP will (acting like a HA) tunnel the packets addressed to the MN to its current address. The details of the MAP operation will be given later in this document. The Home Address contained in the MAP registration MUST be the same Home Address sent in the Home Agent registration. If a MN sends different BU's for different Home Addresses (in the case it has multiple Home Addresses), the same process MUST be performed first for the MAP registrations. This is essential to allow a MAP to forward packets to the right MN when they are tunnelled from the HA. The MN SHOULD also have a prefix length of 128 in its BUs to the HA. This would stop the HA from being proxy for other unregistered Home addresses. The MAP will need to know how the final destination in the packet corresponds to the registered address of a MN. This should be obvious when the packets are sent from a CN to the global Home Address of the MN or to the COA with a routing header. However, if the HA tunnels packets with addresses other than the MN's Home Address (eg. Site- local), of which the MAP would have no knowledge, the HA SHOULD add a routing header to the outer packet. This routing header MUST use one of the MN's registered Home Addresses as the final destination. This will enable the MAP to tunnell the packet to the correct destination (i.e. the MN's current address). 6.1 MN Operations After MAP discovery has taken place, a MN can register with one or more MAPs. The MN performs this local registration by sending a BU to the MAP with the appropriate flags set. When registering with a MAP, the A flag SHOULD be set and the M flag (see section 4.5) MUST be set in the BU. The H flag MUST not be set when registering with a MAP. A MN SHOULD wait for a BAck (Binding Acknowledgement) from the MAP before using the MAP address as an alternate COA in its BUs. After successfully performing registration with a MAP, a MN can start sending BUs, with it's Alternate-COA,to CNs and its HA. The MAP's IP address or RCOA MUST be included in the Alternate-COA sub-option. Soliman, Castelluccia, El-Malki, Bellier [Page 11] INTERNET-DRAFT HMIPv6 ****,2000 The MN SHOULD send a separate home registration BU for each home address, with the prefix length value set to 128. This stops the HA from forming home addresses for that MN on each link that the HA is connected to, thus ensuring consistency in the Binding Caches of both the MAP and HA for the MN. When in a foreign network, a MN needs to know which path a packet has taken from the CN to the MN. That is, whether triangular routing was used via the HA or route optimisation was used. When using HMIPv6, all packets received from a CN will be tunnelled by the MAP to the MN. When using the MAP's address as a COA, packets tunnelled by the HA to the MAP will be decapsulated and then encapsulated again with the MAP's address as the source address of the outer header. Therefore a check on whether the packet was tunnelled by the HA will not be sufficient to decide whether route optimisation is required. Hence, a check for the existence of a routing header in the encapsulated packet (i.e. with CN as source address), where the MN's home address is the final address, will be sufficient to determine whether the path was route optimised or not. If the routing header does not exist, the MN SHOULD send a BU with the appropriate information to initiate route optimisation. It should be noted that such check is generic and would work for all the various use cases of MIPv6 including the different MAP modes of operation in this memo. 6.2 HA Operations If the MN uses a MAP address, the Home Agent operations are affected in a minor way. The only impact due to this HMIPv6 mode on the HA implementation is that when tunnelling packets to the MN with destination addresses other than the addresses registered by the MN in its Home Registration, the HA SHOULD include a routing header in the outer packet with the MN's registered home address as the final destination. This is done to enable the MAP to find the right routing entry for the MN, since it has no knowledge of a non-unicast global home address for the MN. 6.3 MAP Operations The MAP operation is in many ways similar to the HA operation described in [1] with some modifications. Upon reception of a BU from a MN with the M flag set, and provided it is allowed to accept this message (i.e. no local policy restrictions) the MAP MUST process the BU and if successful, add the information to its Binding Cache. Soliman, Castelluccia, El-Malki, Bellier [Page 12] INTERNET-DRAFT HMIPv6 ****,2000 The BU from the MN will contain its LCOA as a source address and its Home address. A MAP MUST first check if the MN is authorised to use the MAP in this mode. If so, the MAP SHOULD process the BU in the normal manner. If the A flag was set, the MAP MUST send a BAck to the MN. All packets directed to the MN will be received by the MAP and tunnelled to the MN. Upon reception of an encapsulated packet, from a MN's HA, with no routing header in the outer packet, the packet is decapsulated in the normal way. If the inside packet contains a destination address that doesn't belong to the MAP, the MAP should check its Binding Cache to see if the address belongs to any of its registered MN's. If it does, the packet MUST be tunnelled to the MN's current address. Otherwise, the packet is processed in the normal way. If the encapsulated packet contains a routing header in the outer packet containing the MN's home address as the next destination, the MAP MUST process the routing header in the normal way, then tunnel the packet to the MN's current address. When a packet containing a routing header is received (from a CN) the routing header is processed as usual and the packet is then encapsulated to the MN. 6.4 CN Operations In this mode, HMIPv6 is transparent to CNs. 7. Comparison between the HMIPv6 modes of operation In this memo two different modes of operation are defined for HMIPv6 depending on the MN's choice of its COA when located in a foreign network. As shown above the selection of the mode of operation is done based on the information sent in the MAP option. Such information MUST be configurable by the network administrator. Hence some administrators may allow a MN to only obtain a RCOA or use the MAP's address as an alternate-COA. To simplify MN and MAP implementations, only one mode is used by the MAP at a time. The use of RCOA is very simple as it is completely independant of the HA's implementation. intercepted by the MAP (using a HA implementation) and encapsulated again to the MN. On the other hand, if the MAP's COA is used, the MAP will decapsulate the packets and then encapsulate them again to the MN. Hence, in the latter case, only one additional IPv6 header is needed as opposed to two headers in the former. If an appropriate header compression mechanism is used, this may not be an issue. However, if no header compression is used, it maybe more efficient for the MN to Soliman, Castelluccia, El-Malki, Bellier [Page 13] INTERNET-DRAFT HMIPv6 ****,2000 use the MAP's COA as an alternate-COA. Another aspect of the comparison, is the Duplicate Address Detection (DAD) required when performing the initial registration with the MAP. If a RCOA is used, the MAP MUST perform DAD for that address. On the other hand, if the MAP address is used as an alternate-COA, there will be no need to perform DAD as the BU sent to the MAP will bind the MN's home address to the LCOA. Since no DAD for the LCOA or the Alternate-COA (being the MAP's address) is required by the MAP, the registration can be faster when using the MAP address as an alternate-COA. This aspect of the comparison may not be relevant if no inter-MAP handoffs are expected when roaming within the visited network (ie. one MAP domain in the visited network). However, if inter-MAP handoffs are expected, the time taken to perform DAD by the MAP may become significant. In the case where RCOA is used, to avoid DAD delays during inter-MAP mobility, the MN MAY register its new LCoA with its previous MAP. Packets will be redirected from the previous MAP to the new LcoA while DAD is performed. In this scenario the time taken to perform DAD by the MAP in the RCOA mode might be not be an issue. 8. MAP discovery This section describes how a MN obtains the MAP address and subnet prefix. Two different methods for MAP discovery are defined below. Dynamic MAP Discovery is based on propagating the MAP option from the MAP to the MN through certain (configured) router interfaces within the hierarchy. 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. Aother method based on Router Renumbering [5] is also shown below. In this method, no manual configuration is required for routers within the hierarchy. 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 maybe a significantly tedious operation. On the other hand, when using this method, any changes in the MAP option's parameters (eg. preference) would require manual intervention. 8.1 Dynamic MAP Discovery The process of MAP discovery can be performed in many different ways. In this document, router advertisements are used for the discovery phase by introducing a new option. The access router is required to send the MAP option in all router advertisements. This option includes the distance from the MN in terms of number of hops, the preference for this particular MAP, the MAP's global IP address and eventually the MAP's subnet prefix. Soliman, Castelluccia, El-Malki, Bellier [Page 14] INTERNET-DRAFT HMIPv6 ****,2000 The ARs can be configured manually or automatically with this information. In the case of automatic configuration, each MAP in the network needs to be configured with a default preference, the right interfaces to send this option on and, if necessary, the IP address to be sent. The initial value of the "Distance" field MUST be set to a value of one. Upon reception of a router advertisement with the MAP option and given that a router is configured to resend this option on certain interfaces, the router MUST copy the option and resend it after incrementing the Distance field by one. If the router was also a MAP, it SHOULD send its own option in the same advertisement. If a router receives more than one MAP option for the same MAP, from two different interfaces, it should 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 MN. 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. 8.2 Using Router Renumbering for MAP discovery The Router Renumbering (RR) mechanism described in [5] 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 can be used here to configure a router to propagate the MAP option on certain interfaces. To be able to achieve this a new PCO command, PROPAGATE, is defined. 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 only 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, after incrementing the Distance field's value by one. This mechanism can be used to configure AR's 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. Soliman, Castelluccia, El-Malki, Bellier [Page 15] INTERNET-DRAFT HMIPv6 ****,2000 8.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). 8.3 MAP Discovery using a new destination option For more flexibility and simplicity, a new destination option is designed to allow a MAP to send its parameters directly to the Access Routers it is serving. This new destination option has to be sent periodically in order to refresh the state of the routers. The format of this MAP destination option is described below. It contains a type, a length and a data fields. The data field contains the MAP option defined in Section 3. As a result when a router receives a message with a MAP destination option, it simply retrieves the data field and insert it in its router advertissement. The alignment requirement for this destination option is 8n+2. Soliman, Castelluccia, El-Malki, Bellier [Page 16] INTERNET-DRAFT HMIPv6 ****,2000 8.4 MN Operations When a HMIPv6-aware MN 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 MN SHOULD register with the MAP having the lowest preference value. A MAP with a preference value of 255 SHOULD not be used in the MAP registration. A MN MAY however choose to register with one MAP rather than another depending on the value received in the Distance field, as long as the preference value is below 255. If a MN has access to several ARs simultaneously, it SHOULD use a LCoA on the subnet defined by the AR that advertises its current MAP. A MN SHOULD 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 MN MUST use the MIPv6 protocol as specified in [1]. Finally if the M flag is set in the MAP option, the MN MUST register with the MAP and inform its HA. A MN MAY choose to register with more than one MAP simultaneously or use both MAP address and its own address as COAs simultaneously with different CNs. 8.5 MAP Operation for Dynamic MAP Discovery When Dynamic MAP Discovery is used, the MAP discovery is done via router advertisements having the new MAP option added. A MAP will be configured to send its option or relay other MAPs' options on certain interfaces. The choice of interfaces is done by the network operator and depends on the network architecture. A default preference value should 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 255 means that the MAP SHOULD not be chosen by a MN. This value could be reached in cases of node overload or 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 SHOULD add its own MAP option and propagate both options to the next level in the hierarchy. Soliman, Castelluccia, El-Malki, Bellier [Page 17] INTERNET-DRAFT HMIPv6 ****,2000 9. Smooth Handoff A MAP should be able to handle smooth handoffs. When a mobile host moves into a new MAP domain, the MN should send a BU to the previous MAP requesting to forward packets addressed to the MN's new CoA. This is similar to the smooth handoff mechanism of Mobile IPv6. 10. Notes on MAP selection by the MN HMIPv6 provides a very 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 independantly of each other. In addition, overlapping MAP domains are also allowed and recommended. Both static and dynamic hierarchies are supported for either mode of operation. Hence the discussion below is independant of the MAP's mode of operation. When the MN 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 MN SHOULD be: - "Eager" to perform new bindings - "Lazy" in releasing existing bindings The above means that the MN will register with any "new" MAP advertised by the AR (Eager). The method by which the MN determines whether the MAP is a "new" MAP is described above. The MN should not release existing bindings until it no longer receives its MAP option or the lifetime of its existing binding expires (Lazy). This Eager-Lazy approach described above will assist in providing a fallback mechanism in case one of the MAP routers crash as it would reduce the time it takes for a MN to inform its CNs and HA about its new COA. 10.1 MAP selection in a static multi-level hierarchy For a MN to select one or more MAPs in a static multi-level hierarchy, in an optimised manner, several factors need to be considered. In terms of the Distance based selection in a multi-level hierarchy, a MN may choose to register with the furthest MAP to avoid frequent reregistrations. This is particularly important for fast MNs 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 CNs and the HA. Soliman, Castelluccia, El-Malki, Bellier [Page 18] INTERNET-DRAFT HMIPv6 ****,2000 If the distance between the MN and the furthest MAP is large, and other MAPs are located in between, a MN may choose to register its LCOA with the closer MAP and register its closer RCOA/alternate-COA with the further one. For example, the MN may receive two MAP options, one with a distance of 5 (MAP5) and another with a distance of 10 (MAP10). To reduce the delays in MAP registration during handoff, a MN may bind its LCOA to the address acquired from MAP5 (LCOA, MAP5) in the BU sent to MAP5, and bind its MAP10 address to the MAP5 address (MAP10,MAP5) in its BU that is sent to MAP10. The MN can then inform CNs of either one of its addresses (LCOA, MAP5, MAP10) when sending BUs to them. Packets sent to MAP10 will be forwarded to MAP5 and then to the LCOA of the MN. 10.2 MAP selection in a flat mobility management architecture Network operators may choose a flat architecture in some cases where a MIP handoff 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 quite useful to reduce the time required to update all CNs and the HA. In this scenario, a MN may choose a MAP (in the AR) as an anchor point when performing a handoff. This kind of dynamic hierarchy (or anchor chaining) is only recommended for cases where inter-AR movement is not frequent. This is to avoid additional delays in packet delivery as well as overloading ARs with traffic that no longer belongs to their subnets. 11. Security considerations HMIPv6 does not introduce more security problems than Mobile IPv6. The IPSec SA are created by using the home address of the mobile host. A mobile host has to register with its home agent and with the Mobility Anchor Point. All registration messages between the MN and the MAP have to be authenticated. This means that the mobile host has to share an authentication key (private or public) with all MAPs it may visit. These keys can be pre-installed manually or obtained dynamically via IKE or AAA servers. 12. AAA Considerations for IPv6 The MAP can be utilised to perform access control on MNs and may interact with the protocol which will be defined for AAA in IPv6. The MAP can speed up a handoff by having the MN's security credentials which will allow it to verify whether a certain node is allowed access to the network. This allows greater efficiency in distributing keys only to certain nodes in the network. Soliman, Castelluccia, El-Malki, Bellier [Page 19] INTERNET-DRAFT HMIPv6 ****,2000 One example of the interaction between a MAP and the AAA infrastructure can be seen when considering the handoff scenario. A MAP can store the MN's security credentials after the MN is allowed network access by the AAA infrastructure. During an intra-domain handoff, the MAP could pass the MN's security credentials to the "new" AR to avoid performing the AAA process. These credentials depend on the access enforcement policies in AAAv6 and will not be covered by this draft. 13. Acknowledgements The authors would like to thank Conny Larsson (Ericsson) and Mattias Pettersson (Ericsson) for their valuable input to this draft. The authors from INRIA would also like to thank the members of the French RNRT MobiSecV6 project (BULL, France Telecom and INRIA) for testing our implementation and for their valuable feedbacks. They would also like to thank the French Governement for partially funding this project. In addition, the authors would like to thank the following members of the working group in alphabetical order: Eva Gustaffson (Ericsson), Dave Johnson (Rice University), Annika Jonsson (Ericsson), Fergal Ladley and Erik Nordmark (Sun) for their comments on the draft. 14. Notice Regarding Intellectual Property Rights see http://www.ietf.org/ietf/IPR/ERICSSON-General 15. References [1] D. Johnson and C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-12.txt, February 2000. [2] E. Gustafsson, A. Jonsson and C. Perkins, "Mobile IP Regional Tunnel Management", draft-ietf-mobileip-reg-tunnel-02.txt (work in progress), March 2000. [3] K. El Malki and H. Soliman "Fast Handoffs in Mobile IPv4". (work in progress). [4] K. El Malki and H. Soliman "Fast Handoffs in Mobile IPv6". draft-elmalki-handoffsv6-00.txt (work in progress). [5] M. Crawford "Router Renumbering for IPv6". RFC 2984. [6] S. Thomson and T. Narten "IPv6 Stateless Address Autoconfiguration". RFC 2462. [7] T. Narten, E. Nordmark and W. Simpson "Neighbour Discovery for IP version 6 ". RFC 2461. Soliman, Castelluccia, El-Malki, Bellier [Page 20] INTERNET-DRAFT HMIPv6 ****,2000 16. Appendix A: Planned additions to future revisions In addition to the existing proposal, the following sections are planned for future revisions: - quick discovery of MAP failures will be essential for the reliability of this mechanism. Some suggestions for handling these scenarios will be included in future revisions. - Detailed notes for implementors will also be added. 17. Authors' Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola M/S M8-540 6000 Connection Drive 1501 West Shure Drive Irving, TX 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com Fax : +1 972-894-5349 Questions about this memo can also be directed to: Hesham Soliman Ericsson Australia 61 Rigall St., Broadmeadows Melbourne, Victoria 3047 AUSTRALIA Phone: +61 3 93012049 Fax: +61 3 93014280 E-mail: Hesham.Soliman@ericsson.com.au 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 Soliman, Castelluccia, El-Malki, Bellier [Page 21] INTERNET-DRAFT HMIPv6 ****,2000 Ericsson Radio Systems AB LM Ericssons Vag. 8 126 25 Stockholm SWEDEN Phone: +46 8 7195803 Fax: +46 8 7190170 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 Soliman, Castelluccia, El-Malki, Bellier [Page 22]