As per Relevance of the word encapsulation, we have this rfc below:
Network Working Group D.
Request for Comments: 2784 T.
Category: Standards Track Procket
S.
Enron
D.
Cisco
P.
Juniper
March 2000
Generic Routing Encapsulation (GRE
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document specifies a protocol for encapsulation of an
network layer protocol over another arbitrary network layer protocol
1.
A number of different proposals [RFC1234, RFC1226] currently
for the encapsulation of one protocol over another protocol.
types of encapsulations [RFC1241, RFC1479] have been proposed
transporting IP over IP for policy purposes. This memo describes
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
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 reduces
problem of encapsulation from its current O(n^2) size to a
manageable size. This memo purposely does not address the issue
when a packet should be encapsulated. This memo acknowledges,
does not address problems such as mutual encapsulation [RFC1326].
Farinacci, et al. Standards Track [Page 1]
RFC 2784 Generic Routing Encapsulation March 2000
In the most general case, a system has a packet that needs to
encapsulated and delivered to some destination. We will call
the payload packet. The payload is first encapsulated in a
packet. The resulting GRE packet can then be encapsulated in
other protocol and then forwarded. We will call this outer
the delivery protocol. The algorithms for processing this packet
discussed later
Finally this specification describes the intersection of
currently deployed by multiple vendors
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as
in RFC 2119 [RFC2119].
2. Structure of a GRE Encapsulated
A GRE encapsulated packet has the form
---------------------------------
| |
| Delivery Header |
| |
---------------------------------
| |
| GRE Header |
| |
---------------------------------
| |
| Payload packet |
| |
---------------------------------
This specification is generally concerned with the structure of
GRE header, although special consideration is given to some of
issues surrounding IPv4 payloads
2.1. GRE
The GRE packet header has the form
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| Reserved0 | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Reserved1 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Farinacci, et al. Standards Track [Page 2]
RFC 2784 Generic Routing Encapsulation March 2000
2.2. Checksum Present (bit 0)
If the Checksum Present bit is set to one, then the Checksum and
Reserved1 fields are present and the Checksum field contains
information. Note that a compliant implementation MUST accept
process this field
2.3. Reserved0 (bits 1-12)
A receiver MUST discard a packet where any of bits 1-5 are non-zero
unless that receiver implements RFC 1701. Bits 6-12 are reserved
future use. These bits MUST be sent as zero and MUST be ignored
receipt
2.3.1. Version Number (bits 13-15)
The Version Number field MUST contain the value zero
2.4. Protocol Type (2 octets
The Protocol Type field contains the protocol type of the
packet. These Protocol Types are defined in [RFC1700] as "
TYPES" and in [ETYPES]. An implementation receiving a
containing a Protocol Type which is not listed in [RFC1700]
[ETYPES] SHOULD discard the packet
2.5. Checksum (2 octets
The Checksum field contains the IP (one's complement) checksum sum
the all the 16 bit words in the GRE header and the payload packet
For purposes of computing the checksum, the value of the
field is zero. This field is present only if the Checksum Present
is set to one
2.6. Reserved1 (2 octets
The Reserved1 field is reserved for future use, and if present,
be transmitted as zero. The Reserved1 field is present only when
Checksum field is present (that is, Checksum Present bit is set
one).
3. IPv4 as a
When IPv4 is being carried as the GRE payload, the Protocol
field MUST be set to 0x800.
Farinacci, et al. Standards Track [Page 3]
RFC 2784 Generic Routing Encapsulation March 2000
3.1. Forwarding Decapsulated IPv4 Payload
When a tunnel endpoint decapsulates a GRE packet which has an IPv
packet as the payload, the destination address in the IPv4
packet header MUST be used to forward the packet and the TTL of
payload packet MUST be decremented. Care should be taken
forwarding such a packet, since if the destination address of
payload packet is the encapsulator of the packet (i.e., the other
of the tunnel), looping can occur. In this case, the packet MUST
discarded
4. IPv4 as a Delivery
The IPv4 protocol 47 [RFC1700] is used when GRE packets
enapsulated in IPv4. See [RFC1122] for requirements relating to
delivery of packets over IPv4 networks
5. Interoperation with RFC 1701 Compliant
In RFC 1701, the field described here as Reserved0 contained a
of flag bits which this specification deprecates. In particular,
Routing Present, Key Present, Sequence Number Present, and
Source Route bits have been deprecated, along with the
Control field. As a result, the GRE header will never contain
Key, Sequence Number or Routing fields specified in RFC 1701.
There are, however, existing implementations of RFC 1701.
following sections describe correct interoperation with
implementations
5.1. RFC 1701 Compliant
An implementation complying to this specification will transmit
Reserved0 field set to zero. An RFC 1701 compliant receiver
interpret this as having the Routing Present, Key Present,
Number Present, and Strict Source Route bits set to zero, and
not expect the RFC 1701 Key, Sequence Number or Routing fields to
present
5.2. RFC 1701 Compliant
An RFC 1701 transmitter may set any of the Routing Present,
Present, Sequence Number Present, and Strict Source Route bits set
one, and thus may transmit the RFC 1701 Key, Sequence Number
Routing fields in the GRE header. As stated in Section 5.3, a
with non-zero bits in any of bits 1-5 MUST be discarded unless
receiver implements RFC 1701.
Farinacci, et al. Standards Track [Page 4]
RFC 2784 Generic Routing Encapsulation March 2000
6. Security
Security in a network using GRE should be relatively similar
security in a normal IPv4 network, as routing using GRE follows
same routing that IPv4 uses natively. Route filtering will
unchanged. However packet filtering requires either that a
look inside the GRE packet or that the filtering is done on the
tunnel endpoints. In those environments in which this is
to be a security issue it may be desirable to terminate the tunnel
the firewall
7. IANA
This section considers the assignment of additional GRE
Numbers and Protocol Types
7.1. GRE Version
This document specifies GRE version number 0. GRE version number 1
used by PPTP [RFC2637]. Additional GRE version numbers are
by IETF Consensus as defined in RFC 2434 [RFC2434].
7.2. Protocol
GRE uses an ETHER Type for the Protocol Type. New ETHER TYPES
assigned by Xerox Systems Institute [RFC1700].
8.
This document is derived from the original ideas of the authors
RFC 1701 and RFC 1702. Hitoshi Asaeda, Scott Bradner, Randy Bush
Brian Carpenter, Bill Fenner, Andy Malis, Thomas Narten, Dave Thaler
Tim Gleeson and others provided many constructive and
comments
Farinacci, et al. Standards Track [Page 5]
RFC 2784 Generic Routing Encapsulation March 2000
9. Appendix -- Known
This document specifies the behavior of currently deployed
implementations. As such, it does not attempt to address
following known issues
o Interaction Path MTU Discovery (PMTU) [RFC1191]
Existing implementations of GRE, when using IPv4 as the
Header, do not implement Path MTU discovery and do not set
Don't Fragment bit in the Delivery Header. This can cause
packets to become fragmented within the tunnel and reassembled
the tunnel exit (independent of whether the payload packet is
PMTU). If a tunnel entry point were to use Path MTU discovery
however, that tunnel entry point would also need to relay
unreachable error messages (in particular the "fragmentation
and DF set" code) back to the originator of the packet, which
not a requirement in this specification. Failure to properly
Path MTU information to an originator can result in the
behavior: the originator sets the don't fragment bit, the
gets dropped within the tunnel, but since the originator doesn'
receive proper feedback, it retransmits with the same PMTU,
subsequently transmitted packets to be dropped
o IPv6 as Delivery and/or Payload
This specification describes the intersection of GRE
deployed by multiple vendors. IPv6 as delivery and/or
protocol is not included in the currently deployed versions of GRE
o Interaction with
o Interaction with the Differentiated Services
o Multiple and Looping
10.
[ETYPES] ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet
[RFC1122] Braden, R., "Requirements for Internet hosts -
communication layers", STD 3, RFC 1122, October 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
Farinacci, et al. Standards Track [Page 6]
RFC 2784 Generic Routing Encapsulation March 2000
[RFC1226] Kantor, B., "Internet Protocol Encapsulation of AX.25
Frames", RFC 1226, May 1991.
[RFC1234] Provan, D., "Tunneling IPX Traffic through IP Networks",
RFC 1234, June 1991.
[RFC1241] Woodburn, R. and D. Mills, "Scheme for an
Encapsulation Protocol: Version 1", RFC 1241, July 1991.
[RFC1326] Tsuchiya, P., "Mutual Encapsulation Considered Dangerous",
RFC 1326, May 1992.
[RFC1479] Steenstrup, M., "Inter-Domain Policy Routing
Specification: Version 1", RFC 1479, July 1993.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
1700, October 1994.
[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "
Routing Encapsulation", RFC 1701, October 1994.
[RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "
Routing Encapsulation over IPv4 networks", RFC 1702,
October 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March, 1997.
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner
"Internet Security Association and Key Management
(ISAKMP)", RFC 2408, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October, 1998.
[RFC2637] Hamzeh, K., et al., "Point-to-Point Tunneling
(PPTP)", RFC 2637, July, 1999.
Farinacci, et al. Standards Track [Page 7]
RFC 2784 Generic Routing Encapsulation March 2000
11. Authors'
Dino
Procket
3850 No. First St., Ste.
San Jose, CA 95134
EMail: dino@procket.
Tony
Procket
3850 No. First St., Ste.
San Jose, CA 95134
Phone: +1 408 954 7903
Fax: +1 408 987 6166
EMail: tony1@home.
Stan
Enron
EMail: stan_hanks@enron.
David
Cisco Systems, Inc
170 Tasman
San Jose, CA, 95134
EMail: dmm@cisco.
Paul
Juniper
EMail: pst@juniper.
Farinacci, et al. Standards Track [Page 8]
RFC 2784 Generic Routing Encapsulation March 2000
12. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Farinacci, et al. Standards Track [Page 9]
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
