Movatterモバイル変換

Network Working Group                                           S. HanksRequest for Comments: 1701                               NetSmiths, Ltd.Category: Informational                                            T. Li                                                            D. Farinacci                                                               P. Traina                                                           cisco Systems                                                            October 1994Generic 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 outerHanks, 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 bitHanks, 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                               0804RFC 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                          8137RFC 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 1994ReferencesRFC 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",RFC1226, 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",RFC1326, 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 1994Acknowledgements   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.comHanks, Li, Farinacci & Traina                                   [Page 8]