idnits 2.17.1 draft-ietf-mip4-gre-key-extension-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 (June 1, 2010) is 5075 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 241 == Unused Reference: 'RFC2890' is defined on line 279, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 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 K. Leung 5 Expires: December 3, 2010 Cisco Systems 6 A. Lior 7 Bridgewater Systems 8 K. Chowdhury 9 J. Navali 10 Cisco Systems 11 June 1, 2010 13 GRE Key Extension for Mobile IPv4 14 draft-ietf-mip4-gre-key-extension-00.txt 16 Abstract 18 The GRE specification contains a Key field, which MAY contain a value 19 that is used to identify a particular GRE data stream. This 20 specification defines a new Mobile IP extension that is used to 21 exchange the value to be used in the GRE Key field. This extension 22 further allows the Mobility Agents to setup the necessary protocol 23 interfaces prior to receiving the mobile's traffic. The new 24 extension option allows a foreign agent to request GRE tunneling 25 without disturbing the Home Agent behavior specified for Mobile Ipv4. 26 GRE tunneling provides an advantage that allows operator's private 27 home networks to be overlaid and allows the HA to provide overlapping 28 home addresses to different subscribers. When the tuple < Care of 29 Address, Home Address and Home Agent Address > is the same across 30 multiple subscriber sessions, GRE tunneling will provide a means for 31 the FA and HA to identify data streams for the individual sessions 32 based on the GRE key. In the absence of this key identifier, the 33 data streams cannot be distinguished from each other, a significant 34 drawback when using IP-in-IP tunneling. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on December 3, 2010. 53 Copyright Notice 55 Copyright (c) 2010 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 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 a GRE Key Extension 186 but without the 'G' bit set, the HA SHOULD treat this as if 'G' bit 187 is set in the Registration Request i.e., the presence of GRE Key 188 Extension indicates a request for GRE encapsulation. 190 If the HA receives the GRE Key Extension in a Registration Request 191 and recognizes the GRE Key Extension as well as supports GRE 192 encapsulation, the following procedures should apply: 194 The HA SHOULD accept the RRQ and send a RRP with code 'Accepted (0)'. 195 The HA MUST assign a GRE key and include the GRE Key Extension in the 196 RRP before sending it to the FA. The HA MUST include the GRE Key 197 Extension in all RRPs in response to any RRQ that included GRE Key 198 Extension, when a GRE key is available for the registration. 200 If the HA receives the GRE Key Extension in the initial Registration 201 Request and recognizes the GRE Key Extension carrying a GRE key value 202 of zero, it SHOULD accept the RRQ and send a RRP with code 'Accepted 203 (0)'. The HA MUST assign GRE keys for both directions and include 204 these keys in the GRE Key Extension in the RRP before sending it to 205 the FA. The HA MUST include the GRE Key Extension in the RRP in 206 response to the initial RRQ that included GRE Key Extension, when a 207 GRE key is available for the registration. 209 4.3. Mobile Node Requirements for GRE Tunneling Support 211 If the MN is capable of supporting GRE encapsulation, it SHOULD set 212 the 'G' bit in the Flags field in the Registration Request per 213 [RFC3344]. 215 5. GRE Key Extension and Tunneling Procedures 217 GRE tunneling support for Mobile IP will permit asymmetric GRE keying 218 i.e., the FA assigns a GRE key for use in encapsulated traffic and 219 the HA can assign its own GRE key. Once the GRE keys have been 220 exchanged, the FA uses the HA-assigned key in the encapsulating GRE 221 header for reverse tunneling and the HA uses the FA-assigned key in 222 the encapsulating GRE header. 224 The format of the GRE Key Extension is as shown below. 226 The GRE Key extension MAY be included in Registration Requests 227 [RFC3344], whose 'G' bit is enabled. The GRE Key extension is used 228 to inform the recipient of the Mobile IP request of the value to be 229 used in GRE's Key field. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Type | Length | Reserved | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Key Identifier | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Type 241 TBD (non-skippable) [2] 243 Length 245 6 247 Reserved 249 This field MUST be set to zero (0). 251 Key Identifier 253 This is a four octet value assigned in the Registration and 254 inserted in every GRE frame. 256 Figure 1: GRE Key Extension 258 6. IANA Considerations 260 The GRE Key extension defined in this memo is as defined in 261 [RFC3344]. IANA should assign a value for this Extension. 263 7. Security Considerations 265 This specification does not introduce any new security 266 considerations, beyond those described in [RFC3344] 268 8. Acknowledgements 270 Thanks to Jun Wang, Gopal Dommety and Sri Gundavelli for their 271 helpful comments, offline discussions and reviewing the initial 272 draft. 274 9. Normative references 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, March 1997. 279 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 280 RFC 2890, September 2000. 282 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 283 August 2002. 285 Authors' Addresses 287 Parviz Yegani 288 Juniper Netowrks 289 1194 North Mathilda Ave. 290 Sunnyvale, California 94089 291 U.S.A 293 Phone: +1 408-759-1973 294 Email: pyegani@juniper.net 296 Kent Leung 297 Cisco Systems Incorporated 298 170 West Tasman Drive 299 San Jose, California 95134 300 U.S.A 302 Phone: +1 408 526 5030 303 Email: kleung@cisco.com 305 Avi Lior 306 Bridgewater Systems Corporation 307 303 Terry Fox Drive 308 Ottawa, Ontario K2K 3J1 309 Canada 311 Phone: +1 613-591-6655 312 Email: avi@bridgewatersystems.com 313 Kuntal Chowdhury 314 Cisco Systems Incorporated 315 170 West Tasman Drive 316 San Jose, California 95134 317 U.S.A 319 Email: kchowdhu@cisco.com 321 Jay Navali 322 Cisco Systems Incorporated 323 170 West Tasman Drive 324 San Jose, California 95134 325 U.S.A 327 Email: jnavali@cisco.com