Network Working Group Dino Farinacci
Internet Draft Tony Li
Category Procket Networks
Stan Hanks
Enron Communications
David Meyer
Cisco Systems
Paul Traina
Juniper Networks
Category Standards Track
draft-meyer-gre-update-01.txt December, 1999
Generic Routing Encapsulation (GRE)
<draft-meyer-gre-update-01.txt>
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
David Meyer [Page 1]
Internet Draft draft-meyer-gre-update-01.txt December, 1999
2. Abstract
This document specifies a protocol for encapsulation of an arbitrary
network layer protocol over another arbitrary network layer protocol.
3. Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved
4. Introduction
A number of different proposals [RFC1234, RFC1226] currently exist
for the encapsulation of one protocol over another protocol. Other
types of encapsulations [RFC1241, SDRP, 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 intent of this protocol
to provide a simple, general purpose mechanism which reduces the
problem of encapsulation from its current O(n^2) problem to a more
manageable state. 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].
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.
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].
4.1. Overall packet
A GRE encapsulated packet has the form:
David Meyer [Page 2]
Internet Draft draft-meyer-gre-update-01.txt December, 1999
---------------------------------
| |
| Delivery Header |
| |
---------------------------------
| |
| GRE Header |
| |
---------------------------------
| |
| Payload packet |
| |
---------------------------------
4.2. Packet 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3. 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 the these fields.
4.4. Reserved0 (bits 1-12)
Bits 1 through 12 are reserved for future use. A sender MUST set them
to zero while a recipient MUST be prepared to deal with non-zero data
as specified in section 7.
David Meyer [Page 3]
Internet Draft draft-meyer-gre-update-01.txt December, 1999
4.4.1. Version Number (bits 13-15)
The Version Number field MUST contain the value zero.
4.5. 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.
4.6. 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.
4.7. 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).
5. IPv4 as a Payload
When IPv4 is being carried as the GRE payload, the Protocol Type
field MUST be set to 0x800.
5.1. Forwarding 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
David Meyer [Page 4]
Internet Draft draft-meyer-gre-update-01.txt December, 1999
discarded.
6. 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.
7. 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 the Informational RFC
1701. The following sections describe correct interoperation with
such implementations.
7.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.
7.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. In this case, an implementation
compliant with this specification MAY discard the packet.
David Meyer [Page 5]
Internet Draft draft-meyer-gre-update-01.txt December, 1999
8. 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.
9. IANA Considerations for Assignment of Protocol Types
New ETHER TYPES as assigned by Xerox Systems Institute [RFC1700]. The
IANA SHOULD NOT encourage the assignment of additional ETHER TYPES
(GRE Protocol Types) for use with GRE.
10. Acknowledgments
This document is derived from the original ideas of the authors of
RFC 1701 and RFC 1702. Brian Carpenter, Bill Fenner, Thomas Narten,
Dave Thaler, Andy Malis, Randy Bush, Scott Bradner and Hitoshi Asaeda
provided many constructive and insightful comments.
11. 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:
11.1. Interaction Path MTU Discovery (PMTU) [RFC1191]
An important issue here is that blackholes can arise if PMTU is used
and the tunnel entry does not relay errors back to the originator of
the packet. The black hole is realized by the following behavior: the
originator sets the don't fragment bit in the delivery header, the
packet gets dropped within the tunnel, but since the originator
doesn't receive feedback, it retransmits with the same PMTU, causing
subsequently transmitted packets to be dropped.
David Meyer [Page 6]
Internet Draft draft-meyer-gre-update-01.txt December, 1999
11.2. 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.
11.3. Interaction with ICMP
11.4. Interaction with the Differentiated Services Architecture
11.5. Multiple and Looping Encapsulations
12. References
[ETYPES] ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers
[RFC1122] R.T. Braden, "Requirements for Internet hosts -
communication layers", RFC1122, Octber 1989
[RFC1191] Mogul, J., and S. Deering, "Path MTU Discovery",
RFC 1191, November 1990.
[RFC1226] Kantor, B. "Internet Protocol Encapsulation of AX.25
Frames", RFC 1226, University of California, San Diego,
May 1991.
[RFC1234] Provan, D. "Tunneling IPX Traffic through IP Networks",
RFC 1234, Novell, Inc., June 1991.
[RFC1241] Woodburn, R., and D. Mills, "Scheme for an Internet
Encapsulation Protocol: Version 1", RFC 1241, SAIC,
University of Delaware, July 1991.
[RFC1326] Tsuchiya, P., "Mutual Encapsulation Considered
Dangerous", RFC 1326, Bellcore, May 1992.
[RFC1479] Steenstrup, M. "Inter-Domain Policy Routing Protocol
Specification: Version 1", RFC 1479, BBN Systems and
Technologies, July 1993.
[RFC1700] J. Reynolds and J. Postel, "Assigned Numbers",
RFC 1700, October 1994.
[RFC1701] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic
David Meyer [Page 7]
Internet Draft draft-meyer-gre-update-01.txt December, 1999
Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and
cisco Systems, October 1994.
[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina,
"Generic Routing Encapsulation over IPv4 networks",
RFC 1702, NetSmiths, Ltd., cisco Systems, October 1994.
[RFC2003] C. Perkins, "IP Encapsulation within IP", RFC 2003,
October, 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", 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.
[RFC2473] A. Conta and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December, 1998.
[SDRP] Estrin, D., Li, T., and Y. Rekhter, "Source Demand
Routing Protocol Specification (Version 1)", Work in
Progress.
13. 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
+1 408 954 7903 (w)
+1 408 987 6166 (f)
Email: tony1@home.net
Stan Hanks
Enron Communications
Email: stan_hanks@enron.net
David Meyer
David Meyer [Page 8]
Internet Draft draft-meyer-gre-update-01.txt December, 1999
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134
Email: dmm@cisco.com
Paul Traina
Juniper Networks
Email: pst@juniper.net
David Meyer [Page 9]