As per Relevance of the word forwarding, we have this rfc below:
Network Working Group C.
Request for Comments: 2004
Category: Standards Track October 1996
Minimal Encapsulation within
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
This document specifies a method by which an IP datagram may
encapsulated (carried as payload) within an IP datagram, with
overhead than "conventional" IP encapsulation that adds a second
header to each encapsulated datagram. Encapsulation is suggested
a means to alter the normal IP routing for datagrams, by
them to an intermediate destination that would otherwise not
selected by the (network part of the) IP Destination Address field
the original IP header. Encapsulation may be serve a variety
purposes, such as delivery of a datagram to a mobile node
Mobile IP
1.
This document specifies a method by which an IP datagram may
encapsulated (carried as payload) within an IP datagram, with
overhead than "conventional" IP encapsulation [4] that adds a
IP header to each encapsulated datagram. Encapsulation is
as a means to alter the normal IP routing for datagrams,
delivering them to an intermediate destination that would
not be selected by the (network part of the) IP Destination
field in the original IP header. The process of encapsulation
decapsulation of a datagram is frequently referred to as "tunneling
the datagram, and the encapsulator and decapsulator are
considered to be the the "endpoints" of the tunnel; the
node is refered to as the "entry point" of the tunnel, and
decapsulator node is refered to as the "exit point" of the tunnel
Perkins Standards Track [Page 1]
RFC 2004 Minimal Encapsulation for IP October 1996
2.
The Mobile IP working group has specified the use of encapsulation
a way to deliver packets from a mobile node's "home network" to
agent that can deliver datagrams locally by conventional means to
mobile node at its current location away from home [5]. The use
encapsulation may also be indicated whenever the source (or
intermediate router) of an IP datagram must influence the route
which a datagram is to be delivered to its ultimate destination
Other possible applications of encapsulation include multicasting
preferential billing, choice of routes with selected
attributes, and general policy routing
See [4] for a discussion concerning the advantages of
versus use of the IP loose source routing option. Using IP
to encapsulate IP datagrams requires the unnecessary duplication
several fields within the inner IP header; it is possible to
some additional space by specifying a new encapsulation
that eliminates the duplication. The scheme outlined here comes
the Mobile IP Working Group (in earlier Internet Drafts), and
similar to that which had been defined in [2].
3. Minimal
A minimal forwarding header is defined for datagrams which are
fragmented prior to encapsulation. Use of this encapsulating
is optional. Minimal encapsulation MUST NOT be used when an
datagram is already fragmented, since there is no room in the
forwarding header to store fragmentation information. To
an IP datagram using minimal encapsulation, the minimal
header is inserted into the datagram, as follows
+---------------------------+ +---------------------------+
| | | |
| IP Header | | Modified IP Header |
| | | |
+---------------------------+ ====> +---------------------------+
| | | Minimal Forwarding Header |
| | +---------------------------+
| IP Payload | | |
| | | |
| | | IP Payload |
+---------------------------+ | |
| |
+---------------------------+
Perkins Standards Track [Page 2]
RFC 2004 Minimal Encapsulation for IP October 1996
The IP header of the original datagram is modified, and the
forwarding header is inserted into the datagram after the IP header
followed by the unmodified IP payload of the original datagram (e.g.,
transport header and transport data). No additional IP header
added to the datagram
In encapsulating the datagram, the original IP header [6] is
as follows
- The Protocol field in the IP header is replaced by
number 55 for the minimal encapsulation protocol
- The Destination Address field in the IP header is replaced by
IP address of the exit point of the tunnel
- If the encapsulator is not the original source of the datagram
the Source Address field in the IP header is replaced by the
address of the encapsulator
- The Total Length field in the IP header is incremented by
size of the minimal forwarding header added to the datagram
This incremental size is either 12 or 8 octets, depending
whether or not the Original Source Address Present (S) bit is
in the forwarding header
- The Header Checksum field in the IP header is recomputed [6]
updated to account for the changes in the IP header
here for encapsulation
Note that unlike IP-in-IP encapsulation [4], the Time to
(TTL) field in the IP header is not modified during encapsulation
if the encapsulator is forwarding the datagram, it will
the TTL as a result of doing normal IP forwarding. Also,
the original TTL remains in the IP header after encapsulation
hops taken by the datagram within the tunnel are visible,
example, to "traceroute".
Perkins Standards Track [Page 3]
RFC 2004 Minimal Encapsulation for IP October 1996
The format of the minimal forwarding header is as follows
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol |S| reserved | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (if present) Original Source Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Copied from the Protocol field in the original IP header
Original Source Address Present (S
0 The Original Source Address field is not present.
length of the minimal tunneling header in this case
8 octets
1 The Original Source Address field is present.
length of the minimal tunneling header in this case
12 octets
Sent as zero; ignored on reception
Header
The 16-bit one's complement of the one's complement sum of
16-bit words in the minimal forwarding header. For purposes
computing the checksum, the value of the checksum field is 0.
The IP header and IP payload (after the minimal
header) are not included in this checksum computation
Original Destination
Copied from the Destination Address field in the original
header
Original Source
Copied from the Source Address field in the original IP header
This field is present only if the Original Source
Present (S) bit is set
Perkins Standards Track [Page 4]
RFC 2004 Minimal Encapsulation for IP October 1996
When decapsulating a datagram, the fields in the minimal
header are restored to the IP header, and the forwarding header
removed from the datagram. In addition, the Total Length field
the IP header is decremented by the size of the minimal
header removed from the datagram, and the Header Checksum field
the IP header is recomputed [6] or updated to account for the
to the IP header described here for decapsulation
The encapsulator may use existing IP mechanisms appropriate
delivery of the encapsulated payload to the tunnel exit point.
particular, use of IP options are allowed, and use of
is allowed unless the "Don't Fragment" bit is set in the IP header
This restriction on fragmentation is required so that nodes
Path MTU Discovery [3] can obtain the information they seek
4. Routing
The use of any encapsulation method for routing purposes brings
it increased susceptibility to routing loops. To cut down
danger, a router should follow the same procedures outlined in [4].
5. ICMP Messages from within the
ICMP messages are to be handled as specified in [4], including
maintenance of tunnel "soft state".
6. Security
Security considerations are not addressed in this document, but
generally similar to those outlined in [4].
7.
The original text for much of Section 3 was taken from the Mobile
draft [1]. Thanks to David Johnson for improving consistency
making many other improvements to the draft
Perkins Standards Track [Page 5]
RFC 2004 Minimal Encapsulation for IP October 1996
[1] Perkins, C., Editor, "IPv4 Mobility Support", Work in Progress
May 1995.
[2] David B. Johnson. Scalable and Robust Internetwork
for Mobile Hosts. In Proceedings of the 14th
Conference on Distributed Computing Systems, pages 2--11,
1994.
[3] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[4] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[5] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
October 1996.
[6] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
Author's
Questions about this memo can be directed to
Charles
Room H3-D34
T. J. Watson Research
IBM
30 Saw Mill River Rd
Hawthorne, NY 10532
Work: +1-914-784-7350
Fax: +1-914-784-6205
EMail: perk@watson.ibm.
The working group can be contacted via the current chair
Jim
Motorola, Inc
1301 E. Algonquin Rd
Schaumburg, IL 60196
Work: +1-847-576-2753
EMail: solomon@comm.mot.
Perkins Standards Track [Page 6]
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
