📄 rfc1241.txt
字号:
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
Woodburn & Mills [Page 1]
RFC 1241 Internet Encapsulation July 1991
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.
Woodburn & Mills [Page 2]
RFC 1241 Internet Encapsulation July 1991
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.
Woodburn & Mills [Page 3]
RFC 1241 Internet Encapsulation July 1991
++++++ 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
Woodburn & Mills [Page 4]
RFC 1241 Internet Encapsulation July 1991
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
Woodburn & Mills [Page 5]
RFC 1241 Internet Encapsulation July 1991
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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -