idnits 2.17.1 draft-calhoun-mobileip-gre-ext-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) == Outdated reference: A later version (-09) exists of draft-ietf-mobileip-reg-tunnel-02 -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Microsystems, Inc. 4 Title: draft-calhoun-mobileip-gre-ext-01.txt Gopal Dommety 5 Date: September 2001 Cisco Systems 6 Tom Hiller 7 Lucent Technologies 8 Peter J. McCann 9 Lucent Technologies 10 Yingchun Xu 11 3Com Corporation 13 GRE Extensions 15 Status of this Memo 17 This document is an individual contribution for consideration by the 18 Mobile IP Working Group of the Internet Engineering Task Force. 19 Comments should be submitted to the mobile- 20 ip@standards.nortelnetworks.com mailing list. 22 Distribution of this memo is unlimited. 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. Internet-Drafts are working 26 documents of the Internet Engineering Task Force (IETF), its areas, 27 and its working groups. Note that other groups may also distribute 28 working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at: 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at: 41 http://www.ietf.org/shadow.html. 43 Copyright (C) The Internet Society 2000. All Rights Reserved. 45 Abstract 47 The GRE specification contains a Key field, which MAY contain a value 48 that is used to identify a particular GRE "flow". This specification 49 defines a new Mobile IP extensions that is used to exchange the value 50 to be used in the GRE Key field. 52 This specification also introduces a new extension, called the GRE 53 Type extension, which is used during registration to signal the GRE 54 type that will be used for the Mobile Node's session. This extension 55 is deemed important in order to allow the Mobility Agents to setup 56 the necessary protocol interfaces prior to receiving the mobile's 57 traffic. 59 Table of Contents 61 1.0 Introduction 62 1.1 Requirements language 63 1.2 Fast handoffs 64 2.0 GRE Key extension 65 3.0 GRE Type extension 66 4.0 Error Values 67 5.0 GRE Encapsulation 68 6.0 IANA Considerations 69 7.0 Security Considerations 70 8.0 References 71 9.0 Acknowledgements 72 10.0 Authors' Addresses 73 11.0 Full Copyright Statement 75 1.0 Introduction 77 The GRE specification contains a Key field, which MAY contain a value 78 that is used to identify a particular GRE "flow". This specification 79 defines a new Mobile IP extensions that is used to exchange the value 80 to be used in the GRE Key field. 82 This specification also introduces a new extension, called the GRE 83 Type extension, which is used during registration to signal the GRE 84 type that will be used for the Mobile Node's session. This extension 85 is deemed important in order to allow the Mobility Agents to setup 86 the necessary protocol interfaces prior to receiving the mobile's 87 traffic. 89 1.1 Requirements language 91 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 92 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 93 described in [2]. 95 2.0 GRE Key extension 97 The GRE Key extension MAY be included in Registration Requests [1], 98 and Regional Registration Requests [3] whose 'G' bit is enabled. The 99 GRE Key extension is used to inform the recipient of the Mobile IP 100 request of the value to be used in GRE's Key field. 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Type | Length | Reserved | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Key Identifier | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 Type 112 TBD (non-skippable) [1] 114 Length 116 6 118 Reserved 120 This field MUST be set to zero (0). 122 Key Identifier 124 This is a four octet value assigned in the Registration or 125 Regional Registration Request, and inserted in every GRE frame 126 (see Section 5). 128 3.0 GRE Type extension 130 The GRE Type extension MAY be included in Registration Requests [1], 131 and Regional Registration Requests [3] whose 'G' bit is enabled. The 132 GRE Type extension is used to signal to the peer the type of traffic 133 that will be sent from the Mobile Node encapsulated in GRE. Note that 134 only one GRE Type extension MAY be present in a request. 136 If the GRE Type is not supported by the receiver of the Registration 137 or Regional Registration Request, it MUST return the appropriate 138 Reply with the Code field set to PROTO_NOT_SUPPORTED (see Section 4). 140 If the GRE Type extension was present in the Request, all traffic for 141 the Mobile Node MUST be of the type specified in this extension. 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Type | Length | GRE Type | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Type 151 TBD (skippable) [1] 153 Length 155 6 157 GRE Type 159 The GRE protocol type, as defined in [4]. 161 4.0 Error Values 163 The following table contains the name of Code [1] to be returned in a 164 Registration and Regional Registration Replies, the value for the 165 Code, and the section in which the error is first mentioned in this 166 specification. 168 Error Name Value Section of Document 169 ---------------------- ----- ------------------- 170 PROTO_NOT_SUPPORTED TBD 3.0 172 5.0 GRE Encapsulation 174 When the Registration or Regional Registration Request has the 'G' 175 bit enabled, contains the GRE Key extension, all GRE [4] encapsulated 176 packets for the Mobile Node MUST include the value found in the 177 extension within the GRE Key field [5]. The receiver of the GRE frame 178 will use the Key field to identify the particular Mobility Binding. 180 6.0 IANA Considerations 182 The GRE Key extension defined in Section 2 and the GRE Type extension 183 are Mobile IP registration extension as defined in RFC 2002 [1] and 184 extended in RFC 2356 [6]. IANA should assign a value of 131 for this 185 purpose. 187 The Code values defined in Section 4 are error codes as defined in 188 RFC 2002 [1] and extended in RFC 2344 [7] and RFC 2356 [6]. 190 7.0 Security Considerations 192 This specification does not introduce any new security 193 considerations, beyond those described in [1]. 195 8.0 References 197 [1] C. Perkins, Editor. "IP Mobility Support". RFC 2002. October 1996. 199 [2] S. Bradner. "Key words for use in RFCs to Indicate Requirement Lev- 200 els". BCP 14. RFC 2119. March 1997. 202 [3] E. Gustafsson, A. Jonsson, C. Perkins. "Mobile IP Regional Regis- 203 tration", draft-ietf-mobileip-reg-tunnel-02.txt (work in progress), 204 March 2000. 206 [4] Farinacci, D., Li, T., Hanks, S., Meyer, D. and Traina, P., 207 "Generic Routing Encapsulation (GRE)," RFC 2784, March 2000. 209 [5] Gopal Dommety. "Key and Sequence Number Extensions to GRE". draft- 210 dommety-gre-ext-04.txt, June 2000. (work in progress) 212 [6] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for 213 Mobile IP", RFC 2356, June 1998. 215 [7] G. Montenegro. Reverse Tunneling for Mobile IP. Request for Com- 216 ments (Proposed Standard) 2344, Internet Engineering Task Force, 217 May 1998. 219 9.0 Acknowledgements 221 The authors would like to thank the authors of draft-ietf- 222 mobileip-3Gwireless-ext-04.txt, given that some text from that Inter- 223 net Draft was copied into this specification. 225 10.0 Authors' Addresses 227 Questions about this memo can be directed to: 229 Pat R. Calhoun 230 Network and Security Research Center, Sun Labs 231 Sun Microsystems, Inc. 232 15 Network Circle 233 Menlo Park, California, 94025 234 USA 236 Phone: +1 650 786 7733 237 Fax: +1 650 786 6445 238 E-mail: pcalhoun@eng.sun.com 240 Gopal Dommety 241 Cisco Systems 242 170 West Tasman Drive 243 San Jose, CA 95134 245 Phone: +1 408 525 1404 246 E-mail: gdommety@cisco.com 247 Tom Hiller 248 Lucent Technologies 249 Rm 2F-218 250 263 Shuman Blvd 251 Naperville, IL 60566-7050 252 USA 254 Phone: +1 630 979 7673 255 Fax: +1 630 979 7673 256 E-Mail: tom.hiller@lucent.com 258 Peter J. McCann 259 Lucent Technologies 260 Rm 2Z-305 261 263 Shuman Blvd 262 Naperville, IL 60566-7050 263 USA 265 Phone: +1 630 713 9359 266 Fax: +1 630 713 4982 267 E-Mail: mccap@lucent.com 269 Yingchun Xu 270 3Com Corporation 271 1800 West Central Road 272 Mount Prospect, 273 USA 60056 275 Phone: +1 847 342 6814 276 E-mail: Yingchun_Xu@3com.com 278 11.0 Full Copyright Statement 280 Copyright (C) The Internet Society (2000). All Rights Reserved. 282 This document and translations of it may be copied and furnished to 283 others, and derivative works that comment on or otherwise explain it 284 or assist in its implementation may be prepared, copied, published 285 and distributed, in whole or in part, without restriction of any 286 kind, provided that the above copyright notice and this paragraph are 287 included on all such copies and derivative works. However, this docu- 288 ment itself may not be modified in any way, such as by removing the 289 copyright notice or references to the Internet Society or other 290 Internet organizations, except as needed for the purpose of develop- 291 ing Internet standards in which case the procedures for copyrights 292 defined in the Internet Standards process must be followed, or as 293 required to translate it into languages other than English. The lim- 294 ited permissions granted above are perpetual and will not be revoked 295 by the Internet Society or its successors or assigns. This document 296 and the information contained herein is provided on an "AS IS" basis 297 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 298 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 299 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 300 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 301 FITNESS FOR A PARTICULAR PURPOSE."