IP Encapsulation within IP
RFC 2003
|
Document |
Type |
|
RFC - Proposed Standard
(October 1996; Errata)
|
|
Author |
|
Charles Perkins
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 2003 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group C. Perkins
Request for Comment: 2003 IBM
Category: Standards Track October 1996
IP Encapsulation within IP
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
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 alter the normal IP routing
for datagrams, by delivering them to an intermediate destination that
would otherwise not be selected by the (network part of the) IP
Destination Address field in the original IP header. Encapsulation
may serve a variety of purposes, such as delivery of a datagram to a
mobile node using Mobile IP.
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 alter the normal IP routing
for datagrams, by delivering them to an intermediate destination that
would otherwise not be selected based on the (network part of the) IP
Destination Address field in the original IP header. Once the
encapsulated datagram arrives at this intermediate destination node,
it is decapsulated, yielding the original IP datagram, which is then
delivered to the destination indicated by the original Destination
Address field. This use of encapsulation and decapsulation of a
datagram is frequently referred to as "tunneling" the datagram, and
the encapsulator and decapsulator are then considered to be the
"endpoints" of the tunnel.
In the most general tunneling case we have
source ---> encapsulator --------> decapsulator ---> destination
with the source, encapsulator, decapsulator, and destination being
separate nodes. The encapsulator node is considered the "entry
Perkins Standards Track [Page 1]
RFC 2003 IP-within-IP October 1996
point" of the tunnel, and the decapsulator node is considered the
"exit point" of the tunnel. There in general may be multiple
source-destination pairs using the same tunnel between the
encapsulator and decapsulator.
2. Motivation
The Mobile IP working group has specified the use of encapsulation as
a way to deliver datagrams from a mobile node's "home network" to an
agent that can deliver datagrams locally by conventional means to the
mobile node at its current location away from home [8]. 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 of encapsulation include multicasting,
preferential billing, choice of routes with selected security
attributes, and general policy routing.
It is generally true that encapsulation and the IP loose source
routing option [10] can be used in similar ways to affect the routing
of a datagram, but there are several technical reasons to prefer
encapsulation:
- There are unsolved security problems associated with the use of
the IP source routing options.
- Current Internet routers exhibit performance problems when
forwarding datagrams that contain IP options, including the IP
source routing options.
- Many current Internet nodes process IP source routing options
incorrectly.
- Firewalls may exclude IP source-routed datagrams.
- Insertion of an IP source route option may complicate the
processing of authentication information by the source and/or
destination of a datagram, depending on how the authentication is
specified to be performed.
- It is considered impolite for intermediate routers to make
modifications to datagrams which they did not originate.
These technical advantages must be weighed against the disadvantages
posed by the use of encapsulation:
- Encapsulated datagrams typically are larger than source routed
datagrams.
Perkins Standards Track [Page 2]
RFC 2003 IP-within-IP October 1996
- Encapsulation cannot be used unless it is known in advance that
the node at the tunnel exit point can decapsulate the datagram.
Since the majority of Internet nodes today do not perform well when
IP loose source route options are used, the second technical
Show full document text