release/src/router/pptp-client/Reference/rfc1701.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                           S. Hanks
   8 Request for Comments: 1701                               NetSmiths, Ltd.
   9 Category: Informational                                            T. Li
  10                                                             D. Farinacci
  11                                                                P. Traina
  12                                                            cisco Systems
  13                                                             October 1994
  14
  15
  16                   Generic Routing Encapsulation (GRE)
  17
  18 Status 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
  25 Abstract
  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
  31 Introduction
  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
  58 Hanks, Li, Farinacci & Traina                                   [Page 1]
  59 \f
  60 RFC 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
  66 Overall 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
  84 Packet 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
 114 Hanks, Li, Farinacci & Traina                                   [Page 2]
 115 \f
 116 RFC 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
 170 Hanks, Li, Farinacci & Traina                                   [Page 3]
 171 \f
 172 RFC 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
 226 Hanks, Li, Farinacci & Traina                                   [Page 4]
 227 \f
 228 RFC 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
 270 Forwarding 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
 282 Hanks, Li, Farinacci & Traina                                   [Page 5]
 283 \f
 284 RFC 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
 298 Current 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
 338 Hanks, Li, Farinacci & Traina                                   [Page 6]
 339 \f
 340 RFC 1701          Generic Routing Encapsulation (GRE)       October 1994
 341
 342
 343 References
 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
 376 Security 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
 394 Hanks, Li, Farinacci & Traina                                   [Page 7]
 395 \f
 396 RFC 1701          Generic Routing Encapsulation (GRE)       October 1994
 397
 398
 399 Acknowledgements
 400
 401    The authors would like to acknowledge Yakov Rekhter (IBM) and Deborah
 402    Estrin (USC) for their advice, encouragement and insightful comments.
 403
 404 Authors'  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
 450 Hanks, Li, Farinacci & Traina                                   [Page 8]
 451 \f