Mobile IP Working Group Naveen PaulKandasamy INTERNET-DRAFT Kent Leung Category: Standards Track Cisco Systems January 2006 Mobile IPv4 NAI-based Home Address Assignment draft-paulkandasamy-mobileip-nai-based-home-addres-01.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 July 20, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract 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 Paulkandasamy & Leung Expires - July 20, 2006 [Page 1] NAI-Based Home Address Assignment January, 2006 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. This document specifies a procedure that the Mobile IP entities should follow in order to facilitate NAI-based home address assignment under various circumstances. Table of Contents Status of this Memo.................................................1 Abstract............................................................1 Table of Contents...................................................2 1. Problem Statement................................................3 2. Proposed Solution Overview.......................................4 3. Terminology......................................................4 4. Requirements and Scope...........................................5 5. The Dynamic Home Address Extension...............................5 6. The Proposed Scheme..............................................6 6.1 Dynamic Home Address Assignment Scenarios.......................6 6.2 Deregistration Scenarios........................................9 7. MN Considerations...............................................11 7.1 Sending Registration Requests..................................12 7.1.1 Initial Registration Requests................................12 7.1.2 Re-registration Requests.....................................12 7.1.3 Deregistration Requests......................................12 7.2 Receiving Registration Replies.................................12 7.2.1 Validity Checks..............................................13 7.2.2 Processing Registration Replies..............................13 8. HA Considerations...............................................13 8.1 Registration Requests..........................................13 8.1.1 Validity Checks..............................................13 8.1.2 Processing Registration Requests.............................14 8.2 Sending Registration Replies...................................14 9. FA Considerations...............................................14 9.1 Registration Replies...........................................15 10. IANA Considerations............................................15 10.1 Mobile IP Extension Type......................................15 10.2 Mobile IP HA Error codes......................................15 11. Security Considerations........................................15 12. Backward Compatibility Considerations..........................15 12.1 Legacy Home Agent.............................................15 12.2 Legacy Foreign Agent..........................................16 12.3 Legacy Mobile Node............................................16 13. Acknowledgements...............................................16 References.........................................................16 Authors’ Addresses.................................................16 Copyright Statement................................................17 Acknowledgement....................................................17 Paulkandasamy & Leung Expires - July 20, 2006 [Page 2] NAI-Based Home Address Assignment January, 2006 1. 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 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 Paulkandasamy & Leung Expires - July 20, 2006 [Page 3] NAI-Based Home Address Assignment January, 2006 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. 2. Proposed Solution Overview In this procedure, the mobile node can request dynamic home address assignment, by appending the NAI extension [1] to the registration request along with the Dynamic Home Address extension (defined in section 5 and hereafter referred to as the Dynamic-HoA) 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. If the home address field is 0.0.0.0 and the request has a NAI extension as well 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. 3. Terminology MN Mobile Node as defined in RFC 3344 HA Home Agent as defined in RFC 3344 FA Foreign Agent as defined in RFC 3344 Paulkandasamy & Leung Expires - July 20, 2006 [Page 4] NAI-Based Home Address Assignment January, 2006 RRQ Mobile IP Registration Request as defined in RFC 3344 RRP Mobile IP Registration Reply as defined in RFC 3344 HoA MN’s Home Address RRQ(HoA) Home Address Value in the RRQ RRQ(NAI) NAI value in the NAI Extension [1] 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, defined in section 5 != Not Equal To == Equal To 4. Requirements and Scope Following are the requirements that the proposed NAI-based home address assignment scheme tries to satisfy. - Allow the 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 HA reboot. - 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/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. 5. The Dynamic Home Address Extension Paulkandasamy & Leung Expires - July 20, 2006 [Page 5] NAI-Based Home Address Assignment January, 2006 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 [2]. 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. 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 - July 20, 2006 [Page 6] NAI-Based Home Address Assignment January, 2006 +----------+----------+------------------+-----------------------+ | | | 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 - July 20, 2006 [Page 7] NAI-Based Home Address Assignment January, 2006 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 Paulkandasamy & Leung Expires - July 20, 2006 [Page 8] NAI-Based Home Address Assignment January, 2006 a different address during its previous registration before the reboot. 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. 6.2 Deregistration Scenarios Paulkandasamy & Leung Expires - July 20, 2006 [Page 9] NAI-Based Home Address Assignment January, 2006 This table outlines the deregistration scenarios related to the cases where the address was assigned using the dynamic home address assignment procedure. The HA and the FA MUST follow this procedure only if the deregistration request contains the Dynamic-HoA extension. +----------+---------------------------+------------------+ | | | | | | 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). Case 2: Paulkandasamy & Leung Expires - July 20, 2006 [Page 10] NAI-Based Home Address Assignment January, 2006 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 - July 20, 2006 [Page 11] NAI-Based Home Address Assignment January, 2006 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. 7.2 Receiving Registration Replies Paulkandasamy & Leung Expires - July 20, 2006 [Page 12] NAI-Based Home Address Assignment January, 2006 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. 8. HA Considerations 8.1 Registration Requests 8.1.1 Validity Checks Paulkandasamy & Leung Expires - July 20, 2006 [Page 13] NAI-Based Home Address Assignment January, 2006 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) [2]. 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) [2]. 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 5 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. 9. FA Considerations Upon receiving a RRQ or a RRP with a NAI extension, the FA MUST perform all the applicable validity checks mentioned in section 3 of RFC 2794. In addition, if the RRQ or the RRP included the Dynamic-HoA extension, the FA MUST follow the procedures mentioned in this document. Paulkandasamy & Leung Expires - July 20, 2006 [Page 14] NAI-Based Home Address Assignment January, 2006 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. IANA Considerations 10.1 Mobile IP Extension Type This document introduces the following Mobile IP extension type. Name : Dynamic Home Address extension Type Value : TBD Section : 5 10.2 Mobile IP HA Error codes This document introduces two error codes that can be returned by the HA in a Mobile IP Registration Reply. Name Value section first referenced ---- ----- ------------------------ ADDR_ALLOC_FAILED TBD 2 11. 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 [2] between the MN and the HA. Thus, this procedure does not introduce any new security concerns. 12. Backward Compatibility Considerations 12.1 Legacy Home Agent Paulkandasamy & Leung Expires - July 20, 2006 [Page 15] NAI-Based Home Address Assignment January, 2006 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. 12.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. 12.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. 13. Acknowledgements Thanks to Alpesh Patel and Alan O’Neill for their review and suggestions. References [1] P. Calhoun and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000. [2] C. Perkins, "IP Mobility Support for IPv4", RFC 3344, August 2002. Authors’ Addresses Naveen PaulKandasamy Kent Leung Cisco Systems Inc. Cisco Systems Inc. 170 W. Tasman Drive 170 W. Tasman Drive San Jose, CA 95134 San Jose, CA 95134 USA USA Email: naveenpk@cisco.com Email: kleung@cisco.com Phone: +1 408-527-8404 Phone: +1 408-526-5030 Intellectual Property Statement Paulkandasamy & Leung Expires - July 20, 2006 [Page 16] NAI-Based Home Address Assignment January, 2006 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Paulkandasamy & Leung Expires - July 20, 2006 [Page 17]