merged branch accel-pptpd

1 files changed, 451 insertions, 0 deletions

diff --git a/rfc/rfc1701.txt b/rfc/rfc1701.txt
new file mode 100644
index 00000000..60a0e9b9
--- /dev/null
+++ b/rfc/rfc1701.txt
@@ -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]
+