RFC relevance of encapsulation

As per Relevance of the word encapsulation, we have this rfc below:

Network Working Group S.
Request for Comments: 1701 NetSmiths, Ltd
Category: Informational T.
D.
P.
cisco
October 1994

Generic Routing Encapsulation (GRE

Status of this

This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited

This document specifies a protocol for performing encapsulation of
arbitrary network layer protocol over another arbitrary network
protocol

A number of different proposals [RFC 1234, RFC 1226] currently
for the encapsulation of one protocol over another protocol.
types of encapsulations [RFC 1241, SDRP, RFC 1479] have been
for transporting IP over IP for policy purposes. This memo
a protocol which is very similar to, but is more general than,
above proposals. In attempting to be more general, many
specific nuances have been ignored. The result is that this
is may be less suitable for a situation where a specific "X over Y
encapsulation has been described. It is the attempt of this
to provide a simple, general purpose mechanism which is reduces
problem of encapsulation from its current O(n^2) problem to a
manageable state. This proposal also attempts to provide
lightweight encapsulation for use in policy based routing. This
explicitly does not address the issue of when a packet should
encapsulated. This memo acknowledges, but does not address
with mutual encapsulation [RFC 1326].

In the most general case, a system has a packet that needs to
encapsulated and routed. We will call this the payload packet.
payload is first encapsulated in a GRE packet, which possibly
includes a route. The resulting GRE packet can then be
in some other protocol and then forwarded. We will call this

Hanks, Li, Farinacci & Traina [Page 1]

RFC 1701 Generic Routing Encapsulation (GRE) October 1994

protocol the delivery protocol. The algorithms for processing
packet are discussed later

Overall

The entire encapsulated packet would then have the form

---------------------------------
| |
| Delivery Header |
| |
---------------------------------
| |
| GRE Header |
| |
---------------------------------
| |
| Payload packet |
| |
---------------------------------

Packet

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
most significant bit, bit 15 is the least significant bit.
13 through 15 are reserved for the Version field. Bits 5
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
is present and contains valid information

If either the Checksum Present bit or the Routing Present bit
set, BOTH the Checksum and Offset fields are present in the
packet

Routing Present (bit 1)

If the Routing Present bit is set to 1, then it indicates that
Offset and Routing fields are present and contain
information

If either the Checksum Present bit or the Routing Present bit
set, BOTH the Checksum and Offset fields are present in the
packet

Key Present (bit 2)

If the Key Present bit is set to 1, then it indicates that the
field is present in the GRE header. Otherwise, the Key field
not present in the GRE header

Sequence Number Present (bit 3)

If the Sequence Number Present bit is set to 1, then it
that the Sequence Number field is present. Otherwise,
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
documents. It is recommended that this bit only be set to 1
all of the the Routing Information consists of Strict
Routes

Recursion Control (bits 5-7)

Recursion control contains a three bit unsigned integer
contains the number of additional encapsulations which
permissible. This SHOULD default to zero

Version Number (bits 13-15)

The Version Number field MUST contain the value 0. Other
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
packet. In general, the value will be the Ethernet protocol
field for the packet. Currently defined protocol types are
below. Additional values may be defined in other documents

Offset (2 octets

The offset field indicates the octet offset from the start of
Routing field to the first octet of the active Source Route
to be examined. This field is present if the Routing Present
the Checksum Present bit is set to 1, and contains
information only if the Routing Present bit is set to 1.

Checksum (2 octets

The Checksum field contains the IP (one's complement) checksum
the GRE header and the payload packet. This field is present
the Routing Present or the Checksum Present bit is set to 1,
contains valid information only if the Checksum Present bit is
to 1.

Key (4 octets

The Key field contains a four octet number which was inserted
the encapsulator. It may be used by the receiver to
the source of the packet. The techniques for
authenticity are outside of the scope of this document. The
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
which is inserted by the encapsulator. It may be used by
receiver to establish the order in which packets have
transmitted from the encapsulator to the receiver. The
algorithms for the generation of the Sequence Number and
semantics of their reception is outside of the scope of
document

Routing (variable

The Routing field is optional and is present only if the
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).
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
address family of type 0x0000 and a length of 0.

Address Family (2 octets

The Address Family field contains a two octet value which
the syntax and semantics of the Routing Information field.
values for this field and the corresponding syntax and semantics
Routing Information are defined in other documents

SRE Offset (1 octet

The SRE Offset field indicates the octet offset from the start of
Routing Information field to the first octet of the active entry
Source Route Entry to be examined

SRE Length (1 octet

The SRE Length field contains the number of octets in the SRE.
the SRE Length is 0, this indicates this is the last SRE in
Routing field

Routing Information (variable

The Routing Information field contains data which may be used
routing this packet. The exact semantics of this field is defined
other documents

Forwarding of GRE

Normally, a system which is forwarding delivery layer packets
not differentiate GRE packets from other packets in any way
However, a GRE packet may be received by a system. In this case,
system should use some delivery-specific means to determine that
is a GRE packet. Once this is determined, the Key, Sequence
and Checksum fields if they contain valid information as indicated
the corresponding flags may be checked. If the Routing Present

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
determine the semantics and use of the SRE Length, SRE Offset
Routing Information fields. The exact semantics for processing a
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
decremented (if one exists) and the payload packet should
forwarded as a normal packet. The exact forwarding method depends
the Protocol Type field

Current List of Protocol

The following are currently assigned protocol types for GRE.
protocol types must be taken from DIX ethernet encoding.
historical reasons, a number of other values have been used for
protocols. The following table of values MUST be used to
the following protocols

Protocol Family
--------------- -----
Reserved 0000
SNA 0004
OSI network layer 00
PUP 0200
XNS 0600
IP 0800
Chaos 0804
RFC 826 ARP 0806
Frame Relay ARP 0808
VINES 0
VINES Echo 0
VINES Loopback 0
DECnet (Phase IV) 6003
Transparent Ethernet Bridging 6558
Raw Frame Relay 6559
Apollo Domain 8019
Ethertalk (Appletalk) 809
Novell IPX 8137
RFC 1144 TCP/IP compression 876
IP Autonomous Systems 876
Secure Data 876
Reserved

See the IANA list of Ether Types for the complete list of
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

RFC 1479
Steenstrup, M. "Inter-Domain Policy Routing
Specification: Version 1", RFC1479, BBN Systems and Technologies
July 1993.

RFC 1226
Kantor, B. "Internet Protocol Encapsulation of AX.25 Frames",
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
Protocol: Version 1", RFC 1241, SAIC, University of Delaware,
1991.

RFC 1326
Tsuchiya, P., "Mutual Encapsulation Considered Dangerous",
1326, Bellcore, May 1992.

Estrin, D., Li, T., and Y. Rekhter, "Source Demand
Protocol Specification (Version 1)", Work in Progress

RFC 1702
Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Encapsulation over IPv4 networks", RFC 1702, NetSmiths, Ltd.,
cisco Systems, October 1994.

Security

Security issues are not discussed in this memo

Hanks, Li, Farinacci & Traina [Page 7]

RFC 1701 Generic Routing Encapsulation (GRE) October 1994

The authors would like to acknowledge Yakov Rekhter (IBM) and
Estrin (USC) for their advice, encouragement and insightful comments

Authors'

Stan
NetSmiths, Ltd
2025 Lincoln
Edison NJ, 08817

EMail: stan@netsmiths.

Tony
cisco Systems, Inc
1525 O'Brien
Menlo Park, CA 94025

EMail: tli@cisco.

Dino
cisco Systems, Inc
1525 O'Brien
Menlo Park, CA 94025

EMail: dino@cisco.

Paul
cisco Systems, Inc
1525 O'Brien
Menlo Park, CA 94025

EMail: pst@cisco.

Hanks, Li, Farinacci & Traina [Page 8]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX