1
2
3
4
5
6
7Network Working Group                                           S. Hanks
8Request for Comments: 1701                               NetSmiths, Ltd.
9Category: Informational                                            T. Li
10                                                            D. Farinacci
11                                                               P. Traina
12                                                           cisco Systems
13                                                            October 1994
14
15
16                  Generic Routing Encapsulation (GRE)
17
18Status of this Memo
19
20
21   This memo provides information for the Internet community.  This memo
22   does not specify an Internet standard of any kind.  Distribution of
23   this memo is unlimited.
24
25Abstract
26
27   This document specifies a protocol for performing encapsulation of an
28   arbitrary network layer protocol over another arbitrary network layer
29   protocol.
30
31Introduction
32
33   A number of different proposals [RFC 1234, RFC 1226] currently exist
34   for the encapsulation of one protocol over another protocol. Other
35   types of encapsulations [RFC 1241, SDRP, RFC 1479] have been proposed
36   for transporting IP over IP for policy purposes. This memo describes
37   a protocol which is very similar to, but is more general than, the
38   above proposals.  In attempting to be more general, many protocol
39   specific nuances have been ignored.  The result is that this proposal
40   is may be less suitable for a situation where a specific "X over Y"
41   encapsulation has been described.  It is the attempt of this protocol
42   to provide a simple, general purpose mechanism which is reduces the
43   problem of encapsulation from its current O(n^2) problem to a more
44   manageable state.  This proposal also attempts to provide a
45   lightweight encapsulation for use in policy based routing.  This memo
46   explicitly does not address the issue of when a packet should be
47   encapsulated.  This memo acknowledges, but does not address problems
48   with mutual encapsulation [RFC 1326].
49
50   In the most general case, a system has a packet that needs to be
51   encapsulated and routed.  We will call this the payload packet.  The
52   payload is first encapsulated in a GRE packet, which possibly also
53   includes a route.  The resulting GRE packet can then be encapsulated
54   in some other protocol and then forwarded.  We will call this outer
55
56
57
58Hanks, Li, Farinacci & Traina                                   [Page 1]
59
60RFC 1701          Generic Routing Encapsulation (GRE)       October 1994
61
62
63   protocol the delivery protocol. The algorithms for processing this
64   packet are discussed later.
65
66Overall packet
67
68   The entire encapsulated packet would then have the form:
69
70                  ---------------------------------
71                  |                               |
72                  |       Delivery Header         |
73                  |                               |
74                  ---------------------------------
75                  |                               |
76                  |       GRE Header              |
77                  |                               |
78                  ---------------------------------
79                  |                               |
80                  |       Payload packet          |
81                  |                               |
82                  ---------------------------------
83
84Packet header
85
86   The GRE packet header has the form:
87
88       0                   1                   2                   3
89       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
90      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
91      |C|R|K|S|s|Recur|  Flags  | Ver |         Protocol Type         |
92      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
93      |      Checksum (optional)      |       Offset (optional)       |
94      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
95      |                         Key (optional)                        |
96      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
97      |                    Sequence Number (optional)                 |
98      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
99      |                         Routing (optional)
100      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
101
102      Flags and version (2 octets)
103
104      The GRE flags are encoded in the first two octets.  Bit 0 is the
105      most significant bit, bit 15 is the least significant bit.  Bits
106      13 through 15 are reserved for the Version field.  Bits 5 through
107      12 are reserved for future use and MUST be transmitted as zero.
108
109
110
111
112
113
114Hanks, Li, Farinacci & Traina                                   [Page 2]
115
116RFC 1701          Generic Routing Encapsulation (GRE)       October 1994
117
118
119      Checksum Present (bit 0)
120
121      If the Checksum Present bit is set to 1, then the Checksum field
122      is present and contains valid information.
123
124      If either the Checksum Present bit or the Routing Present bit are
125      set, BOTH the Checksum and Offset fields are present in the GRE
126      packet.
127
128      Routing Present (bit 1)
129
130      If the Routing Present bit is set to 1, then it indicates that the
131      Offset and Routing fields are present and contain valid
132      information.
133
134      If either the Checksum Present bit or the Routing Present bit are
135      set, BOTH the Checksum and Offset fields are present in the GRE
136      packet.
137
138      Key Present (bit 2)
139
140      If the Key Present bit is set to 1, then it indicates that the Key
141      field is present in the GRE header.  Otherwise, the Key field is
142      not present in the GRE header.
143
144      Sequence Number Present (bit 3)
145
146      If the Sequence Number Present bit is set to 1, then it indicates
147      that the Sequence Number field is present.  Otherwise, the
148      Sequence Number field is not present in the GRE header.
149
150      Strict Source Route (bit 4)
151
152      The meaning of the Strict Source route bit is defined in other
153      documents.  It is recommended that this bit only be set to 1 if
154      all of the the Routing Information consists of Strict Source
155      Routes.
156
157      Recursion Control (bits 5-7)
158
159      Recursion control contains a three bit unsigned integer which
160      contains the number of additional encapsulations which are
161      permissible.  This SHOULD default to zero.
162
163      Version Number (bits 13-15)
164
165      The Version Number field MUST contain the value 0.  Other values
166      are outside of the scope of this document.
167
168
169
170Hanks, Li, Farinacci & Traina                                   [Page 3]
171
172RFC 1701          Generic Routing Encapsulation (GRE)       October 1994
173
174
175      Protocol Type (2 octets)
176
177      The Protocol Type field contains the protocol type of the payload
178      packet.  In general, the value will be the Ethernet protocol type
179      field for the packet.  Currently defined protocol types are listed
180      below.  Additional values may be defined in other documents.
181
182      Offset (2 octets)
183
184      The offset field indicates the octet offset from the start of the
185      Routing field to the first octet of the active Source Route Entry
186      to be examined.  This field is present if the Routing Present or
187      the Checksum Present bit is set to 1, and contains valid
188      information only if the Routing Present bit is set to 1.
189
190      Checksum (2 octets)
191
192      The Checksum field contains the IP (one's complement) checksum of
193      the GRE header and the payload packet.  This field is present if
194      the Routing Present or the Checksum Present bit is set to 1, and
195      contains valid information only if the Checksum Present bit is set
196      to 1.
197
198      Key (4 octets)
199
200      The Key field contains a four octet number which was inserted by
201      the encapsulator.  It may be used by the receiver to authenticate
202      the source of the packet.  The techniques for determining
203      authenticity are outside of the scope of this document.  The Key
204      field is only present if the Key Present field is set to 1.
205
206      Sequence Number (4 octets)
207
208      The Sequence Number field contains an unsigned 32 bit integer
209      which is inserted by the encapsulator.  It may be used by the
210      receiver to establish the order in which packets have been
211      transmitted from the encapsulator to the receiver.  The exact
212      algorithms for the generation of the Sequence Number and the
213      semantics of their reception is outside of the scope of this
214      document.
215
216      Routing (variable)
217
218      The Routing field is optional and is present only if the Routing
219      Present bit is set to 1.
220
221
222
223
224
225
226Hanks, Li, Farinacci & Traina                                   [Page 4]
227
228RFC 1701          Generic Routing Encapsulation (GRE)       October 1994
229
230
231      The Routing field is a list of Source Route Entries (SREs).  Each
232      SRE has the form:
233
234    0                   1                   2                   3
235    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
236   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
237   |       Address Family          |  SRE Offset   |  SRE Length   |
238   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
239   |                        Routing Information ...
240   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
241
242   The routing field is terminated with a "NULL" SRE containing an
243   address family of type 0x0000 and a length of 0.
244
245   Address Family (2 octets)
246
247   The Address Family field contains a two octet value which indicates
248   the syntax and semantics of the Routing Information field.  The
249   values for this field and the corresponding syntax and semantics for
250   Routing Information are defined in other documents.
251
252   SRE Offset (1 octet)
253
254   The SRE Offset field indicates the octet offset from the start of the
255   Routing Information field to the first octet of the active entry in
256   Source Route Entry to be examined.
257
258   SRE Length (1 octet)
259
260   The SRE Length field contains the number of octets in the SRE.  If
261   the SRE Length is 0, this indicates this is the last SRE in the
262   Routing field.
263
264   Routing Information (variable)
265
266   The Routing Information field contains data which may be used in
267   routing this packet.  The exact semantics of this field is defined in
268   other documents.
269
270Forwarding of GRE packets
271
272   Normally, a system which is forwarding delivery layer packets will
273   not differentiate GRE packets from other packets in any way.
274   However, a GRE packet may be received by a system.  In this case, the
275   system should use some delivery-specific means to determine that this
276   is a GRE packet.  Once this is determined, the Key, Sequence Number
277   and Checksum fields if they contain valid information as indicated by
278   the corresponding flags may be checked.  If the Routing Present bit
279
280
281
282Hanks, Li, Farinacci & Traina                                   [Page 5]
283
284RFC 1701          Generic Routing Encapsulation (GRE)       October 1994
285
286
287   is set to 1, then the Address Family field should be checked to
288   determine the semantics and use of the SRE Length, SRE Offset and
289   Routing Information fields.  The exact semantics for processing a SRE
290   for each Address Family is defined in other documents.
291
292   Once all SREs have been processed, then the source route is complete,
293   the GRE header should be removed, the payload's TTL MUST be
294   decremented (if one exists) and the payload packet should be
295   forwarded as a normal packet.  The exact forwarding method depends on
296   the Protocol Type field.
297
298Current List of Protocol Types
299
300   The following are currently assigned protocol types for GRE.  Future
301   protocol types must be taken from DIX ethernet encoding.  For
302   historical reasons, a number of other values have been used for some
303   protocols.  The following table of values MUST be used to identify
304   the following protocols:
305
306       Protocol Family                     PTYPE
307       ---------------                     -----
308       Reserved                            0000
309       SNA                                 0004
310       OSI network layer                   00FE
311       PUP                                 0200
312       XNS                                 0600
313       IP                                  0800
314       Chaos                               0804
315       RFC 826 ARP                         0806
316       Frame Relay ARP                     0808
317       VINES                               0BAD
318       VINES Echo                          0BAE
319       VINES Loopback                      0BAF
320       DECnet (Phase IV)                   6003
321       Transparent Ethernet Bridging       6558
322       Raw Frame Relay                     6559
323       Apollo Domain                       8019
324       Ethertalk (Appletalk)               809B
325       Novell IPX                          8137
326       RFC 1144 TCP/IP compression         876B
327       IP Autonomous Systems               876C
328       Secure Data                         876D
329       Reserved                            FFFF
330
331   See the IANA list of Ether Types for the complete list of these
332   values.
333
334   URL = ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers.
335
336
337
338Hanks, Li, Farinacci & Traina                                   [Page 6]
339
340RFC 1701          Generic Routing Encapsulation (GRE)       October 1994
341
342
343References
344
345   RFC 1479
346      Steenstrup, M. "Inter-Domain Policy Routing Protocol
347      Specification: Version 1", RFC1479, BBN Systems and Technologies,
348      July 1993.
349
350   RFC 1226
351      Kantor, B. "Internet Protocol Encapsulation of AX.25 Frames", RFC
352      1226, University of California, San Diego, May 1991.
353
354   RFC 1234
355      Provan, D. "Tunneling IPX Traffic through IP Networks", RFC 1234,
356      Novell, Inc., June 1991.
357
358   RFC 1241
359      Woodburn, R., and D. Mills, "Scheme for an Internet Encapsulation
360      Protocol: Version 1", RFC 1241, SAIC, University of Delaware, July
361      1991.
362
363   RFC 1326
364      Tsuchiya, P., "Mutual Encapsulation Considered Dangerous", RFC
365      1326, Bellcore, May 1992.
366
367   SDRP
368      Estrin, D., Li, T., and Y. Rekhter, "Source Demand Routing
369      Protocol Specification (Version 1)", Work in Progress.
370
371   RFC 1702
372      Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing
373      Encapsulation over IPv4 networks", RFC 1702, NetSmiths, Ltd.,
374      cisco Systems, October 1994.
375
376Security Considerations
377
378   Security issues are not discussed in this memo.
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394Hanks, Li, Farinacci & Traina                                   [Page 7]
395
396RFC 1701          Generic Routing Encapsulation (GRE)       October 1994
397
398
399Acknowledgements
400
401   The authors would like to acknowledge Yakov Rekhter (IBM) and Deborah
402   Estrin (USC) for their advice, encouragement and insightful comments.
403
404Authors'  Addresses
405
406   Stan Hanks
407   NetSmiths, Ltd.
408   2025 Lincoln Highway
409   Edison NJ, 08817
410
411   EMail: stan@netsmiths.com
412
413
414   Tony Li
415   cisco Systems, Inc.
416   1525 O'Brien Drive
417   Menlo Park, CA 94025
418
419   EMail: tli@cisco.com
420
421
422   Dino Farinacci
423   cisco Systems, Inc.
424   1525 O'Brien Drive
425   Menlo Park, CA 94025
426
427   EMail: dino@cisco.com
428
429
430   Paul Traina
431   cisco Systems, Inc.
432   1525 O'Brien Drive
433   Menlo Park, CA 94025
434
435   EMail: pst@cisco.com
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450Hanks, Li, Farinacci & Traina                                   [Page 8]
451
452