Network Working Group G. Tsirtsis Internet-Draft V. Park Intended status: Standards Track V. Narayanan Expires: August 4, 2007 Qualcomm K. Leung Cisco January 31, 2007 FA extensions to NEMOv4 Base draft-tsirtsis-nemov4-fa-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 August 4, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Tsirtsis, et al. Expires August 4, 2007 [Page 1] Internet-Draft FA extensions to NEMOv4 Base January 2007 Abstract The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. NEMOv4 extensions are defined for use only by the mobile node and the home agent. This specification introduces extensions for NEMO support on the foreign agent. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Extension Formats . . . . . . . . . . . . . . . . . . . . . . 6 4.1. NEMOv4 Tunneling Extension . . . . . . . . . . . . . . . . 6 5. Mobile IP registrations . . . . . . . . . . . . . . . . . . . 7 5.1. Registration Requests . . . . . . . . . . . . . . . . . . 7 5.2. Registration Reply . . . . . . . . . . . . . . . . . . . . 7 5.3. Home Agent Considerations . . . . . . . . . . . . . . . . 7 5.4. Foreign Agent Considerations . . . . . . . . . . . . . . . 8 5.5. Mobile Client Considerations . . . . . . . . . . . . . . . 9 5.6. Disparate Address Space Support . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Tsirtsis, et al. Expires August 4, 2007 [Page 2] Internet-Draft FA extensions to NEMOv4 Base January 2007 1. Requirements notation 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]. Tsirtsis, et al. Expires August 4, 2007 [Page 3] Internet-Draft FA extensions to NEMOv4 Base January 2007 2. Acknowledgments Alexandru Petrescu co-authored with Vidya (one of the co-authors of this I-D) an older document which included some of the mechanisms described herein. Tsirtsis, et al. Expires August 4, 2007 [Page 4] Internet-Draft FA extensions to NEMOv4 Base January 2007 3. Introduction 3.1. Background The base NEMOv4 specification [I-D.ietf-nemo-v4-base] defines extensions to Mobile IPv4 [MIPv4] for mobile networks. NEMOv4 extensions are defined for use only by the mobile node and the home agent so there are no extensions defined for NEMOv4 support by foreign agent. NEMOv4 solution [[I-D.ietf-nemo-v4-base] defines: - When the co-located care-of address model is used, traffic to/ from the mobile network prefixes can be sent over a bidirectional tunnel between the mobile node�s care-of address and the home agent address. - When the care-of address model is used, traffic to/from the mobile network prefixes must be sent over a bidirectional tunnel between the mobile's home address and the home agent address. This results in double tunneling since traffic to the mobile's home address is encapsulated inside the tunnel between the mobile node's care-of address and home agent address. Extensions defined in this document allow the mobile node and/or a foreign agent to indicate to the home agent what address should be used for tunneling traffic to the mobile network prefixes during registration. Thus, this specification removes the need for double encapsulation when a foreign agent is used. Tsirtsis, et al. Expires August 4, 2007 [Page 5] Internet-Draft FA extensions to NEMOv4 Base January 2007 4. Extension Formats The following extension is defined according to this specification. 4.1. NEMOv4 Tunneling Extension A new skippable extension to the Mobile IPv4 header in accordance to the short extension format of MIPv4 [RFC3344] is defined here. The presence of this extension indicates that the sender supports the NEMOv4 and the tunnel selection extensions defined in this specification. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type NEMOv4 Type [I-D.ietf-nemo-v4-base] Length 4 Sub-Type TBA (NEMOv4 Tunneling Extension) Reserved Set to 0 by the sender and ignored by the receiver. Tsirtsis, et al. Expires August 4, 2007 [Page 6] Internet-Draft FA extensions to NEMOv4 Base January 2007 5. Mobile IP registrations 5.1. Registration Requests A mobile node that supports NEMOv4 [I-D.ietf-nemo-v4-base] and this specification MAY include exactly one NEMOv4 tunneling extension when it uses the co-located care-of address mode. When the NEMOv4 tunneling extension is used by the mobile node, it MUST be placed after the registration request header and before the mobile - home authentication extension so, it MUST be included in the computation of any authentication extension. A foreign agent that supports this specification MAY include a NEMOv4 tunneling extension defined in the specification in a registration request when the care-of address mode of operation is used. When the NEMOv4 tunneling extension is used by a foreign agent it MUST be placed after the mobile - home authentication extensions and before the foreign - home authentication extension so it MUST be included in the computation of the foreign - home authentication extension when one exists. 5.2. Registration Reply A foreign agent that supports this specification MAY include a NEMOv4 tunneling extension defined in the specification in a registration reply message When a NEMOv4 tunneling extension is used by a home agent it MUST be placed after the registration reply header and before the mobile - home authentication extension so, it must be included in the calculation of any authentication extension. 5.3. Home Agent Considerations A home agent that supports the extensions in this specification MUST act as in NEMOv4 with the addition to the tunneling mode selection defined below. Tunneling mode selection, for mobile network traffic, depends on the following parameters in a valid registration request: 1) Registration request is received with one or more Mobile Network Extensions [I-D.ietf-nemo-v4-base]. A NEMOv4 tunneling extension is NOT included. Tsirtsis, et al. Expires August 4, 2007 [Page 7] Internet-Draft FA extensions to NEMOv4 Base January 2007 All mobile network traffic MUST be tunneled by the home agent to the registered home address of the mobile. The home agent MUST NOT include a NEMOv4 tunneling extension in the registration reply and it MUST be prepared to accept reverse tunneled packets from the IPv4 home address of the mobile encapsulating packets sent by the mobile node. 2) Registration request is received with one or more Mobile Network Extensions [I-D.ietf-nemo-v4-base]. A NEMOv4 tunneling extension is included. All mobile network traffic SHOULD be tunneled by the home agent to the registered care-of address of the mobile. In that case, the home agent SHOULD include the NEMOv4 Tunneling extension in the registration reply message and it MUST be prepared to accept reverse tunneled packets from the care-of address of the mobile encapsulating packets sent by the mobile network. Alternatively, the home agent MAY ignore the presence of the NEMOv4 Tunneling extension and act as in case (1) above. As defined in NEMOv4, for each mobile network extension included in a valid registration request, a home agent that supports this specification includes a corresponding mobile network acknowledgement extension. 5.4. Foreign Agent Considerations When a foreign agent receives a registration request with NEMOv4 extensions it has the following options: Ignore the [I-D.ietf-nemo-v4-base] extension(s). The registration request is forwarded as is with no NEMOv4 Tunneling extension to the home agent. Attach a NEMOv4 tunneling extension to the registration request sent to the home agent. If the foreign agent sets the R flag included in the mobility agent advertisement MIPv4 [RFC3344] and a mobile client uses the co-located address model, the foreign agent MUST NOT include a NEMOv4 tunneling extension in the registration request messages sent from that mobile client. When a successful Registration Reply is received the foreign agent MUST act as defined by MIPv4 [RFC3344]. In addition to that and according to this specification the foreign agent SHOULD check for a NEMOv4 Tunnel extension. Tsirtsis, et al. Expires August 4, 2007 [Page 8] Internet-Draft FA extensions to NEMOv4 Base January 2007 If the NEMOv4 Tunnel extension is included then the foreign agent MUST establish a bidirectional tunnel. The tunnel endpoints are the care-of address of the foreign agent and the address of the home agent. In addition to setting up a bi-directional tunnel with the home agent, the foreign agent locally establishes forwarding information such that all packets originated by the clients in the mobile network, or originated by the mobile router itself (i.e., packets with source address any address under the registered prefixes for that mobile router) and destined to any correspondent node whose address is topologically correct outside the mobile network are encapsulated through the bi-directional tunnel. Note that registered prefixes are only the prefixes accepted by Mobile Network Acknowledgement Extensions, with Code field set to "0", included in the Registration Reply message. If the NEMOv4 Tunnel extension is not included then the foreign agent SHOULD operate as defined in MIPv4 and NEMOv4. 5.5. Mobile Client Considerations A mobile router that supports the NEMOv4 extensions may use these extensions to register its mobile networks as defined in [I-D.ietf-nemo-v4-base]. The mobile client MAY include exactly one NEMOv4 tunneling extension if it uses the co-located care-of address model, if it wants to specifically request that packets to the mobile network are tunneled to its co-located care-of address. Note that if the mobile client uses the co-located care-of address model but it does not include the NEMOv4 tunneling extension, according to NEMOv4, the home agent MAY tunnel mobile network packets to the mobile client's home address. NEMOv4 also defines the mobile client processing when a registration reply is received. In addition that what is defined in NEMOv4, the following processing MUST be done by the mobile client according to this specification. If NEMOv4 Tunnel extension is not included, the mobile client MUST act as defined by [I-D.ietf-nemo-v4-base]. If NEMOv4 Tunnel extension is included then the mobile client MUST act as follows: If the care-of address mode is used, the mobile client MUST be prepared to send/receive traffic from/to the mobile network on its interface natively, unless reverse tunnel has been Tsirtsis, et al. Expires August 4, 2007 [Page 9] Internet-Draft FA extensions to NEMOv4 Base January 2007 negotiated in which case all traffic MUST be reverse tunneled according to MIPv4 [RFC3344]. If the co-located care-of address mode is used, the mobile client MUST be prepared to send/receive packets from/to the mobile network over the bidirectional tunnel between the home agent address and its co-located care-of address. 5.6. Disparate Address Space Support Mobile IP MIPv4 [RFC3344] assumes that all the entities involved have addresses within the same globally unique space. In many deployment scenarios this is not the case, either because of the use of private address space or because of the use of public address space that is only advertised in not advertised globally. The analysis and suggestions on how to deal with such deployments included in Appendix A of MIPv4 [RFC3344] apply in this specification if the prefixes that a mobile node successfully registers according to NEMOv4 and this specification are treated in the same way MIPv4 [RFC3344] treats the home address of the mobile node. Tsirtsis, et al. Expires August 4, 2007 [Page 10] Internet-Draft FA extensions to NEMOv4 Base January 2007 6. Security Considerations This specification operates in the security constraints and requirements of MIPv4 [RFC3344] and [I-D.ietf-nemo-v4-base]. A foreign agent that supports this specification SHOULD perform ingress filtering on all the packets received from the mobile router prior to reverse tunneling them to the Home Agent. The foreign agent SHOULD drop any packets that do not have a source address belonging to one of the registered prefixes. For traffic coming from the home agent and if the foreign agent has included a NEMOv4 Tunneling extension in the registration request, the foreign agent MUST be prepared to accept encapsulated packets to the home address of the a registered mobile router as well as to any address under any of the registered prefixes for the same mobile router. Tsirtsis, et al. Expires August 4, 2007 [Page 11] Internet-Draft FA extensions to NEMOv4 Base January 2007 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. 7.2. Informative References [I-D.ietf-nemo-v4-base] Leung, K., "IPv4 Network Mobility (NEMO) Basic Support Protocol", draft-ietf-nemo-v4-base-01 (work in progress), June 2006. Tsirtsis, et al. Expires August 4, 2007 [Page 12] Internet-Draft FA extensions to NEMOv4 Base January 2007 Authors' Addresses George Tsirtsis Qualcomm Phone: +908-443-8174 Email: tsirtsis@qualcomm.com Vincent Park Qualcomm Phone: +908-947-7084 Email: vpark@qualcomm.com Vidya Narayana Qualcomm Phone: +858-845-2483 Email: vidyan@qualcomm.com Kent Leung Cisco Phone: +408-526-5030 Email: kleung@cisco.com Tsirtsis, et al. Expires August 4, 2007 [Page 13] Internet-Draft FA extensions to NEMOv4 Base January 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). Tsirtsis, et al. Expires August 4, 2007 [Page 14]