Network Working Group G. Tsirtsis Internet-Draft V. Park Intended status: Standards Track Qualcomm Expires: November 5, 2007 May 4, 2007 GRE-based L2 Tunneling with PMIPv4 draft-tsirtsis-l2gre-pmipv4-00.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 November 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Tsirtsis & Park Expires November 5, 2007 [Page 1] Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007 Abstract This specification introduces mechanisms for creating a GRE-based L2 Tunnel with PMIPv4. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Flag definition for GRE key Extension . . . . . . . . . . . . 6 5. Initial Registration . . . . . . . . . . . . . . . . . . . . . 7 5.1. Sending the Registration Request . . . . . . . . . . . . . 7 5.2. Receiving the Registration Request . . . . . . . . . . . . 7 5.3. Sending the Registration Reply . . . . . . . . . . . . . . 8 5.4. Receiving the Registration Reply . . . . . . . . . . . . . 8 5.5. Registration Tables . . . . . . . . . . . . . . . . . . . 9 5.5.1. Home Agent . . . . . . . . . . . . . . . . . . . . . . 9 5.5.2. Mobility Proxy Agent . . . . . . . . . . . . . . . . . 9 6. Reregistrations . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Registration Request . . . . . . . . . . . . . . . . . . . 10 6.2. Registration Reply . . . . . . . . . . . . . . . . . . . . 10 7. L2 Tunneling and Address Allocation . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Tsirtsis & Park Expires November 5, 2007 [Page 2] Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 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 & Park Expires November 5, 2007 [Page 3] Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007 2. Introduction The Mobile IPv4 (MIPv4) specification [RFC3344] defines optional support for GRE tunneling [RFC2784]. Additionally, there is work in progress on defining extensions that enable signaling of GRE keys [RFC2890] to be used when MIPv4 uses GRE tunneling [draft-yegani-gre-key-extension-02.txt], and also work in progress on defining mobility management based on Proxy Mobile IPv4 (PMIPv4) [draft-leung-mip4-proxy-mode-02.txt]. The primary use case for [draft-yegani-gre-key-extension-02.txt] is the use of GRE keys to support overlapping IPv4 address spaces on the same HA. The mechanisms defined by [draft-yegani-gre-key-extension-02.txt] anticipate the use of unidirectional GRE keys under the control of the sender i.e., the FA (or equivalently the MPA in the case of PMIPv4) indicates (in a Registration Request message) the GRE key to be used for reverse tunneling, and the HA indicates (in the corresponding Registration Reply message) the GRE key to be used for forward tunneling. In this document, the mechanisms defined in [draft-yegani-gre-key-extension-02.txt] are extended to support the use of bidirectional GRE keys under the control of the HA that can be MN specific, realm specific, or otherwise. Also, the mechanisms defined in this specification allow a GRE-based L2 tunnel to be created without necessarily allocating an address to the MN. This allows MNs to use any address configuration mechanism they want directly with the HA including, DHCPv4, DHCPv6, Stateless Address Autoconfiguration etc. Tsirtsis & Park Expires November 5, 2007 [Page 4] Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007 3. Overview In this specification, we define that when the Key Identifier field in a GRE Key extension [draft-yegani-gre-key-extension-02.txt] included in a Registration Request message is set to a predefined known value (i.e., "0"), the MPA requests that the HA assign a bidirectional GRE key for the given registration. The HA allocates a bidirectional GRE key and returns it in the Key Identifier field of a GRE Key extension in the Registration Reply message. Thus, the value of the Key Identifier field returned by the HA is used as the GRE key for both forward and reverse tunneled packets. The mechanisms defined herein, also allow a GRE-based L2 tunnel to be established via PMIPv4. The MN can then run any address allocation procedure, including DHCPv4 and stateless address autoconfiguration for IPv6 etc, directly with the HA on which the L2 tunnel terminates. To enable this capability, a new flag is defined in the GRE Key extension [draft-yegani-gre-key-extension-02.txt], requesting the establishment of an GRE-based L2 tunnel. In that case, the binding created in the HA is between a GRE key and a CoA. This requires the use of unidirectional or bidirectional GRE keys that are unique per MN. Tsirtsis & Park Expires November 5, 2007 [Page 5] Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007 4. Flag definition for GRE key Extension The following extension is based on the GRE Key extension defined in [draft-yegani-gre-key-extension-02.txt]. This specification defines the "A" flag shown below, from within the field previously defined as Reserved. 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 |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type See [draft-yegani-gre-key-extension-02.txt] Length See [draft-yegani-gre-key-extension-02.txt] A Requests GRE-based L2 Tunneling Mode Reserved See [draft-yegani-gre-key-extension-02.txt] Key Identifier See [draft-yegani-gre-key-extension-02.txt] Tsirtsis & Park Expires November 5, 2007 [Page 6] Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007 5. Initial Registration 5.1. Sending the Registration Request According to [draft-yegani-gre-key-extension-02.txt], an FA (or presumably MPA) can send a Registration Request message with a GRE Key extension to request use of GRE keys as part of GRE tunneling. This specification allows the sender of a Registration Request message with a GRE Key extension to further request the use a GRE- based L2 tunnel by setting the "A" flag as follows: "0" Indicates normal GRE Tunneling Mode. "1" Indicates GRE-based L2 Tunneling Mode. In this case the Key Identifier(s) corresponding to the registration MUST be unique per MN. In accordance with this specification, the MPA can also request the use of a bidirectional key according to value of the Key Identifier field of the GRE Key extension in the Registration Request message: When the Key Identifier field is set to "0" the sender requests a bidirectional GRE key to be defined by the HA. When the Key Identifier field is set to any other value, it indicates the value of the GRE key to be used for tunneling from the MPA to the HA. 5.2. Receiving the Registration Request The following defines GRE Key extension processing to be performed by the HA in addition to that described in [draft-yegani-gre-key-extension-02.txt]. If in a Registration Request message with a GRE Key extension, the Key Identifier field is set to "0" and the A flag is set to "0", then the HA MUST allocate a bidirectional GRE key, which need not be unique per MN. The allocated bidirectional GRE key MAY be realm specific or otherwise based on HA policy. If in a Registration Request message with a GRE Key extension, the Key Identifier is set to a value other than "0" and A flag is set to "0", then the HA SHOULD accept the value of the Key Identifier field as the GRE key to be used for reverse tunneling from the MPA to the HA and allocate a unidirectional GRE key, which need not be unique per MN, to be used for forward tunneling. The allocated unidirectional GRE key MAY be realm specific or otherwise based on HA policy. Tsirtsis & Park Expires November 5, 2007 [Page 7] Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007 If in a Registration Request message with a GRE Key extension, the Key Identifier is set to "0" and the A flag is set to "1", then the HA MUST allocate a bidirectional GRE key, which MUST be unique per MN. In this case the HA, creates an L2 tunnel for the MN and maintains a binding between the bidirectional GRE key and the CoA of the MN. If in a Registration Request message with a GRE Key extension, the Key Identifier is set to a value other than "0" and the A flag is set to "1", then the HA SHOULD accept the value of the Key Identifier field as the GRE key to be used for reverse tunneling from the MPA to the HA and allocate a unidirectional GRE key, which MUST be unique per MN, to be used for forward tunneling. In this case the HA, creates an L2 tunnel for the MN and maintains a binding between the GRE keys for each direction and the CoA of the MN. 5.3. Sending the Registration Reply Provided a Registration Request message with a GRE Key extension is accepted, the HA MUST include a GRE Key extension in the corresponding Registration Reply message. In all cases, the Key Identifier field of the GRE Key extension included in the Registration Reply message is set to the value of the GRE key allocated by the HA in response to the corresponding Registration Request message. The A flag of the GRE Key extension included in the Registration Reply message is set to the same value as the A flag of the corresponding Registration Request message. If the GRE key extension is not accepted by the HA, the Registration Request SHOULD be rejected with an appropriate rejection code e.g., Administratively Prohibited, as per [RFC3344]. 5.4. Receiving the Registration Reply Provided a Registration Request message with a GRE Key extension is accepted, the Registration Reply message will also include a GRE key extension. If the GRE key extension in the Registration Request message included a Key Identifier value of "0" then, the receiver of this message MUST accept the value of the Key Identifier field in the GRE key extension in the Registration Reply message as the bidirectional GRE key to be used for this MN. If the GRE key extension in the Registration Request message included a Key Identifier value other than "0" then, the receiver of this message MUST accept the value of the Key Identifier field in the GRE key extension in the Registration Reply message as the GRE key to be Tsirtsis & Park Expires November 5, 2007 [Page 8] Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007 used for this MN in the forward direction. 5.5. Registration Tables 5.5.1. Home Agent In addition to what is defined in [RFC3344], Section 3.8.1., the following information needs to be retained by the HA: - the mobile node's GRE key in the reverse direction - the mobile node's GRE key in the forward direction Also note that unlike what is indicated in the same section of [RFC3344], in some cases the HoA may not be known. 5.5.2. Mobility Proxy Agent While not explicitly outlined in [draft-leung-mip4-proxy-mode-02.txt], an MPA must maintain information associated with registrations. In addition to what is required in support of [draft-leung-mip4-proxy-mode-02.txt], the following information needs to be retained by the MPA: - the mobile node's GRE key in the reverse direction - the mobile node's GRE key in the forward direction Tsirtsis & Park Expires November 5, 2007 [Page 9] Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007 6. Reregistrations 6.1. Registration Request The MPA SHOULD include the GRE Key extension in all reregistrations. If the GRE key, set-up by an earlier MPA, is known, it SHOULD be included in the Key Identifier field of the extension. If the GRE key is not known or a different one needs to be negotiated, the reregistration message has to follow the same rules with the initial registration message defined in Section 5.1. 6.2. Registration Reply Assuming the subsequent Registration Request message includes a GRE key extension that reflects the negotiated GRE key, the HA simply copies the extension to the Registration Reply. If the GRE key extension included in the subsequent Registration Request does not reflect the agreed key, the request will have the same effect as the initial request and the HA MUST treat it as in Section 5.2 and the reply MUST be formed as defined in Section 5.3. Tsirtsis & Park Expires November 5, 2007 [Page 10] Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007 7. L2 Tunneling and Address Allocation When a GRE-based L2 tunnel is requested (the A flag in the GRE key extension is set to "1", see Section 5.1), the binding communicated by the Registration Request message is between the GRE key(s) and the CoA rather than an HoA and the CoA. Unlike [RFC3344], in this case, if the HoA field of the Registration Request message is set to "0", the HA is NOT REQUIRED to allocate an IP Address in the Registration Reply message. Instead the HA MAY also set the HoA field in the Registration Reply message to "0". Also, when L2 Tunneling is used as defined in this specification, the MN MAY use DHCPv4, DHCPv6, IPv6 Address Autoconfiguration or any other mechanism directly with the HA, to configure its addresses. After addresses have been allocated, the MN MAY register them with the HA using appropriate MIPv4 mechanisms. Tsirtsis & Park Expires November 5, 2007 [Page 11] Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007 8. Security Considerations This specification operates in the security constraints and requirements of the underlying protocols. Tsirtsis & Park Expires November 5, 2007 [Page 12] Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. Tsirtsis & Park Expires November 5, 2007 [Page 13] Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007 Authors' Addresses George Tsirtsis Qualcomm Phone: +908-443-8174 Email: tsirtsis@qualcomm.com Vincent Park Qualcomm Phone: +908-443-8141 Email: vpark@qualcomm.com Tsirtsis & Park Expires November 5, 2007 [Page 14] Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 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 & Park Expires November 5, 2007 [Page 15]