Scheme for an internet encapsulation protocol: Version 1
How a datagram is carried across an encapsulation space in a tunnel, without the sender knowing the path.
Woodburn, R.A. and D.L. Mills, "Scheme for an internet encapsulation protocol: Version 1", RFC 1241, DOI 10.17487/RFC1241, July 1991, <https://www.rfc-editor.org/info/rfc1241>.
@misc{rfc1241,
series = {Request for Comments},
number = 1241,
howpublished = {RFC 1241},
publisher = {RFC Editor},
doi = {10.17487/RFC1241},
url = {https://www.rfc-editor.org/info/rfc1241},
author = {R.A. Woodburn and D.L. Mills},
title = {{Scheme for an internet encapsulation protocol: Version 1}},
pagetotal = 17,
year = 1991,
month = jul,
} RFC text
Contents
Network Working Group R. Woodburn
Request for Comments: 1241 SAIC
D. Mills
University of Delaware
July 1991
A Scheme for an Internet Encapsulation Protocol:
Version 1
1. Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are requested.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
2. Glossary
Clear Datagram -
The unmodified IP datagram in the User Space before
Encapsulation.
Clear Header -
The header portion of the Clear Datagram before
Encapsulation. This header includes the IP header and
possibly part or all of the next layer protocol header,
i.e., the TCP header.
Decapsulation -
The stripping of the Encapsulation Header and forwarding
of the Clear Datagram by the Decapsulator.
Decapsulator -
The entity responsible for receiving an Encapsulated
Datagram, decapsulating it, and delivering it to the
destination User Space. Delivery may be direct, or via
Encapsulation. A Decapsulator may be a host or a gateway.
Encapsulated Datagram -
The datagram consisting of a Clear Datagram prepended with
an Encapsulation Header.
Encapsulation -
The process of mapping a Clear Datagram to the
Encapsulation Space, prepending an Encapsulation Header to
the Clear Datagram and routing the Encapsulated Datagram
to a Decapsulator.
Encapsulation Header -
The header for the Encapsulation Protocol prepended to the
Clear Datagram during Encapsulation. This header consists
of an IP header followed by an Encapsulation Protocol
Header.
Encapsulation Protocol Header -
The Encapsulation Protocol specific portion of the
Encapsulation Header.
Encapsulation Space -
The address and routing space within which the
Encapsulators and Decapsulators reside. Routing within
this space is accomplished via Flows. Encapsulation
Spaces do not overlap, that is, the address of any
Encapsulator or Decapsulator is unique for all
Encapsulation Spaces.
Encapsulator -
The entity responsible for mapping a given User Space
datagram to the Encapsulation Space, encapsulating the
datagram, and forwarding the Encapsulated Datagram to a
Decapsulator. An Encapsulator may be a host or a gateway.
Flow -
Also called a "tunnel." A flow is the end-to-end path in
the Encapsulation Space over which Encapsulated Datagrams
travel. There may be several Encapsulator/Decapsulator
pairs along a given flow. Note that a Flow does not
denote what User Space gateways are traversed along the
path.
Flow ID -
A 32-bit identifier which uniquely distinguishes a flow in
a given Encapsulator or Decapsulator. Flow IDs are
specific to a single Encapsulator/Decapsulator Entity and
are not global quantities.
Mapping Function -
This is the function of mapping a Clear Header to a
particular Flow. All encapsulators along a given Flow are
required to map a given Clear Header to the same Flow.
User Address -
The address or identifier uniquely identifying an entity
within a User Space.
Source Route -
A complete end-to-end route which is computed at the
source and enumerates transit gateways.
User Space -
The address and routing space within which the users
reside. Routing within this space provides reachability
between all address pairs within the space. User Spaces
do not overlap, that is, a given User Address is unique in
all User Spaces.
3. Background
For several years researchers in the Internet community have needed a
means of "tunneling" between networks. A tunnel is essentially a
Source Route that circumvents conventional routing mechanisms.
Tunnels provide the means to bypass routing failures, avoid broken
gateways and routing domains, or establish deterministic paths for
experimentation.
There are several means of accomplishing tunneling. In the past,
tunneling has been accomplished through source routing options in the
IP header which allow gateways along a given path to be enumerated.
The disadvantage of source routing in the IP header is that it
requires the source to know something about the networks traversed to
reach the destination. The source must then modify outgoing packets
to reflect the source route. Current routing implementations
generally don't support source routes in their routing tables as a
means of reaching an IP address, nor do current routing protocols.
Another means of tunneling would be to develop a new IP option. This
option field would be part of a separate IP header that could be
prepended to an IP datagram. The IP option would indicate
information about the original datagram. This tunneling option has
the disadvantage of significantly modifying existing IP
implementations to handle a new IP option. It also would be less
flexible in permitting the tunneling of other protocols, such as ISO
protocols, through an IP environment. An even less palatable
alternative would be to replace IP with a new networking protocol or
a new version of IP with tunneling built in as part of its
functionality.
A final alternative is to create a new IP encapsulation protocol
which uses the current IP header format. By using encapsulation, a
destination can be reached transparently without the source having to
know topology specifics. Virtual networks can be created by tying
otherwise unconnected machines together with flows through an
encapsulation space.
++++++ Clear Datagram
****** Encapsulated
Datagram
#
Encapsulator/Decapsulator
& User Space Host
User Space A User Space C
-------------- -----------
/ \ / \
/ \ / \
| | | |
| & | | |
| + +++++ | | ***** |
| +++++ + | | * * |
| + | | ***** * |
\ + / ----------- \ * * / ----------
\ ++> # * **> # * ***> # ++++ \
-------------- / * * \ ------------ / + \
| * * | | + |
| * * | | + |
| ***** * | | +++++++ |
| ***** | | V |
| | | & |
\ / \ /
\ / \ /
----------- ----------
Encapsulation User
Space B Space D
Fig. 1. Encapsulation Architectural Model
Up until now, there has been no standard for an encapsulation
protocol. This RFC provides a means of performing encapsulation in
the Internet environment.
4. Architecture and Approach
The architecture for encapsulation is based on two entities -- an
Encapsulator and a Decapsulator. These entities and the associated
spaces are shown in Fig. 1.
Encapsulators and Decapsulators have addresses in the User Spaces to
which they belong, as well as addresses in the Encapsulation Spaces
to which they belong. An encapsulator will receive a Clear Datagram
from its User Space, and after determining that encapsulation should
be used, perform a mapping function which translates the User Space
information in the Clear Header to an Encapsulation Header. This
Encapsulation Header is then prepended to the Clear Datagram to form
the Encapsulated Datagram, as in Fig 2. It is desirable that the
encapsulation process be transparent to entities in the User Space.
Only the Encapsulator need know that encapsulation is occurring.
+---------------+-----------------+--------+----------------+
| Encapsulating | Encapsulation | Clear | Remainder of |
| IP Header | Protocol Header | Header | Clear Datagram |
+---------------+-----------------+--------+----------------+
| | |
| Encapsulation Header | Clear Datagram |
| | |
Fig. 2. Example of an Encapsulated Datagram
The Encapsulator forwards the datagram to a Decapsulator whose
identity is determined at the time of encapsulation. The
Decapsulator receives the Encapsulated Datagram and removes the
Encapsulation Header and treats the Clear Datagram as if it were
received locally. The requirement for the address of the
Decapsulator is that it be reachable from the Encapsulator's
Encapsulation Space address.
5. Generation of the Encapsulation Header
The contents of the Encapsulation Header are generated by performing
a mapping function from the Clear Header to the contents of the
Encapsulation Header. This mapping function could take many forms,
but the end result should be the same. The following paragraphs
describe one method of performing the mapping. The process is
illustrated in Fig. 3.
In the first part of the mapping function, the Clear Header is
matched with stored headers and masks to determine a Flow ID. This
is essentially a "mask-and-match" table look up, where the lookup
table holds three entries, a Clear Header, a header mask, and a
corresponding Flow ID. The mask can be used for allowing a range of
source and destination addresses to map to a given flow. Other
fields, such as the IP TOS bits or even the TCP source or destination
port addresses could also be used to discriminate between Flows.
This flexibility allows many possibilities for using the mapping
function. Not only can a given network be associated with a
particular flow, but even a particular TCP protocol or connection
could be distinguished from another.
How the lookup table is built and maintained is not part of this
protocol. It is assumed that it is managed by some higher layer
entity. It would be sufficient to configure the tables from ascii
text files if necessary.
+--------+
| |
+->| Encap. |--+
| | Info. | |
+-------+ | | Table | |
| Mask | +---------+ | | | |
Clear --+-->| & |-->| Flow ID |---+ | | |
Header | | Match | +---------+ +--------+ |
| +-------+ |
| +--> Encap
+-----------------------------------------------> Header
Fig. 3. Generation of the Encapsulation Header
The Flow IDs are managed at a higher layer as well. An example of
how Flow IDs can be managed is found in the Setup protocol of the
Inter-Domain Policy Sensitive Routing Protocol (IDPR). [4] The upper
layer protocol would be responsible for maintaining information not
carried in the encapsulation protocol related to the flow. This
could include the information necessary to construct the
Encapsulation Header (described below) as well as information such as
the type of data being encapsulated (currently only IP is defined),
and the type of authentication used if any. Note that IDPR Setup
requires the use of a longer Flow ID which is unique for the entire
universe of Encapsulators and is the same at every Encapsulator.
The Flow ID that results from the mapping of a Clear Header is a 32
bit quantity and identifies the Flow as it is seen by the
Encapsulator. If a Clear Datagram must be encapsulated and
decapsulated several times in order reach the destination, the Flow
ID may be different at each Encapsulator, but need not be. The Flow
ID acts as an index into a table of Encapsulation Header information
that is used to build the Encapsulation Header. Note that the
decision to make the Flow ID local to the Encapsulator is due to the
difficulty in choosing and maintaining globally unique identifiers.
The intermediate step of using a Flow ID entirely optional. The
important requirement is that all Encapsulators along a Flow map the
same Clear Header to the same Flow (which could be identified by
different identifiers along the way). However, by allowing for a
Flow ID in the protocol, a more efficient implementation of the
mapping function becomes possible. This is discussed in more detail
when we consider the Decapsulator.
The following information is required to construct the Encapsulation
Header:
Flow ID -
This is the key for this table of information and
represents the Flow ID relative to the current
Encapsulator.
Decapsulator Address -
The IP address of the Decapsulator in the Encapsulation
Space must be known to build the IP portion of the
Encapsulation Header.
Decapsulator's Flow ID -
The Flow ID, if any, for the Flow as seen by the
Decapsulator must be known.
Previous Encapsulator's Address -
If this is not the first Encapsulator along the Flow, the
previous Encapsulator's address must be known for error
reporting.
Previous Encapsulator's Flow ID -
In addition to the previous Encapsulator's address, the
Flow ID of the Flow relative to the previous Encapsulator
must be known.
The Encapsulation Header consists of an IP Header as well as an
Encapsulation Protocol Header. The two pieces of information
required for the Encapsulation Protocol Header which must be
determined at the time of encapsulation are the protocol which is
being encapsulated and the Flow ID to send to the Decapsulator. The
generation of the IP header is more complicated.
There are two possible ways each field in the Clear Header could
related to the new IP header.
Copy -
Copy the existing field from the Clear Header to the IP
header in the Encapsulation Header.
Ignore -
The field may or may not have existed in the Clear Header,
but does not apply to the new IP header.
The IP header has a fixed portion and a variable portion, the options
list. A summary of all possible IP fields and the relation to the
Clear Header follows in Table 1. [2]
Note that most of the fields in the Clear Header are simply ignored.
Fields such as the Header Length in the Clear Header have no effect
on the Header Length of the new IP header. The fields which are more
interesting and require some thought are now discussed.
The Quality of Service bits should be copied from the Clear Header to
the new IP header. This is in keeping with the transparency
principle that if the User Space was providing a given service, then
the Encapsulation Space must provide the same service.
The More Fragments bit and Fragment Offset should not be copied,
since the datagram being built is a complete datagram, regardless of
the status of the encapsulated datagram. If the completed datagram
is too large for the interface, it will be fragmented for
transmission to the decapsulator by the normal IP fragmentation
mechanism.
The Don't Fragment bit should not be copied into the Encapsulation
Header. The transparency principle would again be violated. It
should be up to the Encapsulator to decide whether fragmentation
should be allowed across the Encapsulation Space. If it is decided
that the DF bit should be used, then ICMP message would be returned
if the Encapsulated Datagram required fragmentation across the
Encapsulation Space The mechanism for returning an ICMP message to
the source in the User space will have to be modified, however, and
this is discussed in the Appendix B.
Regarding the Time To Live (TTL) field, the easiest thing to do is to
ignore the TTL from the Clear Header. If this field were copied from
the Clear Header to the new IP header, the packet life might be
prematurely exceeded during transit in the Encapsulation Space. This
breaks the transparency rule of encapsulation as seen from the User
Space. The TTL of the Clear Header is decremented before
encapsulation by the IP forwarding function, so there is no chance of
a packet looping forever if the links of a Flow form a loop.
+---------------------+---------+
| Field | Mapping |
+---------------------+---------+
| Version | Ignore |
| Header Length | Ignore |
| Precedence | Copy |
| QoS bits | Copy |
| Total Length | Ignore |
| Identification | Ignore |
| Don't Fragment Bit | Ignore |
| More Fragments Bit | Ignore |
| Fragment Offset | Ignore |
| Time to Live | Ignore |
| Protocol | Ignore |
| Header Checksum | Ignore |
| Source Address | Ignore |
| Destination Address | Ignore |
| End of Option List | Ignore |
| NOP Option | Ignore |
| Security Option | Copy |
| LSR Option | Ignore |
| SSR Option | Ignore |
| RR Option | Ignore |
| Stream ID Option | Ignore |
| Timestamp Option | Ignore |
+---------------------+---------+
Table 1. Summary of IP Header Mappings
The protocol field for the new IP header should be filled with the
protocol number of the encapsulation protocol.
The source address in the new IP header becomes the IP address of the
Encapsulator in the Encapsulation Domain. The destination address
becomes the IP address of the Decapsulator as found in the
encapsulation table.
IP Options are generally not copied because most don't make sense in
the context of the Encapsulation Space, as the transparency principle
would indicate. The security option is probably the one option that
should get copied for the same reason QOS and precedence fields are
copied, the Encapsulation Space must provide the expected service.
Timestamp, Loose Source Route, Strict Source Route, and Record Route
are not copied during encapsulation.
6. Decapsulation
In the ideal situation, a Decapsulator receives an Encapsulated
Datagram, strips off the Encapsulation Header and sends the Clear
Datagram back into IP so that it is forwarded from that point.
However, if the Clear Datagram has not reached the destination User
Space, it must again be encapsulated to move it close to the
destination User Space. In this latter case the Decapsulator would
become an Encapsulator and would perform the same calculation to
generate the Encapsulation Header as did the previous Encapsulator.
In order to make this process more efficient, the use of Flow IDs
have been incorporated into the protocol.
When Flow IDs are used, the Flow ID received in the Encapsulation
Header corresponds to a stored Flow ID in the Decapsulator. At this
point the Decapsulator has the option of bypassing the mask and match
operation on the Clear Header. The received Flow ID can be used to
point directly into the local Encapsulator tables for the
construction of the next Encapsulation Header. If the Flow ID is
unknown, an error message is sent back to the previous Encapsulator
to that effect and a signal is sent to upper layer entity managing
the encapsulation tables.
Because the normal IP forwarding mechanism is being bypassed when
Flow IDs are used, certain mechanisms normally handled by IP must be
taken care of by the Decapsulator before encapsulation. The
Decapsulator must decrement the TTL before the next encapsulation
occurs. If a Time Exceeded error occurs, then an ICMP message is
sent to the source indicated in the Clear Header.
7. Error Messages
There are two kinds of error message built into the encapsulation
protocol. The first is used to report unknown flow identifiers seen
by a Decapsulator and the second is for the forwarding of ICMP
messages.
When a Decapsulator is using the received Flow ID in an Encapsulation
Header to forward a datagram to the next Decapsulator in a Flow, it
is possible that the Flow ID may not be known. For this case the
Decapsulator will notify the previous Encapsulator that the Flow was
not known so that the problem may be reported to the layer
responsible for the programming of the Flow tables. This is
accomplished through an encapsulation error message.
If an Encapsulator receives an ICMP messages regarding a given flow,
this message should be forwarded backwards along the flow to the
source Encapsulator. This is accomplished by the second kind of
error message. The ICMP message will contain the Flow ID of the
message which caused the error. This Flow ID must be translated to
the Flow ID relative to the Encapsulator to which the error message
is sent.
If an error occurs while sending any error message, no further error
message are generated.
8. References
[1] J. Postel, Internet Control Message Protocol, RFC 792,
September 1981.
[2] J. Postel, Internet Protocol, RFC 791, September 1981.
[3] J. Postel, Transmission Control Protocol, RFC 793, September
1981.
[4] ORWG, Inter-Domain Policy Routing Protocol Specification and
Usage, Draft, August 1990
A. Packet Formats
This section describes the packet formats for the encapsulation
protocol.
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | HL | MT | RC | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. A.1. Encapsulation Protocol Header Example
Vers 4 bits The version number of the encapsulation
protocol. The version of the protocol
described by this document is 1.
HL 4 bits The header length of the Encapsulation
Protocol Header in octets.
MT 4 bits The message type of the Encapsulation
Protocol message. A data message has a
message type of 1. An error message has a
message type of 2.
RC 4 bits The reason code. This field is unused in the
Data Message and must have a value of 0. In
the Error Message it contains the reason code
for the Error Message. Defined reason code
values are:
1 Unknown Flow ID
2 ICMP returned
Checksum 16 bits A one's complement checksum for the
Encapsulation Protocol Header. This field is
set to 0 upon calculation of the checksum and
is filled with the checksum calculation
result before the data message is sent.
Flow ID 32 bits The Flow ID as seen by the Decapsulator or
Encapsulator to which this message is being
sent. In the case of an Unknown Flow ID
error, the Flow ID causing the error is used.
For Data Messages, the Encapsulation Protocol Header is followed by the
Clear Datagram. For Error Messages, the header is followed by the ICMP
message being forwarded along a flow.
B. Encapsulation and Existing IP Mechanisms
This section discusses in detail the effect of this encapsulation
protocol upon the existing mechanisms available with IP and some the
possible effects of IP mechanisms upon this protocol. Specifically
these are Fragmentation and ICMP messages.
B.1 Fragmentation and Maximum Transmission Unit
An immediate concern of using an encapsulation mechanism is that of
restrictions based upon MTU size. The source of a Clear Datagram is
going to generate packets consistent with MTU of the interface over
which datagram is transmitted. If these packets reach an
Encapsulator and are encapsulated, they may be fragmented if they are
larger than the MTU of the Encapsulator, even though the physical
interfaces of the source and Encapsulator may have the same MTU.
Because the Encapsulated Datagram is sent to the Decapsulator using
IP, there is no problem in allowing IP to perform fragmentation and
reassembly. However, fragmentation is known to be inefficient and is
generally avoided. Because a new header is being prepended to the
Clear Datagram by the encapsulation process, the likelihood of
fragmentation occurring is increased. If the Encapsulator decides to
disallow fragmentation through the Encapsulation Space, it must send
an ICMP message back to the source. This means that the MTU of the
interface in the encapsulation space is effectively smaller than that
of the physical MTU of the interface.
Fragmentation by intermediate User Space Gateways introduces another
problem. Fragmentation occurs at the IP level. If a TCP protocol is
in use and fragmentation occurs, the TCP header is contained in the
first fragment, but not the following fragments. [3] If these
fragments are forwarded by an Encapsulator, discrimination of the
Clear Header for a given flow will only be able to occur on the IP
header portion of the Clear Header. If discrimination is attempted
on the TCP portion of the header, then only the first fragment will
be matched, while remaining fragments will not.
B.2 ICMP Messages
The most controversial aspect of encapsulation is the handling of
ICMP messages. [1] Because the Encapsulation Header contains the
source address of the Encapsulator in the Encapsulation Space, ICMP
messages which occur within the Encapsulation Space will be sent back
to the Encapsulator. Once the Encapsulator receives the ICMP
message, the question is what should the next action be. Since the
original source of the Clear Datagram knows nothing about the
Encapsulation Space, it does not make sense to forward an ICMP
message on to it and ICMP message are not supposed to beget ICMP
messages. Yet not sending the original source something may break
some important mechanisms.
In addition to deciding what to forward to the source of the Clear
Datagram, there is the problem of possibly not having enough
information to send anything at all back to the source. An ICMP
message returns the header of the offending message and the first
eight octets of the data after the header. For the case of the
encapsulation protocol, this translates to the IP portion of the
Encapsulation Header, the first eight octets of the Encapsulation
Protocol Header, and nothing else. The contents of the Clear
Datagram are completely lost. Therefore, for the Encapsulator to
send an ICMP message back to the source it has to reconstruct the
Clear Header. However, it is essentially impossible to reproduce the
exact header.
For the purpose of this specification, the Flow ID has been assumed
to be a unique one way mapping from a Clear Header. There is no
guarantee that the Flow ID could be used to map back to the Clear
Header, since several headers potentially map to the same flow. With
there being no effective way to regenerate the original datagram,
some compromises must be examined.
For each of the possible ICMP messages, the alternatives and impact
will be assessed. There are three categories of ICMP message
involved. The first is those ICMP messages which are not applicable
in the context of Encapsulation. These are: Echo/Echo Reply and
Timestamp/Timestamp Reply.
The second category are those ICMP messages which concern mechanisms
local to the encapsulation domain. These are messages which would
not make sense to the original source if it did receive them. In
these cases the encapsulator will have to decide what to do, but no
ICMP message need be sent back to the original source. The datagram
will simply be lost, IP is not meant to be a reliable protocol.
Subsequent messages received for encapsulation may cause the
encapsulator to generate ICMP Destination Unreachable messages back
to the original source if the encapsulator can no longer send
messages to the destination decapsulator. This requires that ICMP
messages inside the encapsulation domain affect the mapping from the
Flow ID. ICMP messages in the second category are: Parameter
Problem, Redirect, Destination Unreachable, Time Exceeded.
Finally there is one ICMP message which has direct bearing on the
operation of the original source of datagrams destined for
encapsulation, the ICMP Source Quench message. The only possible
mechanism available to the Encapsulator to handle this message is for
the source quench message set a flag for the offending Flow ID such
that subsequent messages that map the Flow cause the generation of a
source quench back to the original source before the datagram is
encapsulated.
This last mechanism may be a solution for the more general problem.
The rule of thumb could be that when an ICMP message is received for
a given flow, then flag the Flow so that then next message
encapsulated will cause the next message encapsulated on that flow to
force an ICMP message to the source. After the ICMP message is sent
to the source, the mechanism could be reset. This would effectively
cause every other packet to receive an ICMP message if there were a
persistent problem. This mechanism is probably only safe for
Unreachable messages and Source Quench.
C. Reception of Clear Datagrams
In order to use the encapsulation protocol a modification is required
to IP forwarding. There must be some way for the IP module in a
system to pass Clear Datagrams to the encapsulation protocol. A
suggested means of doing this is to make an addition to a system's
routing table structures. A flag could be added to a route that
tells the forwarding function to use encapsulation. Note that the
default route could also be set to use encapsulation.
With this mechanism in place, a system's IP forwarding mechanism
would examine its routing tables to try and match the IP destination
to a specific route. If a route was found, it would be then checked
to see if encapsulation should be used. If not the packet would be
handled normally. If encapsulation was turned on for the route, then
the datagram would be sent to encapsulation for forwarding.
In addition to snagging packets as they are forwarded, something
must be done at the last Decapsulator on a given flow so that
packets that are decapsulated are properly dumped into the IP
module for delivery. Because the packets are encapsulated just
before forwarding, it should be a simple matter for decapsulated
datagrams to be injected into the output portion of IP. However, the
source address in the Clear Header must not change. The address
must remain the address of the source in the source User Space and
not be overwritten with that of the Decapsulator.
D. Construction of Virtual Networks with Encapsulation
Because of the modification to the routing table to permit
encapsulation, it becomes possible to specify a virtual interface
whose sole purpose is encapsulation. Using this mechanism, it would
become possible to link topologically distant entities with Flows.
This would allow the construction of a Virtual Network which would
overlay the actual routing topology. An example of such a virtual
network is shown in Fig. 4.
++++++ Virtual Network A
****** Virtual Network B
# Encapsulator/Decapsulator
------ Common Routing Space
------------ ------------
/ \ / \
/ +++ # \ / \
| # +++ + | | # ***** # |
| + + | | * * |
| + + | | * * |
| + + | | * * |
| # ++++ # + | | * * |
\ + / ------------- \ # ** / ---------
\ + # ++ \ # ****** *** # ** \
------------ / +++ * ------------ / *** \
| # * | | # *** #|
| + ** | | * *|
| + # | | * ** |
| + ++++ * | | * * |
| #+ * | | * * |
------------ \ ++++ */ ------------ \ * # /
/ \ # + # ** * # ***** /
/ + ------------- / # ****** # *\ --------
| # +++++++ +| | * * |
| + + + | | * * |
| + # | | * * |
| + ++ | | * # |
| # ++++++ | | * ********* |
\ / \ # /
\ / \ /
------------ ------------
Fig. 4. Virtual Networks Example
Each Encapsulator shown has an virtual interface on one of the
virtual networks. The lines represent individual links in the flows
that connect each member of the virtual network. Note that new links
could be added between any points as long as the two entities are
visible to each other in a common Encapsulation Space. The routing
within the virtual network would be handled by the encapsulation
mechanism. The programming of the routing tables could be a variant
of any of the currently existing routing protocols, an encapsulated
OSPF for example.
With this in mind, it would be possible to have special encapsulation
gateways with virtual interfaces on two virtual networks to form an
entire virtual internet. This is the role of the Encapsulators
joining Virtual Network A and Virtual Network B.
E. Encapsulation and OSI
It is intended that the encapsulation mechanism described in the memo
be extensible to other environments outside of the Internet. It
should be possible to encapsulate many different protocols within IP
and IP within many other protocols.
The key concepts defined in this memo are the mapping of a header to
a Flow ID and the mapping of fields in the original header to the
encapsulating header. Special mappings between protocols would have
to be defined, i.e. for the QoS bits, and some sort of translation of
meanings carefully crafted, but it would be possible, none the less.
F. Security Considerations
No means of authentication or integrity checking is specifically
defined for this protocol apart from the checksum for the header
information. However for authentication or integrity checking to be
used with this protocol, it is suggested that the authentication
information be appended to the Encapsulated Datagram. Information
regarding the type of authentication or integrity check in use would
have to be included in the flow management protocol which is used to
distribute the flow information.
G. Authors' Addresses
Robert A. Woodburn
SAIC
8619 Westwood Center Drive
Vienna, VA 22182
Phone: (703) 734-9000 or (703) 448-0210
EMail: woody@cseic.saic.com
David L. Mills
Electrical Engineering Department
University of Delaware
Newark, DE 19716
Phone: (302) 451-8247
EMail: mills@udel.edu
ISO Plain Language
On this page
§2The Terms the Protocol Uses
The protocol is built on a small set of defined terms. The Clear Datagram is the unmodified IP datagram in the User Space before encapsulation, and the Clear Header is the header portion of that datagram, which includes the IP header and possibly part or all of the next layer protocol header, such as the TCP header. The Encapsulated Datagram is the datagram consisting of a Clear Datagram with an Encapsulation Header prepended, and the Encapsulation Header is that prepended header, which consists of an IP header followed by an Encapsulation Protocol Header, the protocol-specific part of it. Encapsulation is the process of mapping a Clear Datagram to the Encapsulation Space, prepending the header and routing the result, and Decapsulation is the stripping of the header and forwarding of the Clear Datagram by the Decapsulator.
An Encapsulator is the entity responsible for mapping a given User Space datagram to the Encapsulation Space, encapsulating it, and forwarding the Encapsulated Datagram to a Decapsulator; it may be a host or a gateway. A Decapsulator receives an Encapsulated Datagram, decapsulates it and delivers it to the destination User Space, either directly or via further encapsulation; it may also be a host or a gateway.
A User Space is the address and routing space within which the users reside, providing reachability between all address pairs within it. A User Address is the address or identifier uniquely identifying an entity within a User Space. An Encapsulation Space is the address and routing space within which the Encapsulators and Decapsulators reside, and routing within it is accomplished via Flows. A Flow, also called a tunnel, is the end-to-end path in the Encapsulation Space over which Encapsulated Datagrams travel; there may be several Encapsulator and Decapsulator pairs along a given flow, and a flow does not denote what user space gateways are traversed along the path. A Flow ID is a 32-bit identifier which uniquely distinguishes a flow in a given Encapsulator or Decapsulator; flow IDs are specific to a single entity and are not global quantities. A Mapping Function maps a Clear Header to a particular flow, and all encapsulators along a given flow are required to map a given Clear Header to the same flow. A Source Route is a complete end-to-end route computed at the source which enumerates the transit gateways.
The protocol separates the network the user is in from the network the tunnel runs in. The datagram the user sends is called the clear datagram; the one that travels in the tunnel is the encapsulated datagram.
§3What Encapsulation Is For
For several years researchers in the Internet community had needed a means of tunneling between networks. A tunnel is essentially a source route that circumvents conventional routing mechanisms. Tunnels provide the means to bypass routing failures, avoid broken gateways and routing domains, or establish deterministic paths for experimentation.
There were several means of accomplishing tunneling. In the past it had been done through source routing options in the IP header, which allow gateways along a path to be enumerated. The disadvantage is that source routing requires the source to know something about the networks traversed to reach the destination, and to modify outgoing packets to reflect the source route; current routing implementations generally do not support source routes in their routing tables as a means of reaching an IP address, nor do current routing protocols.
Another means would be to develop a new IP option, in a separate IP header that could be prepended to an IP datagram, indicating information about the original datagram. That has the disadvantage of significantly modifying existing IP implementations to handle a new IP option, and it is less flexible in permitting the tunneling of other protocols, such as ISO protocols, through an IP environment. An even less palatable alternative would be to replace IP with a new networking protocol, or a new version of IP with tunneling built in as part of its functionality.
The final alternative is what this RFC takes: a new IP encapsulation protocol that uses the current IP header format. By using encapsulation, a destination can be reached transparently without the source having to know topology specifics, and virtual networks can be created by tying otherwise unconnected machines together with flows through an encapsulation space. Up until then there had been no standard for an encapsulation protocol, and this RFC provides a means of performing encapsulation in the Internet environment.
Tunneling lets two machines talk over a path that the ordinary routing does not know about. The earlier ways of doing this all needed changes to IP or to the routing tables; this one only adds a header.
§4The Encapsulation Architecture
The architecture is based on two entities, an Encapsulator and a Decapsulator, and the associated spaces. Encapsulation Spaces do not overlap, so the address of any Encapsulator or Decapsulator is unique across them, and User Spaces do not overlap either, so a given user address is unique in all User Spaces.
Encapsulators and Decapsulators have addresses in the User Spaces to which they belong, as well as addresses in the Encapsulation Spaces to which they belong. An Encapsulator receives a Clear Datagram from its User Space and, after determining that encapsulation should be used, performs a mapping function which translates the user space information in the Clear Header into an Encapsulation Header. That header is prepended to the Clear Datagram to form the Encapsulated Datagram. The encapsulation process is desirable if it is transparent to entities in the User Space: only the Encapsulator needs to know that encapsulation is occurring.
The Encapsulator forwards the datagram to a Decapsulator whose identity is determined at the time of encapsulation. The Decapsulator removes the Encapsulation Header and treats the Clear Datagram as if it had been received locally. The requirement on the address of the Decapsulator is that it be reachable from the Encapsulator's Encapsulation Space address.
Using the encapsulation protocol requires a modification to IP forwarding, so that the IP module can pass Clear Datagrams to the encapsulation protocol. A suggested means is to add a flag to a route in the routing table structures, telling the forwarding function to use encapsulation; the default route could also be set to use encapsulation. The forwarding mechanism would then examine its routing tables to match the IP destination to a specific route, check whether encapsulation should be used, and if so send the datagram to encapsulation for forwarding. At the last Decapsulator on a flow, decapsulated datagrams are injected into the output portion of IP, and the source address in the Clear Header must not change: it must remain the address of the source in the source User Space and not be overwritten with that of the Decapsulator. Because of the modification to the routing table, it also becomes possible to specify a virtual interface whose sole purpose is encapsulation, which allows a virtual network to be constructed that overlays the actual routing topology.
There are two separate address spaces: the one the user's own network uses, and the one the tunnel runs in. A machine at the entrance of the tunnel wraps the datagram for the tunnel space; a machine at the far end unwraps it and puts it back into the user's space.
- Clear DatagramThe datagram arrives with the addresses of its own user space.
- Encapsulated DatagramAn IP header for the encapsulation space and the Encapsulation Protocol Header are prepended, and the flow is chosen by matching the Clear Header.
- Clear DatagramThe Decapsulator strips the header and forwards the datagram locally, keeping the original source address.
§5Generating the Encapsulation Header
The contents of the Encapsulation Header are produced by a mapping function from the Clear Header. In the first part of that function the Clear Header is matched with stored headers and masks to determine a Flow ID, which is essentially a mask-and-match table lookup where the table holds three entries: a Clear Header, a header mask and a corresponding Flow ID. The mask allows a range of source and destination addresses to map to a given flow, and other fields such as the IP TOS bits or even the TCP source or destination port addresses could also be used to discriminate between flows. This flexibility allows many possibilities: not only can a given network be associated with a particular flow, but even a particular TCP protocol or connection could be distinguished from another. How the lookup table is built and maintained is not part of this protocol; it is assumed to be managed by some higher layer entity, and it would be sufficient to configure the tables from ASCII text files.
The Flow IDs are managed at a higher layer as well. The RFC points to the Setup protocol of the Inter-Domain Policy Sensitive Routing Protocol as an example, and notes that the upper layer protocol would be responsible for maintaining information not carried in the encapsulation protocol, such as the type of data being encapsulated, currently only IP, and the type of authentication used if any.
The Flow ID that results from the mapping is a 32-bit quantity identifying the flow as seen by the Encapsulator. If a datagram must be encapsulated and decapsulated several times to reach the destination, the Flow ID may be different at each Encapsulator but need not be. It acts as an index into a table of Encapsulation Header information used to build the header. Making the Flow ID local to the Encapsulator is due to the difficulty of choosing and maintaining globally unique identifiers. The intermediate step of using a Flow ID is entirely optional: the important requirement is that all Encapsulators along a flow map the same Clear Header to the same flow, which could be identified by different identifiers along the way.
The information needed to build the Encapsulation Header is the Flow ID relative to the current Encapsulator, the IP address of the Decapsulator in the Encapsulation Space, the Flow ID for the flow as seen by the Decapsulator if any, the previous Encapsulator's address if this is not the first Encapsulator along the flow, for error reporting, and the previous Encapsulator's Flow ID. The two pieces of information that must be determined at the time of encapsulation for the Encapsulation Protocol Header are the protocol being encapsulated and the Flow ID to send to the Decapsulator.
The generation of the IP header is more complicated, because each field in the Clear Header could relate to the new IP header in one of two ways: Copy, meaning the existing field is copied across, or Ignore, meaning the field may or may not have existed in the Clear Header but does not apply to the new IP header. Most fields in the Clear Header are simply ignored: fields such as the Header Length in the Clear Header have no effect on the Header Length of the new IP header. The Quality of Service bits should be copied, in keeping with the transparency principle that if the User Space was providing a given service, the Encapsulation Space must provide the same service. The More Fragments bit and Fragment Offset should not be copied, since the datagram being built is a complete datagram regardless of the status of the encapsulated datagram; if the completed datagram is too large for the interface it will be fragmented by the normal IP fragmentation mechanism. The Don't Fragment bit should not be copied either, because the transparency principle would again be violated; it should be up to the Encapsulator to decide whether fragmentation is allowed across the Encapsulation Space, and if the DF bit is used then an ICMP message would be returned if the Encapsulated Datagram required fragmentation across the Encapsulation Space.
For the TTL the easiest thing to do is to ignore the TTL from the Clear Header, since copying it could mean the packet life is prematurely exceeded during transit in the Encapsulation Space. The TTL of the Clear Header is decremented before encapsulation by the IP forwarding function, so there is no chance of a packet looping forever if the links of a flow form a loop. The protocol field of the new IP header should carry the protocol number of the encapsulation protocol, the source address becomes the IP address of the Encapsulator in the Encapsulation Domain, and the destination address becomes the IP address of the Decapsulator as found in the encapsulation table. IP options are generally not copied because most do not make sense in the context of the Encapsulation Space, and the security option is probably the one that should be copied, for the same reason the QoS and precedence fields are copied.
The protocol header itself is eight octets long. The first octet holds the version number of the encapsulation protocol in four bits, and the version described by this document is 1, and the header length in octets in the other four bits. The second octet holds the message type in four bits and the reason code in the other four bits: a data message has a message type of 1 and an error message has a message type of 2, the reason code is unused in a data message and must be 0, and in an error message it holds the reason code, of which 1 is Unknown Flow ID and 2 is ICMP returned. The next two octets carry a 16-bit one's complement checksum for the header, set to zero while the checksum is calculated and filled in with the result before the data message is sent. The last four octets carry the 32-bit Flow ID as seen by the Encapsulator or Decapsulator the message is being sent to; in an Unknown Flow ID error, the Flow ID causing the error is used. For data messages the protocol header is followed by the Clear Datagram, and for error messages it is followed by the ICMP message being forwarded along a flow.
The wrapping decision is a table lookup: the original header is matched against a mask, and the match gives a number identifying the tunnel. The new IP header is mostly built fresh, but the type-of-service bits and the security option are carried across so the service the user gets does not change.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
VERS | Vers | 4 bits | 1 | The version of the encapsulation protocol. This document describes version 1. |
HL | HL | 4 bits | The header length of the Encapsulation Protocol Header in octets. | |
MT | MT | 4 bits | 1 | The message type: 1 for a data message, 2 for an error message. |
RC | RC | 4 bits | The reason code. Unused in a data message, where it must be 0. In an error message, 1 is Unknown Flow ID and 2 is ICMP returned. | |
CHECKSUM | Checksum | 2 bytes | A one's complement checksum for the Encapsulation Protocol Header, set to zero while calculating. | |
FLOW-ID | Flow ID | 4 bytes | The flow as seen by the Encapsulator or Decapsulator the message is sent to. |
| IP header field | Mapping |
|---|---|
| Version | Ignore |
| Header Length | Ignore |
| Precedence | Copy |
| QoS bits | Copy |
| Total Length | Ignore |
| Identification | Ignore |
| Don't Fragment Bit | Ignore |
| More Fragments Bit | Ignore |
| Fragment Offset | Ignore |
| Time to Live | Ignore |
| Protocol | Ignore |
| Header Checksum | Ignore |
| Source Address | Ignore |
| Destination Address | Ignore |
| Security Option | Copy |
| Loose Source Route Option | Ignore |
| Strict Source Route Option | Ignore |
| Record Route Option | Ignore |
| Timestamp Option | Ignore |
§6Decapsulation
In the ideal situation a Decapsulator receives an Encapsulated Datagram, strips off the Encapsulation Header and sends the Clear Datagram back into IP so that it is forwarded from that point. However, if the Clear Datagram has not reached the destination User Space, it must again be encapsulated to move it closer to the destination User Space. In that case the Decapsulator becomes an Encapsulator and performs the same calculation to generate the next Encapsulation Header as the previous Encapsulator did. To make this more efficient, the use of Flow IDs has been incorporated into the protocol.
When Flow IDs are used, the Flow ID received in the Encapsulation Header corresponds to a stored Flow ID in the Decapsulator, and the Decapsulator has the option of bypassing the mask and match operation on the Clear Header. The received Flow ID can be used to point directly into the local tables for the construction of the next Encapsulation Header. If the Flow ID is unknown, an error message is sent back to the previous Encapsulator and a signal is sent to the upper layer entity managing the encapsulation tables.
Because the normal IP forwarding mechanism is bypassed when Flow IDs are used, certain mechanisms normally handled by IP must be taken care of by the Decapsulator. The Decapsulator must decrement the TTL before the next encapsulation occurs, and if a Time Exceeded error occurs, an ICMP message is sent to the source indicated in the Clear Header.
At each end of the tunnel the number in the header says which tunnel it is. If the far end does not know that number it reports it back, and if a packet expires the far end sends the error to the original sender rather than to the tunnel.
§7Error Messages, Fragmentation and Forwarding
There are two kinds of error message built into the encapsulation protocol. The first reports unknown flow identifiers seen by a Decapsulator: the Decapsulator notifies the previous Encapsulator that the flow was not known, so that the problem may be reported to the layer responsible for programming the flow tables. The second is for forwarding ICMP messages. If an Encapsulator receives an ICMP message regarding a given flow, the message should be forwarded backwards along the flow to the source Encapsulator. The ICMP message will contain the Flow ID of the message which caused the error, and this Flow ID must be translated to the Flow ID relative to the Encapsulator the error message is sent to. If an error occurs while sending any error message, no further error messages are generated.
The handling of ICMP messages is called the most controversial aspect of encapsulation. Because the Encapsulation Header contains the source address of the Encapsulator in the Encapsulation Space, ICMP messages which occur within the Encapsulation Space are sent back to the Encapsulator. The original source of the Clear Datagram knows nothing about the Encapsulation Space, so forwarding an ICMP message on to it does not make sense, and ICMP messages are not supposed to beget ICMP messages; yet not sending the original source something may break some important mechanisms. There is also the problem of possibly not having enough information to send anything at all back: an ICMP message returns the header of the offending message and the first eight octets of the data after it, which for the encapsulation protocol means the IP portion of the Encapsulation Header, the first eight octets of the Encapsulation Protocol Header and nothing else, so the contents of the Clear Datagram are completely lost and the Encapsulator would have to reconstruct the Clear Header, which is essentially impossible to do exactly. The Flow ID has been assumed to be a unique one-way mapping from a Clear Header, with no guarantee that it could be used to map back.
The RFC divides the ICMP messages into three categories. The first are those not applicable in the context of encapsulation: Echo and Echo Reply, and Timestamp and Timestamp Reply. The second concern mechanisms local to the encapsulation domain and would not make sense to the original source, such as Parameter Problem, Redirect, Destination Unreachable and Time Exceeded; for these the datagram is simply lost, since IP is not meant to be a reliable protocol. The third is the ICMP Source Quench message, for which the only possible mechanism available to the Encapsulator is to set a flag for the offending Flow ID so that subsequent messages mapping that flow cause a source quench to be generated back to the original source before the datagram is encapsulated.
One immediate concern with encapsulation is restrictions based on MTU size. The source of a Clear Datagram generates packets consistent with the MTU of the interface over which the datagram is transmitted, and if these reach an Encapsulator and are encapsulated they may be fragmented if they are larger than the MTU of the Encapsulator, even though the physical interfaces of the source and the Encapsulator may have the same MTU. Because a new header is prepended by the encapsulation process, the likelihood of fragmentation increases, and if the Encapsulator disallows fragmentation through the Encapsulation Space it must send an ICMP message back to the source, which means the effective MTU of the interface in the encapsulation space is smaller than the physical MTU of the interface. Fragmentation by intermediate user space gateways introduces another problem, because fragmentation occurs at the IP level and, if TCP is in use, the TCP header is contained in the first fragment but not the following ones, so discrimination of the Clear Header for a given flow can only be done on the IP header portion.
Two things need care. A wrapped datagram is bigger than the original, so it may have to be split on the way. And the wrapping changes what a broken path reports back, so the RFC works out which ICMP messages should cross the tunnel and which should not.