508 lines
16 KiB
Plaintext
508 lines
16 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|