hacks and glory await
This commit is contained in:
451
RFC/rfc1701.txt
Normal file
451
RFC/rfc1701.txt
Normal file
@@ -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]
|
||||
|
||||
Reference in New Issue
Block a user