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