Network Working Group S. Hanks
`Request for Comments: 1701 NetSmiths, Ltd.
`Category: Informational T. Li
` D. Farinacci
` P. Traina
` cisco Systems
` October 1994
`
` Generic Routing Encapsulation (GRE)
`
`Status of this Memo
`
` This memo provides information for the Internet community. This memo
` does not specify an Internet standard of any kind. Distribution of
` this memo is unlimited.
`
`Abstract
`
` This document specifies a protocol for performing encapsulation of an
` arbitrary network layer protocol over another arbitrary network layer
` protocol.
`
`Introduction
`
` A number of different proposals [RFC 1234, RFC 1226] currently exist
` for the encapsulation of one protocol over another protocol. Other
` types of encapsulations [RFC 1241, SDRP, RFC 1479] 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
` is 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 is reduces the
` problem of encapsulation from its current O(n^2) problem to a more
` manageable state. This proposal also attempts to provide a
` lightweight encapsulation for use in policy based routing. This memo
` explicitly does not address the issue of when a packet should be
` encapsulated. This memo acknowledges, but does not address problems
` with mutual encapsulation [RFC 1326].
`
` In the most general case, a system has a packet that needs to be
` encapsulated and routed. We will call this the payload packet. The
` payload is first encapsulated in a GRE packet, which possibly also
` includes a route. The resulting GRE packet can then be encapsulated
` in some other protocol and then forwarded. We will call this outer
`
`Hanks, Li, Farinacci & Traina [Page 1]
`
`Microsoft
`Ex. 1030 - Page 1
`
`

`

`RFC 1701 Generic Routing Encapsulation (GRE) October 1994
`
` protocol the delivery protocol. The algorithms for processing this
` packet are discussed later.
`
`Overall packet
`
` The entire encapsulated packet would then have the form:
`
` ---------------------------------
` | |
` | Delivery Header |
` | |
` ---------------------------------
` | |
` | GRE Header |
` | |
` ---------------------------------
` | |
` | Payload packet |
` | |
` ---------------------------------
`
`Packet header
`
` The GRE packet header has the form:
`
` 0 1 2 3
` 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|R|K|S|s|Recur| Flags | Ver | Protocol Type |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Checksum (optional) | Offset (optional) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Key (optional) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Sequence Number (optional) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Routing (optional)
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` Flags and version (2 octets)
`
` The GRE flags are encoded in the first two octets. Bit 0 is the
` most significant bit, bit 15 is the least significant bit. Bits
` 13 through 15 are reserved for the Version field. Bits 5 through
` 12 are reserved for future use and MUST be transmitted as zero.
`
`Hanks, Li, Farinacci & Traina [Page 2]
`
`Microsoft
`Ex. 1030 - Page 2
`
`

`

`RFC 1701 Generic Routing Encapsulation (GRE) October 1994
`
` Checksum Present (bit 0)
`
` If the Checksum Present bit is set to 1, then the Checksum field
` is present and contains valid information.
`
` If either the Checksum Present bit or the Routing Present bit are
` set, BOTH the Checksum and Offset fields are present in the GRE
` packet.
`
` Routing Present (bit 1)
`
` If the Routing Present bit is set to 1, then it indicates that the
` Offset and Routing fields are present and contain valid
` information.
`
` If either the Checksum Present bit or the Routing Present bit are
` set, BOTH the Checksum and Offset fields are present in the GRE
` packet.
`
` Key Present (bit 2)
`
` If the Key Present bit is set to 1, then it indicates that the Key
` field is present in the GRE header. Otherwise, the Key field is
` not present in the GRE header.
`
` Sequence Number Present (bit 3)
`
` If the Sequence Number Present bit is set to 1, then it indicates
` that the Sequence Number field is present. Otherwise, the
` Sequence Number field is not present in the GRE header.
`
` Strict Source Route (bit 4)
`
` The meaning of the Strict Source route bit is defined in other
` documents. It is recommended that this bit only be set to 1 if
` all of the the Routing Information consists of Strict Source
` Routes.
`
` Recursion Control (bits 5-7)
`
` Recursion control contains a three bit unsigned integer which
` contains the number of additional encapsulations which are
` permissible. This SHOULD default to zero.
`
` Version Number (bits 13-15)
`
` The Version Number field MUST contain the value 0. Other values
` are outside of the scope of this document.
`
`Hanks, Li, Farinacci & Traina [Page 3]
`
`Microsoft
`Ex. 1030 - Page 3
`
`

`

