Network Working Group G. Tsirtsis Internet-Draft V. Park Intended status: Standards Track V. Narayanan Expires: August 18, 2008 Qualcomm K. Leung Cisco February 15, 2008 FA extensions to NEMOv4 Base draft-ietf-mip4-nemov4-fa-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 August 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Tsirtsis, et al. Expires August 18, 2008 [Page 1] Internet-Draft FA extensions to NEMOv4 Base February 2008 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Tsirtsis, et al. Expires August 18, 2008 [Page 2] Internet-Draft FA extensions to NEMOv4 Base February 2008 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 18, 2008 [Page 3] Internet-Draft FA extensions to NEMOv4 Base February 2008 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 18, 2008 [Page 4] Internet-Draft FA extensions to NEMOv4 Base February 2008 3. Introduction 3.1. Background The base NEMOv4 specification [I-D.ietf-mip4-nemo-v4-base] defines extensions to MIPv4 [RFC3344] 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-mip4-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 18, 2008 [Page 5] Internet-Draft FA extensions to NEMOv4 Base February 2008 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 TBA (Mobile Network Extension) (skippable type range to be assigned by IANA) [I-D.ietf-mip4-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 18, 2008 [Page 6] Internet-Draft FA extensions to NEMOv4 Base February 2008 5. Mobile IP registrations 5.1. Registration Requests A mobile node that supports [I-D.ietf-mip4-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 [I-D.ietf-mip4-nemo-v4-base] 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-mip4-nemo-v4-base]. A NEMOv4 tunneling extension is NOT included. Tsirtsis, et al. Expires August 18, 2008 [Page 7] Internet-Draft FA extensions to NEMOv4 Base February 2008 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-mip4-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 [I-D.ietf-mip4-nemo-v4-base], 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 [I-D.ietf-mip4-nemo-v4-base] extensions it has the following options: Ignore the [I-D.ietf-mip4-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 18, 2008 [Page 8] Internet-Draft FA extensions to NEMOv4 Base February 2008 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 [RFC3344] and [I-D.ietf-mip4-nemo-v4-base]. 5.5. Mobile Client Considerations A mobile router that supports the [I-D.ietf-mip4-nemo-v4-base] extensions may use these extensions to register its mobile networks as defined in [I-D.ietf-mip4-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 [I-D.ietf-mip4-nemo-v4-base], the home agent MAY tunnel mobile network packets to the mobile client's home address. [I-D.ietf-mip4-nemo-v4-base] also defines the mobile client processing when a registration reply is received. In addition that what is defined in [I-D.ietf-mip4-nemo-v4-base], 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-mip4-nemo-v4-base] If NEMOv4 Tunnel extension is included then the mobile client MUST act as follows: Tsirtsis, et al. Expires August 18, 2008 [Page 9] Internet-Draft FA extensions to NEMOv4 Base February 2008 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 negotiated in which case all traffic MUST be reverse tunneled according to REVTUN [RFC3024]. 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 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 REVTUN [RFC3024]] apply in this specification if the prefixes that a mobile node successfully registers according to [I-D.ietf-mip4-nemo-v4-base] and this specification are treated in the same way REVTUN [RFC3024] treats the home address of the mobile node. Tsirtsis, et al. Expires August 18, 2008 [Page 10] Internet-Draft FA extensions to NEMOv4 Base February 2008 6. Security Considerations This specification operates in the security constraints and requirements of MIPv4 [RFC3344] and [I-D.ietf-mip4-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 a registered mobile router as well as to any address belonging to any of the registered prefixes for the same mobile router. Tsirtsis, et al. Expires August 18, 2008 [Page 11] Internet-Draft FA extensions to NEMOv4 Base February 2008 7. IANA Considerations This document has the following action for IANA. A new value needs to be allocated for the NEMOv4 Tunneling Extension defined in this document, from the number space of the Sub-Type for Mobile Network Extensions defined in [I-D.ietf-mip4-nemo-v4-base]. Tsirtsis, et al. Expires August 18, 2008 [Page 12] Internet-Draft FA extensions to NEMOv4 Base February 2008 8. Normative References [I-D.ietf-mip4-nemo-v4-base] Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, "Network Mobility (NEMO) Extensions for Mobile IPv4", draft-ietf-mip4-nemo-v4-base-08 (work in progress), January 2008. [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. Tsirtsis, et al. Expires August 18, 2008 [Page 13] Internet-Draft FA extensions to NEMOv4 Base February 2008 Authors' Addresses George Tsirtsis Qualcomm Phone: +908-443-8174 Email: tsirtsis@googlemail.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 18, 2008 [Page 14] Internet-Draft FA extensions to NEMOv4 Base February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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 18, 2008 [Page 15]