Internet Engineering Task Force A. Muhanna INTERNET-DRAFT Nortel Networks draft-muhanna-mobileip-compat-00.txt Date: 20 June 2002 L. Salgarelli Expires: December 2002 Bell Labs P. Boulos Nortel Networks Mobile IPv4 Compatibility Extensions Status of this memo This document is an individual contribution for consideration 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. Muhanna/Salgarelli/Boulos Expires 12/02 [Page 1] INTERNET-DRAFT draft-muhanna-mobileip-compat-00.txt June 2002 Abstract Mobile-IP, together with several other supporting standards such as Reverse Tunneling and the Challenge-Response extensions, have all been recently revised. Although such revisions are for the most part backward compatible with the original versions, sometimes static configuration of Mobile Nodes and Mobility Agents is required to ensure smooth transition and avoid any possible conflict between different standard versions implemented by already-deployed equipment. In this draft we define compatibility extensions for Mobile-IP Agent Advertisement, Registration Request and Registration Reply messages that allow all Mobile-IPv4 entities to dynamically synchronize their "compatibility versions", defined as the versions of the Mobile-IP standards that a particular node is able to support. This solution offers a dynamic mechanism which informs all entities involved in a Mobile-IP exchange of the version of the standard they support, therefore reducing the need to statically configure such information at Mobile Nodes or Mobility Agents Contents 1 Introduction 3 2 The Mobile-IP Compatibility Extension 4 2.1 Compatibility Version Values ............................. 4 3 Mobile-IP Registration process using the Compatibility extension 5 3.1 Foreign Agent Considerations ............................. 5 3.2 Mobile Node Considerations ............................... 6 3.3 Home Agent Considerations ................................ 7 4 Error Values 8 5 Security Considerations 9 Muhanna/Salgarelli/Boulos Expires 12/02 [Page 2] INTERNET-DRAFT draft-muhanna-mobileip-compat-00.txt June 2002 1 Introduction Mobile-IP [1], as well as the set of its supporting mechanisms such as [2], is a relatively new standard. As such, the IETF Mobile-IP WG has been working on continuous enhancements of its original specifications [3], with the creation of new versions of the standards (e.g. RFC2002bis, now [1], and RFC3012bis [4]). While the new versions of the standards are for the most part backward-compatible with their original versions, some of the new or modified features require at least manual configuration of all the entities involved in a Mobile-IP exchange in order to achieve compatibility. While a helping infrastructure (e.g. AAA) can be used to communicate the version of each node to the rest of the Mobile-IP entities, as more parameters are added and changed in each incremental version, the management of backward compatibility gets more complicated by the day. In some circumstances, this helping infrastructure may not be available for use and so the need for a purely mobile IP solution to this problem is needed. One example that illustrates the problem is the case of Mobile Node handover from one foreign agent to another. There is a possibility that the new foreign agent supports a different set of capabilities than the previous one. As another example, a Home Agent in a foreign domain might be dynamically assigned to serve a Mobile Node which it may have never had a previous relation with, and which might support versions of the Mobile-IP standards different from its own. As a final example, we bring up the point that as Mobile-IP nodes are upgraded to new versions, manual configuration of clients and agents is currently needed to ensure compatibility with already-deployed equipment. Therefore, a dynamic mechanism that explicitly details the protocol versions that each node supports is the best approach to synchronize the compatibility between different Mobile-IP versions at the Foreign Agent, Home Agent, and the Mobile Node. In this draft, we propose the introduction of a Mobile-IP Compatibility extension that, included in Agent Advertisements, Registration Requests and Replies, will allow mobile nodes and mobility agents to synchronize the information on which version of the standards they support during the registration procedure, without the need for static configuration. Muhanna/Salgarelli/Boulos Expires 12/02 [Page 3] INTERNET-DRAFT draft-muhanna-mobileip-compat-00.txt June 2002 2 The Mobile-IP Compatibility Extension The Compatibility extension is a skippable TLSV extension [1], and 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 | Sub-Type |Compat.Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (Compatibility extension). Length Indicates the length of the data field within this extension including the Sub-Type octet. It MUST be set to 2. Sub-Type 1, for MN-Net/Net-MN Compatibility extension 2, for FA-HA/HA-FA Compatibility extension. Compatibility Version 0 - 255. The meaning of this field is specified in the following section. This extension is included in registration requests, registration replies, and agent advertisement messages by Mobile-IP nodes that comply with this specification, as explained in section 3. 2.1 Compatibility Version Values The Compatibility Version values of the MN-NET and FA-HA Compatibility extensions indicate what version of the Mobile-IP standards a particular node supports. The absence of the MN-NET Compatibility extension in the Agent Advertisement messages of a Foreign Agent indicates that it supports a MN-NET compatibility version of 0. The same concept is applied when the compatibility extension is missing in either the Mobile-IP Registration Request or Registration Reply messages. Therefore, the significance of what standards to include in Compatibility Version '0' is particularly important. Muhanna/Salgarelli/Boulos Expires 12/02 [Page 4] INTERNET-DRAFT draft-muhanna-mobileip-compat-00.txt June 2002 For Version 0, we propose the inclusion of the following versions of the standards: Compatibility extension Version Value Supported Standards MN-NET 0 RFC2002 + RFC2794 + RFC2977 + RFC3012 + RFC3024 FA-HA 0 RFC2002 + RFC2003 + RFC2006 + RFC2794 + RFC2977 + RFC3012 + RFC3024 The Compatibility version values, as well as the versions of the Mobile-IP standards that refer to them, should be controlled by IANA and by the Mobile-IP Working Group. 3 Mobile-IP Registration process using the Compatibility extension This section presents the overall behavior of Mobile-IP registrations with the proposed compatibility solution. Mobility Agents that support this functionality MUST be able to support their own compatibility version and all lower values. 3.1 Foreign Agent Considerations Foreign Agents compliant with this specification MUST include the NET-MN compatibility extension in their Agent Advertisement messages. This extension provides the Mobile Node with the compatibility version the Foreign Agent supports and can offer for the Mobile Node. When a Foreign Agent that advertised the NET-MN compatibility extension receives an initial registration request message and the MN-NET Compatibility extension is present, the Foreign Agent SHOULD append its Compatibility extension with subtype FA-HA to the registration request message before relaying it to the Home Agent. If the Foreign Agent appends the FA-HA compatibility extension to the registration request message, such extension MUST appear before the FA-HA authentication extension. In the case when a Foreign Agent receives a registration request message with a compatibility extension with subtype of MN-NET and a compatibility version value greater than the one the Foreign Agent advertised, the Foreign Agent MUST reject the registration request with code COMPATIBILITY_VERSION_TOO_HIGH. Muhanna/Salgarelli/Boulos Expires 12/02 [Page 5] INTERNET-DRAFT draft-muhanna-mobileip-compat-00.txt June 2002 If a Foreign Agent relayed a Registration Request message to the Home Agent with the Compatibility extension included and it received a successful Registration Reply message without a Compatibility extension, the Foreign Agent MUST assume that this Home Agent supports a FA-HA compatibility version of '0' (see section 2.1). The Foreign Agent MUST save the compatibility versions of the Mobile Node and the Home Agent in its binding table throughout the session. 3.2 Mobile Node Considerations A Mobile Node that receives an Agent Advertisement with a Compatibility extension, and is able to interpret it, MUST compare its compatibility version with the one received in the Agent Advertisement message. In this case, the Mobile Node MUST append the compatibility extension to the initial registration request message before any authorization enabling extension (e.g. MN-HA, MN-AAA [1]) with a compatibility version not greater than the one received in the Agent Advertisement message. In the case where both the MN-HA authentication and MN-AAA authentication extensions are present in the registration request, the Compatibility extension MUST be placed in the registration message before the MN-HA authentication extension. If a Mobile Node receives an Agent Advertisement that contains no Compatibility extension, it MUST assume that the Foreign Agent supports only MN-NET compatibility version 0. Nevertheless, even in this case, the Mobile Node MUST append its MN-NET compatibility extension to the Registration Request message, as described above, to inform the Home Agent of the compatibility version it supports. When a Mobile Node receives a Registration Reply message with code INVALID_TIMESTAMP_AND_COMPATIBILITY (sections 3.3 and 4), it MUST compare the compatibility version included in the Compatibility extension of the Reply message to its own before it retries to register. In this case, the Mobile Node SHOULD NOT include a Compatibility Version value higher than the one received in the registration reply message. If the Mobile Node receives a successful Registration Reply message without the MN-NET Compatibility extension in response to a registration request where the MN-NET Compatibility extension was included, the Mobile Node MUST assume that its Home Agent only supports a MN-NET Compatibility Version '0' (see section 2.1). Muhanna/Salgarelli/Boulos Expires 12/02 [Page 6] INTERNET-DRAFT draft-muhanna-mobileip-compat-00.txt June 2002 If the negotiated Compatibility version is other than the Mobile Node version, the Mobile Node MUST save this compatibility version throughout the duration of the session, and use it to behave according to the relative standard versions. 3.3 Home Agent Considerations When a Home Agent compliant with this specification receives a Registration Request, after the normal processing of the request as specified in [3] or [1], and before sending back the corresponding registration reply, it proceeds as follows: 1. If the registration request does not contain a Compatibility extension with sub-type FA-HA, the Home Agent MUST assume that the Foreign Agent supports a compatibility version of 0. 2. If the registration request contains a Compatibility extension with sub-type FA-HA, the Home Agent MUST include in the registration reply a Compatibility extension of type FA-HA with the compatibility version set to the lesser of the value declared by the FA and the one that it supports. Such extension MUST appear before the FA-HA Authentication extension. 3. If the registration request does not contain a Compatibility extension with sub-type MN-NET, the Home Agent MUST assume that the Mobile Node supports a compatibility version of 0. 4. If the registration request contains a Compatibility extension with sub-type MN-NET which specifies a compatibility version equal or smaller than the one the Home Agent supports and the Home Agent accepts the registration request, the Home Agent MUST include in the registration reply a Compatibility extension of type MN-NET with the same compatibility version declared by the Mobile Node. Such extension MUST appear before the MN-HA Authentication extension. 5. If the registration request contains a Compatibility extension with sub-type MN-NET which specifies a compatibility version greater than the one the Home Agent supports, the Home Agent MUST reject the registration request with code UNSUPPORTED_COMPATIBILITY_VERSION (see section 4). In the registration reply, the Home Agent MUST include a Compatibility extension with the supported compatibility version. Such extension MUST appear before the MN-HA Authentication extension. In this case the Mobile Node SHOULD Muhanna/Salgarelli/Boulos Expires 12/02 [Page 7] INTERNET-DRAFT draft-muhanna-mobileip-compat-00.txt June 2002 retry the registration using the compatibility version received from the Home Agent. (1) 6. If the registration request contains a Compatibility extension with sub-type MN-NET, and if the normal processing of the registration request would require the Home Agent to generate a reply with code INVALID_TIMESTAMP (133), the Home Agent MUST include in the registration reply a Compatibility extension of type MN-NET with the compatibility version set to the lesser of the value declared by the Mobile Node and the one that it supports. Such extension MUST appear before the MN-HA Authentication extension. Additionally, if the compatibility version declared by the Mobile Node is greater than the one it supports, the Home Agent MUST reject the registration request with code INVALID_TIMESTAMP_AND_COMPATIBILITY. 7. Finally, in case of successful registration, the Home Agent MUST save the compatibility version declared by the Mobile Node and by the Foreign Agent in the binding table for the duration of the session. 4 Error Values Each entry in the following table contains the name of the Code [1] to be returned in a Registration Reply, its corresponding value, and the section in which the error is first mentioned in this specification. Error Name Value Section of Document COMPATIBILITY_VERSION_TOO_HIGH TBD 3.1 UNSUPPORTED_COMPATIBILITY_VERSION TBD 3.3 INVALID_TIMESTAMP_AND_COMPATIBILITY TBD 3.3 _____________________________ (1) Note that statically-assigned Home Agents will usually be upgraded before the Mobile Nodes they support, so this case is unlikely to happen in such scenario. However, there is the possibility that the Mobile Node is dynamically assigned a Home Agent in the Foreign domain. In this case, it is possible that the Mobile Node would be assigned a Home Agent which may support a compatibility version smaller than the one supported by the Mobile Node. This scenario requires a two round trip registration similar to the scenario when the mobile node receives a registration reply message with code of 133 [1]. Muhanna/Salgarelli/Boulos Expires 12/02 [Page 8] INTERNET-DRAFT draft-muhanna-mobileip-compat-00.txt June 2002 5 Security Considerations This document assumes that Mobile-IP messages are authenticated using the authentication extensions defined by the Mobile-IP protocol [3, 1]. Since such authentication extensions are used to protect the extensions specified in this document, this draft does not impose any additional requirements on Mobile-IP messages from a security point of view. Acknowledgments The authors would like to thank Steve Currin and Glenn Morrow for their useful discussions and comments. References [1] Charles Perkins (Editor). IP Mobility Support for IPv4. RFC 3220, IETF, January 2002. [2] Charles Perkins and Pat Calhoun. Mobile IPv4 Challenge/Response Extensions. RFC 3012, IETF, November 2000. [3] Charles Perkins (Editor). IP Mobility Support. RFC 2002, IETF, October 1996. [4] C. Perkins and P. Calhoun. Mobile IPv4 Challenge/Response Extensions. Work in progress - Internet Draft, IETF, May 2002. draft-ietf-mobileip-rfc3012bis-03.txt. Authors' Addresses Ahmad Muhanna, Pierre Boulos Nortel Networks 2201 Lakeside Blvd. Richardson TX 75082, USA Tel.: +1-972-685-{1416,1261} E-Mail: {amuhanna,boulos}@nortelnetworks.com Luca Salgarelli Bell Laboratories - Lucent Technologies Room 4F-506, 101 Crawfords Corner Rd., Holmdel, NJ 07733, USA Tel.: +1-732-332-6870 E-Mail: salga@bell-labs.com Muhanna/Salgarelli/Boulos Expires 12/02 [Page 9] INTERNET-DRAFT draft-muhanna-mobileip-compat-00.txt June 2002 Full Copyright Statement "Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Muhanna/Salgarelli/Boulos Expires 12/02 [Page 10]