idnits 2.17.00 (12 Aug 2021) /tmp/idnits23765/draft-yegani-gre-key-extension-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 355. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2007) is 5454 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2' on line 230 == Unused Reference: 'RFC2890' is defined on line 266, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Yegani 3 Internet-Draft G. Dommety 4 Intended status: Standards Track Cisco Systems 5 Expires: December 3, 2007 A. Lior 6 Bridgewater Systems 7 K. Chowdhury 8 J. Navali 9 Starent Networks 10 June 2007 12 GRE Key Extension for Mobile IPv4 13 draft-yegani-gre-key-extension-03 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 3, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 The GRE specification contains a Key field, which MAY contain a value 47 that is used to identify a particular GRE data stream. This 48 specification defines a new Mobile IP extension that is used to 49 exchange the value to be used in the GRE Key field. This extension 50 further allows the Mobility Agents to setup the necessary protocol 51 interfaces prior to receiving the mobile's traffic. The new 52 extension option allows a foreign agent to request GRE tunneling 53 without disturbing the Home Agent behavior specified for Mobile Ipv4. 54 GRE tunneling provides an advantage that allows operator's private 55 home networks to be overlaid and allows the HA to provide overlapping 56 home addresses to different subscribers. When the tuple < Care of 57 Address, Home Address and Home Agent Address > is the same across 58 multiple subscriber sessions, GRE tunneling will provide a means for 59 the FA and HA to identify data streams for the individual sessions 60 based on the GRE key. In the absence of this key identifier, the 61 data streams cannot be distinguished from each other, a significant 62 drawback when using IP-in-IP tunneling. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. GRE-Key Extension . . . . . . . . . . . . . . . . . . . . . . . 3 69 4. Operation and Use of the GRE-Key Extension . . . . . . . . . . 3 70 4.1. Foreign Agent Requirements for GRE Tunneling Support . . . 3 71 4.2. Home Agent Requirements for GRE Tunneling Support . . . . . 4 72 4.3. Mobile Node Requirements for GRE Tunneling Support . . . . 5 73 5. GRE Key Extension and Tunneling Procedures . . . . . . . . . . 5 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 77 9. Normative references . . . . . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 79 Intellectual Property and Copyright Statements . . . . . . . . . . 9 81 1. Introduction 83 This document specifies a new extension for use by Foreign Agents 84 operating Mobile IP for IPv4. The new extension option allows a 85 foreign agent to request GRE tunneling without disturbing the Home 86 Agent behavior specified for Mobile IPv4 [RFC3344]. This extension 87 contains the GRE key and other necessary information required for 88 establishing a GRE tunnel between the FA and the HA. 90 GRE tunneling provides an advantage that allows operator's private 91 home networks to be overlaid and it allows the HA to provide 92 overlapping home addresses to different subscribers. When the tuple 93 < Care of Address, Home Address and Home Agent Address > is the same 94 across multiple subscriber sessions, GRE tunneling will provide a 95 means for the FA and the HA to identify data streams for the 96 individual sessions based on the GRE key. In the absence of this key 97 identifier, the data streams cannot be distinguished from each other, 98 a significant drawback when using IP-in-IP tunneling. 100 2. Terminology 102 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. Other 105 terminology is used as already defined in [RFC3344]. 107 3. GRE-Key Extension 109 The format of the GRE-Key Extension conforms to the Extension format 110 specified for Mobile IPv4 [RFC3344]. This extension option is used 111 by the Foreign Agent to supply GRE key and other necessary 112 information to the Home Agent to establish a GRE tunnel between the 113 FA and the HA. 115 4. Operation and Use of the GRE-Key Extension 117 4.1. Foreign Agent Requirements for GRE Tunneling Support 119 The FA MUST support IP-in-IP tunneling of datagrams for Mobile IPv4 120 [RFC3344]. The FA may support GRE tunneling that can be used, for 121 example, to allow for overlapping private home IP addresses 122 [X.S0011-D]. If the FA is capable of supporting GRE encapsulation, 123 it should set the 'G' bit in the Flags field in the Agent 124 Advertisement message sent to the MN during the Mobile IP session 125 establishment. 127 If the MN does not set the 'G' bit, the FA MAY fall back to using IP- 128 in-IP encapsulation for the session per [RFC3344]. 130 If the MN does not set the 'G' bit, and the local policy allows the 131 FA to override the 'G' bit setting received from the MS, the FA MUST 132 include the GRE-Key Extension as defined in this memo in the 133 Registration Request message to request GRE encapsulation for the 134 session. 136 If the FA does not support GRE encapsulation, the FA MUST reset the 137 'G' bit in the Agent Advertisement message. In this case, if the MN 138 sets the 'G' bit in the Registration Request message, the FA returns 139 a Registration Reply message to the MN with code 'Requested 140 Encapsulation Unavailable' (0x48) per [RFC3344]. 142 If the FA allows GRE encapsulation, and either the MN requested GRE 143 encapsulation or local policy dictates using GRE encapsulation for 144 the session, the FA MUST include the GRE Key in the GRE Key Extension 145 in all Mobile IP Registration Requests (including initial, renewal 146 and de-registration requests) before forwarding the request to the 147 HA. The FA may include a GRE key of value zero in the GRE Key 148 Extension to signal that the HA assign GRE keys in both directions. 149 The GRE key assignment in the FA and the HA is outside the scope of 150 this memo. 152 The GRE Key Extension SHALL follow the format defined in [RFC3344]. 153 This extension SHALL be added after the MN-HA and MN-FA Challenge and 154 MN-AAA extensions (if any) and before the FA-HA Auth extension (if 155 any). 157 4.2. Home Agent Requirements for GRE Tunneling Support 159 The HA MUST follow the procedures specified in RFC 3344 in processing 160 this extension in Registration Request messages. If the HA receives 161 the GRE Key Extension in a Registration Request and does not 162 recognize GRE Key Extension, it MUST send an RRP with code 'Unknown 163 Extension (0xY1)' per [RFC3344]. 165 If the HA receives the GRE Key Extension in a Registration Request 166 and recognizes the GRE Key Extension but is not configured to support 167 GRE encapsulation, it MUST send an RRP with code 'Requested 168 Encapsulati on Unavailable (0xYY)'. 170 If the HA receives a Registration Request with the 'G' bit set but 171 without the GRE Key Extension, it SHALL send an RRP with code 'Poorly 172 Formed Request (0xY2)'. 174 If the HA receives a Registration Request with a GRE Key Extension 175 but without the 'G' bit set, the HA SHOULD treat this as if 'G' bit 176 is set in the Registration Request i.e., the presence of GRE Key 177 Extension indicates a request for GRE encapsulation. 179 If the HA receives the GRE Key Extension in a Registration Request 180 and recognizes the GRE Key Extension as well as supports GRE 181 encapsulation, the following procedures should apply: 183 The HA SHOULD accept the RRQ and send a RRP with code 'Accepted (0)'. 184 The HA MUST assign a GRE key and include the GRE Key Extension in the 185 RRP before sending it to the FA. The HA MUST include the GRE Key 186 Extension in all RRPs in response to any RRQ that included GRE Key 187 Extension, when a GRE key is available for the registration. 189 If the HA receives the GRE Key Extension in the initial Registration 190 Request and recognizes the GRE Key Extension carrying a GRE key value 191 of zero, it SHOULD accept the RRQ and send a RRP with code 'Accepted 192 (0)'. The HA MUST assign GRE keys for both directions and include 193 these keys in the GRE Key Extension in the RRP before sending it to 194 the FA. The HA MUST include the GRE Key Extension in the RRP in 195 response to the initial RRQ that included GRE Key Extension, when a 196 GRE key is available for the registration. 198 4.3. Mobile Node Requirements for GRE Tunneling Support 200 If the MN is capable of supporting GRE encapsulation, it SHOULD set 201 the 'G' bit in the Flags field in the Registration Request per 202 [RFC3344]. 204 5. GRE Key Extension and Tunneling Procedures 206 GRE tunneling support for Mobile IP will permit asymmetric GRE keying 207 i.e., the FA assigns a GRE key for use in encapsulated traffic and 208 the HA can assign its own GRE key. Once the GRE keys have been 209 exchanged, the FA uses the HA-assigned key in the encapsulating GRE 210 header for reverse tunneling and the HA uses the FA-assigned key in 211 the encapsulating GRE header. 213 The format of the GRE Key Extension is as shown below. 215 The GRE Key extension MAY be included in Registration Requests 216 [RFC3344], whose 'G' bit is enabled. The GRE Key extension is used 217 to inform the recipient of the Mobile IP request of the value to be 218 used in GRE's Key field. 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Type | Length | Reserved | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Key Identifier | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Type 230 TBD (non-skippable) [2] 232 Length 234 6 236 Reserved 238 This field MUST be set to zero (0). 240 Key Identifier 242 This is a four octet value assigned in the Registration and 243 inserted in every GRE frame. 245 Figure 1: GRE Key Extension 247 6. IANA Considerations 249 The GRE Key extension defined in this memo is as defined in 250 [RFC3344]. IANA should assign a value for this Extension. 252 7. Security Considerations 254 This specification does not introduce any new security 255 considerations, beyond those described in [RFC3344] 257 8. Acknowledgements 259 Thanks to ... 261 9. Normative references 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, March 1997. 266 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 267 RFC 2890, September 2000. 269 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 270 August 2002. 272 Authors' Addresses 274 Parviz Yegani 275 Cisco Systems Inc. 276 California 277 U.S.A 279 Phone: +1 408-83-5729 280 Email: pyegani@cisco.com 282 Gopal Dommety 283 Cisco Systems Inc. 284 170 West Tasman Dr. 285 San Jose, California 95134 286 U.S.A 288 Phone: +1 408 525 1404 289 Email: gdommety@cisco.com 291 Avi Lior 292 Bridgewater Systems Corporation 293 303 Terry Fox Drive 294 Ottawa, Ontario K2K 3J1 295 Canada 297 Phone: +1 613-591-6655 298 Email: avi@bridgewatersystems.com 299 Kuntal Chowdhury 300 Starent Networks 301 30 International Place 302 Tewksbury, MA 01876 303 USA 305 Phone: +1 214 550 1416 306 Email: kchowdhury@starentnetworks.com 308 Jay Navali 309 Starent Networks 310 30 International Place 311 Tewksbury, MA 01876 312 USA 314 Phone: +1 978 851 1141 315 Email: jnavali@starentnetworks.com 317 Full Copyright Statement 319 Copyright (C) The IETF Trust (2007). 321 This document is subject to the rights, licenses and restrictions 322 contained in BCP 78, and except as set forth therein, the authors 323 retain all their rights. 325 This document and the information contained herein are provided on an 326 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 327 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 328 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 329 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 330 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 331 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 333 Intellectual Property 335 The IETF takes no position regarding the validity or scope of any 336 Intellectual Property Rights or other rights that might be claimed to 337 pertain to the implementation or use of the technology described in 338 this document or the extent to which any license under such rights 339 might or might not be available; nor does it represent that it has 340 made any independent effort to identify any such rights. Information 341 on the procedures with respect to rights in RFC documents can be 342 found in BCP 78 and BCP 79. 344 Copies of IPR disclosures made to the IETF Secretariat and any 345 assurances of licenses to be made available, or the result of an 346 attempt made to obtain a general license or permission for the use of 347 such proprietary rights by implementers or users of this 348 specification can be obtained from the IETF on-line IPR repository at 349 http://www.ietf.org/ipr. 351 The IETF invites any interested party to bring to its attention any 352 copyrights, patents or patent applications, or other proprietary 353 rights that may cover technology that may be required to implement 354 this standard. Please address the information to the IETF at 355 ietf-ipr@ietf.org. 357 Acknowledgment 359 Funding for the RFC Editor function is provided by the IETF 360 Administrative Support Activity (IASA).