Internet Engineering Task Force C. Perkins
INTERNET DRAFT IBM
06 July 1995
Minimal Encapsulation within IP
draft-ietf-minenc-00.txt
Status of This Memo
This document is a submission by the Mobile-IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the mobile-ip@tadpole.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents
at any time. It is not appropriate to use Internet Drafts as
reference material, or to cite them other than as a ``working draft''
or ``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the internet-drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
This document specifies a method by which an IP datagram may
be encapsulated (carried as payload) within an IP datagram.
Encapsulation is suggested as a means to effect "re-addressing"
datagrams (i.e, delivering them to an intermediate destination other
than that specified in the IP destination field) for any of a variety
of reasons, but particularly those useful for adherence to the
mobile-IP specification.
Perkins Expires 06 January 1996 [Page i]
Internet Draft Minimal Encapsulation for IP 06 July 1995
1. Introduction
This document specifies a method by which an IP datagram may
be encapsulated (carried as payload) within an IP datagram.
Encapsulation is suggested as a means to effect "re-addressing"
datagrams -- that is, delivering them to an intermediate destination
other than that specified in the IP destination field. The process
of encapsulation and decapsulation a datagram is frequently referred
to as "tunneling" the datagram, and the encapsulator and decapsulator
are then considered to be the the "endpoints" of the tunnel.
2. Motivation
The mobile-IP working group has specified the use of encapsulation as
a way to deliver packets from a mobile host's "home network" to an
agent which can deliver packets to the mobile host by conventional
means [1]. The use of encapsulation may also be desirable whenever
the source (or an intermediate router) of an IP datagram must
influence the route by which a datagram is to be delivered to
its ultimate destination. Other possible applications include
preferential billing, choice of routes with selected security
attributes, and general policy routing.
See [4] for a discussion concerning the advantages of encapsulation
versus source routing. Since using IP headers to encapsulate IP
datagrams requires the unwarranted duplication of several fields
within the inner IP header, it is possible to save some additional
space by specifying a new encapsulation mechanism that eliminates
the duplication. The scheme outlined in this protocol specification
comes from the mobile-IP working group (in earlier Internet Drafts),
and is similar to that outlined in [2].
3. Minimal Encapsulation
A minimal forwarding header is defined for datagrams which are not
fragmented prior to encapsulating. Use of this encapsulating method
is optional. Minimal encapsulation must not be used when an original
datagram is already fragmented, since there is no room in the inner
header to store fragmentation information.
Perkins Expires 06 January 1996 [Page 1]
Internet Draft Minimal Encapsulation for IP 06 July 1995
The minimal encapsulation process produces a datagram structured as
shown below; the IP header of the original datagram is modified, then
followed by the minimal forwarding header, followed by the unmodified
IP payload of the original datagram.
+---------------------------+ +---------------------------+
| IP Header | | Modified IP Header |
+---------------------------+ ====> +---------------------------+
| | | Minimal Forwarding Header |
| IP Payload | +---------------------------+
| | | |
+---------------------------+ | IP Payload |
| |
+---------------------------+
Encapsulation is performed as follows. The protocol field in
the IP header is replaced by protocol number 55 for the minimal
encapsulation protocol. The destination field in the IP header
is replaced by the care-of address of the mobile node. If the
encapsulating agent is not the original source of the datagram, the
source field in the IP header is replaced by the IP address of the
encapsulating agent.
When decapsulating a datagram, the fields in the forwarding header
are restored to the IP header, and the forwarding header is removed
from the datagram.
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 Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Original Destination Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol
Copied from the protocol field in the original IP header.
Perkins Expires 06 January 1996 [Page 2]
Internet Draft Minimal Encapsulation for IP 06 July 1995
S
Source field present bit, which indicates that the Original
Source Address field is present.
0 not present.
1 present.
reserved
Sent as zero; ignored on reception.
Header Checksum
The 16-bit one's complement of the one's complement sum of the
encapsulation header. For computing the checksum, the checksum
field is set to 0.
Original Destination Address
Copied from the destination field in the original IP header.
Original Source Address
Copied from the source field in the original IP header.
Present only if the S-bit is set.
The encapsulating agent is free to use existing IP mechanisms
appropriate for delivery of the encapsulated payload to the tunnel
endpoint. In particular, this means that use of IP options and
fragmentation are allowed, unless the "Don't Fragment" bit is set in
the inner IP header. This is required so that hosts employing Path
MTU discovery [3] can obtain the information they seek.
4. ICMP messages from within the tunnel
The following discussion, included here for convenience, is the same
as that in [4].
After an encapsulated datagram has been sent, the encapsulating
agent may receive an ICMP message from any intermediate router
within the tunnel, except for the tunnel endpoint. The action taken
by the encapsulating agent depends on the type of ICMP message
received. In many cases, the encapsulating agent will use the
incoming message to create a similar ICMP message, which then is
sent to the originator of the inner IP datagram. This process will
Perkins Expires 06 January 1996 [Page 3]
Internet Draft Minimal Encapsulation for IP 06 July 1995
be referred to as "relaying" the ICMP message to the source of the
original uncapsulated datagram.
4.1. Destination Unreachable
Destination Unreachable messages are handled depending upon their
type. The model suggested here allows the tunnel to "extend" a
network to include non-local (e.g, mobile) hosts. Thus, if the
original destination in the unencapsulated datagram is on the same
network as the encapsulating agent, certain Destination Unreachable
codes may be modified to conform to the suggested model.
Code 0
A Destination Unreachable message may be returned to
the original sender. If the original destination in
the unencapsulated datagram is on the same network as
the encapsulating agent, the newly generated Destination
Unreachable message sent by the encapsulating agent can have
type 1, since presumably the packet arrived to the correct
network and the encapsulating agent is trying to create the
appearance that the original destination is local even if
it's not. Otherwise, the encapsulating agent must return a
Destination Unreachable with code 0 message to the original
sender.
Code 1
The encapsulating agent must relay Destination Unreachable
messages of code 1 (host unreachable) to the source of the
original unencapsulated datagram.
Code 2
When the encapsulating agent receives a Destination Unreachable
ICMP message with code 2 (protocol unreachable) it should
send a Destination Unreachable message with code 0 or 1 (see
the discussion for code 0) to the sender of the original
unencapsulated datagram. Since the original sender did not
necessarily use protocol 4, it would be meaningless to return
code 2 to that sender.
Code 3
This code (port unreachable) should never be received by the
encapsulating agent, since the outer IP header does not refer
Perkins Expires 06 January 1996 [Page 4]
Internet Draft Minimal Encapsulation for IP 06 July 1995
to any port number. It must not be relayed to the source of
the original unencapsulated datagram.
Code 4
The encapsulating agent must relay Destination Unreachable
messages of code 4 (fragmentation needed and DF set) to the
source of the original unencapsulated datagram.
Code 5
This code (source route failed) should be treated by the
encapsulating agent itself. It must not be relayed to the
source of the original unencapsulated datagram.
4.2. Time Exceeded
The encapsulating agent may relay Time Exceeded messages to the
source of the original unencapsulated datagram.
4.3. Parameter Problem
If the parameter problem points to a field copied from the original
unencapsulated datagram, the encapsulating agent may relay the ICMP
message to the source; otherwise, if the problem occurs with an IP
option inserted by the encapsulating agent, then the encapsulating
agent must not relay the ICMP message to the source. Note that an
encapsulating agent following prevalent current practice will never
insert any IP options into the encapsulated datagram.
4.4. Redirect
The encapsulating agent may act on the Redirect message if it is
possible, but it should not relay the Redirect back to the source
of the datagram which was encapsulated. Acting upon the Redirect
message would require that the encapsulating agent maintain storage
for encapsulated packets, and this may be an unpopular design choice
for many purposes.
4.5. Source Quench
The encapsulating agent may relay Source Quench messages to the
source of the original unencapsulated datagram.
Perkins Expires 06 January 1996 [Page 5]
Internet Draft Minimal Encapsulation for IP 06 July 1995
4.6. Other messages
Other ICMP messages are not related to the encapsulation operations
described within this protocol specification, and should be acted on
as specified in [5].
5. Security Considerations
Security considerations are not addressed in this document.
6. Acknowledgements
The text for most of section 3 was taken from the mobile-IP
draft [1].
References
[1] IETF Mobile-IP Working Group. IPv4 Mobility Support.
ietf-draft-mobileip-protocol-10.txt -- work in progress, May
1995.
[2] David B. Johnson. Scalable and Robust Internetwork Routing
for Mobile Hosts. In Proceedings of the 14th International
Conference on Distributed Computing Systems, pages 2--11, June
1994.
[3] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191, November
1990.
[4] Charles Perkins. IP Encapsulation within IP. Internet Draft --
work in progress, July 1995.
[5] J. Postel. Internet Control Message Protocol. RFC 792,
September 1981.
Author's Address
Questions about this memo can be directed to:
Charles Perkins
Room J1-A25
T. J. Watson Research Center
IBM Corporation
30 Saw Mill River Rd.
Perkins Expires 06 January 1996 [Page 6]
Internet Draft Minimal Encapsulation for IP 06 July 1995
Hawthorne, NY 10532
Work: +1-914-784-7350
Fax: +1-914-784-7007
E-mail: perk@watson.ibm.com
The working group can be contacted via the current chairs:
Jim Solomon Tony Li
Motorola, Inc. cisco systems
1301 E. Algonquin Rd. 170 W. Tasman Dr.
Schaumburg, IL 60196 San Jose, CA 95134
Work: +1-708-576-2753 Work: +1-408-526-8186
E-mail: solomon@comm.mot.com E-mail: tli@cisco.com
Perkins Expires 06 January 1996 [Page 7]
