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
datatracker.ietf.org