idnits 2.17.1 draft-yegani-gre-key-extension-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 28, 2009) is 5386 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 245 == Unused Reference: 'RFC2890' is defined on line 281, 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 (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Yegani 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track G. Dommety 5 Expires: January 29, 2010 Cisco Systems 6 A. Lior 7 Bridgewater Systems 8 K. Chowdhury 9 J. Navali 10 Starent Networks 11 July 28, 2009 13 GRE Key Extension for Mobile IPv4 14 draft-yegani-gre-key-extension-04.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may contain material 20 from IETF Documents or IETF Contributions published or made publicly 21 available before November 10, 2008. The person(s) controlling the 22 copyright in some of this material may not have granted the IETF 23 Trust the right to allow modifications of such material outside the 24 IETF Standards Process. Without obtaining an adequate license from 25 the person(s) controlling the copyright in such materials, this 26 document may not be modified outside the IETF Standards Process, and 27 derivative works of it may not be created outside the IETF Standards 28 Process, except to format it for publication as an RFC or to 29 translate it into languages other than English. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on January 29, 2010. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents in effect on the date of 56 publication of this document (http://trustee.ietf.org/license-info). 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. 60 Abstract 62 The GRE specification contains a Key field, which MAY contain a value 63 that is used to identify a particular GRE data stream. This 64 specification defines a new Mobile IP extension that is used to 65 exchange the value to be used in the GRE Key field. This extension 66 further allows the Mobility Agents to setup the necessary protocol 67 interfaces prior to receiving the mobile's traffic. The new 68 extension option allows a foreign agent to request GRE tunneling 69 without disturbing the Home Agent behavior specified for Mobile Ipv4. 70 GRE tunneling provides an advantage that allows operator's private 71 home networks to be overlaid and allows the HA to provide overlapping 72 home addresses to different subscribers. When the tuple < Care of 73 Address, Home Address and Home Agent Address > is the same across 74 multiple subscriber sessions, GRE tunneling will provide a means for 75 the FA and HA to identify data streams for the individual sessions 76 based on the GRE key. In the absence of this key identifier, the 77 data streams cannot be distinguished from each other, a significant 78 drawback when using IP-in-IP tunneling. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 3. GRE-Key Extension . . . . . . . . . . . . . . . . . . . . . . . 4 85 4. Operation and Use of the GRE-Key Extension . . . . . . . . . . 4 86 4.1. Foreign Agent Requirements for GRE Tunneling Support . . . 4 87 4.2. Home Agent Requirements for GRE Tunneling Support . . . . . 5 88 4.3. Mobile Node Requirements for GRE Tunneling Support . . . . 6 89 5. GRE Key Extension and Tunneling Procedures . . . . . . . . . . 6 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 93 9. Normative references . . . . . . . . . . . . . . . . . . . . . 8 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 96 1. Introduction 98 This document specifies a new extension for use by Foreign Agents 99 operating Mobile IP for IPv4. The new extension option allows a 100 foreign agent to request GRE tunneling without disturbing the Home 101 Agent behavior specified for Mobile IPv4 [RFC3344]. This extension 102 contains the GRE key and other necessary information required for 103 establishing a GRE tunnel between the FA and the HA. 105 GRE tunneling provides an advantage that allows operator's private 106 home networks to be overlaid and it allows the HA to provide 107 overlapping home addresses to different subscribers. When the tuple 108 < Care of Address, Home Address and Home Agent Address > is the same 109 across multiple subscriber sessions, GRE tunneling will provide a 110 means for the FA and the HA to identify data streams for the 111 individual sessions based on the GRE key. In the absence of this key 112 identifier, the data streams cannot be distinguished from each other, 113 a significant drawback when using IP-in-IP tunneling. 115 2. Terminology 117 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. Other 120 terminology is used as already defined in [RFC3344]. 122 3. GRE-Key Extension 124 The format of the GRE-Key Extension conforms to the Extension format 125 specified for Mobile IPv4 [RFC3344]. This extension option is used 126 by the Foreign Agent to supply GRE key and other necessary 127 information to the Home Agent to establish a GRE tunnel between the 128 FA and the HA. 130 4. Operation and Use of the GRE-Key Extension 132 4.1. Foreign Agent Requirements for GRE Tunneling Support 134 The FA MUST support IP-in-IP tunneling of datagrams for Mobile IPv4 135 [RFC3344]. The FA may support GRE tunneling that can be used, for 136 example, to allow for overlapping private home IP addresses 137 [X.S0011-D]. If the FA is capable of supporting GRE encapsulation, 138 it should set the 'G' bit in the Flags field in the Agent 139 Advertisement message sent to the MN during the Mobile IP session 140 establishment. 142 If the MN does not set the 'G' bit, the FA MAY fall back to using IP- 143 in-IP encapsulation for the session per [RFC3344]. 145 If the MN does not set the 'G' bit, and the local policy allows the 146 FA to override the 'G' bit setting received from the MS, the FA MUST 147 include the GRE-Key Extension as defined in this memo in the 148 Registration Request message to request GRE encapsulation for the 149 session. 151 If the FA does not support GRE encapsulation, the FA MUST reset the 152 'G' bit in the Agent Advertisement message. In this case, if the MN 153 sets the 'G' bit in the Registration Request message, the FA returns 154 a Registration Reply message to the MN with code 'Requested 155 Encapsulation Unavailable' (0x48) per [RFC3344]. 157 If the FA allows GRE encapsulation, and either the MN requested GRE 158 encapsulation or local policy dictates using GRE encapsulation for 159 the session, the FA MUST include the GRE Key in the GRE Key Extension 160 in all Mobile IP Registration Requests (including initial, renewal 161 and de-registration requests) before forwarding the request to the 162 HA. The FA may include a GRE key of value zero in the GRE Key 163 Extension to signal that the HA assign GRE keys in both directions. 164 The GRE key assignment in the FA and the HA is outside the scope of 165 this memo. 167 The GRE Key Extension SHALL follow the format defined in [RFC3344]. 168 This extension SHALL be added after the MN-HA and MN-FA Challenge and 169 MN-AAA extensions (if any) and before the FA-HA Auth extension (if 170 any). 172 4.2. Home Agent Requirements for GRE Tunneling Support 174 The HA MUST follow the procedures specified in RFC 3344 in processing 175 this extension in Registration Request messages. If the HA receives 176 the GRE Key Extension in a Registration Request and does not 177 recognize GRE Key Extension, it MUST send an RRP with code 'Unknown 178 Extension (0xY1)' per [RFC3344]. 180 If the HA receives the GRE Key Extension in a Registration Request 181 and recognizes the GRE Key Extension but is not configured to support 182 GRE encapsulation, it MUST send an RRP with code 'Requested 183 Encapsulati on Unavailable (0xYY)'. 185 If the HA receives a Registration Request with the 'G' bit set but 186 without the GRE Key Extension, it SHALL send an RRP with code 'Poorly 187 Formed Request (0xY2)'. 189 If the HA receives a Registration Request with a GRE Key Extension 190 but without the 'G' bit set, the HA SHOULD treat this as if 'G' bit 191 is set in the Registration Request i.e., the presence of GRE Key 192 Extension indicates a request for GRE encapsulation. 194 If the HA receives the GRE Key Extension in a Registration Request 195 and recognizes the GRE Key Extension as well as supports GRE 196 encapsulation, the following procedures should apply: 198 The HA SHOULD accept the RRQ and send a RRP with code 'Accepted (0)'. 199 The HA MUST assign a GRE key and include the GRE Key Extension in the 200 RRP before sending it to the FA. The HA MUST include the GRE Key 201 Extension in all RRPs in response to any RRQ that included GRE Key 202 Extension, when a GRE key is available for the registration. 204 If the HA receives the GRE Key Extension in the initial Registration 205 Request and recognizes the GRE Key Extension carrying a GRE key value 206 of zero, it SHOULD accept the RRQ and send a RRP with code 'Accepted 207 (0)'. The HA MUST assign GRE keys for both directions and include 208 these keys in the GRE Key Extension in the RRP before sending it to 209 the FA. The HA MUST include the GRE Key Extension in the RRP in 210 response to the initial RRQ that included GRE Key Extension, when a 211 GRE key is available for the registration. 213 4.3. Mobile Node Requirements for GRE Tunneling Support 215 If the MN is capable of supporting GRE encapsulation, it SHOULD set 216 the 'G' bit in the Flags field in the Registration Request per 217 [RFC3344]. 219 5. GRE Key Extension and Tunneling Procedures 221 GRE tunneling support for Mobile IP will permit asymmetric GRE keying 222 i.e., the FA assigns a GRE key for use in encapsulated traffic and 223 the HA can assign its own GRE key. Once the GRE keys have been 224 exchanged, the FA uses the HA-assigned key in the encapsulating GRE 225 header for reverse tunneling and the HA uses the FA-assigned key in 226 the encapsulating GRE header. 228 The format of the GRE Key Extension is as shown below. 230 The GRE Key extension MAY be included in Registration Requests 231 [RFC3344], whose 'G' bit is enabled. The GRE Key extension is used 232 to inform the recipient of the Mobile IP request of the value to be 233 used in GRE's Key field. 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type | Length | Reserved | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Key Identifier | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Type 245 TBD (non-skippable) [2] 247 Length 249 6 251 Reserved 253 This field MUST be set to zero (0). 255 Key Identifier 257 This is a four octet value assigned in the Registration and 258 inserted in every GRE frame. 260 Figure 1: GRE Key Extension 262 6. IANA Considerations 264 The GRE Key extension defined in this memo is as defined in 265 [RFC3344]. IANA should assign a value for this Extension. 267 7. Security Considerations 269 This specification does not introduce any new security 270 considerations, beyond those described in [RFC3344] 272 8. Acknowledgements 274 Thanks to ... 276 9. Normative references 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, March 1997. 281 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 282 RFC 2890, September 2000. 284 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 285 August 2002. 287 Authors' Addresses 289 Parviz Yegani 290 Juniper Netowrks 291 1194 North Mathilda Ave. 292 Sunnyvale, California 94089 293 U.S.A 295 Phone: +1 408-759-1973 296 Email: pyegani@juniper.net 298 Gopal Dommety 299 Cisco Systems Inc. 300 170 West Tasman Dr. 301 San Jose, California 95134 302 U.S.A 304 Phone: +1 408 525 1404 305 Email: gdommety@cisco.com 307 Avi Lior 308 Bridgewater Systems Corporation 309 303 Terry Fox Drive 310 Ottawa, Ontario K2K 3J1 311 Canada 313 Phone: +1 613-591-6655 314 Email: avi@bridgewatersystems.com 315 Kuntal Chowdhury 316 Starent Networks 317 30 International Place 318 Tewksbury, MA 01876 319 USA 321 Phone: +1 214 550 1416 322 Email: kchowdhury@starentnetworks.com 324 Jay Navali 325 Starent Networks 326 30 International Place 327 Tewksbury, MA 01876 328 USA 330 Phone: +1 978 851 1141 331 Email: jnavali@starentnetworks.com