`RFC 1701 Generic Routing Encapsulation (GRE) October 1994
`
` Protocol Type (2 octets)
`
` The Protocol Type field contains the protocol type of the payload
` packet. In general, the value will be the Ethernet protocol type
` field for the packet. Currently defined protocol types are listed
` below. Additional values may be defined in other documents.
`
` Offset (2 octets)
`
` The offset field indicates the octet offset from the start of the
` Routing field to the first octet of the active Source Route Entry
` to be examined. This field is present if the Routing Present or
` the Checksum Present bit is set to 1, and contains valid
` information only if the Routing Present bit is set to 1.
`
` Checksum (2 octets)
`
` The Checksum field contains the IP (one’s complement) checksum of
` the GRE header and the payload packet. This field is present if
` the Routing Present or the Checksum Present bit is set to 1, and
` contains valid information only if the Checksum Present bit is set
` to 1.
`
` Key (4 octets)
`
` The Key field contains a four octet number which was inserted by
` the encapsulator. It may be used by the receiver to authenticate
` the source of the packet. The techniques for determining
` authenticity are outside of the scope of this document. The Key
` field is only present if the Key Present field is set to 1.
`
` Sequence Number (4 octets)
`
` The Sequence Number field contains an unsigned 32 bit integer
` which is inserted by the encapsulator. It may be used by the
` receiver to establish the order in which packets have been
` transmitted from the encapsulator to the receiver. The exact
` algorithms for the generation of the Sequence Number and the
` semantics of their reception is outside of the scope of this
` document.
`
` Routing (variable)
`
` The Routing field is optional and is present only if the Routing
` Present bit is set to 1.
`
`Hanks, Li, Farinacci & Traina [Page 4]
`
`Microsoft
`Ex. 1030 - Page 4
`
`

`

`RFC 1701 Generic Routing Encapsulation (GRE) October 1994
`
` The Routing field is a list of Source Route Entries (SREs). Each
` SRE has the form:
`
` 0 1 2 3
` 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
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Address Family | SRE Offset | SRE Length |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Routing Information ...
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` The routing field is terminated with a "NULL" SRE containing an
` address family of type 0x0000 and a length of 0.
`
` Address Family (2 octets)
`
` The Address Family field contains a two octet value which indicates
` the syntax and semantics of the Routing Information field. The
` values for this field and the corresponding syntax and semantics for
` Routing Information are defined in other documents.
`
` SRE Offset (1 octet)
`
` The SRE Offset field indicates the octet offset from the start of the
` Routing Information field to the first octet of the active entry in
` Source Route Entry to be examined.
`
` SRE Length (1 octet)
`
` The SRE Length field contains the number of octets in the SRE. If
` the SRE Length is 0, this indicates this is the last SRE in the
` Routing field.
`
` Routing Information (variable)
`
` The Routing Information field contains data which may be used in
` routing this packet. The exact semantics of this field is defined in
` other documents.
`
`Forwarding of GRE packets
`
` Normally, a system which is forwarding delivery layer packets will
` not differentiate GRE packets from other packets in any way.
` However, a GRE packet may be received by a system. In this case, the
` system should use some delivery-specific means to determine that this
` is a GRE packet. Once this is determined, the Key, Sequence Number
` and Checksum fields if they contain valid information as indicated by
` the corresponding flags may be checked. If the Routing Present bit
`
`Hanks, Li, Farinacci & Traina [Page 5]
`
`Microsoft
`Ex. 1030 - Page 5
`
`

