以下为英文原版
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 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.
- 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
disadvantage of encapsulation is not as serious as it might seem at
first.
3. IP in IP Encapsulation
To encapsulate an IP datagram using IP in IP encapsulation, an outer
IP header [10] is inserted before the datagram's existing IP header,
as follows:
The outer IP header Source Address and Destination Address identify
the "endpoints" of the tunnel. The inner IP header Source Address
and Destination Addresses identify the original sender and recipient
of the datagram, respectively. The inner IP header is not changed by
the encapsulator, except to decrement the TTL as noted below, and
remains unchanged during its delivery to the tunnel exit point. No
change to IP options in the inner header occurs during delivery of
the encapsulated datagram through the tunnel. If need be, other
protocol headers such as the IP Authentication header [1] may be
inserted between the outer IP header and the inner IP header. Note
that the security options of the inner IP header MAY affect the
choice of security options for the encapsulating (outer) IP header.
3.1. IP Header Fields and Handling
The fields in the outer IP header are set by the encapsulator as
follows:
Version
4
IHL
The Internet Header Length (IHL) is the length of the outer IP
header measured in 32-bit words [10].
TOS
The Type of Service (TOS) is copied from the inner IP header.
Total Length
The Total Length measures the length of the entire encapsulated
IP datagram, including the outer IP header, the inner IP
header, and its payload.
Identification, Flags, Fragment Offset
These three fields are set as specified in [10]. However, if
the "Don't Fragment" bit is set in the inner IP header, it MUST
be set in the outer IP header; if the "Don't Fragment" bit is
not set in the inner IP header, it MAY be set in the outer IP
header, as described in Section 5.1.
Time to Live
The Time To Live (TTL) field in the outer IP header is set to a
value appropriate for delivery of the encapsulated datagram to
the tunnel exit point.
Protocol
4
Header Checksum
The Internet Header checksum [10] of the outer IP header.
Source Address
The IP address of the encapsulator, that is, the tunnel entry
point.
Destination Address
The IP address of the decapsulator, that is, the tunnel exit
point.
Options
Any options present in the inner IP header are in general NOT
copied to the outer IP header. However, new options specific
to the tunnel path MAY be added. In particular, any supported
types of security options of the inner IP header MAY affect the
choice of security options for the outer header. It is not
expected that there be a one-to-one mapping of such options to
the options or security headers selected for the tunnel.
When encapsulating a datagram, the TTL in the inner IP header is
decremented by one if the tunneling is being done as part of
forwarding the datagram; otherwise, the inner header TTL is not
changed during encapsulation. If the resulting TTL in the inner IP
header is 0, the datagram is discarded and an ICMP Time Exceeded
message SHOULD be returned to the sender. An encapsulator MUST NOT
encapsulate a datagram with TTL = 0.
The TTL in the inner IP header is not changed when decapsulating.
If, after decapsulation, the inner datagram has TTL = 0, the
decapsulator MUST discard the datagram. If, after decapsulation, the
decapsulator forwards the datagram to one of its network interfaces,
it will decrement the TTL as a result of doing normal IP forwarding.
See also Section 4.4.
The encapsulator may use any existing IP mechanisms appropriate for
delivery of the encapsulated payload to the tunnel exit point. In
particular, use of IP options is allowed, and use of fragmentation is
allowed unless the "Don't Fragment" bit is set in the inner IP
header. This restriction on fragmentation is required so that nodes
employing Path MTU Discovery [7] can obtain the information they
seek.
3.2. Routing Failures
Routing loops within a tunnel are particularly dangerous when they
cause datagrams to arrive again at the encapsulator. Suppose a
datagram arrives at a router for forwarding, and the router determines
that the datagram has to be encapsulated before further
delivery. Then:
- If the IP Source Address of the datagram matches the router's own
IP address on any of its network interfaces, the router MUST NOT
tunnel the datagram; instead, the datagram SHOULD be discarded.
- If the IP Source Address of the datagram matches the IP address
of the tunnel destination (the tunnel exit point is typically
chosen by the router based on the Destination Address in the
datagram's IP header), the router MUST NOT tunnel the datagram;
instead, the datagram SHOULD be discarded.
See also Section 4.4.
4. ICMP Messages from within the Tunnel
After an encapsulated datagram has been sent, the encapsulator may
receive an ICMP [9] message from any intermediate router within the
tunnel other than the tunnel exit point. The action taken by the
encapsulator depends on the type of ICMP message received. When the
received message contains enough information, the encapsulator MAY
use the incoming message to create a similar ICMP message, to be sent
to the originator of the original unencapsulated IP datagram (the
original sender). This process will be referred to as "relaying" the
ICMP message from the tunnel.
ICMP messages indicating an error in processing a datagram include a
copy of (a portion of) the datagram causing the error. Relaying an
ICMP message requires that the encapsulator strip off the outer IP
header from this returned copy of the original datagram. For cases
in which the received ICMP message does not contain enough data to
relay the message, see Section 5.
4.1. Destination Unreachable (Type 3)
ICMP Destination Unreachable messages are handled by the encapsulator
depending upon their Code field. The model suggested here allows the
tunnel to "extend" a network to include non-local (e.g., mobile)
nodes. Thus, if the original destination in the unencapsulated
datagram is on the same network as the encapsulator, certain
Destination Unreachable Code values may be modified to conform to the
suggested model.
Network Unreachable (Code 0)
An ICMP Destination Unreachable message SHOULD be returned
to the original sender. If the original destination in
the unencapsulated datagram is on the same network as the
encapsulator, the newly generated Destination Unreachable
message sent by the encapsulator MAY have Code 1 (Host
Unreachable), since presumably the datagram arrived at the
correct network and the encapsulator is trying to create the
appearance that the original destination is local to that
network even if it is not. Otherwise, if the encapsulator
returns a Destination Unreachable message, the Code field MUST
be set to 0 (Network Unreachable).
Host Unreachable (Code 1)
The encapsulator SHOULD relay Host Unreachable messages to the
sender of the original unencapsulated datagram, if possible.
Protocol Unreachable (Code 2)
When the encapsulator receives an ICMP Protocol Unreachable
message, 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 use protocol 4 in sending the datagram, it would
be meaningless to return Code 2 to that sender.
Port Unreachable (Code 3)
This Code should never be received by the encapsulator, since
the outer IP header does not refer to any port number. It MUST
NOT be relayed to the sender of the original unencapsulated
datagram.
Datagram Too Big (Code 4)
The encapsulator MUST relay ICMP Datagram Too Big messages to
the sender of the original unencapsulated datagram.
Source Route Failed (Code 5)
This Code SHOULD be handled by the encapsulator itself.
It MUST NOT be relayed to the sender of the original
unencapsulated datagram.
4.2. Source Quench (Type 4)
The encapsulator SHOULD NOT relay ICMP Source Quench messages to the
sender of the original unencapsulated datagram, but instead SHOULD
activate whatever congestion control mechanisms it implements to help
alleviate the congestion detected within the tunnel.
4.3. Redirect (Type 5)
The encapsulator MAY handle the ICMP Redirect messages itself. It
MUST NOT not relay the Redirect to the sender of the original
unencapsulated datagram.
4.4. Time Exceeded (Type 11)
ICMP Time Exceeded messages report (presumed) routing loops within
the tunnel itself. Reception of Time Exceeded messages by the
encapsulator MUST be reported to the sender of the original
unencapsulated datagram as Host Unreachable (Type 3, Code 1). Host
Unreachable is preferable to Network Unreachable; since the datagram
was handled by the encapsulator, and the encapsulator is often
considered to be on the same network as the destination address in
the original unencapsulated datagram, then the datagram is considered
to have reached the correct network, but not the correct destination
node within that network.
4.5. Parameter Problem (Type 12)
If the Parameter Problem message points to a field copied from the
original unencapsulated datagram, the encapsulator MAY relay the ICMP
message to the sender of the original unencapsulated datagram;
otherwise, if the problem occurs with an IP option inserted by the
encapsulator, then the encapsulator MUST NOT relay the ICMP message
to the original sender. Note that an encapsulator following
prevalent current practice will never insert any IP options into the
encapsulated datagram, except possibly for security reasons.
4.6. Other ICMP Messages
Other ICMP messages are not related to the encapsulation operations
described within this protocol specification, and should be acted on
by the encapsulator as specified in [9].
5. Tunnel Management
Unfortunately, ICMP only requires IP routers to return 8 octets (64
bits) of the datagram beyond the IP header. This is not enough to
include a copy of the encapsulated (inner) IP header, so it is not
always possible for the encapsulator to relay the ICMP message from
the interior of a tunnel back to the original sender. However, by
carefully maintaining "soft state" about tunnels into which it sends,
the encapsulator can return accurate ICMP messages to the original
sender in most cases. The encapsulator SHOULD maintain at least the
following soft state information about each tunnel:
- MTU of the tunnel (Section 5.1)
- TTL (path length) of the tunnel
- Reachability of the end of the tunnel
The encapsulator uses the ICMP messages it receives from the interior
of a tunnel to update the soft state information for that tunnel.
ICMP errors that could be received from one of the routers along the
tunnel interior include:
- Datagram Too Big
- Time Exceeded
- Destination Unreachable
- Source Quench
When subsequent datagrams arrive that would transit the tunnel, the
encapsulator checks the soft state for the tunnel. If the datagram
would violate the state of the tunnel (for example, the TTL of the
new datagram is less than the tunnel "soft state" TTL) the
encapsulator sends an ICMP error message back to the sender of the
original datagram, but also encapsulates the datagram and forwards it
into the tunnel.
Using this technique, the ICMP error messages sent by the
encapsulator will not always match up one-to-one with errors
encountered within the tunnel, but they will accurately reflect the
state of the network.
Tunnel soft state was originally developed for the IP Address
Encapsulation (IPAE) specification [4].
5.1. Tunnel MTU Discovery
When the Don't Fragment bit is set by the originator and copied into
the outer IP header, the proper MTU of the tunnel will be learned
from ICMP Datagram Too Big (Type 3, Code 4) messages reported to the
encapsulator. To support sending nodes which use Path MTU Discovery,
all encapsulator implementations MUST support Path MTU Discovery [5,
7] soft state within their tunnels. In this particular application,
there are several advantages:
- As a benefit of Path MTU Discovery within the tunnel, any
fragmentation which occurs because of the size of the
encapsulation header is performed only once after encapsulation.
This prevents multiple fragmentation of a single datagram, which
improves processing efficiency of the decapsulator and the
routers within the tunnel.
- If the source of the unencapsulated datagram is doing Path MTU
Discovery, then it is desirable for the encapsulator to know
the MTU of the tunnel. Any ICMP Datagram Too Big messages from
within the tunnel are returned to the encapsulator, and as noted
in Section 5, it is not always possible for the encapsulator to
relay ICMP messages to the source of the original unencapsulated
datagram. By maintaining "soft state" about the MTU of the
tunnel, the encapsulator can return correct ICMP Datagram Too Big
messages to the original sender of the unencapsulated datagram to
support its own Path MTU Discovery. In this case, the MTU that
is conveyed to the original sender by the encapsulator SHOULD
be the MTU of the tunnel minus the size of the encapsulating
IP header. This will avoid fragmentation of the original IP
datagram by the encapsulator.
- If the source of the original unencapsulated datagram is
not doing Path MTU Discovery, it is still desirable for the
encapsulator to know the MTU of the tunnel. In particular, it is
much better to fragment the original datagram when encapsulating,
than to allow the encapsulated datagram to be fragmented.
Fragmenting the original datagram can be done by the encapsulator
without special buffer requirements and without the need to
keep reassembly state in the decapsulator. By contrast, if
the encapsulated datagram is fragmented, then the decapsulator
must reassemble the fragmented (encapsulated) datagram before
decapsulating it, requiring reassembly state and buffer space
within the decapsulator.
Thus, the encapsulator SHOULD normally do Path MTU Discovery,
requiring it to send all datagrams into the tunnel with the "Don't
Fragment" bit set in the outer IP header. However there are problems
with this approach. When the original sender sets the "Don't
Fragment" bit, the sender can react quickly to any returned ICMP
Datagram Too Big error message by retransmitting the original
datagram. On the other hand, suppose that the encapsulator receives
an ICMP Datagram Too Big message from within the tunnel. In that
case, if the original sender of the unencapsulated datagram had not
set the "Don't Fragment" bit, there is nothing sensible that the
encapsulator can do to let the original sender know of the error.
The encapsulator MAY keep a copy of the sent datagram whenever it
tries increasing the tunnel MTU, in order to allow it to fragment and
resend the datagram if it gets a Datagram Too Big response.
Alternatively the encapsulator MAY be configured for certain types of
datagrams not to set the "Don't Fragment" bit when the original
sender of the unencapsulated datagram has not set the "Don't
Fragment" bit.
5.2. Congestion
An encapsulator might receive indications of congestion from the
tunnel, for example, by receiving ICMP Source Quench messages from
nodes within the tunnel. In addition, certain link layers and
various protocols not related to the Internet suite of protocols
might provide such indications in the form of a Congestion
Experienced [6] flag. The encapsulator SHOULD reflect conditions of
congestion in its "soft state" for the tunnel, and when subsequently
forwarding datagrams into the tunnel, the encapsulator SHOULD use
appropriate means for controlling congestion [3]; However, the
encapsulator SHOULD NOT send ICMP Source Quench messages to the
original sender of the unencapsulated datagram.
6. Security Considerations
IP encapsulation potentially reduces the security of the Internet,
and care needs to be taken in the implementation and deployment of IP
encapsulation. For example, IP encapsulation makes it difficult for
border routers to filter datagrams based on header fields. In
particular, the original values of the Source Address, Destination
Address, and Protocol fields in the IP header, and the port numbers
used in any transport header within the datagram, are not located in
their normal positions within the datagram after encapsulation.
Since any IP datagram can be encapsulated and passed through a
tunnel, such filtering border routers need to carefully examine all
datagrams.
6.1. Router Considerations
Routers need to be aware of IP encapsulation protocols in order to
correctly filter incoming datagrams. It is desirable that such
filtering be integrated with IP authentication [1]. Where IP
authentication is used, encapsulated packets might be allowed to
enter an organization when the encapsulating (outer) packet or the
encapsulated (inner) packet is sent by an authenticated, trusted
source. Encapuslated packets containing no such authentication
represent a potentially large security risk.
IP datagrams which are encapsulated and encrypted [2] might also pose
a problem for filtering routers. In this case, the router can filter
the datagram only if it shares the security association used for the
encryption. To allow this sort of encryption in environments in
which all packets need to be filtered (or at least accounted for), a
mechanism must be in place for the receiving node to securely
communicate the security association to the border router. This
might, more rarely, also apply to the security association used for
outgoing datagrams.
6.2. Host Considerations
Host implementations that are capable of receiving encapsulated IP
datagrams SHOULD admit only those datagrams fitting into one or more
of the following categories:
- The protocol is harmless: source address-based authentication is
not needed.
- The encapsulating (outer) datagram comes from an authentically
identified, trusted source. The authenticity of the source could
be established by relying on physical security in addition to
border router configuration, but is more likely to come from use
of the IP Authentication header [1].
- The encapuslated (inner) datagram includes an IP Authentication
header.
- The encapsulated (inner) datagram is addressed to a network
interface belonging to the decapsulator, or to a node with which
the decapsulator has entered into a special relationship for
delivering such encapsulated datagrams.
Some or all of this checking could be done in border routers rather
than the receiving node, but it is better if border router checks are
used as backup, rather than being the only check.
7. Acknowledgements
Parts of Sections 3 and 5 of this document were taken from portions
(authored by Bill Simpson) of earlier versions of the Mobile IP
Internet Draft [8]. The original text for section 6 (Security
Considerations) was contributed by Bob Smart. Good ideas have also
been included from RFC 1853 [11], also authored by Bill Simpson.
Thanks also to Anders Klemets for finding mistakes and suggesting
improvements to the draft. Finally, thanks to David Johnson for
going over the draft with a fine-toothed comb, finding mistakes,
improving consistency, and making many other improvements to the
draft.
References
[1] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[2] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
August 1995.
[3] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[4] Gilligan, R., Nordmark, E., and B. Hinden, "IPAE: The SIPP
Interoperability and Transition Mechanism", Work in Progress.
[5] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[6] Mankin, A., and K. Ramakrishnan, "Gateway Congestion Control
Survey", RFC 1254, August 1991.
[7] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[8] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
October 1996.
[9] Postel, J., Editor, "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[10] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
[11] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
Author's Address
Questions about this memo can be directed to:
Charles Perkins
Room H3-D34
T. J. Watson Research Center
IBM Corporation
30 Saw Mill River Rd.
Hawthorne, NY 10532
Work: +1-914-784-7350
Fax: +1-914-784-6205
EMail: perk@watson.ibm.com
The working group can be contacted via the current chair:
Jim Solomon
Motorola, Inc.
1301 E. Algonquin Rd.
Schaumburg, IL 60196
Work: +1-847-576-2753
EMail: solomon@comm.mot.com
以下为自己做的中文翻译
网络工作组 查尔斯.帕金斯
征求意见编号：2003 IBM
类别：将会标准化的草案 1996年10月
在IP内封装IP
此条备忘录的状态
此篇文档阐述了一个互联网通信中将会标准化的协议草案，为了对其进行改进而征求讨论和建议。关于标准化的状态和此协议的状态请参阅当前版本的“互联网官方协议标准”（STD 1）。分发此份备忘录不受限制。
摘要
此篇文档阐述了一种一个IP数据报会被封装进另一个IP数据报中（作为负载传输）的方法。
封装被认为对改变正常IP数据报的路由选择来说非常重要。取决于将它们交付到一个中间目的地，这个目的地也许不是在原始IP数据报头部所选取的目的地址字段。封装可以服务于多种目的，比如使用移动IP将一个IP数据报交付到一个移动节点。
1.介绍
此篇文档阐述了一种一个IP数据报会被封装进另一个IP数据报中（作为负载传输）的方法。封装被认为对改变正常IP数据报路由选择来说非常重要。依赖于将它们交付到一个中间目的地，这个目的地也许不是在原始IP数据报头部所选取的目的地址字段。一旦被封装的数据报到达这个中间目的网点就会被去封装，产生原始的IP数据报。这个数据报就会被交付到在原始目的地址字段中指定的地点去。一个数据报封装与去封装的使用频繁涉及到“隧道”数据报，那么封装与去封装就被认为是隧道的“终点”。
在最常见的隧道情况就是：
源--->封装端--->去封装端--->目的
这里源、封装端、去封装端、目的都是分离的节点。封装端节点被认为是隧道的“入口点”，而去封装端节点被认为是隧道的“出口点”。在封装端与去封装端之间多个源-目的对使用相同的隧道。
2.动机
移动IP工作组已经阐述了封装作为一种交付数据报从一个移动节点的归属地网络到另外一个代理网络的方法的使用，该代理能够以传统方式在移动节点在当前异于家乡的位置“本地”地传送数据包（参见参考文献[8]）。封装的使用也可以表明无论何时一个IP数据报的源（或者一个中间路由器）必须影响数据报送达最终目的地所经过的路由。其他可能的封装应用包括多播、预付费、安全属性选择路由和一般的安全路由。
一般来说封装和IP松散源路由选项（参见参考文献[10]）能以相同的方式来影响一个数据报的路由，但是有几个技术上的原因使得更趋向于封装。
- 与使用IP源路由选项关联的安全问题有待解决；
- 当前的互联网路由器当转发包含IP选项，包括IP源路由选项的数据报时显示出了性能上的问题；
- 许多当前的互联网节点不正确地处理IP源路由选项；
- 防火墙可能丢弃IP源路由过的数据报
- 插入一个IP源路由选项可能使一个数据报的源或目的认证信息处理复杂化，取决于被指定的认证如何进行；
- 中间路由对那些不是它产生的数据报做出修改我们认为是鲁棒式的；
- 除非我们事先知道隧道的终点节点能够对数据报去封装，否则不应使用封装。
由于今天大多数互联网上的节点在使用IP松散源路由时性能都不够好，封装的第二个技术劣势就不像一开始看到的那样严重。
3.IP in IP封装
要使用IP in IP封装一个IP数据报，一个外部的IP头部（参见参考文献[10]）要插入在数据报已存在的IP头部之前，如下图所示：
外部IP头部源地址和目的地址标识了隧道的终点。内部的IP头部源地址和目的地址分别标识了原始数据报的发送方和接收方。内部的IP头部不会被封装端改变，除非下面指出的方法递减TTL，交付到隧道的终点时依旧对其不改变。封装的数据报通过隧道交付的时候在内部头部的IP选项没有发生改变。如果需要，其他协议头部比如说IP认证头部（参见参考文献[1]）可能会被插入到外部IP头部和内部IP头部中间。注意内部IP头部的安全选项可能对（外部）IP头部封装的安全选项的选择产生影响。
3.1IP头部字段和处理
位于外部IP头部的字段被封装定义为如下形式：
版本Version：4；
因特网首部长度IHL：因特网首部长度是外部IP头部的长度，以32位的字表示（参见参考文献[10]）；
服务类型TOS：服务类型由内部IP头部复制而来；
总长度Total Length：总长度表示整个被封装的IP数据报的长度。包括外部IP头部，内部IP头部，及其负载；
标识Identification，标志Flag，分片首地址Fragment OffSet：这三个字段按参考文献[10]进行设置。然而，如果“不分片”位在内部IP头部被设置了，它必须在外部IP头部也被设置。如果“不分片”位在内部IP头部没有被设置，它可以在外部头部IP头部被设置，正如5.1部分所描述的那样；
生存时间Time to Live：外部IP头部的生存时间字段被设置一个大致的值使封装的数据报交付到隧道的终点：
协议Protocol：4；
首部校验和Header Checksum：为外部IP头部的“Internet头部检验和”（参见参考文献[10]）；
源地址Source Address：封装端的IP地址，也是隧道的入口点；
目的地址Destination Address：去封装端的IP地址，也是隧道的出口点；
选项Options：任何出现在内部IP头部的选项一般意义上都不会被复制到外部IP头部。然而，新的选项指明了隧道的路径可能会被添加。尤其是任何内部IP头部所支持的安全选项类型可能影响到外部IP头部的安全选项的选择。不应该在这些选项到隧道的选项或安全头部之间建立一对一的映射。
在封装一个数据报时，如果隧道作为转发数据报的一部分，内部IP头部的生存时间（TTL）减1；否则在封装时内部IP头部的生存时间（TTL）不作修改。如果在内部IP头部的生存时间（TTL）值为0，数据报就会被丢弃并且一个ICMP的超时报文应该返回给发送方。封装端不可以封装一个生存时间（TTL）为0的数据报。
当去封装时内部IP头部的生存时间（TTL）没有被修改。如果，在去封装之后内部数据报的生存时间（TTL）为0，那么去封装端必须丢弃此数据报。如果，去封装之后，去封装端转发数据报到它的一个网络接口，它就会像处理一般的IP转发一样将生存时间（TTL）减1。另参见4.4部分。
封装端可以使用任意存在的IP机制来把封装后的净载数据传送到隧道的出口点。特别地，允许使用IP选项。分片也被允许使用，除非内部IP头部“不分片”位被设置了。这种分片的约束是必须的，以便于使用路径MTU发现（参考文献[7]）的节点能够得到他们所要寻找的信息。
3.2路由失败
在一个隧道内的路由环回非常危险，它们使得数据报再次回到封装端。设想一下，一个数据报到达一台路由器等待转发，而该路由器认为该数据报在传送之前必须封装，那么：
- 如果此数据报的IP源地址与路由器拥有的任意网络接口的IP地址相匹配，该路由器不允许为该数据报建立隧道；相反，该数据报应该被丢弃。
-如果该数据报的IP源地址与隧道的目的IP地址匹配（隧道出口点一般由路由器根据数据报的IP头部的目的地址选择）路由器不允许为该数据报建立隧道，相反，该数据报应该被丢弃。另参见4.4部分。
4.隧道内部的ICMP报文
一个封装过的数据报发送之后，封装端会从隧道内任意一个中间节点（不是隧道的出口点）路由器那里收到一个ICMP报文。封装端所采取的动作取决于所收到的ICMP报文的类型。当所收到的报文包含足够的信息时，封装端可以使用所收到的报文去创建一个相类似的报文。发送给产生未封装IP数据报的构建者（原始发送方）。此处理称为中继（“Relaying”）来自隧道的ICMP报文。
指出在处理数据报时错误的ICMP报文中包含一份（或一部分）引起错误的数据报的副本。中继一个ICMP报文需要封装端从返回的那份原始数据报中剥离出外部的IP头部。所收到的ICMP报文没有包含足够的数据来中继此报文的情况，请参见部分5。
4.1目的不可达（类型3）
ICMP目的不可达报文由封装端根据它们的代码字段进行处理。在此建议的模式允许隧道“拓展”到一个包含非本地节点的网络（例如移动节点）。这样，如果未封装数据报的原始目的地与封装端在同一个网络中，无疑目的不可达代码值就能被修改成符合所建议的模式。
网络不可达（代码0）
一个ICMP目的不可达报文应该被返回给原始发送端。如果在未封装数据报中原始目的地与封装端在同一个网络，由封装端发送的新产生的目的不可达报文可以使代码为1（主机不可达），因为数据报可能到达正确的网络并且即便不是，封装端也应把最初的目的地址视为该网络的本地地址。否则，如果封装端返回一个目的不可达报文，代码字段必须被设置为0（网络不可达）
主机不可达（代码1）
如果可能的话，封装端应该将原始的主机不可达报文中继给非封装数据报发送方。
协议不可达（代码2）
当封装端收到一个ICMP协议不可达报文，它应该用代码0或1（参见代码0的讨论）发送一个目的不可达报文给原始未封装数据报的发送方。因为在发送数据报时，发送方没有使用协议4，它将会返回代码2给发送方。
端口不可达（代码3）
此代码不应该被封装端所接收。因为外部IP头部不涉及任何端口号。它不能中继给原始未封装数据报的发送方。
数据报过大（代码4）
封装端不许中继ICMP数据报过大报文给原始非封装数据报的发送者。
源路由失败（代码5）
该代码应该由封装端自己处理。它不许中继给原始未封装数据报的发送者。
4.2源淹没（类型4）
封装端不应该中继ICMP源淹没报文给原始未封装数据报的发送者，但是应该激活其实现的拥塞控制机制来缓解在隧道中检测到的拥塞。
4.3重定向（类型5）
封装端可以自己处理ICMP重定向报文。它不应该将重定向中继给原始未封装数据报的发送者。
4.4超时（类型11）
ICMP超时报文报告（推测）给隧道内部本身的路由环回。封装方接收到超时报文必须以主机不可达（类型3，代码1）报告给原始非封装数据报的发送方。主机不可达比网络不可达更适合。因为数据报由封装端处理，并且通常认为封装端与位于原始未封装数据报中的目的地址在同一网络上，那么数据报被认为已经到达了正确的网络，但是没有到达该网络的正确目的节点。
4.5参数问题（类型12）
如果参数问题报文指向一个从原始未封装数据报复制而来的字段，封装端可以中继此ICMP报文给原始未封装数据报的发送者；否则，如果问题发生在一个由封装端插入的IP选项，那么封装端不能将ICMP报文中继给原始发送方。注意遵循实际情况的封装端永远不会把IP选项插入到封装的数据报中，除非出于安全原因。
4.6其他的ICMP报文
其他的ICMP报文不涉及本协议说明中所描述的封装操作，封装端应该遵循按参考文献[9]中所定义的规范。
5.隧道管理
不幸的是，ICMP只要求IP路由器返回IP头部之外的8个字节（64位）数据报。这不够包括一个封装（内部）的IP头部拷贝。因此封装端不总是能从隧道内部中继ICMP报文到原始发送方。然而，借助于仔细维护隧道的 “软状态”，大多数情况下封装端还是能够给原始发送方返回准确的ICMP报文的。封装端对每一个隧道应该至少维护一下软状态信息：
- 隧道的最大传输单元（MTU）（参见部分5.1）
- 隧道的生存时间（TTL）（路径长度）
- 隧道尽头的可达性
封装端使用从隧道内部受到的ICMP报文来为此隧道更新软状态信息。从一个沿着隧道内部的路由器那里可以接收到的ICMP错误包括：
- 数据报过长
- 超时
- 目的不可达
- 源淹没
当后续的数据报到达将要承载它们的隧道时，封装端检查此隧道的软状态。如果此数据报违背了当前隧道的软状态（例如新的数据报生存时间少于隧道“软状态”的生存时间），封装端发送给原始数据报发送方一个ICMP错误报文，但是仍然封装数据报并将其转发到隧道。
使用这种技术，由封装端发送的ICMP错误报文不总是与隧道内发生的错误一一匹配，但它们会精确地反映网络的状态。
隧道软状态起初是为IP地址封装（IPAE）说明而开发的（参见参考文献[4]）
5.1隧道MTU发现
当不分片位被原始端设置并且复制到了外部IP头部时，隧道的适当最大传输单元（MTU）将会从报告给封装端的ICMP数据报过大（类型3，代码4）报文中学习而来。为支持使用路径MTU发现的发送节点，所有封装端的实现必须支持其隧道中的路径MTU发现（参见参考文献[5]、[7]）软状态。在这个特殊的应用中，由如下几个优势：
- 在隧道内路径MTU发现作为一项优势，任何由于封装头部的大小而发生的分片在封装后只发生一次。这样就阻止了对一个数据报的多次分片，改善了去封装端和隧道内部路由器的处理效率。
- 如果未封装数据报的源在处理路径MTU发现，那么就要求封装端知道隧道的MTU。任何来自于隧道内部的ICMP数据报过长报文都返回给封装端，正如第五部分所提到的那样，封装端不总是能从隧道内部中继ICMP报文到原始未封装数据报的源头。借助于维护隧道中关于MTU的“软状态”，封装端能够向未封装数据报的原始发送者返回正确的ICMP数据报过大报文，以支持其自身的路径MTU发现。在这种情况下，由封装端传达给原发送方的MTU应该是此隧道MTU中，封装IP头部最小的。这样就会避免原始IP数据报被封装端的分片。
- 如果原始未封装数据报的源不做路径MTU发现，封装端仍然要知道隧道的MTU。特别地，比起允许封装了的数据报再去分片，在封装的时候就把原始数据报分片要好得多。在封装端完成原始数据报的分片，不需要特别的缓冲，也不需要在拆分端保存重新装配的状态。相比之下，如果封装了的数据报被分片，那么去封装端在对数据报去封装之前必须重新组装分片的（封装的）数据报，同时在去封装端需要保存装配状态和缓冲空间。
这样，封装端应该正常情况下做路径MTU发现，需要在外部IP头部设置不分片位，将所有数据报发送到隧道中。然而该方法带来几个问题：当原始发送方设置不分片位时，发送方能迅速地对转发原始数据报时返回的任何ICMP数据报过大错误报文做出相应。另外一方面，加入封装端从隧道中收到了一个ICMP数据报过大报文，这种情况下，如果未封装数据报的原始发送者没有设置不分片位，那么封装端就不能让原始发送者知道这个错误。为了允许对数据报分片，并且如果封装端收到了一个数据报过大的应答它可以重新发送此数据报，无论何时封装端尝试增加隧道的MTU，它都可以保留一份发送过的数据报的副本。作为选择，当未封装数据报的原始发送方没有设置“不分片”位时，封装端可以配置某种数据报的类型不去设置“不分片”位。
5.2拥塞
封装端可以从隧道中收到拥塞暗示，例如，从隧道内部节点受到ICMP源淹没报文。另外，某些链路层和不涉及Internet协议族的多种协议可能以Congestion Experienced标志位（参见参考文献[6]）的形式提供该暗示。封装方应该在隧道的软状态中反映拥塞状态，当后续的转发数据报进入隧道时，封装端应该使用适当的方法对拥塞进行控制（参见参考文献[3]）；然而，封装端不应该向未封装数据报的原始发送方发送ICMP源淹没报文。
6安全方面的考虑
IP封装可能降低Internet的安全性，所以实现和部署IP封装时要特别注意。例如，IP封装使得边界路由器通过头部字段过滤数据报变得困难。特别是原始值中的源地址、目的地址和头部的协议字段，以及数据报中传输层头部使用的端口号，在封装之后这些信息都不再位于数据报的通常位置了。因为任何IP数据报都能被封装并通过隧道传输，这样的过滤边界路由器需要仔细地检查所有数据报。
6.1路由器方面的考虑
路由器需要知道IP封装的协议以便正确地过滤来源数据报。这样的过滤与IP认证（参见参考文献[1]）结合在一起是可取的。IP认证被使用的地方，当封装（外部）包或者已封装（内部）包由授权的、信任的源发送而来时，封装的数据报就被允许进入该组织。封装过的包不包含这样的认证表明潜在着极大的安全隐患。
被封装并且加密的（参见参考文献[2]）IP数据报可能也要给过滤路由器带来问题。在这种情况下，路由器仅能过滤那些共享了用于加密的安全关联数据报。在所有数据包都需要过滤（或者至少说明）的环境中，为允许这种加密，接收节点必须采用一种机制来安全地把安全关联送到边沿路由器。对于传出的数据包也适用这种安全关联，但较少使用。
6.2主机方面的考虑
主机能够收到封装的IP数据报的实现应该只接受符合下面几种类型的一种或多种的数据报：
- 协议是无害的：不需要基于源地址的认证。
- 封装（外部）数据报来自一个认证识别的可信任的源。源的真实性建立于物理安全和边沿路由器的配置，但更可能来自IP身份认证头部（参考文献[1]）。
- 被封装（内部）数据报包含一个IP认证头部。
- 被封装（内部）数据报地址指向一个属于去封装端的网络接口，或者去封装端已与之建立特殊关系以传输这些已封装数据报的节点。
部分或所有这些检查都可以在边界路由器内完成，而不是在接收节点。但是如果边沿路由器检查作为备份而不是仅仅作为检查会更好。
7致谢
此文档的第三、第五部分摘自（经过Bill Simpson授权）早期的移动IP Internet草案（参见参考文献[8]）。第六部分的原始文本（安全方面的考虑）由Bob Smart贡献。一些好的想法也被包含自RFC1853（参见参考文献[11]），也是经过Bill Simpson授权的。也要感谢Anders Klemets找到的一些错误以及对此草案的改善建议。最后还要感谢David Johnson对草案的非常细致的审阅，勘误，润色以及对此文档其他方面的改进。
参考文献
[1] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[2] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, August 1995.
[3] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC1812, June 1995.
[4] Gilligan, R., Nordmark, E., and B. Hinden, "IPAE: The SIPP Interoperability and Transition Mechanism", Work in Progress.
[5] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[6] Mankin, A., and K. Ramakrishnan, "Gateway Congestion Control Survey", RFC 1254, August 1991.
[7] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[8] Perkins, C., Editor, "IP Mobility Support", RFC 2002,October 1996.
[9] Postel, J., Editor, "Internet Control Message Protocol", STD 5,RFC 792, September 1981.
[10] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,September 1981.
[11] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
作者地址：
关于此份备忘录的疑问可直接联系
Charles Perkins
Room H3-D34
T. J. Watson Research Center
IBM Corporation
30 Saw Mill River Rd.
Hawthorne, NY 10532
Work: +1-914-784-7350
Fax: +1-914-784-6205
EMail: perk@watson.ibm.com
本工作组可以通过现任主席联系：
Jim Solomon
Motorola, Inc.
1301 E. Algonquin Rd.
Schaumburg, IL 60196
Work: +1-847-576-2753
EMail: solomon@comm.mot.com
扫一扫
1280
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
