summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2784.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2784.txt')
-rw-r--r--doc/rfc/rfc2784.txt507
1 files changed, 507 insertions, 0 deletions
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]
+