idnits 2.17.1 draft-meyer-gre-update-02.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 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 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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) == Unused Reference: 'RFC1701' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'RFC1702' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'RFC2408' is defined on line 298, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ETYPES' ** Downref: Normative reference to an Experimental RFC: RFC 1226 ** Downref: Normative reference to an Historic RFC: RFC 1234 ** Downref: Normative reference to an Experimental RFC: RFC 1241 ** Downref: Normative reference to an Informational RFC: RFC 1326 ** Downref: Normative reference to an Historic RFC: RFC 1479 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1701 ** Downref: Normative reference to an Informational RFC: RFC 1702 ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) Summary: 15 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dino Farinacci 2 Internet Draft Tony Li 3 Procket Networks 4 Stan Hanks 5 Enron Communications 6 David Meyer 7 Cisco Systems 8 Paul Traina 9 Juniper Networks 10 Category Standards Track 11 draft-meyer-gre-update-02.txt January, 2000 13 Generic Routing Encapsulation (GRE) 14 16 1. Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC 2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 2. Abstract 38 This document specifies a protocol for encapsulation of an arbitrary 39 network layer protocol over another arbitrary network layer protocol. 41 3. Copyright Notice 43 Copyright (C) The Internet Society (1999). All Rights Reserved 45 4. Introduction 47 A number of different proposals [RFC1234, RFC1226] currently exist 48 for the encapsulation of one protocol over another protocol. Other 49 types of encapsulations [RFC1241, RFC1479] have been proposed for 50 transporting IP over IP for policy purposes. This memo describes a 51 protocol which is very similar to, but is more general than, the 52 above proposals. In attempting to be more general, many protocol 53 specific nuances have been ignored. The result is that this proposal 54 may be less suitable for a situation where a specific "X over Y" 55 problem of encapsulation from its current O(n^2) problem to a more 56 manageable state. This memo purposely does not address the issue of 57 when a packet should be encapsulated. This memo acknowledges, but 58 does not address problems such as mutual encapsulation [RFC1326]. 60 In the most general case, a system has a packet that needs to be 61 encapsulated and delivered to some destination. We will call this 62 the payload packet. The payload is first encapsulated in a GRE 63 packet. The resulting GRE packet can then be encapsulated in some 64 other protocol and then forwarded. We will call this outer protocol 65 the delivery protocol. The algorithms for processing this packet are 66 discussed later. 68 The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, 69 SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined 70 in RFC 2119 [RFC2119]. 72 5. Structure of a GRE Encapsulated Packet 74 A GRE encapsulated packet has the form: 76 --------------------------------- 77 | | 78 | Delivery Header | 79 | | 80 --------------------------------- 81 | | 82 | GRE Header | 83 | | 84 --------------------------------- 85 | | 86 | Payload packet | 87 | | 88 --------------------------------- 90 This specification is generally concerned with the structure of the 91 GRE header, although special consideration is given to some of the 92 issues surrounding IPv4 payloads. 94 5.1. GRE Header 96 The GRE packet header has the form: 98 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 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 |C| Reserved0 | Ver | Protocol Type | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Checksum (optional) | Reserved1 (Optional) | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 5.2. Checksum Present (bit 0) 107 If the Checksum Present bit is set to one, then the Checksum and the 108 Reserved1 fields are present and the Checksum field contains valid 109 information. Note that a compliant implementation MUST accept and 110 process this field. 112 5.3. Reserved0 (bits 1-12) 114 Bits 1 through 12 are reserved for future use. A sender MUST set them 115 to zero while a recipient MUST be prepared to deal with non-zero data 116 as specified in section 7. 118 5.3.1. Version Number (bits 13-15) 120 The Version Number field MUST contain the value zero. 122 5.4. Protocol Type (2 octets) 124 The Protocol Type field contains the protocol type of the payload 125 packet. These Protocol Types are defined in [RFC1700] as "ETHER 126 TYPES" and in [ETYPES]. An implementation receiving a packet 127 containing a Protocol Type which is not listed in [RFC1700] or 128 [ETYPES] SHOULD discard the packet. 130 5.5. Checksum (2 octets) 132 The Checksum field contains the IP (one's complement) checksum sum of 133 the all the 16 bit words in the GRE header and the payload packet. 134 For purposes of computing the checksum, the value of the checksum 135 field is zero. This field is present only if the Checksum Present bit 136 is set to one. 138 5.6. Reserved1 (2 octets) 140 The Reserved1 field is reserved for future use, and if present, MUST 141 be transmitted as zero. The Reserved1 field is present only when the 142 Checksum field is present (that is, Checksum Present bit is set to 143 one). 145 6. IPv4 as a Payload 147 When IPv4 is being carried as the GRE payload, the Protocol Type 148 field MUST be set to 0x800. 150 6.1. Forwarding Decapsulated IPv4 Payload Packets 152 When a tunnel endpoint decapsulates a GRE packet which has an IPv4 153 packet as the payload, the destination address in the IPv4 payload 154 packet header MUST be used to forward the packet and the TTL of the 155 payload packet MUST be decremented. Care should be taken when 156 forwarding such a packet, since if the destination address of the 157 payload packet is the encapsulator of the packet (i.e., the other end 158 of the tunnel), looping can occur. In this case, the packet MUST be 159 discarded. 161 7. IPv4 as a Delivery Protocol 163 The IPv4 protocol 47 [RFC1700] is used when GRE packets are 164 enapsulated in IPv4. See [RFC1122] for requirements relating to the 165 delivery of packets over IPv4 networks. 167 8. Interoperation with RFC 1701 Compliant Implementations 169 In RFC 1701, the field described here as Reserved0 contained a number 170 of flag bits which this specification deprecates. In particular, the 171 Routing Present, Key Present, Sequence Number Present, and Strict 172 Source Route bits have been deprecated, along with the Recursion 173 Control field. As a result, the GRE header will never contain the 174 Key, Sequence Number or Routing fields specified in RFC 1701. 176 There are, however, existing implementations of the RFC 1701. The 177 following sections describe correct interoperation with such 178 implementations. 180 8.1. RFC 1701 Compliant Receiver 182 An implementation complying to this specification will transmit the 183 Reserved0 field set to zero. An RFC 1701 compliant receiver will 184 interpret this as having the Routing Present, Key Present, Sequence 185 Number Present, and Strict Source Route bits set to zero, and will 186 not expect the RFC 1701 Key, Sequence Number or Routing fields to be 187 present. 189 8.2. RFC 1701 Compliant Transmitter 191 An RFC 1701 transmitter may set any of the Routing Present, Key 192 Present, Sequence Number Present, and Strict Source Route bits set to 193 one, and thus may transmit the RFC 1701 Key, Sequence Number or 194 Routing fields in the GRE header. In this case, an implementation 195 compliant with this specification MAY discard the packet. 197 9. Security Considerations 199 Security in a network using GRE should be relatively similar to 200 security in a normal IPv4 network, as routing using GRE follows the 201 same routing that IPv4 uses natively. Route filtering will remain 202 unchanged. However packet filtering requires either that a firewall 203 look inside the GRE packet or that the filtering is done on the GRE 204 tunnel endpoints. In those environments in which this is considered 205 to be a security issue it may be desirable to terminate the tunnel at 206 the firewall. 208 10. IANA Considerations for Assignment of Protocol Types 210 New ETHER TYPES as assigned by Xerox Systems Institute [RFC1700]. The 211 IANA SHOULD NOT encourage the assignment of additional ETHER TYPES 212 (GRE Protocol Types) for use with GRE. 214 11. Acknowledgments 216 This document is derived from the original ideas of the authors of 217 RFC 1701 and RFC 1702. Hitoshi Asaeda, Scott Bradner, Randy Bush, 218 Brian Carpenter, Bill Fenner, Andy Malis, Thomas Narten, and Dave 219 Thaler and provided many constructive and insightful comments. 221 12. Appendix -- Known Issues 223 This document specifies the behavior of currently deployed GRE 224 implementations. As such, it does not attempt to address the 225 following known issues: 227 12.1. Interaction Path MTU Discovery (PMTU) [RFC1191] 229 Existing implementations of GRE, when using IPv4 as the Delivery 230 Header, do not implement Path MTU discovery and do not set the Don't 231 Fragment bit in the Delivery Header. This can cause large packets to 232 become fragmented within the tunnel and reassembled at the tunnel 233 exit (independent of whether the payload packet is using PMTU). If a 234 tunnel entry point were to use Path MTU discovery, however, that 235 tunnel entry point would also need to relay ICMP unreachable error 236 messages (in particular the "fragmentation needed and DF set" code) 237 back to the originator of the packet, which is not a requirement in 238 this specification. Failure to properly relay Path MTU information to 239 an originator can result in the following behavior: the originator 240 sets the don't fragment bit, the packet gets dropped within the 241 tunnel, but since the originator doesn't receive proper feedback, it 242 retransmits with the same PMTU, causing subsequently transmitted 243 packets to be dropped. 245 12.2. IPv6 as Delivery and/or Payload Protocol 247 This specification describes the intersection of GRE currently 248 deployed by multiple vendors. IPv6 as delivery and/or payload 249 protocol is not included in the currently deployed versions of GRE. 251 12.3. Interaction with ICMP 253 12.4. Interaction with the Differentiated Services Architecture 255 12.5. Multiple and Looping Encapsulations 256 13. REFERENCES 258 [ETYPES] ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers 260 [RFC1122] R.T. Braden, "Requirements for Internet hosts - 261 communication layers", RFC1122, Octber 1989 263 [RFC1191] Mogul, J., and S. Deering, "Path MTU Discovery", 264 RFC 1191, November 1990. 266 [RFC1226] Kantor, B. "Internet Protocol Encapsulation of AX.25 267 Frames", RFC 1226, University of California, San Diego, 268 May 1991. 270 [RFC1234] Provan, D. "Tunneling IPX Traffic through IP Networks", 271 RFC 1234, Novell, Inc., June 1991. 273 [RFC1241] Woodburn, R., and D. Mills, "Scheme for an Internet 274 Encapsulation Protocol: Version 1", RFC 1241, SAIC, 275 University of Delaware, July 1991. 277 [RFC1326] Tsuchiya, P., "Mutual Encapsulation Considered 278 Dangerous", RFC 1326, Bellcore, May 1992. 280 [RFC1479] Steenstrup, M. "Inter-Domain Policy Routing Protocol 281 Specification: Version 1", RFC 1479, BBN Systems and 282 Technologies, July 1993. 284 [RFC1700] J. Reynolds and J. Postel, "Assigned Numbers", 285 RFC 1700, October 1994. 287 [RFC1701] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic 288 Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and 289 cisco Systems, October 1994. 291 [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, 292 "Generic Routing Encapsulation over IPv4 networks", 293 RFC 1702, NetSmiths, Ltd., cisco Systems, October 1994. 295 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 296 Requirement Levels", RFC 2119, March, 1997. 298 [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. 299 Turner, "Internet Security Association and Key 300 Management Protocol (ISAKMP)", RFC 2408, November 301 1998. 303 14. Authors' Addresses 305 Dino Farinacci 306 Procket Networks 307 3850 No. First St., Ste. C 308 San Jose, CA 95134 309 Email: dino@procket.com 311 Tony Li 312 Procket Networks 313 3850 No. First St., Ste. C 314 San Jose, CA 95134 315 +1 408 954 7903 (w) 316 +1 408 987 6166 (f) 317 Email: tony1@home.net 319 Stan Hanks 320 Enron Communications 321 Email: stan_hanks@enron.net 323 David Meyer 324 Cisco Systems, Inc. 325 170 Tasman Drive 326 San Jose, CA, 95134 327 Email: dmm@cisco.com 329 Paul Traina 330 Juniper Networks 331 Email: pst@juniper.net