IETF Mobile IP Working Group Hesham Soliman, Ericsson INTERNET-DRAFT Claude Castelluccia, INRIA Karim El-Malki, Ericsson Ludovic Bellier, INRIA February, 2001 Hierarchical MIPv6 mobility management 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@STANDARDS.NORTELNETWORKS.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/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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. MIPv6 extension _ BU extensions ........................ 8 4. Neighbour Discovery extension _ MAP option message .... 10 5. MAP Discovery.......................................... 12 5.1 Receiving packets in a foreign network............ 12 5.2 MAP Operation..................................... 12 5.3 MAP Operation..................................... 14 5.4 MAP Operation..................................... 14 6. Basic mode: Supporting MNs with a Regional COA (RCOA).. 15 6.1 MN Operations..................................... 15 6.2 MAP operations ................................... 15 6.3 HA operations .................................... 16 6.4 CN operations .................................... 16 7. Extended mode: Using the MAP COA as an alternate-COA .. 17 7.1 MN Operations..................................... 18 7.2 MAP operations.................................... 19 7.3 HA operations..................................... 19 7.4 CN operations..................................... 20 8. Comparison between the two MAP modes................... 20 9. Load balacing in HMIPv6................................ 21 10. Smooth Handoffs........................................ 21 11. Location Privacy in HMIPv6............................. 21 12. Special optimisations for sending Binding Updates...... 21 13. Notes on MAP selection by the MN....................... 22 14. Security Considerations................................ 23 15. AAA Considerations for IPv6............................ 23 16. Acknowledgements....................................... 24 17. Notice Regarding Intellectual Property Rights.......... 24 Soliman, Castelluccia, El-Malki, Bellier [Page 2] INTERNET-DRAFT HMIPv6 ****,2000 18. References............................................. 24 19. Appendix A: Future additions........................... 25 20. Authors' addresses..................................... 25 Soliman, Castelluccia, El-Malki, Bellier [Page 3] 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. Similar 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 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 4] 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. 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 5] 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. Although a multi-level hierarchy is not required for a higher performance, it is possible to use multi- level hierarchies of routers and implement the MAP functionality in AR1 and AR2 if needed. This would be required in cases where Mobile Routers are supported as will be explained later in chapter 7. 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 network, 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. Soliman, Castelluccia, El-Malki, Bellier [Page 6] INTERNET-DRAFT HMIPv6 ****,2000 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 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 (Extended mode), 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(triangular routing) or received directly from a CN (route optimised). 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 Soliman, Castelluccia, El-Malki, Bellier [Page 7] INTERNET-DRAFT HMIPv6 ****,2000 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 on-link address (LCOA) as a COA. The knowledge of whether a CN's address belongs to the same site or not is outside the scope of this memo. However, [9] provides a mechanism for gaining this knowledge. 3. 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|U|L| Prefix Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- Description of extensions to the BU option: M If set indicates a MAP registration. L 1 bit field to request load balancing of packets destined to the MN. The L flag MUST NOT be set when the B flag is set. If both flags are set, the MAP MUST reject the BU with an appropriate error code 3.1 Load Balancing sub-option Load balancing can be a useful feature in cases where the MN is connected to different access technologies with different characteristics. When using the load balancing sub-option below, a MN would be able to `move' one flow to another AR/interface while maintaining the reception of other flows on the current interface. requesting the load balancing service from the MAP can be decided based on some local policies within the MN and based on the link characteristics and the types of applications running at the time. The Load balancing sub-option is included within the BU option. The sub-option contains information that allows the MAP to identify a Soliman, Castelluccia, El-Malki, Bellier [Page 8] INTERNET-DRAFT HMIPv6 ****,2000 traffic flow and route it to a given address. Multiple sub-options may exist within a BU. These sub-options may contain the same destination IPv6 address or different addresses. Only one destination address is allowed in each sub-option. A traffic flow may be identified by using the flow label or by combining the destination address and port number. Alternatively, a MN may simply request per-packet load balancing without identifying a flow label or a port number. The message format for the Load balancing sub-option is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type| Sub-Option Len|F|P|A| Prot number |r| dest- | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | port | Flow label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Option Type TBD Sub-Option Len F When set, indicates that the Flow label MUST be used to identify a flow P When set, indicates that the port number and IP address MUST be used to identify a flow A When set, indicates that the destination address only should be used for load balancing. This implies that per-packet load balancing is requested. This flag MUST NOT be set when the F or P flags are set. Prot number A value corresponding to the protocol number associated with the port numbers. This field is only relevant when the P flag is set. Soliman, Castelluccia, El-Malki, Bellier [Page 9] INTERNET-DRAFT HMIPv6 ****,2000 It should be noted that per-packet load balancing may have some negative impacts on TCP congestion avoidance mechanisms as it is desirable to maintain order between packets belonging to the same TCP connection. This behaviour is specified in [8]. Other negative impacts are also foreseen for other types of real time connections due to the potential variations in RTT between packets. Hence, a MN SHOULD NOT request per-packet load balancing when TCP connections are active. However, the MN can still request per-flow load balancing provided that the entire flow is moved to the new address. The MN SHOULD be aware of the negative consequences of per- packet filtering when requesting it. When requesting load balancing, the MN can set the `flow identifiers' using the F (flow label) or P (address and port number) flags. If the A flag is set, per-packet load balancing is requested. Per-packet load balancing can be done based on local policies in the MAP. A MN can include several load balancing sub-options within the BU option. For instance, an MN could move a number of connections to another interface. In this case the MN would include a number of load balancing sub-options, each identifying one connection. The MN MUST NOT include conflicting sub-options. Ie. the MN MUST NOT mix per-packet load balancing with per-flow load balancing. If a MAP finds a request for both per-packet and per-flow load balancing, it MUST reject the Load balancing request with an appropriate error code. 4. 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|T| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Global IP Address for MAP + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The alignment requirements for this option is 8n. Soliman, Castelluccia, El-Malki, Bellier [Page 10] INTERNET-DRAFT HMIPv6 ****,2000 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. The Distance MUST be set to one if the MAP is on the same subnet as the MN. 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 value different from 128 indicates that the MN should configure its RCoA using the prefix length 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 T Indicates that the on-link prefix is topologically incorrect. Hence the MN MUST use the MAP's CoA to be reached. This flag MUST only be set if the M flag was set. Global Address One of the MAP's global addresses. To ensure a secure communication between routers, router advertisements, sent between routers, 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 or use another MAP discovery mechanism as shown in this document (eg. router renumbering). Soliman, Castelluccia, El-Malki, Bellier [Page 11] INTERNET-DRAFT HMIPv6 ****,2000 5. 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. Another 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. 5.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. 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. 5.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 Soliman, Castelluccia, El-Malki, Bellier [Page 12] INTERNET-DRAFT HMIPv6 ****,2000 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. 5.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 13] INTERNET-DRAFT HMIPv6 ****,2000 5.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 advertisement. The alignment requirement for this destination option is 8n+2. 5.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 over another depending on the value received in the Distance field, provided that 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. 5.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 Soliman, Castelluccia, El-Malki, Bellier [Page 14] INTERNET-DRAFT HMIPv6 ****,2000 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. 6. 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. 6.1 MN Operations When a MN moves into a new MAP domain (i.e. its MAP changes), it needs to get 2 COAs: A Regional CoA on the MAP's subnet (RCoA) and an on-link one (LCoA). These addresses maybe formed in a stateless or stateful manner. After forming the RCOA, the MN sends a BU to the MAP with the M flag set. The BU 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 Acknowledgement (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, Home Address) as in MIPv6 (The home address field of the BU is set to the Home Address. An alternate-CoA sub-option 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. Soliman, Castelluccia, El-Malki, Bellier [Page 15] INTERNET-DRAFT HMIPv6 ****,2000 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. 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 that 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. 6.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 Neighbour Advertisement, encapsulated and routed to the MN position (LCoA). 6.3 HA Operations The support of basic mode in HMIPv6 is completely 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]. 6.4 CN Operations Both HMIPv6 modes are completely transparent to CNs. Soliman, Castelluccia, El-Malki, Bellier [Page 16] INTERNET-DRAFT HMIPv6 ****,2000 7. Extended mode: Supporting Mobile Nodes and Mobile Networks The Extended mode of operation can support both Mobile Nodes and Mobile networks. 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 within the visited network, MNs connected to it may use its CoA 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 (being the AR) 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 BUs 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 zero 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 tunnel the packet to the correct destination (i.e. the MN's current address). Soliman, Castelluccia, El-Malki, Bellier [Page 17] INTERNET-DRAFT HMIPv6 ****,2000 7.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 its Alternate-COA, to CNs and its HA. The MAP's IP address or RCOA MUST be included in the Alternate-COA sub-option. The MN SHOULD send a separate home registration BU for each home address, with the prefix length value set to zero. 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. If the MN is connected to a Mobile Router (MR) which also acts as a MAP. When the MR moves to another AR, it will advertise a new MAP option (its own) as well as others belonging to higher MAPs in the hierarchy. To be able to receive route optimised packets, the MN SHOULD send a BU to the further MAP to bind its Home address to the MR's (on link MAP) CoA. This would cause all packets sent to the MN to be forwarded to the MR which in turn will forward them to 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's Extended mode, all packets received from a CN will be tunnelled by the MAP to the MN regardless of whether they were routed via the HA or directly to the MAP. 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 apply to all use cases of MIPv6 including the different MAP modes of operation in this memo. Soliman, Castelluccia, El-Malki, Bellier [Page 18] INTERNET-DRAFT HMIPv6 ****,2000 Hence, this check need not be an additional implementation for this mode of operation and can be the only check in an implementation to determine whether a BU should be sent to CN. 7.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 Home addresses for which it received no BUs from the MN. 7.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. 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 received encapsulated packet contains a routing header, the MAP MUST process the routing header in the normal way. After procesing the routing header, the MAP MUST check whether the final destination corresponds to an entry in its binding cache. If it does, the MAP MUST tunnel the packet to the MN's current address (LCoA). 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. Soliman, Castelluccia, El-Malki, Bellier [Page 19] INTERNET-DRAFT HMIPv6 ****,2000 If the MAP is an MR with one or more MNs connected on one interface, and an AR on the other interface. When changing ARs, the MAP MUST advertise its own MAP option as well as other MAP options received from the AR. The MR's MAP option would contain its own LCoA. This would allow the MNs to obtain a new topologically correct RCoA and update the higher MAP in the hierarchy. 7.4 CN Operations In this mode, HMIPv6 is transparent to CNs. 8. 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 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 Soliman, Castelluccia, El-Malki, Bellier [Page 20] INTERNET-DRAFT HMIPv6 ****,2000 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. 9. Load balancing in HMIPv6 In some cases, a MN may be connected to more than one link simultaneously. A MAP domain may cover one or more Access technologies connected to different ARs. Different links may have different properties like bandwidth availability, Quality of Service and reliability. Different applications maybe better suited to certain types of links. Hence, a MN may prefer to move some connections to one link while keeping the rest connected to the same link. To achieve this, the MN needs to send the necessary information required to identify a connection. This information is included in the Load-balancing sub-option shown in ch 3.1. Load balancing may be done on a per-connection or per-packet basis. In the case of load balancing on per packet basis, the ratio of packets sent to each link to the total number of packets received by the MN is left to local policies defined in the MAP. It is important to note that per-packet load balancing may have some negative effects on some connections, causing packets to be delivered out of order. Other impacts on TCP are mentioned earlier in this memo. Hence, generally, per-packet load balancing in not recommended unless the MN is certain that no negative impacts on connections will occur. 10. 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. 11. Location privacy in HMIPv6 HMIPv6 (basic mode) provides users with the ability to hide their exact location. This is done by providing the users with a `local' Home address while roaming within a MAP domain. A MN MAY choose to show the RCoA to the application. By using the provided RCoA, an application would be able to hide its exact location (subnet) from other nodes on the Internet. Providing the RCoA to the application is an implementation dependant issue and can be provided by API implementors. When using Extended mode, the MN MUST NOT provide the RCoA (MAP's address) to the applications. 12. Special optimisations for sending BUs In some link layers that require some L2 signalling before sending each frame, it maybe useful for MNs to encapsulate the BU sent to the HA inside the BU sent to the MAP. The decision on whether this Soliman, Castelluccia, El-Malki, Bellier [Page 21] INTERNET-DRAFT HMIPv6 ****,2000 optimisation should be used or not is left up to the 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 (eg. if DAD failed and the MN s required to provide a new Home address). 13. 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 should register 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. 13.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. Except for the case of a Mobile network connected via an MR to an AR, 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 delays and elimiate the robustness of IP routing between the highest MAP and the MN. Hence, allowing more than one MAP (above the AR) within a network should imply that the MN forces packets to be routed down the hierarchy of Soliman, Castelluccia, El-Malki, Bellier [Page 22] INTERNET-DRAFT HMIPv6 ****,2000 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 MNs. 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 re-registrations. 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. In the case of Mobile networks, connected via an MR to another network, MNs should bind their MR's CoA (advertised in the MR's MAP option) to their Home addresses. For example, in this case the MN may receive two MAP options, one including the MR's address and another for a MAP further away in the hierarchy of routers (MAP2). The MN should then send a BU to MAP2 binding its Home address to the MR. 13.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. 14. Security considerations HMIPv6 does not introduce more security problems than Mobile IPv6. A mobile host has to register with its HA and with the Mobility Anchor Point. All BUs between the MN and the MAP have to be authenticated as per MIPv6. 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. The Security association establishment between the MN and the MAP MUST be based on the Home address when using the extended mode, and the RCOA when using the basic mode. 15. 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 Soliman, Castelluccia, El-Malki, Bellier [Page 23] INTERNET-DRAFT HMIPv6 ****,2000 keys only to certain nodes in the network. 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. Similarly, the protocol used to transfer such credentials is outside the scope of this draft. 16. 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 feedback. 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: Samita Chakrabarti (Sun), Gopal Dommety (Cisco), Eva Gustaffson (Ericsson), Dave Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf (Sun), Fergal Ladley, Erik Nordmark (Sun), Basavaraj Patil (Nokia) and Alper Yegin (Sun) for their comments on the draft. 17. Notice Regarding Intellectual Property Rights see http://www.ietf.org/ietf/IPR/ERICSSON-General 18. References [1] D. Johnson and C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-12.txt, February 2000. [2] E. Gustafsson et al, "Mobile IP Regional Tunnel Management", draft-ietf-mobileip-reg-tunnel-03.txt (work in progress), March 2000. [3] K. ElMalki, Editor, "Low latency Handoffs in Mobile IPv4". draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, work in progress. [4] G. Tsirtsis, Editor, "Fast Handovers for Mobile IPv6", draft- ietf-mobileip-fast-mipv6-00.txt, work in progress. [5] M. Crawford _Router Renumbering for IPv6_. RFC 2984. Soliman, Castelluccia, El-Malki, Bellier [Page 24] INTERNET-DRAFT HMIPv6 ****,2000 [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. [8] D. Awduche et al, _Requirements for traffic engineering over MPLS_. RFC 2702. [9] E. Nordmark, _Site prefixes in Neigbour Disocvery_. draft-ietf-ipng-site-prefixes-05.txt. Work in progress. 19. 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. - Add the necessary error codes for the BAck, due to the introduction of the MAP. 20. 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 Radio Systems AB Torshamnsgatan 29, Kista, Stockholm 16480 Sweden Phone: +46 8 7578162 Fax: +46 8 4043630 Soliman, Castelluccia, El-Malki, Bellier [Page 25] INTERNET-DRAFT HMIPv6 ****,2000 E-mail: Hesham.Soliman@era.ericsson.se 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 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 26]