Generic Routing Encapsulation (GRE)
updated by
Extracted elements (21)
GRE was designed as a general-purpose encapsulation mechanism to reduce the protocol encapsulation problem from O(n^2) specific pairings to a manageable size, at the cost of ignoring protocol-specific nuances that more targeted encapsulations might address.
This specification intentionally describes only the intersection of GRE implementations currently deployed by multiple vendors, consciously deferring issues such as PMTU interaction, IPv6 as delivery or payload, ICMP interaction, Differentiated Services interaction, and multiple/looping encapsulations to future work.
An RFC 1701 compliant transmitter may set Routing Present, Key Present, Sequence Number Present, or Strict Source Route bits to one and include those fields. A receiver complying only to RFC 2784 MUST discard such packets (non-zero bits 1-5) unless it also implements RFC 1701.
An RFC 2784-compliant transmitter sends Reserved0 as zero, which an RFC 1701 receiver interprets correctly as having all optional-field-present bits unset, so no RFC 1701 optional fields are expected.
Existing deployed GRE implementations over IPv4 do not implement Path MTU Discovery and do not set the Don't Fragment bit in the Delivery Header, causing large packets to be fragmented within the tunnel and reassembled at the exit. PMTU relay of ICMP 'fragmentation needed' messages back to the originator is not required by this specification.
IPv6 as either the delivery protocol or payload protocol is not included in the currently deployed versions of GRE described by this specification and is therefore out of scope.
RFC 2784 deprecates the Routing Present, Key Present, Sequence Number Present, Strict Source Route bits, and the Recursion Control field that were present in RFC 1701. As a result, the GRE header under this specification will never contain Key, Sequence Number, or Routing fields from RFC 1701.
A receiver MUST discard a packet where any of bits 1-5 of Reserved0 are non-zero, unless the receiver implements RFC 1701. Bits 6-12 MUST be sent as zero and MUST be ignored on receipt.
If the Checksum Present bit is set to one, a compliant implementation MUST accept and process the Checksum and Reserved1 fields. The Checksum field contains valid information only when this bit is set.
The Reserved1 field (2 octets), when present, MUST be transmitted as zero. It is present only when the Checksum Present bit is set to one.
The Version Number field (bits 13-15) MUST contain the value zero. GRE version 0 is defined by this specification.
When decapsulating a GRE packet with an IPv4 payload, the destination address in the IPv4 payload header MUST be used to forward the packet and the TTL of the payload MUST be decremented. If the payload destination is the encapsulator itself (potential loop), the packet MUST be discarded.
When IPv4 is carried as the GRE payload, the Protocol Type field MUST be set to 0x800.
A GRE encapsulated packet consists of three layers: a Delivery Header (outer protocol), a GRE Header, and the Payload packet. The payload is first encapsulated in GRE, and the resulting packet is then encapsulated in the delivery protocol for forwarding.
GRE packets encapsulated in IPv4 use IP protocol number 47, as assigned in RFC 1700. Requirements for delivery over IPv4 networks are governed by RFC 1122.
GRE Protocol Types use ETHER TYPE values. New ETHER TYPES are assigned by the Xerox Systems Institute as documented in RFC 1700 and the IANA Ethernet Numbers registry.
GRE Version Numbers are assigned by IETF Consensus (RFC 2434). This document defines version 0; version 1 is used by PPTP (RFC 2637).
Security in a GRE network is broadly similar to a normal IPv4 network since GRE follows the same routing. However, packet filtering requires either inspecting inside the GRE packet or filtering at tunnel endpoints; terminating the tunnel at a firewall may be desirable in security-sensitive environments.
The Checksum field (2 octets, optional) contains the IP one's-complement checksum of all 16-bit words in the GRE header and the payload packet; the checksum field itself is treated as zero during computation. Present only when the Checksum Present bit is set.
The GRE header begins with a 2-octet word containing: Checksum Present (bit 0), Reserved0 (bits 1-12), and Version (bits 13-15), followed by a 2-octet Protocol Type field. An optional second word contains Checksum (2 octets) and Reserved1 (2 octets), present only when the Checksum Present bit is set.
The Protocol Type field is 2 octets and carries the ETHER TYPE of the payload packet as defined in RFC 1700 and the IANA Ethernet Numbers registry. An implementation receiving an unrecognized Protocol Type SHOULD discard the packet.