MIP4 N. Paulkandasamy Internet-Draft K. Leung Intended status: Standards Track Cisco Systems Expires: September 3, 2007 Mar 2, 2007 Mobile IPv4 NAI-based Home Address Assignment draft-paulkandasamy-mobileip-nai-based-home-addres-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on September 3, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI). Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also Paulkandasamy & Leung Expires September 3, 2007 [Page 1] Internet-Draft NAI-based Home Address Assignment Mar 2007 updates RFC 2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero and specifying a comprehensive procedure for achieving a NAI-based home address assignment and more particularly, the Home Agent and Mobile Node behaviors including the error recovery mechanisms for various scenarios related to NAI-based home address assignment. Paulkandasamy & Leung Expires September 3, 2007 [Page 2] Internet-Draft NAI-based Home Address Assignment Mar 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements and Scope . . . . . . . . . . . . . . . . . . . . 4 3. The NAI-Based Home Address Assignment extensions . . . . . . . 5 3.1. The Mobile Node NAI Extension . . . . . . . . . . . . . . 5 3.2. The Dynamic Home Address Extension . . . . . . . . . . . . 6 4. Proposed Solution Overview . . . . . . . . . . . . . . . . . . 6 5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. The Proposed Scheme . . . . . . . . . . . . . . . . . . . . . 7 6.1. Dynamic Home Address Assignment Scenarios . . . . . . . . 7 6.2. Deregistration Scenarios . . . . . . . . . . . . . . . . . 11 7. MN Considerations . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Sending Registration Requests . . . . . . . . . . . . . . 13 7.1.1. Initial Registration Requests . . . . . . . . . . . . 13 7.1.2. Re-registration Requests . . . . . . . . . . . . . . . 13 7.1.3. Deregistration Requests . . . . . . . . . . . . . . . 13 7.2. Receiving Registration Replies . . . . . . . . . . . . . . 14 7.2.1. Validity Checks . . . . . . . . . . . . . . . . . . . 14 7.2.2. Processing Registration Replies . . . . . . . . . . . 14 8. HA Considerations . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Registration Requests . . . . . . . . . . . . . . . . . . 15 8.1.1. Validity Checks . . . . . . . . . . . . . . . . . . . 15 8.1.2. Processing Registration Requests . . . . . . . . . . . 15 8.2. Sending Registration Replies . . . . . . . . . . . . . . . 15 9. FA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Registration Replies . . . . . . . . . . . . . . . . . . . 16 10. Interactions with Mobile-IPv4 Configuration Option to IPCP . . 16 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11.1. Mobile IP Extension Type . . . . . . . . . . . . . . . . . 17 11.2. Mobile IP Error codes . . . . . . . . . . . . . . . . . . 17 11.2.1. HA Error code . . . . . . . . . . . . . . . . . . . . 17 11.2.2. FA Error codes . . . . . . . . . . . . . . . . . . . . 17 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 13. Backward Compatibility Considerations . . . . . . . . . . . . 18 13.1. Legacy Home Agent . . . . . . . . . . . . . . . . . . . . 18 13.2. Legacy Foreign Agent . . . . . . . . . . . . . . . . . . . 18 13.3. Legacy Mobile Node . . . . . . . . . . . . . . . . . . . . 18 14. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 19 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 16.1. Normative References . . . . . . . . . . . . . . . . . . . 19 16.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. Problem Statement . . . . . . . . . . . . . . . . . . 20 Appendix B. Home Domain Allocation Function (HDAF) . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Paulkandasamy & Leung Expires September 3, 2007 [Page 3] Internet-Draft NAI-based Home Address Assignment Mar 2007 1. Introduction AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI) [RFC2486]. This document specifies the Mobile Node NAI extension to the Mobile IP Registration Request [RFC3344] message from the mobile node. Since the NAI is typically used to uniquely identify the mobile node, the mobile node's home address is not always necessary to provide that function. Thus, it is possible for a mobile node to authenticate itself, and be authorized for connection to the foreign domain, without even having a home address. A message containing the Mobile Node NAI extension MAY set the Home Address field to zero (0) in the Registration Request, to request that a home address be assigned and this document specifies a procedure that the Mobile IP entities should follow in order to facilitate NAI-based home address assignment in such a case. The "Mobile-IPv4 Configuration" option to IPCP has been specified in [RFC2290] for proper interaction between a mobile node and a peer, through which the mobile node connects to the network using PPP. According to that specification the Mobile Node's Home Address field of the option MUST not be zero. However, in the context of this memo which allows a mobile node to be identified by its NAI and to obtain an address after the PPP phase of connection establishment, the Home Address field is allowed to be zero while maintaining all other aspects of RFC 2290. Interpretation of various scenarios from RFC 2290 is given in section 10. 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 [RFC2119]. 2. Requirements and Scope Following are the requirements that the proposed NAI-based home address assignment scheme tries to satisfy. - Allow the Mobile Node (MN) to request a particular address to be assigned as the home address. This allows the MN to continue using its old address across a Home Agent (HA) reboot. Paulkandasamy & Leung Expires September 3, 2007 [Page 4] Internet-Draft NAI-based Home Address Assignment Mar 2007 - Specify that re-registrations MUST have the NAI extension, if the initial registration had one. Also, the re-registrations MUST have the assigned home address in the home address field, unless the MN rebooted. - Specify the HA, FA (Foreign Agent) and the MN behavior for the scenarios where the HA rebooted and/or the MN rebooted after the MN was successfully registered. - Specify a unique error code for the HA to return in the registration reply, when NAI-based home address assignment fails, which will allow the MN to resort to an appropriate error recovery mechanism. - Allow the HA to simultaneously support MNs that support the NAI- based home address assignment procedure described in this document as well as the MNs that don't. (Backward Compatibility) - MN that returns back to its home network is outside the scope of this document and should be covered in the specific address management specification (e.g. DHCP). - NAI-based home address assignment involving a legacy FA is outside the scope of this document. 3. The NAI-Based Home Address Assignment extensions 3.1. The Mobile Node NAI Extension The Mobile Node NAI extension, shown in figure 1, contains the user name following the format defined in [RFC2486]. When it is present in the Registration Request, the Home Address field MAY be set to zero (0). The Mobile Node NAI extension MUST appear in the Registration Request before both the Mobile-Home Authentication extension and the Mobile-Foreign 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 | MN-NAI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 131 (skippable) [RFC3344] Length The length in bytes of the MN-NAI field Paulkandasamy & Leung Expires September 3, 2007 [Page 5] Internet-Draft NAI-based Home Address Assignment Mar 2007 MN-NAI A string in the NAI format defined in [RFC2486]. 3.2. The Dynamic Home Address Extension This extension, also referred to as the Dynamic-HoA, is a skippable extension, included by the MN to inform the home agent that the MN is capable of the dynamic home address assignment procedure outlined in this document. This extension follows the Type-Length-Value extension format as defined in RFC 3344. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Dynamic-HoA (skippable) Length 0 The Dynamic-HoA extension MUST always precede the authorization- enabling extension between the MN and the HA. When this extension is present and the RRQ(HoA) is non-zero, the HA tries to assign the RRQ(HoA) to the MN. If it is unable to assign this requested address, the HA MUST try to allocate an alternative address to the MN and return it in the RRP(HoA). If the HA is unable to assign the requested address or an alternative address, the HA returns a RRP with code ADDR_ALLOC_FAILED and the HoA set to 0.0.0.0. When this extension is present and the RRQ(HoA) is 0.0.0.0, and if there is an existing binding entry for that MN, then the HA MUST return the home address in the MN's binding entry as the RRP(HoA). If there is no binding entry, then the HA MUST try to assign a new address to the MN and return it in the RRP(HoA). If the HA is unable to assign a address to the MN, the HA returns a RRP with code ADDR_ALLOC_FAILED and the RRP(HoA) set to 0.0.0.0. 4. Proposed Solution Overview In this procedure, the mobile node can request dynamic home address assignment, by appending the NAI extension [RFC2794] to the registration request along with the Dynamic-HoA extension (defined in section 3.2) and by setting the home address field to 0.0.0.0 or to a particular address (as a hint) that it prefers to be assigned. Paulkandasamy & Leung Expires September 3, 2007 [Page 6] Internet-Draft NAI-based Home Address Assignment Mar 2007 If the home address field is 0.0.0.0 and the request has a NAI extension as well as the Dynamic-HoA extension, indicating that the mobile node is capable of dynamic home address assignment, then the home agent tries to assign a new address for the mobile node and return a reply with the home address field containing the assigned address. If the home agent is unable to assign an address, it rejects the request with the code ADDR_ALLOC_FAILED. If the home address field is non-zero and the request has a NAI extension as well as the Dynamic-HoA extension, indicating that the mobile node is capable of dynamic home address assignment, the home agent tries to assign the requested address specified in the home address field and return the same address in the reply. If the home agent is unable to assign the requested address, the home agent tries to assign an alternative address and return the alternative address in the reply. If the home agent is unable to assign an alternative address, it rejects the request with the code ADDR_ALLOC_FAILED. In all the above cases, if the registration request does not contain the Dynamic-HoA extension, the HA behaves according to the RFC 2794 and RFC 3344. 5. Terminology RRQ(HoA) Home Address Value in the RRQ RRQ(NAI) NAI value in the NAI Extension [RFC2794] in the RRQ RRP(HoA) Home Address Value in the RRP Binding(HoA) Home Address of the Mobile Node in the HA's Binding List Dynamic-HoA Dynamic Home Address extension != Not Equal To == Equal To 6. The Proposed Scheme The following tables summarize the behavior of the HA, FA and MN in various scenarios involving dynamic home address assignment and deregistrations. Each of the cases in the tables are described in detail following each table. 6.1. Dynamic Home Address Assignment Scenarios This table outlines the scenarios involving dynamic address assignment, where the RRQ contains the NAI extension and the Dynamic- HoA extension and the lifetime in the RRQ is non-zero. Paulkandasamy & Leung Expires September 3, 2007 [Page 7] Internet-Draft NAI-based Home Address Assignment Mar 2007 +----------+----------+------------------+-----------------------+ | | | HoA is Unassigned| Case 1 | | | No +------------------+-----------------------+ | | Binding | HoA Not Allowed | | | | for | OR | Case 2 | | | RRQ(NAI) | HoA in Use by | | | Non-Zero | | a different MN | | | HoA +----------+------------------+-----------------------+ | | | RRQ(HoA) == | Case 3 | | | Binding | Binding(HoA) | | | | Exists +------------------+-------------+---------+ | | for | | RRQ(HoA) | Case 4 | | | RRQ(NAI) | RRQ(HoA) != | Available | | | | | Binding(HoA) +-------------+---------+ | | | | RRQ(HoA) | Case 5 | | | | | Unavailable | | +----------+----------+------------------+-------------+---------+ | | No | | | | Binding | Case 6 | | | for | | | Zero | RRQ(NAI) | | | HoA +----------+------------------------------------------+ | | Binding | | | | Exists | Case 7 | | | for | | | | RRQ(NAI) | | +----------+----------+------------------------------------------+ Case 1: Scenario: HA reboots after a MN successfully registered and then receives a re-registration from the MN. For the HA, this RRQ is indistinguishable from an initial RRQ, since there is no binding. HA Behavior: The HA MUST try to assign the RRQ(HoA) to the MN, and if successful, it MUST create the binding entry and send a successful RRP with HoA == RRQ(HoA). FA Behavior: If the Code value in the RRP indicates that the registration was accepted by the HA, then the FA MUST create or update the corresponding visitor entry with HoA == RRP(HoA). MN Behavior: If the Code value in the RRP indicates that the registration was accepted, then the MN starts using the RRP(HoA). Paulkandasamy & Leung Expires September 3, 2007 [Page 8] Internet-Draft NAI-based Home Address Assignment Mar 2007 Case 2: Scenario: HA reboots after a MN successfully registered and then receives a re-registration from the MN and the HA is unable to assign the RRQ(HoA) to the MN. HA Behavior: The HA MUST try to assign an alternative address and if successful, it MUST create a new binding entry and MUST return a RRP with HoA containing the alternative address. If the HA is unable to assign an alternative address, it MUST return a RRP with the code ADDR_ALLOC_FAILED and RRP(HoA) set to 0.0.0.0. FA Behavior: If the Code value in the RRP indicates that the registration was accepted by the HA, then the FA MUST create or update the corresponding visitor entry with HoA == RRP(HoA). If the RRP has the code ADDR_ALLOC_FAILED, the FA just forwards the RRP to the MN without taking any action. MN Behavior: Same behavior as in Case 1. Case 3: Scenario: MN reboots after it was successfully registered and then tries dynamic home address assignment using Dynamic-HoA extension with RRQ(HoA) containing the requested address. HA Behavior: No new behavior. The HA MUST return the Binding(HoA) in the RRP(HoA). FA Behavior: Same behavior as in Case 1. MN Behavior: Same behavior as in Case 1. Case 4: Scenario: MN reboots after it was successfully registered and then tries dynamic home address assignment using Dynamic-HoA extension with RRQ(HoA) containing the requested address. But the HA has a binding entry for the MN in its binding list with HoA different from the RRQ(HoA). This could be the case where the MN has been configured with a preferred address but was assigned a different address during its previous registration before the reboot. Paulkandasamy & Leung Expires September 3, 2007 [Page 9] Internet-Draft NAI-based Home Address Assignment Mar 2007 HA Behavior: Same behavior as in case 1. The HA MUST try to assign RRQ(HoA) to the MN and if successful, it MUST create a new binding entry and return a RRP with HoA == RRQ(HoA). FA Behavior: Same behavior as in Case 1. MN Behavior: Same behavior as in Case 1. Case 5: Scenario: Same as case 4, except that the RRQ(HoA) cannot be assigned to the MN. HA Behavior: Same behavior as in case 2. FA Behavior: Same behavior as in case 2. MN Behavior: Same behavior as in case 1. Case 6: Scenario: Initial RRQ (No binding in the HA). MN and HA reboot after a successful registration. HA Behavior: The HA MUST try to assign a new HoA for the MN and return it in the RRP(HoA). FA Behavior: Same behavior as in case 1. MN Behavior: If the RRP indicates that the registration request was accepted and RRP(HoA) is non-zero, then the MN starts using the RRP(HoA). Case 7: Scenario: MN reboots after successfully registering and then sends a RRQ with the Dynamic-HoA. HA Behavior: HA returns Binding(HoA) in the RRP(HoA). FA Behavior: Same behavior as in case 1. MN Behavior: Same behavior as in case 6. Paulkandasamy & Leung Expires September 3, 2007 [Page 10] Internet-Draft NAI-based Home Address Assignment Mar 2007 6.2. Deregistration Scenarios +----------+---------------------------+------------------+ | | | | | | No Binding | | | | for | Case 1 | | | (RRQ(NAI),RRQ(HoA)) | | | Non-zero | | | | RRQ(HoA) +---------------------------+------------------+ | | | | | | Binding Exists | | | | for | Case 2 | | | (RRQ(NAI),RRQ(HoA)) | | | | | | +----------+---------------------------+------------------+ | | | | | | No Binding | | | | for | Case 3 | | | RRQ(NAI) | | | Zero | | | | RRQ(HoA) +---------------------------+------------------+ | | | | | | Binding Exists | | | | for | Case 4 | | | RRQ(NAI) | | | | | | +----------+---------------------------+------------------+ Case 1: Scenario: HA reboots after the MN successfully registered. HA Behavior: The HA MUST send a reply indicating the registration was accepted with RRP(HoA) == RRQ(HoA), since this will allow the MN to stop using the home address. FA Behavior: If the RRP indicates that the RRQ was accepted, the FA MUST delete the visitor entry corresponding to RRP(NAI) and RRP(HoA). The FA MUST forward the RRP in even if there is no corresponding visitor entry. MN Behavior: If the RRP indicates that the RRQ was accepted, then the MN stops using the RRP(HoA). Paulkandasamy & Leung Expires September 3, 2007 [Page 11] Internet-Draft NAI-based Home Address Assignment Mar 2007 Case 2: Scenario: Normal deregistration scenario. HA Behavior: The HA MUST delete the binding entry with the matching RRQ(NAI) and RRQ(HoA) depending upon the value of the care-of address in the RRQ as per RFC 3344. FA Behavior: Same as in Case 1. MN Behavior: Same as in Case 1. Case 3: Scenario: The MN and the HA reboot after the MN successfully registered and the MN sends a deregistration with zero HoA. And in this case, the HA does not have any binding corresponding to the RRQ(NAI). HA Behavior: The HA MUST send a RRP indicating the registration was accepted. FA Behavior: If the RRP indicates that the RRQ was accepted, and the RRP(HoA) is zero, the FA MUST delete all the visitor entries corresponding to RRP(NAI). The FA MUST forward the RRP in even if there is no corresponding visitor entry. MN Behavior: No new behavior. Case 4: Scenario: The MN reboots after it successfully registered with the HA and wants the HA to clear all the bindings corresponding to its NAI. HA Behavior: The HA MUST delete all the binding entries corresponding to the RRQ(NAI). This will enable the HA to clear the stale binding entries, in case of a MN reboot. FA Behavior: Same as in Case 3. MN Behavior: No new behavior. 7. MN Considerations Paulkandasamy & Leung Expires September 3, 2007 [Page 12] Internet-Draft NAI-based Home Address Assignment Mar 2007 7.1. Sending Registration Requests 7.1.1. Initial Registration Requests This section describes the MN considerations for the initial registration case, where the MN is trying to acquire a new home address from its HA. A MN following the NAI-based home address assignment procedure specified in this document, MUST append the NAI extension to the RRQ and MUST follow one of the following methods whenever it wants to acquire a new home address: - by sending the RRQ(HoA) as 0.0.0.0 along with the Dynamic-HoA extension. - by sending a preferred address in the home address field along with the Dynamic-HoA extension. In the case where the MN is registering via a FA, the MN MUST set the IP Source Address of the RRQ to 0.0.0.0, if it is requesting dynamic home address assignment, even for cases where the MN is sending a non-zero value in the RRQ(HoA) as a hint to the HA. 7.1.2. Re-registration Requests Once the MN successfully obtains a dynamically assigned home address from its HA, it MUST set the home address field to that address and MUST append the NAI extension as well as the Dynamic-HoA extension that was included in its last successful registration, in all its subsequent re-registrations. 7.1.3. Deregistration Requests To deregister a specific dynamic address that was obtained using the procedures mentioned in this document, the MN MUST append the NAI extension and MUST set the RRQ(HoA) to that assigned home address. The MN MAY also append the Dynamic-HoA extension from its last successful RRQ. In cases like a MN reboot, the MN MAY try to clear the stale binding entries in the HA by sending a deregistration with the NAI extension and with RRQ(HoA) set to 0.0.0.0. In this case, the MN MUST add the Dynamic-HoA extension to inform the HA and the FA to follow the deregistration procedures defined in section 6.2 of this document. Paulkandasamy & Leung Expires September 3, 2007 [Page 13] Internet-Draft NAI-based Home Address Assignment Mar 2007 7.2. Receiving Registration Replies 7.2.1. Validity Checks Whenever a MN sends a RRQ with a Dynamic-HoA extension, it SHOULD verify that the corresponding RRP also includes the Dynamic-HoA extension. If the RRP does not have the Dynamic-HoA extension, then the MN SHOULD assume that the HA is incapable of the NAI-Based home address assignment procedure and the MN SHOULD behave as per RFC 2794 and RFC 3344. 7.2.2. Processing Registration Replies Whenever a MN sends a registration request, it can receive any of the following type of replies from the HA. - RRQ rejected with code ADDR_ALLOC_FAILED. In this case, the MN's request for dynamic home address assignment has been rejected by the HA. The MN can resort to some error recovery mechanism depending upon the type of RRQ that got rejected. For example, if the dynamic address assignment failed, the MN could try registering using a static address as per the RFC 2794 and RFC 3344. - RRQ accepted with RRP(HoA) == RRQ(HoA). In this case, the MN requested a non-zero home address and the HA was able to assign the same address to the MN. - RRQ accepted with RRP(HoA) != RRQ(HoA) If the RRQ(HoA) was 0.0.0.0, then the HA assigned a new address to the MN. If the RRQ(HoA) was non-zero and the RRQ was sent with a Dynamic- HoA extension, then the HA assigned a different address to the MN than the RRQ(HoA). In this case, the MN MUST check for the presence of the Dynamic-HoA extension. If this was a re-registration request where the HoA was obtained from a successful reply, then the MN MUST stop using the old address RRQ(HoA) and MUST start using the new address RRP(HoA), since this could be the case where the HA rebooted and cannot allocate the RRQ(HoA) to this MN again. In addition to these replies, the MN can also receive registration replies denied by the FA as per section 3 of RFC 2794. Paulkandasamy & Leung Expires September 3, 2007 [Page 14] Internet-Draft NAI-based Home Address Assignment Mar 2007 8. HA Considerations 8.1. Registration Requests 8.1.1. Validity Checks If the Dynamic-HoA extension is present in the RRQ, it MUST precede an authorization-enabling extension between the MN and the HA. Otherwise the HA SHOULD reject the RRQ with Code 134 (poorly formed request)[RFC3344]. The HA MAY choose to ignore such requests, to prevent any possible DOS attacks. The HA MUST start the NAI-based home address assignment procedure for a RRQ having a non-zero lifetime value, only after authenticating the MN using an authorization-enabling extension. If the RRQ has a Dynamic-HoA extension and the MN is not provisioned for dynamic home address assignment, then the HA MUST reject the RRQ with code 129 (administratively prohibited)[RFC3344]. 8.1.2. Processing Registration Requests Upon receiving a RRQ with a non-zero lifetime, the home-agent can provide dynamic home address assignment to the MN. This is the case where the RRQ has the Dynamic-HoA extension. The HA behavior for this case will be as defined in the sections 3.2 and 6.1. The HA behavior in the case of a deregistration will be as defined in section 6.2. 8.2. Sending Registration Replies If the HA is successful in assigning a new address for the MN, then it sends a RRP with the home address field containing the newly assigned address. If the HA is denying the request with ADDR_ALLOC_FAILED, then the home address field MUST be set to 0.0.0.0. If the RRQ included the Dynamic-HoA Extension and the HA is able to recognize that extension, then it MUST include same extension in the RRP, preceding the authorization-enabling extension between the MN and the HA. On the other hand, if the HA does not recognize the Dynamic-HoA extension, then the HA MUST NOT include this extension in the RRP. This would enable the MN to know whether the HA is capable of NAI-based home address assignment procedure. Paulkandasamy & Leung Expires September 3, 2007 [Page 15] Internet-Draft NAI-based Home Address Assignment Mar 2007 9. FA Considerations Upon receiving a Registration Request only with a NAI extension and with Home Address set to zero, the Registration Request, the foreign agent MUST use the NAI instead in its pending registration request records, along with the Identification field as usual. If the foreign agent cannot manage pending registration request records in this way, it MUST return a Registration Reply with Code indicating NONZERO_HOMEADDR_REQD (section 11). If the mobile node includes the Mobile Node NAI extension in its Registration Request, then the Registration Reply from the home agent MUST include the Mobile Node NAI extension. If not, the foreign agent SHOULD send the Registration Reply to the mobile node, changing the Code to the value MISSING_NAI (section 11). The Registration Reply MUST include a nonzero Home Agent address and mobile node's Home Address. If not, the foreign agent SHOULD send the Registration Reply to the mobile node, changing the Code to the value MISSING_HOME_AGENT or MISSING_HOMEADDR, respectively (section 11). In addition, if the RRQ or the RRP included the Dynamic-HoA extension, the FA MUST follow the procedures mentioned in the following sections. 9.1. Registration Replies Whenever the FA is originating a RRP with a FA reject code or forwarding a RRP from the HA to the MN, it MUST set the IP Destination address of the reply to be the IP Source Address of the corresponding RRQ, if it is non-zero. This is because, in the case of NAI-based home address assignment, the FA has no way of knowing if the MN has already started using the RRQ(HoA) or the RRP(HoA). If the IP Source Address of the RRQ is set to 0.0.0.0, then the IP Destination address is set to 255.255.255.255. This is because, if the foreign agent set the IP Destination Address of a successful reply to the mobile node's home address as per RFC 3344 (section 3.7.2.3), the mobile node might not be knowing its home address till it gets the first successful registration reply and so might not be able to receive the reply packet. 10. Interactions with Mobile-IPv4 Configuration Option to IPCP In the Mobile-IPv4 Configuration Option to IPCP [RFC2290], the Mobile Node's Home Address field may be zero. In this section, we specify the action to be taken in that case, when the mobile node is using the Mobile Node NAI extension in the Mobile IP Registration Request. Paulkandasamy & Leung Expires September 3, 2007 [Page 16] Internet-Draft NAI-based Home Address Assignment Mar 2007 Whether or not the IP Address Configuration Option contains a nonzero IP address, the mobile node will subsequently attempt to obtain a home address from the Mobile IP Registration Reply. If the IP Address Configuration Option to IPCP has IP address equal to zero, the PPP peer is expected to allocate and assign a co-located care-of address to the Mobile Node. If, on the other hand, the IP Address Configuration Option to IPCP has a nonzero IP address, the PPP peer is expected to assign that address to the Mobile Node as its co-located care-of address. Finally, if the IP Address Configuration Option is left out of the IPCP Configure-Request, then no co-located care of address is assigned during IPCP. The mobile node will acquire a co-located care of address during a later stage of configuration or will use an FA- located care-of address. 11. IANA Considerations 11.1. Mobile IP Extension Type This document introduces the following Mobile IP extension type. Name : Dynamic Home Address extension Type Value : TBD Section : 3.2 11.2. Mobile IP Error codes 11.2.1. HA Error code This document introduces the following error code that can be returned by the HA in a Mobile IP Registration Reply. Name Value section first referenced ---- ----- ------------------------ ADDR_ALLOC_FAILED TBD 3.2 11.2.2. FA Error codes This document introduces the following error codes that can be returned by the FA in a Mobile IP Registration Reply. Paulkandasamy & Leung Expires September 3, 2007 [Page 17] Internet-Draft NAI-based Home Address Assignment Mar 2007 Name Value section first referenced ---- ----- ------------------------ NONZERO_HOMEADDR_REQD 96 9 MISSING_NAI 97 9 MISSING_HOME_AGENT 98 9 MISSING_HOMEADDR 99 9 12. Security Considerations The above mentioned procedure for NAI-based home address assignment introduces the Dynamic-HoA extension which MUST be protected by an authorization-enabling extension [RFC3344] between the MN and the HA. Thus, this procedure does not introduce any new security concerns. 13. Backward Compatibility Considerations 13.1. Legacy Home Agent Upon receiving a RRQ from a MN following the procedure outlined in this document, the legacy HA SHOULD follow the behavior as per RFC 2794 and RFC 3344 ignoring the Dynamic-HoA extension which has been defined in the skippable range of extensions. 13.2. Legacy Foreign Agent For the cases where the RRQ is sent by the MN with home address field set to 0.0.0.0 or where the RRQ(HoA) is non-zero and is the same as RRP(HoA), the behavior of the legacy FA should be the same as per RFC 2794. For the case where the RRQ(HoA) is non-zero and is different from the RRP(HoA) the behavior is implementation dependant, since this case was outlined neither in RFC 2794 nor in RFC 3344. Hence, the scenarios involving a legacy FA operating between a MN and a HA following the NAI-based home address assignment procedure described in this document is outside the scope of this document. 13.3. Legacy Mobile Node The behavior of a legacy MN will not be affected, since the new behavior will be applicable only for RRQs and RRPs which include the Dynamic-HoA extension. Paulkandasamy & Leung Expires September 3, 2007 [Page 18] Internet-Draft NAI-based Home Address Assignment Mar 2007 14. IPv6 Considerations Supporting NAI-based registrations for Mobile IPv6 [RFC3775] is outside the scope of this document. This section contains some ideas how Stateless Address Autoconfiguration [RFC2462] and DHCPv6 [RFC3315] might be extended to support NAI-based Mobile IPv6 registrations. For mobile nodes using IPv6, there are no commonly deployed mechanisms by which a mobile node may present its credentials, such as exist today with IPv4. Nevertheless, a mobile node using IPv6 mobility may wish to specify the domain in which their credentials may be checked, by using a NAI just as this specification proposes for IPv4. In the case of IPv6, however, there is no foreign agent in place to manage the connectivity of the mobile node, and thus to manage the verification of the credentials offered by the mobile node. To identify the HDAF (Appendix B) that has the expected relationship with the mobile node, the NAI would have to be forwarded to a local AAA by the local agent involved with configuring the care-of address of the mobile node. This agent can either be a router sending out Router Advertisements [RFC2462], or a DHCPv6 server. In the former case, the router could signal its ability to handle the NAI by attaching some yet to be defined option to the Router Advertisement. In the latter case, for managed links, the mobile node could include a yet to be defined NAI extension in its DHCP Solicitation message. Such an NAI extension and appropriate authentication would also be required on the subsequent DHCP Request sent by the mobile node to the DHCP Server selected on the basis of received DHCP Advertisements. Once a care- of address on the foreign network has been obtained, the mobile node can use regular MIPv6 [RFC3775]. 15. Acknowledgements Thanks to Alpesh Patel and Alan O'Neill for their review and suggestions. 16. References 16.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2290] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Paulkandasamy & Leung Expires September 3, 2007 [Page 19] Internet-Draft NAI-based Home Address Assignment Mar 2007 Option for PPP IPCP", RFC 2290, February 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. 16.2. Informative References [RFC2344] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May 1998. [RFC2356] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Appendix A. Problem Statement With the introduction of NAIs for identifying Mobile Nodes, RFC 2794 also enabled the Home Agents to be able to assign IP addresses to Mobile Nodes during their initial registration. Though the concept of NAI-based home address assignment is referenced in both RFC 2794 and RFC 3344, a comprehensive procedure for achieving such a NAI- based home address assignment has not been outlined. More particularly, the Home Agent and Mobile Node behaviors including the error recovery mechanisms for various scenarios related to NAI-based home address assignment have not yet been specified as described below. - Home Agent and Mobile Node behaviors during various error scenarios have not been clearly specified. RFC 2794 allows the mobile node to send a registration request with the NAI extension and with a non-zero home address. In this scenario, the home agent behavior is undefined for the case where it is unable to Paulkandasamy & Leung Expires September 3, 2007 [Page 20] Internet-Draft NAI-based Home Address Assignment Mar 2007 assign that requested home address. For example, whether the home agent should return a error code informing that it cannot assign the requested home address or whether the home agent can assign an alternative address and return it in the reply. Another example could be the scenario where the home agent reboots after a mobile node successfully registered and then the home agent receives a re-registration from the mobile node. For the home agent, this request is indistinguishable from an initial request as mentioned in the paragraph above. In this case, if the home agent is unable to assign the home address in the request, there are no error codes or provisions that the HA can use to inform the MN that the address assignment failed for the requested home address, but it might still be able to assign a new home address. - Home Agent and the Mobile Node behaviors during the re- registration and deregistration scenarios have not been clearly outlined for the case where the mobile node obtained the home address using NAI-based home address assignment. For example, whether the NAI extension is mandatory in re-registrations or deregistrations, or whether the home address field in the re- registrations and deregistrations can be 0.0.0.0. - Other details like what should be the IP Destination Address of the first successful registration reply forwarded by the foreign agent to the mobile node in the case of a dynamic home address assignment has not been specified. According to RFC 3344 (section 3.7.2.3), the foreign agent should set the IP Destination Address of a successful reply to the mobile node's home address. But in the case of NAI-based home address assignment, the mobile node might not be knowing its home address till it gets the first successful registration reply and so it might not be able to receive the packet if the IP Destination Address was set to its home address. This document specifies a procedure that the Mobile IP entities should follow in order to facilitate NAI-based home address assignment under various circumstances like those mentioned above. Appendix B. Home Domain Allocation Function (HDAF) This appendix introduces a new function named the Home Domain Allocation Function (HDAF) that can dynamically assign a Home Address to the mobile node. The figure below illustrates the Home HDAF, which receives messages Paulkandasamy & Leung Expires September 3, 2007 [Page 21] Internet-Draft NAI-based Home Address Assignment Mar 2007 from foreign agents (e.g., FA) and assigns a Home Address within the Home Domain. The HDAF does not perform any Mobile IP processing on the Registration Request, but simply forwards the request to a Home Agent (HA) within the network that is able to handle the request. +------+ | | +---+ HA-1 | +------+ +------+ +------+ | | | | | | | | | | +------+ | MN |-------| FA |-------| HDAF +---+ ... | | | | | | | +------+ +------+ +------+ +------+ | | | +---+ HA-n | | | +------+ Figure 2: Home Domain Allocator Function (HDAF) Upon receipt of the Registration Request from the mobile node (MN), FA extracts the NAI and finds the domain name associated with it. FA then finds the HDAF that handles requests for the mobile node's domain. The discovery protocol is outside of the scope of this specification. As an example, however, FA might delegate the duty of finding a HDAF to a local AAA server. The local AAA server may also assist FA in the process of verifying the credentials of the mobile node, using protocols not specified in this document. Authors' Addresses Naveen Paulkandasamy Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-527-8404 Email: naveenpk@cisco.com Paulkandasamy & Leung Expires September 3, 2007 [Page 22] Internet-Draft NAI-based Home Address Assignment Mar 2007 Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-526-5030 Email: kleung@cisco.com Paulkandasamy & Leung Expires September 3, 2007 [Page 23] Internet-Draft NAI-based Home Address Assignment Mar 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Paulkandasamy & Leung Expires September 3, 2007 [Page 24]