Network Working Group Stan Hanks INTERNET DRAFT Technology Transfer Associates Tony Li Dino Farinacci Paul Traina cisco Systems September 8, 1993 Generic Routing Encapsulation (GRE) Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". 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, IDPR] 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] Expiration Date February 1994 [Page 1] Internet Draft August 1993 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 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| Flags | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Offset (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing (optional) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expiration Date February 1994 [Page 2] Internet Draft August 1993 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. 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. Version Number (bits 13-15) The Version Number field MUST contain the value 0. Other values Expiration Date February 1994 [Page 3] Internet Draft August 1993 are outside of the scope of this document. 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. Expiration Date February 1994 [Page 4] Internet Draft August 1993 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 15 bit 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 Expiration Date February 1994 [Page 5] Internet Draft August 1993 the corresponding flags may be checked. If the Routing Present bit 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. Since this is considered a differnet media type, there is no need for multiple encapsulations based upon media type. If there are multiple encapsulation methods for various media types, the ethertype should be used. Selection for encodings are made according to this scheme: 1. Use the DIX ethernet encoding (e.g. 0x0800 = IP) 2. If the protocol is encoded with the SNAP LSAP, use the SNAP protocol ID field (ethernet encoding). (e.g. 0x0800 = IP) 3. Use 00 followed by the LSAP (e.g. 0x00FE = OSI network layer) 4. Full SNAP encoding with a non zero OUI field is reserved for proprietary use. In this case, 0x00AA should be used for the GRE protocol type and the OUI and additional encodings immediately follow the GRE header. These values have been computed using this scheme and MUST be used to identify the following protocols: Protocol Family PTYPE --------------- ----- SNA 0004 SNAP encoding (OUI follows GRE) 00AA OSI network layer 00FE PUP 0200 XNS 0600 IP 0800 Chaos 0804 RFC 826 ARP 0806 Expiration Date February 1994 [Page 6] Internet Draft August 1993 Frame Relay ARP 0808 VINES 0BAD VINES Echo 0BAE VINES Loopback 0BAF DECnet (Phase IV) 6003 Ethertalk 809B Apollo Domain 8019 Novell IPX 8137 In addition, the following values are specified: Reserved 0000 Transparent Ethernet Bridging 6558 Raw Frame Relay 6559 IP Autonomous Systems fffe Reserved FFFF Security Considerations Security considerations are not discussed in this memo. Acknowledgements The authors would like to acknowledge Yakov Rekhter (IBM) and Deborah Estrin (USC) for their advice, encouragement and insightful comments. Authors' Addresses: Stanley P. Hanks Technology Transfer Associates P.O. Box 2087 Bellaire TX, 77402 stan@tta.com Tony Li cisco Systems, Inc. 1525 O'Brien Drive Menlo Park, CA 94025 tli@cisco.com Dino Farinacci cisco Systems, Inc. Expiration Date February 1994 [Page 7] Internet Draft August 1993 1525 O'Brien Drive Menlo Park, CA 94025 dino@cisco.com Paul Traina cisco Systems, Inc. 1525 O'Brien Drive Menlo Park, CA 94025 pst@cisco.com References IDPR Steenstrup, M. "Inter-Domain Policy Routing Protocol Specification: Version 1". Work in progress. RFC 1226 Kantor, B. "Internet protocol encapsulation of AX.25 frames", May 1991 RFC 1234 Provan, D. "Tunneling IPX Traffic through IP Networks". June 1991 RFC 1241 Woodburn, R.A.; Mills, D.L. "Scheme for an internet encapsulation protocol: Version 1". July 1991 RFC 1326 Tsuchiya, P. "Mutual Encapsulation Considered Dangerous". May 1992 SDRP Estrin, D., Li, T., Rekhter, Y. "Source Demand Routing Protocol Specification (Version 1)". Work in progress. GRE-IP Hanks, S., Li, T., Farinacci, D., Traina, P. "Generic Routing Encapsulation over IPv4 networks". Work in progress. Expiration Date February 1994 [Page 8]