Mobile IP Working Group Eva Gustafsson INTERNET DRAFT Ericsson 1 March 2002 Annika Jonsson Ericsson Charles E. Perkins Nokia Research Center Mobile IPv4 Regional Registration draft-ietf-mobileip-reg-tunnel-06.txt Status of This Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mobile-ip@sunroof.eng.sun.com mailing list. Distribution of this memo is unlimited. 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 to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long. We propose a new kind of "regional" registration, i.e., registration local to the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another, within the same visited domain. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page i] Internet Draft Regional Registration 1 March 2002 Contents Status of This Memo i Abstract i 1. Introduction 2 2. Terminology 3 3. Description of the Protocol 4 3.1. General Assumptions . . . . . . . . . . . . . . . . . . . 4 3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 3.3. Advertising Foreign Agent and GFA . . . . . . . . . . . . 7 4. Home Registration 8 4.1. Mobile Node Considerations . . . . . . . . . . . . . . . 8 4.2. Foreign Agent Considerations . . . . . . . . . . . . . . 9 4.3. GFA Considerations . . . . . . . . . . . . . . . . . . . 10 4.4. Home Agent Considerations . . . . . . . . . . . . . . . . 10 5. Regional Registration 11 5.1. Mobile Node Considerations . . . . . . . . . . . . . . . 12 5.2. Foreign Agent Considerations . . . . . . . . . . . . . . 13 5.3. GFA Considerations . . . . . . . . . . . . . . . . . . . 13 6. Generalized NAI Extension 14 7. Router Discovery Extensions 15 7.1. Regional Registration Flag . . . . . . . . . . . . . . . 15 7.2. Foreign Agent NAI Extension . . . . . . . . . . . . . . . 15 8. Regional Extensions to Mobile IPv4 Registration Messages 16 8.1. GFA IP Address Extension . . . . . . . . . . . . . . . . 16 8.2. Hierarchical Foreign Agent Extension . . . . . . . . . . 17 8.3. Replay Protection Style . . . . . . . . . . . . . . . . . 18 8.4. New Code Values for Registration Reply . . . . . . . . . 19 9. Regional Registration Message Formats 20 9.1. Regional Registration Request . . . . . . . . . . . . . . 20 9.2. Regional Registration Reply . . . . . . . . . . . . . . . 22 9.3. New Regional Registration Reply Code Values . . . . . . . 22 10. Authentication Extensions 23 11. IANA considerations 24 Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page ii] Internet Draft Regional Registration 1 March 2002 12. Security Considerations 24 13. Acknowledgements 25 A. Changes from Previous Versions 27 A.1. Updates from version 05 . . . . . . . . . . . . . . . . . 27 A.2. List of updates made for previous revisions . . . . . . . 27 A.3. Updates from version 02 . . . . . . . . . . . . . . . . . 28 B. Hierarchical Foreign Agents 29 B.1. Registration with Home Agent . . . . . . . . . . . . . . 29 B.2. Handling Binding Updates . . . . . . . . . . . . . . . . 32 B.3. Regional Registration . . . . . . . . . . . . . . . . . . 33 B.4. Regional Registrations and Smooth Handover . . . . . . . 34 B.5. Co-located care of address . . . . . . . . . . . . . . . 35 B.6. Data Traffic . . . . . . . . . . . . . . . . . . . . . . 35 B.7. GFA-RFA Subtype for Generalized MN-FA Key Reply Extension 36 C. Authentication, Authorization and Accounting AAA Interactions 36 D. Anchoring at a GFA/RFA/FA 37 Addresses 38 Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 1] Internet Draft Regional Registration 1 March 2002 1. Introduction This document adds to the Mobile IP protocol, by proposing a means for mobile nodes to register locally within a visited domain. By registering locally, the signaling delay is reduced, and this may improve the performance of handover. In Mobile IP, as specified in RFC 3220 [9], a mobile node registers with its home agent each time it changes care-of address. If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long. We propose a solution for performing registrations locally in the visited domain: regional registrations. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another, within the same visited domain. When a mobile node first arrives at a visited domain, it performs a _home_registration -- that is, a registration with its home agent. At this registration, we assume that the home network generates a registration key (e.g. using [12]) for the mobile node. This registration key is distributed to the mobile node and to the visited domain, and can be used for authentication of regional registrations. During a home registration, the home agent registers the care-of address of the mobile node. When the visited domain supports regional tunnel management, the care-of address that is registered at the home agent is the publicly routable address of a Gateway Foreign Agent (GFA). This care-of address will not change when the mobile node changes foreign agent under the same GFA. When changing GFA, a mobile node MUST perform a home registration; when changing foreign agent under the same GFA, the mobile node MAY instead perform a regional registration within the visited domain. The proposed regional registration protocol supports one level of foreign agent hierarchy beneath the GFA, but the protocol may be utilized to support several levels of hierarchy, as discussed in Appendix B. Foreign agents that support regional registrations are also required to support registrations according to Mobile IPv4 [9]. If there is a foreign agent address announced in the Agent Advertisement, the mobile node may register that foreign agent care-of address with its home agent [9]. Similarly, if the mobile node chooses not to employ regional registrations, it may register a co-located care-of address directly with its home agent, according to [9]. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 2] Internet Draft Regional Registration 1 March 2002 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. This document uses the following terms: Critical type A type value for an extension in the range 0-127, which indicates that the extension MUST either be known to the recipient, or that the message containing the extension MUST be rejected. In other words, an extension with a critical type value is non-skippable. Domain A collection of networks sharing a common network administration. Foreign Agent (FA) As defined in [9]. Gateway Foreign Agent (GFA) A Foreign Agent which has a publicly routable IP address. A GFA may, for instance, be placed in or near a firewall. Home Agent (HA) As defined in [9]. Home domain The domain where the home network and home agent are located. Home network As defined in [9]. Home Registration A registration, processed by the home agent and the GFA, using the specification in [9] possibly with additional extensions defined in this document. Local Care-of Address A Care-of Address which is either assigned to a mobile node, or to a foreign agent offering local connectivity to a mobile node. A registration message from the mobile node is subsequently sent to a GFA (or another RFA, see Appendix B) via the local care-of address. Mobile Node (MN) As defined in [9]. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 3] Internet Draft Regional Registration 1 March 2002 Mobility Agent (MA) As defined in [9]. Network Access Identifier(NAI) Some features of this protocol specification rely on use of the Network Access Identifier (NAI) [3]. Regional Foreign Agent (RFA) A Foreign Agent which may be the target of a request for regional registration. Regional Registration A mobile node performs registration locally at the visited domain, by sending a Regional Registration Request to a GFA, and receiving a Regional Registration Reply in return. Registration Key A key used by mobile nodes and mobility agents to secure certain signals and control messages specified by Mobile IP. Visited domain The domain where the visited network, the current foreign agent and the GFA are located. Visited network As defined in [9]. 3. Description of the Protocol This section provides an overview of the regional registration protocol. 3.1. General Assumptions Our general model of operation is illustrated in figure 1, showing a visited domain with foreign agent and GFA, and a home network with a home agent. For mobile nodes that cannot process a NAI, or with mobility agents that are not configured to advertise their NAI, regional registration is still useful, but the lack of certain features may result in less than optimal results. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 4] Internet Draft Regional Registration 1 March 2002 +---------------------------+ +----------------+ | Visited Domain | | Home | | | +---------+ | Network | | | | | | | | +------+ +-------+ | | Public | | +------+ | | | FA |------| GFA |-------------------------| HA | | | +--+---+ +-------+ | | Network | | +------+ | | | | | | | | +-----|---------------------+ +---------+ +----------------+ | +--+---+ | MN | +------+ Figure 1: Visited domain with a GFA, and a home network with HA. 3.1.1. Visited Domain We assume two hierarchy levels of foreign agents in the visited domain. At the top level of the hierarchy, there is at least one GFA, which is a foreign agent with additional features. A GFA must have a publicly routable address. Beneath a GFA, there are one or more regional foreign agents (RFAs). We assume that there exist established security associations between a GFA and the RFAs beneath it. Multiple hierarchy levels of foreign agents are discussed in Appendix B. When designing a domain supporting regional registrations, the RFAs and GFA must be compatible. That is, they should support the same encapsulation types, compression mechanisms etc. When a mobile node changes care-of address under the same GFA, it MAY perform a regional registration. If the mobile node changes GFA, within a visited domain or between visited domains, it MUST perform a home registration. 3.1.2. Authentication With the regional registration protocol, a GFA address is registered at the home agent as the care-of address of the mobile node. If a Mobile-Foreign Authentication extension is present in a Registration Request message, the GFA will perform the authentication. Similarly, if a Foreign-Home Authentication extension is present in a Registration Request message, the authentication is performed between the GFA and the home agent. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 5] Internet Draft Regional Registration 1 March 2002 As part of a registration at the home network, a registration key may be distributed to the mobile node and to the visited domain, for example according to [4, 12]. The registration key is expected to be used for authentication of regional registrations (see section 3.1.2). When the regional registration protocol is employed, the GFA is the agent within the visited domain which receives the registration keys. This is because the GFA address is the registered care-of address of the mobile node at its home network. The distributed registration keys are subsequently used to enable proper authentication for regional registrations (see sections 9.1 and 9.2). 3.2. Protocol Overview When a mobile node first arrives at a visited domain, it performs a registration with its home network. At this registration, the home agent registers the care-of address of the mobile node. In case the visited domain supports regional registrations, the care-of address that is registered at the home agent is the address of a GFA. The GFA keeps a visitor list of all the mobile nodes currently registered with it. Since the care-of address registered at the home agent is the GFA address, it will not change when the mobile node changes foreign agent under the same GFA. Thus, the home agent does not need to be informed of any further mobile node movements within the visited domain. MN FA1 GFA HA | | | | | Registration Request | | | |---------------------->| Reg. Request w/ext. | | | |---------------------->| Reg. Request | | | |--------------->| | | | Reg. Reply | | | Reg. Reply w/ext. |<---------------| | Registration Reply |<----------------------| | |<----------------------| | | | | | | Figure 2: Registration at the GFA and the home agent. Figure 2 illustrates the signaling message flow for registration with the home network. After the registration at the home agent, the home agent records the GFA address as the care-of address of the mobile node. If the GFA address was dynamically assigned to the Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 6] Internet Draft Regional Registration 1 March 2002 mobile node, the Registration Reply has an extension indicating the IP address of the GFA to the mobile node. MN FA2 GFA HA | | | | | Regional Reg. Req. | | | |---------------------->| Regional Reg. Req. w/ext. | | | |----------------------------->| | | | Regional Reg. Reply w/ext. | | | Regional Reg. Reply |<-----------------------------| | |<----------------------| | | | | | | Figure 3: Regional registration at the GFA. Figure 3 illustrates the signaling message flow for regional registration. Even though the mobile node's local care-of address changes, the home agent continues to record the GFA address as the care-of address of the mobile node. We introduce two new message types for regional registrations: Regional Registration Request and Regional Registration Reply. 3.3. Advertising Foreign Agent and GFA A foreign agent typically announces its presence via an Agent Advertisement message [9]. If the domain to which a foreign agent belongs supports regional registrations, the following changes are applied to the Agent Advertisement message. The `I' flag (see Section 7) MUST be set to indicate that the domain supports regional tunnel management, and that the availability of a GFA is advertised in the Agent Advertisement message. If the `I' bit is set, there MUST be at least one care-of address in the Agent Advertisement message, but that address MAY be set to zero. If the `I' bit is set, and there is only one care-of address, it is the address of the GFA. When only the GFA address is present, and thus the local foreign agent is not advertising its care-of address, the FA-NAI (see section 7.2) SHOULD also be present to enable the mobile node to determine whether or not it has changed foreign agent (so that a new regional registration may be initiated). The mobile node also uses the FA-NAI to decide whether or not it is in its home domain. The decision is based on whether the realm part of the advertised FA-NAI matches the mobile node's realm. If the `I' bit Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 7] Internet Draft Regional Registration 1 March 2002 is set, and there are multiple care-of addresses, the first care-of address is the local FA, and the last care-of address is the GFA. 4. Home Registration This section gives a detailed description of home registration, i.e., registration with the home agent (on the home network). Home registration is performed when a mobile node first arrives at a visited domain, when it requests a new home agent, or when it changes GFA. Home registration is also performed to renew bindings which would otherwise expire. 4.1. Mobile Node Considerations Upon receipt of an Agent Advertisement message with the `I' flag set and a FA-NAI extension, the mobile node compares the domain part of the foreign agent NAI with the domain part of its own NAI, to determine whether it is in its home domain or in a visited domain. If the NAIs do not match, the mobile node MUST assume it is in a foreign domain. Otherwise, if the mobile node determines that it is in its home domain, it acts as defined in [9]. If the mobile node determines that it is in a visited domain, it SHOULD either use the advertised GFA address in the care-of address field in the Registration Request message, or set this field to zero to request to be assigned a GFA. If the mobile node sets the care-of address to zero, the mobile node and its home agent MUST support the GFA IP address extension (see section 8.1). In that case, the mobile node MUST check to make sure that it receives a GFA IP address extension in the Registration Reply. A mobile node with a co-located care-of address might also want to use Regional Registrations. It then finds out the address of a GFA, either from Agent Advertisments sent by a Foreign Agent, or by some means not described in this draft. The mobile node MAY then generate a Registration Request message, with the GFA address in the care-of address field, and send it directly to the GFA (not via a foreign agent). In this case, the mobile node MUST add a Hierarchical Foreign Agent extension 8.2, including its co-located care-of address, to the Registration Request before sending it. The Hierarchical Foreign Agent extension SHOULD be placed after the MN-HA authentication extension. It SHOULD be authenticated by using the MN-GFA authentication extension (see Section 10). The authentication data SHOULD be calculated using a mobility security association that has been established with the GFA (Section 3.1.2). If the mobile node receives an Agent Advertisement with the `R' bit set it, even if it has a co-located care-of address, still formulates the Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 8] Internet Draft Regional Registration 1 March 2002 same Registration Request message with extensions, but it sends the message to the advertising foreign agent instead of to the GFA. 4.2. Foreign Agent Considerations When the foreign agent receives a Registration Request message from a mobile node, it extracts the care-of address field in the Registration Request message, to find the GFA to which the message shall be relayed. All Foreign Agents that advertise the `I' flag MUST also be able to handle Registration Requests with a zero care-of address. If the care-of address field is set to zero, the foreign agent assigns a GFA to the mobile node. A Foreign Agent can either have a default GFA that it assigns to all mobile nodes or it can assign a GFA by some means not described in this specification. It then adds a GFA IP Address extension with the address of the assigned GFA to the Registration Request message. The foreign agent MUST NOT insert the GFA address directly in the care-of address field in the Registration Request message, since that would cause the Mobile-Home authentication to fail. If the Registration Request has the `T' bit set, the mobile node is requesting Reverse Tunneling [8]. In this case, the foreign agent has to tunnel packets from the mobile node to the GFA for further handling. The GFA will then decapsulate the packets from the foreign agent and re-encapsulate them for further delivery back to the home agent. These actions are required because the home agent has to receive such packets from the expected care-of address (i.e., that of the GFA) instead of the local care-of address. If the care-of address in the Registration Request is the address of the foreign agent, the foreign agent relays the message directly to the home agent, as described in [9]. For each pending or current home registration, the foreign agent maintains a visitor list entry as described in [9]. If reverse tunneling is being used, the visitor list MUST, in addition to the fields required in [9], contain the address of the GFA. Otherwise, if the care-of address in the Registration Request is the address of a GFA (or zero), the foreign agent adds a Hierarchical Foreign Agent extension, including its own address, to the Registration Request message, and relays it to the GFA. The Hierarchical Foreign Agent extension MUST be appended at the end of all previous extensions that were included in the Registration Request message when the foreign agent received it, and it SHOULD be protected by an FA-FA Authentication extension (see section 10). Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 9] Internet Draft Regional Registration 1 March 2002 4.3. GFA Considerations For each pending or current home registration, the GFA maintains a visitor list entry as described in [9]. This visitor list entry is also updated for the regional registrations performed by the mobile node. In addition to the fields required in [9], the list entry MUST contain: - the current care-of address of the mobile node (i.e., the foreign agent or co-located address) in the Hierarchical Foreign Agent extension - the remaining Lifetime of the regional registration - the style of replay protection in use for the regional registration - the Identification value for the regional registration. If the Registration Request message contains a Replay Protection extension (see section 8.3) requesting a style of replay protection not supported by the GFA, the GFA MUST reject the Registration Request and send a Registration Reply with the value in the Code field set to REPLAY_PROT_UNAVAIL (see section 8.4). If the Hierarchical Foreign Agent extension comes after the MN-FA authentication extension, the GFA MUST remove it from the Registration Request message. The GFA then sends the request to the home agent. Upon receipt of the Registration Reply message, the GFA consults its pending registration record to find the care-of address within its domain that is currently used by the mobile node, and sends the Registration Reply to that care-of address. If the Replay extension (see section 8.3) is present in a home registration, and follows the MN-HA authentication extension, the GFA SHOULD remove the Replay extension after performing any necessary processing, before sending the home registration to the home agent. 4.4. Home Agent Considerations A Registration Request that does not contain a GFA IP Address extension or a Replay Protection Style extension is processed by the home agent as described in [9]. If the home agent receives a Registration Request with one of these extensions, and the home agent does not support the extension, the home agent must return a Registration Reply with the Code value set to UNSUPPORTED_EXTENSION [9]. If a home agent receives a Registration Request message with the care-of address set to zero, and a GFA IP Address extension, it MUST register the IP address of the GFA as the care-of address of the mobile node in its mobility binding list. If the Registration Request is accepted, the home agent MUST Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 10] Internet Draft Regional Registration 1 March 2002 include the GFA IP Address extension in the Registration Reply, before the Mobile-Home Authentication extension. If a home agent receives a Registration Request message with the care-of address set to zero, but no GFA IP Address extension, it MUST deny the request by sending a Registration Reply message with the Code field set to ZERO_CAREOF_ADDRESS (see section 8.4). Otherwise, the home agent then generates a Registration Reply message, including the GFA IP Address extension, and sends it back to the GFA. 5. Regional Registration This section describes in detail regional registration. Once the home agent has registered the GFA address as the care-of address of the mobile node, the mobile node may perform regional registrations. When performing regional registrations, the mobile node may either register a foreign agent care-of address or a co-located address with the GFA (or, another RFA -- see Appendix B). In the following, we assume that a home registration has already occurred, as described in section 4, and that the GFA has a mobility security association with the mobile node. Suppose the mobile node moves from one foreign agent to another foreign agent within the same visited domain. It will then receive an Agent Advertisement from the new foreign agent. Suppose further that the Agent Advertisement indicates that the visited domain supports regional registrations, and that either the advertised GFA address is the same as the one the mobile node has registered as its care-of address during its last home registration, or the realm part of the newly advertised FA-NAI matches the FA-NAI advertised by the mobile node's previous foreign agent. Then, the mobile node can perform a regional registration with this foreign agent and GFA. The mobile node issues a Regional Registration Request message to the GFA via the new foreign agent. The request is authenticated using the registration key that was distributed to the GFA and to the mobile node from the home network and the message is authenticated by the MN-GFA Authentication Extension. The care-of address should be set to the address of the local foreign agent, or else zero if the local foreign agent is not advertising its own care-of address. If the Regional Registration Request does not contain its care-of address, the foreign agent adds a Hierarchical Foreign Agent extension to the message and relays it to the GFA. Based on the information in the Hierarchical Foreign Agent extension, the GFA updates the mobile node's current point of attachment in its visitor list. The GFA then issues a Regional Registration Reply to the mobile node via the foreign agent. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 11] Internet Draft Regional Registration 1 March 2002 If the advertised GFA is not the same as the one the mobile node has registered as its care-of address, and if the mobile node is still within the same domain as it was when it registered that care-of address, the mobile node MAY try to perform a regional registration with its registered GFA. If the foreign agent cannot support regional registration to a GFA, other than advertised, the foreign agent denies the regional registration with code UNKNOWN_GFA (see section 9.3). In this case the MN has to do a new home registration via the new GFA. It is essential for the mobile node to distinguish regional registrations from home registrations, since in the former case the nonces are not synchronized with its home agent. Furthermore, a home registration MUST be directed to the home network before the lifetime of the GFA's regional care-of address expires. Since the mobile node can use a zero Care-of Address either to request a GFA (in a home registration) or to signify the use of an unspecified (perhaps privately addressed) RFA (in a regional registration), it is necessary to distinguish regional registrations from home registration. Thus, we introduce new message types for the Regional Registration messages. 5.1. Mobile Node Considerations For each pending or current home registration, the mobile node maintains the information described in [9]. The information is also updated for the regional registrations performed by the mobile node. In addition to the information described in [9], the mobile node MUST maintain the following information, if present: - the GFA address - the style of replay protection in use for the regional registration - the Identification value for the regional registration. The replay protection for registrations and regional registrations is performed as described in [9]. Since the mobile node performs regional registrations at the GFA in parallel with registrations at its home network, the mobile node MUST be able to keep one replay protection mechanism and sequence for the GFA, and a separate mechanism and sequence for the home agent. For regional registrations, replay protection may also be provided at the foreign agent by the challenge-response mechanism, as described in [5]. In this case, the mobile node inserts the 64 bit response value (timestamp or nonce, according to Mobile IPv4 [9]) in the Identification field in the Regional Registration Request. Thus, the GFA SHOULD expect such an Identification field. When a mobile Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 12] Internet Draft Regional Registration 1 March 2002 node, which has already registered a GFA care-of address with its home agent, changes foreign agent within the same domain and receives an Agent Advertisement which advertises another GFA address, it MAY still generate a Regional Registration Request message destined to its old GFA. 5.2. Foreign Agent Considerations When the foreign agent receives a Regional Registration Request message from a mobile node, addressed to a GFA, it processes the message generally according to the rules of processing a Registration Request message addressed to a home agent (see section 4.2). The only difference is that the GFA IP address field replaces the home agent address field. If that address belongs to a known GFA, the foreign agent forwards the request to the indicated GFA. Otherwise, the foreign agent MUST generate a Regional Registration Reply with error code UNKNOWN_GFA. For each pending or current registration, the foreign agent maintains a visitor list entry as described in [9]. If reverse tunneling is being used, the visitor list MUST contain the address of the GFA, in addition to the fields required in [9]. This is required so that the foreign agent can tunnel datagrams, sent by the mobile node, to the GFA. The GFA then decapsulates the datagrams, re-encapsulates them and sends them to the home agent. 5.3. GFA Considerations If the GFA accepts a request for regional registration, it MUST set the lifetime to be no greater than the remaining lifetime of the mobile node's registration with its home agent, and put this lifetime into the corresponding Regional Registration Reply. The GFA MUST NOT accept a request for a regional registration if the lifetime of the mobile node's registration with its home agent has expired. In that case the GFA sends a Regional Registration Reply with the value in the Code field set to HOME_REG_EXPIRED. If the GFA receives a tunneled packet from a foreign agent in its domain, then after decapsulation the GFA looks to see whether it has an entry in its visitor list for the source IP address of the inner IP header after decapsulation. If so, then it checks the visitor list to see whether reverse tunneling has been requested; if it was requested, the GFA re-encapsulates the packet with its own address as the source IP address, and the address of the home agent as the destination IP address. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 13] Internet Draft Regional Registration 1 March 2002 6. Generalized NAI Extension The revised specification for "IP Mobility Support for IPv4" [9] defines a new extension header format, that is intended to extend the Mobile IP extension address space. The use of a Network Access Identifier (NAI) [1] for mobile nodes is specified for Mobile IPv4 in [3]. The Generalized NAI (GNAI) extension, defined in this section, uses the new extension header format to extend this idea, enabling NAIs to be used for identifying IPv4 mobility agents (i.e., the Foreign Agent or the Home agent) or other possible network elements that may be involved with the processing of Registration Requests. For Regional Registration, only a single sub-type is defined; it is used to carry a Foreign Agent's NAI (see section 7.2). The GNAI extension, illustrated in figure 4, may be carried by Registration Request and Reply messages. 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 | Sub-Type | NAI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: The Generalized NAI (GNAI) Extension Type (Type to be assigned by IANA) (skippable) Length 8-bit unsigned integer. Length of the extension, in octets, excluding the extension Type and the extension Length fields, but including the Sub-Type field and the variable length NAI field. Sub-Type 8-bit unsigned integer identifying the specific sub-type of the GNAI extension, and thus be implication the type of the entity which is to be identified by using the NAI. NAI A string containing the Network Access Identifier NAI in the format prescribed in [1]. When a mobile node or home agent adds a GNAI extension to a registration message, the extension MUST appear prior to any authentication extensions. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 14] Internet Draft Regional Registration 1 March 2002 When the Foreign Agent adds an GNAI extension to a registration message, the extension MUST appear prior to any authentication extensions added by the FA. 7. Router Discovery Extensions This section specifies a new flag within the Mobile IP Agent Advertisement, and an optional extension to the ICMP Router Discovery Protocol [6]. 7.1. Regional Registration Flag The only change to the Mobility Agent Advertisement Extension defined in [9] is a flag indicating that the domain, to which the foreign agent generating the Agent Advertisement belongs, supports regional registrations. The flag is inserted after the flags defined in [9], [8] and [11]. 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 | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime |R|B|H|F|M|G|V|T|S|I| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero or more Care-of Addresses | | ... | The flag is defined as follows: I Regional registration. This domain supports Regional Registration as specified in this document. 7.2. Foreign Agent NAI Extension The FA-NAI extension is defined as a subtype 4 of the Generalized NAI Extension (GNAIE) (see section 6). The foreign agent SHOULD include its NAI in the Agent Advertisement message. If present, the Foreign Agent NAI (FA-NAI) extension MUST appear in the Agent Advertisement message after any of the advertisement extensions defined in [9]. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 15] Internet Draft Regional Registration 1 March 2002 By comparing the domain part of the foreign agent NAI with the domain part of its own NAI, the mobile node can determine whether it is in its home domain or in a visited domain, and whether it has changed domain since it last registered. 8. Regional Extensions to Mobile IPv4 Registration Messages In this section we specify new Mobile IP registration extensions for the purpose of managing regional registrations. 8.1. GFA IP Address Extension In order to assign a GFA to the mobile node, the foreign agent adds a GFA IP Address extension to the Registration Request before relaying it to the selected GFA. The mobile node indicates that it wants a GFA to be assigned by sending a Registration Request message with the care-of address field set to zero. The GFA IP Address extension MUST appear in the Registration Request message before the Foreign-Home Authentication extension, if present. 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 | GFA IP Address .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GFA IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: The GFA IP Address extension If a home agent receives a Registration Request message with the care-of address set to zero, and a GFA IP Address extension, it MUST register the IP address of the GFA as the care-of address of the mobile node. When generating a Registration Reply message, the home agent MUST include the GFA IP Address extension from the Registration Request in the Registration Reply message. The GFA IP Address extension MUST appear in the Registration Reply message before the Mobile-Home Authentication extension. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 16] Internet Draft Regional Registration 1 March 2002 The GFA IP Address extension, illustrated in figure 5 is defined as follows: Type TBD (GFA IP Address) Length 4 GFA IP Address The GFA IP Address field contains the Gateway Foreign Agent's publicly routable address. 8.2. Hierarchical Foreign Agent Extension The Hierarchical Foreign Agent extension may be present in a Registration Request or Regional Registration Request message. When this extension is added to a Registration Request by a foreign agent, the receiving mobility agent sets up a pending registration record for the mobile node, using the IP address in the Hierarchical Foreign Agent extension as the care-of address for the mobile node. Furthermore, in this case, the extension MUST be appended at the end of all previous extensions that had been included in the registration message as received by the foreign agent. The Hierarchical Foreign Agent extension SHOULD be protected by an FA-FA Authentication extension. When the receiving foreign agent receives the registration message, it MUST remove the Hierarchical Foreign Agent extension added by the sending foreign agent. The Hierarchical Foreign Agent extension is defined as follows: 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 | FA IP Address .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FA IP Address .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: The Hierarchical Foreign Agent Extension Type TBD (Hierarchical Foreign Agent) Length 4 FA IP Address The IP Address of the foreign agent relaying the Registration Request. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 17] Internet Draft Regional Registration 1 March 2002 8.3. Replay Protection Style When a mobile node uses Mobile IP to register a care-of address with its home agent, the style of replay protection used for the registration messages is assumed to be known by way of a Mobility Security Association that is required to exist between the mobile node and the home agent receiving the request. No such pre-existing security association between the mobile node and the GFA is likely to be available. By default, the mobile node SHOULD treat replay protection for Regional Registration messages exactly as specified in Mobile IPv4 [9] for timestamp-based replay protection. If the mobile node requires nonce-based replay protection, also as specified in Mobile IPv4, it MAY append a Replay Protection extension to a home registration message. Since home registrations are forwarded to the home agent by way of the GFA, the GFA will be able to establish the selected replay protection (see section 4.3). The format of this extension is shown in figure 7. 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 | Replay Protection Style | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Initial Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: The Replay Protection Extension Type TBD (Replay Protection Style) Length 2 Replay Protection Style An integer specifying the style of replay protection desired by the mobile node. Initial Identification The timestamp or nonce to be used for initial synchronization for the replay mechanism. Admissible values for the Replay Protection Style are as follows: Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 18] Internet Draft Regional Registration 1 March 2002 Value Replay Protection Style ----- ----------------------- 0 timestamp [9] 1 nonce [9] The mobile node SHOULD append the Replay Protection Style Extension to the home registration following the MN-HA authentication extension, but before any MN-GFA authentication extension. Then, the GFA can remove the extension without damaging the MN-HA authentication data needed by the home agent. Replay protection MAY also be provided through a challenge-response mechanism, at the foreign agent issuing the Agent Advertisement, as described in [5]. 8.4. New Code Values for Registration Reply The values to use within the Code field of the Registration Reply are defined in [9]. In addition, the following values are defined: Registration denied by the FA: Error Name Value Section of Document ---------------------- ----- ------------------- SMOOTH_HO_REQUIRED TBD B.4 Registration denied by the GFA: Error Name Value Section of Document ---------------------- ----- ------------------- REPLAY_PROT_UNAVAIL TBD 8.3 Registration denied by the HA: Error Name Value Section of Document ---------------------- ----- ------------------- ZERO_CAREOF_ADDRESS TBD 4.4 Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 19] Internet Draft Regional Registration 1 March 2002 9. Regional Registration Message Formats This section specifies two new registration message types: Regional Registration Request and Regional Registration Reply. These messages are used by the mobile node instead of the existing Registration Request and Registration Reply, in order to make registration work faster, and also to reduce network load for Mobile IP registration, as described in section 5. Regional registration messages are protected by requiring authentication extensions, in the same way as the existing Mobile IP registration messages are protected. The following rules apply to authentication extensions: - The Mobile-GFA Authentication extension [9] MUST be included in all regional registration messages. - The Mobile-Foreign Authentication extension [9] MAY be included in regional registration messages. - The Foreign-Home Authentication extension [9] MUST NOT be included in any regional registration message. 9.1. Regional Registration Request The Regional Registration Request, illustrated below, is used by a mobile node to register with its current GFA. 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 |S|B|D|M|G|r|T|x| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GFA IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 20] Internet Draft Regional Registration 1 March 2002 The Regional Registration Request message is defined as the Registration Request message in [9], but with the following changes: Type TBD (Regional Registration Request) GFA IP Address The IP address of the Gateway Foreign Agent. (Replaces Home Agent field in Registration Request message in [9].) Care-of Address Care-of address of local foreign agent; MAY be set to zero. Extensions For the Regional Registration Request, the Hierarchical Foreign Agent Extension is also an allowable extension in addtion to those which are allowable for the Registration Request message. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 21] Internet Draft Regional Registration 1 March 2002 9.2. Regional Registration Reply The Regional Registration Reply message, illustrated below, delivers the indication of regional registration acceptance or denial to a mobile node. The UDP header is followed by the Mobile IP fields 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Regional FA IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- This message is defined as the Registration Reply message in [9], but with the following changes: Type TBD (Regional Registration Reply) Regional FA IP Address The IP address of the Gateway Foreign Agent. (Replaces Home Agent field specified in Mobile IPv4 [9]). Extensions The Regional FA IP Address is the address of the regional foreign agent generating the Regional Registration Reply message. For the two-level hierarchy specified here, it is the address of the GFA. For more levels of hierarchy, it may be the address of an intermediate RFA. 9.3. New Regional Registration Reply Code Values For a Regional Registration Reply, the following additional Code values are defined in addition to those specified in Mobile IPv4 [9]. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 22] Internet Draft Regional Registration 1 March 2002 Registration denied by the FA: Error Name Value Section of Document ---------------------- ----- ------------------- UNKNOWN_GFA TBD 5.2 GFA_UNREACHABLE TBD GFA_HOST_UNREACHABLE TBD GFA_PORT_UNREACHABLE TBD SMOOTH_HO_REQUIRED TBD B.4 Registration denied by the GFA: Error Name Value Section of Document ---------------------- ----- ------------------- HOME_REG_EXPIRED TBD 5.3 The four first Code values are returned to the mobile node in response to ICMP errors that may be received by the foreign agent. 10. Authentication Extensions In this section, two new subtypes for the Generalized Authentication Extension [5] are specified. First, the FA-FA Authentication extension is used by regional foreign agents to secure the Hierarchical Foreign Agent (HFA) extension to the Registration Request and Regional Registration Request messages. A new authentication extension is necessary because the HFA extension is typically added after the Mobile-Home (or some other authorization-enabling [9] (e.g. MN-AAA [3], see section C) authentication extension. The MN-GFA authentication extension is used whenever the mobile node has a co-located address. Furthermore, the MN-GFA extension is used to provide authentication for a Regional Registration Request. The subtype values for these new subtypes are as follows: Subtype Name Value ---------------------- ------ FA-FA authentication TBD MN-GFA authentication TBD The default algorithm for computation of the authenticator is the same as for the MN-AAA Authentication subtype defined in [5]. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 23] Internet Draft Regional Registration 1 March 2002 11. IANA considerations This document defines: - The Generalized NAI extension, specified in section 6. The type number for this new extension is to be assigned from the number space for Mobile IPv4 skippable extensions (128-255). - A Sub-Type for the GNAI extension is specified in section 7.2, which needs to have a value assigned from the space of GNAI subtypes. - Three new extensions to Mobile IP Registration messages: GFA IP Address, Hierarchical Foreign Agent, and Replay Protection Style (see section 8.1, 8.2 and 8.3). The Type values for these extensions must be within the range 0 through 127. - New Code values for Registration Reply messages (see section 8.4). - Two new subtypes for the Generalized Authentication Extension [5]; see section 10 - Two new message types for Mobile IP: Regional Registration Request and Regional Registration Reply (see section 9.1 and 9.2). - Code values for Regional Registration Reply messages (see section 9.3) 12. Security Considerations This document proposes a method for a mobile node to register locally in a visited domain. The authentication extensions to be used are those defined either in [9], [11], or [4]. Key distribution is to be performed, for instance, according to [4], or [12]. If the Hierarchical Foreign Agent (HFA) extension is appended to a Registration Request message, that extension is to be followed by an FA-FA Authentication Extension (see section 10) to prevent any modification to the data. Likewise, if the GFA IP Address extension is added to such a message, it is to be followed by an authentication extension. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 24] Internet Draft Regional Registration 1 March 2002 13. Acknowledgements This document is a logical successor to documents written with Pat Calhoun and Gabriel Montenegro; thanks to them and their many efforts to help explore this problem space. Many thanks also to Jari Malinen at the Nokia Research Center for his commentary on a rough version of this document, and providing motivation for section B.4. The text in section 6 was taken directly from a previous Internet Draft [7] written by Mohamed M. Khalil, Emad Qaddoura, Haseeb Akhtar of Nortel Networks, along with Pat R. Calhoun of Black Storm Networks. References [1] B. Aboba and M. Beadles. The Network Access Identifier. Request for Comments (Proposed Standard) 2486, Internet Engineering Task Force, January 1999. [2] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [3] P. Calhoun and C. Perkins. Mobile IP Network Access Identifier Extension for IPv4. Request for Comments (Proposed Standard) 2794, Internet Engineering Task Force, January 2000. [4] P. Calhoun and C. Perkins. DIAMETER Mobile IP Extensions (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-aaa-diameter-mobileip-06.txt, June 2001. [5] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent Challenge/Response Extension. Request for Comments (Proposed Standard) 3012, Internet Engineering Task Force, December 2000. [6] S. Deering. ICMP Router Discovery Messages. Request for Comments (Proposed Standard) 1256, Internet Engineering Task Force, September 1991. [7] Mohamed Khalil, Emad Qaddoura, Haseeb Akhtar, and Pat R. Calhoun. Generalized NAI Extension (GNAIE) (work in progress). draft-ietf-mobileip-gnaie-00.txt, September 2001. [8] Editor G. Montenegro. Reverse Tunneling for Mobile IP, revised. Request for Comments (Proposed Standard) 3024, Internet Engineering Task Force, January 2001. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 25] Internet Draft Regional Registration 1 March 2002 [9] C. Perkins. IP Mobility Support. Request for Comments (Proposed Standard) 3220, Internet Engineering Task Force, December 2001. [10] C. Perkins and P. Calhoun. AAA Keys for Mobile IP (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-mobileip-aaa-key-00.txt, July 2001. [11] C. Perkins and D. Johnson. Route Optimization in Mobile IP (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-mobileip-optim-11.txt, September 2001. [12] Charles E. Perkins and Pat R. Calhoun. AAA Registration Keys for Mobile IP (work in progress). draft-ietf-mobileip-aaa-key-05.txt, May 2001. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 26] Internet Draft Regional Registration 1 March 2002 A. Changes from Previous Versions The following updates and changes were made in this version of the Mobile IP Regional Registration draft, compared to earlier versions. A.1. Updates from version 05 Specified the GNAI extension (see section 6, as was previously done in [7]. Changed IANA considerations and section 7.2 as needed. Upgraded citations for RFC 2002 to instead refer to RFC 3220. A.2. List of updates made for previous revisions Added `v4' to the title, changed all code values, message types and extensions to `TBD', and added an `IANA Considerations' section. Section 3.3 Clarified that the care-of address can be zero. Section 4.2 Added that any Foreign Agent that supports regional registrations must be able to assign a GFA to a mobile node if the care-of address in the Registration Request is zero. Section 5.2 Clarified that in regional registrations the GFA address field replaces the HA address field. Section 5.3 Added a new error code: HOME_REG_EXPIRED that the GFA use when denying a regional registration because the home registration lifetime has expired. Section 7.1 Clarified the placement of the 'I' flag. Section 10 Added reference to a default algorithm for the authentication extensions. Section B.5 Added a section to allow a mobile node with a co-located care of address to use multi-level hierarchies. Section B.4 Interactions with delivery of Binding Update messages to RFAs along the previous routing path have been suggested in order to prevent various race conditions that have been observed in practice. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 27] Internet Draft Regional Registration 1 March 2002 A.3. Updates from version 02 The following updates and changes were made in this version of the Mobile IP Regional Registration draft, compared to the earlier version (version 02). Section 4.3 The contents of the visitor list entry at the GFA have been clarified. A GFA keeps a visitor list entry for each pending or current home registration. The entry is also updated for the regional registrations performed by the mobile node. Section 8.4 A new code value for the Registration Reply has been defined: MISSING_GFA_ADDRESS. This section has also been re-structured for clarification. Section 5.1 Specific message types for regional registrations messages (Regional Registration Request and Regional Registration Reply) were defined. The reason for defining specific message types for the regional registration messages, instead of using the Registration Request and Reply as defined in [9] are the following: - a mobile node must be able to distinguish between regional registrations and home registrations, because when it uses regional registration, the nonces are not synchronized with its home agent; - a mobile node can use a zero care-of address either to request a GFA (in a home registration) or to signify the use of an unspecified regional foreign agent (in a regional registration). For regional registrations, the challenge-response mechanism may be used to provide replay protection. In this case, the mobile node inserts the 64 bit response value in the Identification field in the Regional Registration Request. Section 7.2 The FA-NAI extension is defined as a subtype TBD of the Generalized NAI Extension (GNAIE). Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 28] Internet Draft Regional Registration 1 March 2002 Section 9 This entire section is added to the draft, and it describes the Regional Registration Request and Regional Registration Reply messages. Appendix B The contents of the visitor list entry at the RFA and GFA have been clarified. An RFA/GFA keeps a visitor list entry for each pending or current home registration. The entry is also updated for the regional registrations performed by the mobile node. Appendix D This appendix has been added to the draft. It clarifies how a mobile node can register a care-of address with its home agent; a GFA, RFA or FA care-of address, and then maintain this care-of address when it moves in the visited domain. B. Hierarchical Foreign Agents The main body of this specification assumes two hierarchy levels of foreign agents in the visited domain. At the top level, there is one or several GFAs, and on the lower level, there is a number of foreign agents. The structure can be extended to include multiple hierarchy levels of foreign agents beneath the GFA level (Figure 8). Such multiple hierarchy levels are discussed in this appendix. We assume that security associations have been established among a GFA and all the foreign agents beneath it in the hierarchy. As before, we assume that when a mobile node performs registration at its home network, registration keys are generated and distributed to the mobile node and to the GFA. The GFA may then in turn distribute the registration keys to the foreign agents beneath it in the hierarchy, using methods not specified in this document. We also assume that all foreign agents and the mobile node support smooth handover as specified in [11], with some modifications as explained below. B.1. Registration with Home Agent As described in this specification, a foreign agent announces itself and a GFA in the Agent Advertisement in the first and last address in the care-of address field in the Mobility Agent Advertisement extension [9]. If there is a hierarchy of foreign agents between the GFA and the announcing foreign agent, the foreign agent MUST support smooth handover (specifically, the Previous Foreign Agent Notification extension) as described in [11]. The foreign agent MAY Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 29] Internet Draft Regional Registration 1 March 2002 +--------+ | | | GFA | | | +--------+ / | \ ... ... ... | +--------+ | | | RFA3 | | | +--------+ / \ +--------+ +--------+ | | | | | FA2 | | FA1 | | | | | +--------+ +--------+ | | | +--------+ ... | | | MN | | | +--------+ Figure 8: Domain with a GFA and multiple hierarchies of FAs, enabled for regional registrations. also include the addresses of the foreign agents in the hierarchy in order between its own address (first) and the GFA address (last): - Address of announcing foreign agent - Address of the next higher-level Regional Foreign Agent (RFA) - ... - Address of GFA If a foreign agent advertises the entire hierarchy between itself and the GFA, the Registration Request messages MUST be delivered to each RFA address in turn within that hierarchy. When newly arriving at a visited domain, the mobile node sends a Registration Request, with the care-of address set to the GFA address announced in the Agent Advertisement. The mobile node may also request a GFA to be assigned, as described earlier in this specification. The registration Request MUST include the Previous Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 30] Internet Draft Regional Registration 1 March 2002 Foreign Agent Notification Extension defined in [11]. The Binding Update that results is processed as described in Section B.2. When the foreign agent closest to the mobile node receives the Registration Request, processing is as described in Section 4.2. It adds a Hierarchical Foreign Agent extension to the Registration Request, including its own address, and relays the Registration Request to the next RFA in the hierarchy toward the GFA. It also constructs a Binding Update and sends it to the previous foreign agent, as defined in [11]. The next RFA receives the Registration Request. For each pending or current registration, an RFA maintains a visitor list entry. In addition to the list entry contents (described in [9]), the list entry for regional registrations MUST contain: - the address of the next lower-level RFA, or FA, in the hierarchy - the remaining Lifetime of the regional registration - the style of replay protection in use for the regional registration - the Identification value for the regional registration. The RFA removes the Hierarchical Foreign Agent extension that the last FA or RFA added, and adds a new Hierarchical Foreign Agent extension with its own address. This procedure is repeated at each RFA, or FA, in the hierarchy under the GFA. When the GFA receives the Registration Request, it removes the Hierarchical Foreign Agent extension and caches information about the next lower-level RFA in the hierarchy. It then relays the Registration Request to the home agent, possibly via AAA servers. For each pending or current home registration, the GFA maintains a visitor list entry as described in [9]. The list entry is also updated for regional registrations reaching the GFA. In addition to the list entry contents required in [9], the list entry MUST contain: - the address of the next lower-level RFA in the hierarchy - the remaining Lifetime of the regional registration - the style of replay protection in use for the regional registration - the Identification value for the regional registration. If there is only one level of hierarchy beneath the GFA, the address of the next lower-level RFA is the current care-of address of the mobile node, as stated in Section 4.3. The home agent, as described before, processes the Registration Request, stores the GFA address as the current care-of address of Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 31] Internet Draft Regional Registration 1 March 2002 the mobile node, generates a Registration Reply, and sends it to the GFA. The home agent also distributes a registration key to the mobile node, perhaps with the assistance of the GFA, for instance by way of other AAA functions [12]. When the GFA receives the Registration Reply, it checks its pending Registration Request record to see which next lower-level RFA to send the Registration Reply message to. It SHOULD then add, for instance, a new FA-FA Key Reply extension to the Registration Reply message, before relaying it to the next foreign agent. The new FA-FA Agent Key Reply extension contains the registration key, encrypted with a secret shared between the GFA and the next lower-level RFA in the hierarchy. Similar procedures are to be used with [12]. The next lower-level RFA receives the Registration Reply and checks its pending Registration Request record to see which lower-level foreign agent should next receive the Registration Reply. It extracts, decrypts and caches the registration key, and relays the Registration Reply to the next foreign agent. This procedure is repeated in every foreign agent in the hierarchy, until the message reaches the foreign agent closest to the mobile node. When the lowest-level foreign agent receives the Registration Reply, it checks its cached information, as described in [9], and relays the Registration Reply to the mobile node. B.2. Handling Binding Updates Meanwhile, when the previous foreign agent receives the Binding Update, it will process it according to [11], except that instead of sending back a Binding Acknowledge message, it sends the Binding Update to the next RFA in the hierarchy towards the GFA. This is done to make sure that all RFAs in the path to the previous FA are notified that the mobile node has moved. The previous foreign agent must be sure that the next RFA received the Binding Update, therefore the RFA MUST send a Binding Acknowledge message back to the foreign agent that it got the Binding Update from. Note that this is the same Binding Acknowledge message than the one defined in [11], but this one is addressed to the IP address of the Foreign Agent that sent the Binding Update instead of to the mobile node. The RFA that received the Binding Update sends the Binding Acknowledge message back to the lower-layer Foreign Agent, and relays the Binding Update to the next RFA in the hierarchy towards the GFA. The RFA will also update the binding cache for the mobile node so that it will expire according to the lifetime in the Binding Update, but the binding cache entry will still point to the same lower-level foreign agent. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 32] Internet Draft Regional Registration 1 March 2002 The crossover FA is the foreign agent lowest in the hierarchy which is part of both the old and the new path to the mobile node. When the Binding Update reaches the crossover FA, which might be an RFA or the GFA, it will, in addition to sending a Binding Acknowledge back to the sending RFA, also send a Binding Acknowledge to the mobile node. This Binding Acknowledge message is the one defined in [11] and it is addressed to the mobile node and sent down the hierarchy via the old path and the previous Foreign Agent, who tunnels it to the new Foreign Agent. The crossover FA will receive both a Registration Request and a Binding Update for the mobile node. When the crossover FA receives the Registration Request, it continues to send traffic via the old path until it receives a valid Registration Reply with a Code indicating success. Then it starts sending traffic via the new route. In the unlikely event that the crossover FA receives the Binding Update before it receives the Registration Request, it doesn't know that it is the crossover FA yet, and therefore relays the Binding Update to the next Foreign Agent. When the crossover FA later receives the Registration Request, it will know that it is the crossover FA, and will send a Binding Acknowledge message to the mobile node (via the old route). The foreign agents above the crossover FA in the hierarchy that also got the Binding Update will see that the Binding Update does not supply any new care-of address information. so they and will ignore the Binding Update. B.3. Regional Registration A Regional Registration Request is forwarded to the GFA by way of one or more intermediate regional foreign agents. When the Regional Registration Request message arrives at the first foreign agent, the foreign agent checks its visitor list to see if this mobile node is already registered with it. If it is not, the foreign agent checks which next higher-level RFA to relay the Regional Registration Request to. It adds a Hierarchical Foreign Agent extension to the Regional Registration Request, including its address, and relays the message to the next RFA in the hierarchy toward the GFA. The next RFA checks its visitor list to see if the mobile node is already registered with it. If it is not, the RFA removes the Hierarchical Foreign Agent extension and adds a new one, with its own address, and relays the message to the next higher-level RFA in the hierarchy toward the GFA. This process is repeated in each RFA in the hierarchy, until an RFA recognizes the mobile node as already registered. This RFA may be Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 33] Internet Draft Regional Registration 1 March 2002 the GFA, or any RFA beneath it in the hierarchy. If the mobile node is already registered with this RFA, the RFA generates a Regional Registration Reply and sends it to the next lower-level RFA in the hierarchy. The lifetime field in the Regional Registration Reply is set to the remaining lifetime that was earlier agreed upon between the mobile node and the GFA. If the lifetime of the GFA registration has expired, the Regional Registration Request is relayed all the way to the GFA. The Previous Foreign Agent Notification Extension, Binding Updates and Binding Acknowledge messages are used for Regional Registrations in the same way as for Home Registrations. If the hierarchy between the advertising foreign agent and the GFA is announced in the Agent Advertisement, the mobile node may generate a Regional Registration Request not destined to the GFA, but to the closest RFA with which it can register. Replay protection can be provided at the announcing foreign agent, through the challenge-response mechanism described in [5]. If the GFA, and the RFAs in the hierarchy, trust the announcing foreign agent to perform the replay protection, timestamps or nonces between the mobile node and the GFA, or between the mobile node and each RFA, are not needed. If the challenge-response mechanism is used for replay protection, the mobile node inserts the 64 bit response value in the Identification field in the Regional Registration Request message. If a mobile node includes a Hierarchical Foreign Agent extension in its Registration Request message, it MAY insert the extension before the MN-HA or MN-FA authentication extension. In this case, the Hierarchical Foreign Agent extension MUST NOT be removed by the GFA or any other RFA prior to the generation of the Registration Reply message. If more than one Hierarchical Foreign Agent extension is inserted by the mobile node into the registration message, the order of the extensions MUST be maintained through the hierarchy. When sending a Regional Registration Reply, the GFA MUST ensure that the order of the Hierarchical Foreign Agent extensions is reversed from the order found in the Regional Registration Request. B.4. Regional Registrations and Smooth Handover Multiple hierarchy levels of foreign agents requires the use of smooth handover from [11], as discussed in Appendix B. This is not needed in a two level hierarchy. But a mobile node might not know how many levels of hierarchy a network has, so if the foreign agents in one network support both Regional Registrations and Smooth Handover a mobile node MAY try to use Regional Registrations Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 34] Internet Draft Regional Registration 1 March 2002 without Smooth Handover. If the network requires the use of Smooth Handover (because it has more than two levels of hierarchy, or for other reasons) the Foreign Agent MUST deny the request by sending back a Registration Reply message with the Code field set to SMOOTH_HO_REQUIRED. The Foreign Agent NAI extension (see section 7.2) is also used during Smooth Handover. If Smooth Handovers are used, and the foreign agent does not advertise its own address in the Agent Advertisement message, the FA-NAI will be used to identify the Previous Foreign agent instead. This will be done by adding an FA-NAI extension (defined in section 6) to the Registration Request (together with the Previous Foreign Agent Notification extension) and in the Binding Update and setting the care-of address to zero. B.5. Co-located care of address If a mobile node uses a co-located care-of address, it MAY use Regional Registrations directly to the GFA (see section 4.1 and section 5). It MAY also use the same method to make use of multiple levels of Foreign Agents, if it can find out about the hierarchy, either from Mobility Agent Advertisments, or in some other way outside the scope of this specification. B.6. Data Traffic When a correspondent node sends traffic to the mobile node, the traffic arrives at the home agent, and the home agent tunnels the traffic to the GFA. The GFA or RFA at each level of the hierarchy has a visitor list for the mobile node, showing the address of the next lower-level RFA or FA in the hierarchy. Thus, a datagram arriving at the top level of the hierarchy, that is, the GFA, will be re-routed to the next lower-level RFA in the hierarchy. This re-routing occurs at each level of the hierarchy, until the datagram reaches the last point which is either the mobile node itself (in case of a co-located care-of address) or a foreign agent that can deliver the datagram to the mobile node with no further special Mobile IP handling. In case of decapsulation and re-encapsulation, it should be noted that the actual decapsulation need not occur at each step of the hierarchy. Instead, the foreign agent at that level can merely change the source and destination IP addresses of the encapsulating IP header. Traffic from the mobile node is sent as described in [9] or [8]. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 35] Internet Draft Regional Registration 1 March 2002 According to the Route Optimization specification [11], Binding Updates send to the correspondent node from the Home Agent will contain the address of the GFA, since this is the only care-of address known to the Home Agent. Therefore, Binding Updates from the mobile node sent to the correspondent node SHOULD also have the care-of address belonging to the GFA. This also has the advantage of reducing the number of Binding Update messages that have to be sent to the correspondent node, at a modest increase in routing path length. Furthermore, the local network domain may be configured to admit such traffic into the local domain only if packets are tunneled directly to the GFA. B.7. GFA-RFA Subtype for Generalized MN-FA Key Reply Extension If a GFA uses the Registration Reply to distribute an MN-FA key to the other RFAs in its domain, a new subtype for the Generalized MN-FA Key Reply Extension [10] is required. The subtype value is as follows: Subtype Name Value -------------- ------------ GFA-RFA Key Reply 5 The subtype data for the GFA-RFA Key Reply subtype is a 4 byte SPI, followed by the registration key encoded according to the recipe indicated by the SPI. C. Authentication, Authorization and Accounting AAA Interactions When the mobile node has to obtain authorization by way of Authentication, Authorization and Accounting (AAA) infrastructure services, the control flow implicit in the main body of this specification is likely to be modified. Typically, the mobile node will supply credentials for authorization by AAA as part of its registration messages. The GFA will parse the credentials supplied by the mobile and forward the appropriate authorization request to a local AAA server (see [5, 4]). Concretely, this means that: - The GFA MAY include the Mobile IP Registration Request data inside an authorization request, directed to a local AAA server. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 36] Internet Draft Regional Registration 1 March 2002 - The GFA MAY receive the Mobile IP Registration Reply data from a message granting authorization, received from the AAA infrastructure. D. Anchoring at a GFA/RFA/FA As described earlier in this draft, once a mobile node has registered the address of a GFA as its care-of address with its home agent, it MAY perform regional registrations when changing foreign agent under the same GFA. When detecting that is has changed foreign agent, and if the new foreign agent advertises the `I' flag, the mobile node MAY address a Regional Registration Request message to its registered GFA, even if the address of that particular GFA is not advertised by the new foreign agent. The foreign agent MAY then relay the request to the GFA in question, or deny the request with error code 'unknown GFA'. Similarly, a mobile node MAY address a Regional Registration Request message to any Regional Foreign Agent or foreign agent that it has registered as the current care-of address with its home agent. Assume that a mobile node has registered the address of an RFA or foreign agent as its care-of address with its home agent. When detecting that it changes foreign agent, and if the new foreign agent advertises the `I' flag, the mobile node MAY address a Regional Registration Request to that RFA/FA. The new foreign agent MAY then relay the request to the RFA/FA in question, or deny the request with error code 'unknown GFA'. If the Regional Registration Request reaches the RFA/FA, and if the RFA/FA also has the capability to act as a GFA, it MAY accept the request and generate a Regional Registration Reply to the mobile node. This scenario assumes that keys have been distributed to the RFA/FA and to the mobile node prior to the regional registration, so that the Regional Registration Request message can be authenticated with the MN-GFA Authentication extension. Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 37] Internet Draft Regional Registration 1 March 2002 Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Megisto Corp. 6000 Connection Dr. Suite 120 20251 Century Blvd Irving, TX. 75039 Germantown MD 20874 USA USA Phone: +1 972-894-6709 Phone: +1 847-202-9314 Email: Basavaraj.Patil@nokia.com Email: PRoberts@MEGISTO.com Questions about this memo can be directed to: Eva Gustafsson Annika Jonsson Ericsson Inc. Ericsson Radio Systems AB 2100 Shattuck Avenue Network and Systems Research Berkeley, CA 94704 SE-164 80 Stockholm USA SWEDEN +1 510 305-6107 +46 8 4047242 eva.gustafsson@ericsson.com annika.jonsson@ericsson.com Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2986 EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Gustafsson, Jonsson, Perkins Expires 1 September 2002 [Page 38]