`

`RFC 1701 Generic Routing Encapsulation (GRE) October 1994
`
` is set to 1, then the Address Family field should be checked to
` determine the semantics and use of the SRE Length, SRE Offset and
` Routing Information fields. The exact semantics for processing a SRE
` for each Address Family is defined in other documents.
`
` Once all SREs have been processed, then the source route is complete,
` the GRE header should be removed, the payload’s TTL MUST be
` decremented (if one exists) and the payload packet should be
` forwarded as a normal packet. The exact forwarding method depends on
` the Protocol Type field.
`
`Current List of Protocol Types
`
` The following are currently assigned protocol types for GRE. Future
` protocol types must be taken from DIX ethernet encoding. For
` historical reasons, a number of other values have been used for some
` protocols. The following table of values MUST be used to identify
` the following protocols:
`
` Protocol Family PTYPE
` --------------- -----
` Reserved 0000
` SNA 0004
` OSI network layer 00FE
` PUP 0200
` XNS 0600
` IP 0800
` Chaos 0804
`RFC 826 ARP 0806
` Frame Relay ARP 0808
` VINES 0BAD
` VINES Echo 0BAE
` VINES Loopback 0BAF
` DECnet (Phase IV) 6003
` Transparent Ethernet Bridging 6558
` Raw Frame Relay 6559
` Apollo Domain 8019
` Ethertalk (Appletalk) 809B
` Novell IPX 8137
`RFC 1144 TCP/IP compression 876B
` IP Autonomous Systems 876C
` Secure Data 876D
` Reserved FFFF
`
` See the IANA list of Ether Types for the complete list of these
` values.
`
` URL = ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers.
`
`Hanks, Li, Farinacci & Traina [Page 6]
`
`Microsoft
`Ex. 1030 - Page 6
`
`

`

`RFC 1701 Generic Routing Encapsulation (GRE) October 1994
`
`References
`
`RFC 1479
` Steenstrup, M. "Inter-Domain Policy Routing Protocol
` Specification: Version 1", RFC1479, BBN Systems and Technologies,
` July 1993.
`
`RFC 1226
` Kantor, B. "Internet Protocol Encapsulation of AX.25 Frames", RFC
`1226, University of California, San Diego, May 1991.
`
`RFC 1234
` Provan, D. "Tunneling IPX Traffic through IP Networks", RFC 1234,
` Novell, Inc., June 1991.
`
`RFC 1241
` Woodburn, R., and D. Mills, "Scheme for an Internet Encapsulation
` Protocol: Version 1", RFC 1241, SAIC, University of Delaware, July
` 1991.
`
`RFC 1326
` Tsuchiya, P., "Mutual Encapsulation Considered Dangerous", RFC
`1326, Bellcore, May 1992.
`
` SDRP
` Estrin, D., Li, T., and Y. Rekhter, "Source Demand Routing
` Protocol Specification (Version 1)", Work in Progress.
`
`RFC 1702
` Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing
` Encapsulation over IPv4 networks", RFC 1702, NetSmiths, Ltd.,
` cisco Systems, October 1994.
`
`Security Considerations
`
` Security issues are not discussed in this memo.
`
`Hanks, Li, Farinacci & Traina [Page 7]
`
`Microsoft
`Ex. 1030 - Page 7
`
`

`

`RFC 1701 Generic Routing Encapsulation (GRE) October 1994
`
`Acknowledgements
`
` The authors would like to acknowledge Yakov Rekhter (IBM) and Deborah
` Estrin (USC) for their advice, encouragement and insightful comments.
`
`Authors’ Addresses
`
` Stan Hanks
` NetSmiths, Ltd.
` 2025 Lincoln Highway
` Edison NJ, 08817
`
` EMail: stan@netsmiths.com
`
` Tony Li
` cisco Systems, Inc.
` 1525 O’Brien Drive
` Menlo Park, CA 94025
`
` EMail: tli@cisco.com
`
` Dino Farinacci
` cisco Systems, Inc.
` 1525 O’Brien Drive
` Menlo Park, CA 94025
`
` EMail: dino@cisco.com
`
` Paul Traina
` cisco Systems, Inc.
` 1525 O’Brien Drive
` Menlo Park, CA 94025
`
` EMail: pst@cisco.com
`
`Hanks, Li, Farinacci & Traina [Page 8]
`
`Microsoft
`Ex. 1030 - Page 8
`
`