summaryrefslogtreecommitdiff
path: root/rfc/rfc1701.txt
diff options
context:
space:
mode:
Diffstat (limited to 'rfc/rfc1701.txt')
-rw-r--r--rfc/rfc1701.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/rfc/rfc1701.txt b/rfc/rfc1701.txt
new file mode 100644
index 00000000..60a0e9b9
--- /dev/null
+++ b/rfc/rfc1701.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+