From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2784.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc2784.txt (limited to 'doc/rfc/rfc2784.txt') diff --git a/doc/rfc/rfc2784.txt b/doc/rfc/rfc2784.txt new file mode 100644 index 0000000..614926a --- /dev/null +++ b/doc/rfc/rfc2784.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group D. Farinacci +Request for Comments: 2784 T. Li +Category: Standards Track Procket Networks + S. Hanks + Enron Communications + D. Meyer + Cisco Systems + P. Traina + Juniper Networks + March 2000 + + + Generic Routing Encapsulation (GRE) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This document specifies a protocol for encapsulation of an arbitrary + network layer protocol over another arbitrary network layer protocol. + +1. Introduction + + A number of different proposals [RFC1234, RFC1226] currently exist + for the encapsulation of one protocol over another protocol. Other + types of encapsulations [RFC1241, RFC1479] have been proposed for + transporting IP over IP for policy purposes. This memo describes a + protocol which is very similar to, but is more general than, the + above proposals. In attempting to be more general, many protocol + specific nuances have been ignored. The result is that this proposal + may be less suitable for a situation where a specific "X over Y" + encapsulation has been described. It is the attempt of this protocol + to provide a simple, general purpose mechanism which reduces the + problem of encapsulation from its current O(n^2) size to a more + manageable size. This memo purposely does not address the issue of + when a packet should be encapsulated. This memo acknowledges, but + does not address problems such as mutual encapsulation [RFC1326]. + + + + +Farinacci, et al. Standards Track [Page 1] + +RFC 2784 Generic Routing Encapsulation March 2000 + + + In the most general case, a system has a packet that needs to be + encapsulated and delivered to some destination. We will call this + the payload packet. The payload is first encapsulated in a GRE + packet. The resulting GRE packet can then be encapsulated in some + other protocol and then forwarded. We will call this outer protocol + the delivery protocol. The algorithms for processing this packet are + discussed later. + + Finally this specification describes the intersection of GRE + currently deployed by multiple vendors. + + The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, + SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined + in RFC 2119 [RFC2119]. + +2. Structure of a GRE Encapsulated Packet + + A GRE encapsulated packet has the form: + + --------------------------------- + | | + | Delivery Header | + | | + --------------------------------- + | | + | GRE Header | + | | + --------------------------------- + | | + | Payload packet | + | | + --------------------------------- + + This specification is generally concerned with the structure of the + GRE header, although special consideration is given to some of the + issues surrounding IPv4 payloads. + +2.1. GRE Header + + The GRE packet header has the form: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |C| Reserved0 | Ver | Protocol Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Checksum (optional) | Reserved1 (Optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Farinacci, et al. Standards Track [Page 2] + +RFC 2784 Generic Routing Encapsulation March 2000 + + +2.2. Checksum Present (bit 0) + + If the Checksum Present bit is set to one, then the Checksum and the + Reserved1 fields are present and the Checksum field contains valid + information. Note that a compliant implementation MUST accept and + process this field. + +2.3. Reserved0 (bits 1-12) + + A receiver MUST discard a packet where any of bits 1-5 are non-zero, + unless that receiver implements RFC 1701. Bits 6-12 are reserved for + future use. These bits MUST be sent as zero and MUST be ignored on + receipt. + +2.3.1. Version Number (bits 13-15) + + The Version Number field MUST contain the value zero. + +2.4. Protocol Type (2 octets) + + The Protocol Type field contains the protocol type of the payload + packet. These Protocol Types are defined in [RFC1700] as "ETHER + TYPES" and in [ETYPES]. An implementation receiving a packet + containing a Protocol Type which is not listed in [RFC1700] or + [ETYPES] SHOULD discard the packet. + +2.5. Checksum (2 octets) + + The Checksum field contains the IP (one's complement) checksum sum of + the all the 16 bit words in the GRE header and the payload packet. + For purposes of computing the checksum, the value of the checksum + field is zero. This field is present only if the Checksum Present bit + is set to one. + +2.6. Reserved1 (2 octets) + + The Reserved1 field is reserved for future use, and if present, MUST + be transmitted as zero. The Reserved1 field is present only when the + Checksum field is present (that is, Checksum Present bit is set to + one). + +3. IPv4 as a Payload + + When IPv4 is being carried as the GRE payload, the Protocol Type + field MUST be set to 0x800. + + + + + + +Farinacci, et al. Standards Track [Page 3] + +RFC 2784 Generic Routing Encapsulation March 2000 + + +3.1. Forwarding Decapsulated IPv4 Payload Packets + + When a tunnel endpoint decapsulates a GRE packet which has an IPv4 + packet as the payload, the destination address in the IPv4 payload + packet header MUST be used to forward the packet and the TTL of the + payload packet MUST be decremented. Care should be taken when + forwarding such a packet, since if the destination address of the + payload packet is the encapsulator of the packet (i.e., the other end + of the tunnel), looping can occur. In this case, the packet MUST be + discarded. + +4. IPv4 as a Delivery Protocol + + The IPv4 protocol 47 [RFC1700] is used when GRE packets are + enapsulated in IPv4. See [RFC1122] for requirements relating to the + delivery of packets over IPv4 networks. + +5. Interoperation with RFC 1701 Compliant Implementations + + In RFC 1701, the field described here as Reserved0 contained a number + of flag bits which this specification deprecates. In particular, the + Routing Present, Key Present, Sequence Number Present, and Strict + Source Route bits have been deprecated, along with the Recursion + Control field. As a result, the GRE header will never contain the + Key, Sequence Number or Routing fields specified in RFC 1701. + + There are, however, existing implementations of RFC 1701. The + following sections describe correct interoperation with such + implementations. + +5.1. RFC 1701 Compliant Receiver + + An implementation complying to this specification will transmit the + Reserved0 field set to zero. An RFC 1701 compliant receiver will + interpret this as having the Routing Present, Key Present, Sequence + Number Present, and Strict Source Route bits set to zero, and will + not expect the RFC 1701 Key, Sequence Number or Routing fields to be + present. + +5.2. RFC 1701 Compliant Transmitter + + An RFC 1701 transmitter may set any of the Routing Present, Key + Present, Sequence Number Present, and Strict Source Route bits set to + one, and thus may transmit the RFC 1701 Key, Sequence Number or + Routing fields in the GRE header. As stated in Section 5.3, a packet + with non-zero bits in any of bits 1-5 MUST be discarded unless the + receiver implements RFC 1701. + + + + +Farinacci, et al. Standards Track [Page 4] + +RFC 2784 Generic Routing Encapsulation March 2000 + + +6. Security Considerations + + Security in a network using GRE should be relatively similar to + security in a normal IPv4 network, as routing using GRE follows the + same routing that IPv4 uses natively. Route filtering will remain + unchanged. However packet filtering requires either that a firewall + look inside the GRE packet or that the filtering is done on the GRE + tunnel endpoints. In those environments in which this is considered + to be a security issue it may be desirable to terminate the tunnel at + the firewall. + +7. IANA Considerations + + This section considers the assignment of additional GRE Version + Numbers and Protocol Types. + +7.1. GRE Version Numbers + + This document specifies GRE version number 0. GRE version number 1 is + used by PPTP [RFC2637]. Additional GRE version numbers are assigned + by IETF Consensus as defined in RFC 2434 [RFC2434]. + +7.2. Protocol Types + + GRE uses an ETHER Type for the Protocol Type. New ETHER TYPES are + assigned by Xerox Systems Institute [RFC1700]. + +8. Acknowledgments + + This document is derived from the original ideas of the authors of + RFC 1701 and RFC 1702. Hitoshi Asaeda, Scott Bradner, Randy Bush, + Brian Carpenter, Bill Fenner, Andy Malis, Thomas Narten, Dave Thaler, + Tim Gleeson and others provided many constructive and insightful + comments. + + + + + + + + + + + + + + + + + +Farinacci, et al. Standards Track [Page 5] + +RFC 2784 Generic Routing Encapsulation March 2000 + + +9. Appendix -- Known Issues + + This document specifies the behavior of currently deployed GRE + implementations. As such, it does not attempt to address the + following known issues: + + o Interaction Path MTU Discovery (PMTU) [RFC1191] + + Existing implementations of GRE, when using IPv4 as the Delivery + Header, do not implement Path MTU discovery and do not set the + Don't Fragment bit in the Delivery Header. This can cause large + packets to become fragmented within the tunnel and reassembled at + the tunnel exit (independent of whether the payload packet is using + PMTU). If a tunnel entry point were to use Path MTU discovery, + however, that tunnel entry point would also need to relay ICMP + unreachable error messages (in particular the "fragmentation needed + and DF set" code) back to the originator of the packet, which is + not a requirement in this specification. Failure to properly relay + Path MTU information to an originator can result in the following + behavior: the originator sets the don't fragment bit, the packet + gets dropped within the tunnel, but since the originator doesn't + receive proper feedback, it retransmits with the same PMTU, causing + subsequently transmitted packets to be dropped. + + o IPv6 as Delivery and/or Payload Protocol + + This specification describes the intersection of GRE currently + deployed by multiple vendors. IPv6 as delivery and/or payload + protocol is not included in the currently deployed versions of GRE. + + o Interaction with ICMP + + o Interaction with the Differentiated Services Architecture + + o Multiple and Looping Encapsulations + +10. REFERENCES + + [ETYPES] ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet- + numbers + + [RFC1122] Braden, R., "Requirements for Internet hosts - + communication layers", STD 3, RFC 1122, October 1989. + + [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, + November 1990. + + + + + +Farinacci, et al. Standards Track [Page 6] + +RFC 2784 Generic Routing Encapsulation March 2000 + + + [RFC1226] Kantor, B., "Internet Protocol Encapsulation of AX.25 + Frames", RFC 1226, May 1991. + + [RFC1234] Provan, D., "Tunneling IPX Traffic through IP Networks", + RFC 1234, June 1991. + + [RFC1241] Woodburn, R. and D. Mills, "Scheme for an Internet + Encapsulation Protocol: Version 1", RFC 1241, July 1991. + + [RFC1326] Tsuchiya, P., "Mutual Encapsulation Considered Dangerous", + RFC 1326, May 1992. + + [RFC1479] Steenstrup, M., "Inter-Domain Policy Routing Protocol + Specification: Version 1", RFC 1479, July 1993. + + [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC + 1700, October 1994. + + [RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic + Routing Encapsulation", RFC 1701, October 1994. + + [RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic + Routing Encapsulation over IPv4 networks", RFC 1702, + October 1994. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March, 1997. + + [RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, + "Internet Security Association and Key Management Protocol + (ISAKMP)", RFC 2408, November 1998. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October, 1998. + + [RFC2637] Hamzeh, K., et al., "Point-to-Point Tunneling Protocol + (PPTP)", RFC 2637, July, 1999. + + + + + + + + + + + + + +Farinacci, et al. Standards Track [Page 7] + +RFC 2784 Generic Routing Encapsulation March 2000 + + +11. Authors' Addresses + + Dino Farinacci + Procket Networks + 3850 No. First St., Ste. C + San Jose, CA 95134 + + EMail: dino@procket.com + + + Tony Li + Procket Networks + 3850 No. First St., Ste. C + San Jose, CA 95134 + + Phone: +1 408 954 7903 + Fax: +1 408 987 6166 + EMail: tony1@home.net + + + Stan Hanks + Enron Communications + + EMail: stan_hanks@enron.net + + + David Meyer + Cisco Systems, Inc. + 170 Tasman Drive + San Jose, CA, 95134 + + EMail: dmm@cisco.com + + + Paul Traina + Juniper Networks + EMail: pst@juniper.net + + + + + + + + + + + + + + +Farinacci, et al. Standards Track [Page 8] + +RFC 2784 Generic Routing Encapsulation March 2000 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Farinacci, et al. Standards Track [Page 9] + -- cgit v1.2.3