RFC1853：IP in IP Tunneling，October 1995
本备忘录的状态
本备忘录为 Internet 社区提供信息。它没有指定 Internet 标准。本备忘录的分发不受限制。
IESG 注意：
请注意，本备忘录是作者的个人努力。本文件反映了互联网当前的非正式做法。IETF 移动 IP 工作组正在努力提供一个合适的提议标准来解决这个问题。
梗概
本文档讨论了使用 IPv4 协议/有效负载封装与 IP 安全和其他协议进行隧道传输的实现技术。
1、 简介
IPv4封装协议/有效负载[RFC-1700] 中的 IP 长期以来一直用于桥接具有不相交功能或策略的 Internet 部分。本文档描述了业余分组无线电网络多年来用于加入大型移动网络的实施技术，以及 IP 安全协议的早期实施。
在 IP 封装中使用 IP 不同于后来的隧道技术（例如，协议号 98 [RFC-1241]、94 [IDM91a]、53 [swIPe] 和 47 [RFC-1701]），因为它不插入自己的IP 报文头之间的特殊固定报文头。取而代之的是，保留了原始未经修饰的 IP 报文头，并简单地包装在另一个标准 IP 报文头中。
此信息主要适用于 IP 版本 4 的封装。其他 IP 版本将在单独的文档中描述。
2、 封装
封装技术相当简单。在原始 IP 报文头之前添加一个外部 IP 报文头。它们之间是路径的任何其他报文头，例如特定于隧道配置的安全报文头。
外部 IP 报文头 Source 和 Destination 标识隧道的“端点”。内部 IP 报头 Source 和 Destination 标识数据报的原始发送者和接收者。
每个报文头使用 IP 协议值 [RFC-1700] 链接到下一个报文头。
IP 头的格式在 [RFC-791] 中描述。
从内部 IP 报文头复制的服务类型。可选地，可以在合作对等体之间使用另一个 TOS。
这符合透明原则，即如果用户期望给定的服务级别，那么隧道应该提供相同的服务。但是，作为政策问题，可能会专门构建一些隧道以提供不同级别的服务。
Identification：鉴别，为每个外部 IP 报文头生成一个新编号。
封装的数据报文可能已经被分片，并且由于隧道封装可能会发生另一级别的分片。这些隧道分片将由解封装器重新组装，而不是最终目的地。
Reserved：保留，忽略（设置为零）。
这个非官方标志已经被实验使用，虽然它保留在内部 IP 报文头中，但不会影响隧道。
Don't Fragment：不要分片。从内部 IP 报文头复制。这允许发起者控制性能权衡的水平。请参阅“隧道 MTU 发现”。
More Fragments：更多分片。分片时根据需要设置。
不复制标志的原因与使用单独标识的原因相同。
Time To Live：生存时间。在最近的“Assigned Numbers”[RFC-1700] 中指定的默认值。这确保了意外的长隧道不会中断端点之间的数据包流。
内层TTL在封装前递减一次，不受解封装影响。
Protocol：协议。
下一个报文头；4 用于内部 IP 报头，当没有使用中间隧道报头时。
Source：源地址。与用于发送数据报的接口关联的 IP 地址。
Destination：目的地址。隧道解封装器的 IP 地址。
Options：选项。
不是从内部 IP 报文头复制的。但是，可以添加特定于路径的新选项。
Timestamp、Loose Source Route、Strict Source Route 和 Record Route 被故意隐藏在隧道内。通常，建造隧道是为了克服这些选择的不足之处。
任何支持的内部 IP 报文头的安全选项风格都可能影响隧道安全选项的选择。预计不会有此类选项与为隧道选择的选项或安全报文头的一对一映射。
3、 隧道管理
隧道内部的其中一个路由器在处理数据报时可能会遇到错误，导致它向隧道 IP 源的封装器返回 ICMP [RFC-792] 错误消息。不幸的是，ICMP 只要求 IP 路由器在 IP 报头之外返回 8 个字节（64 位）的数据包。这不足以包含整个封装的报文头。因此，封装路由器通常不可能立即将 ICMP 消息从隧道内部反射回始发主机。
但是，通过仔细维护其隧道的“软状态”，封装器可以在大多数情况下返回准确的 ICMP 消息。路由器应该至少维护以下关于每个隧道的软状态信息：
- 隧道尽头的可达性。
- 隧道拥塞。
- 隧道MTU。
路由器使用它从隧道内部接收到的 ICMP 消息来更新该隧道的软状态信息。当随后将通过隧道的数据报到达时，路由器检查隧道的软状态。如果数据报会违反隧道的状态（例如设置 Don't Fragment 时 MTU 大于隧道 MTU），路由器将适当的 ICMP 错误消息发送回始发者，同时将数据报转发到隧道。尽管返回错误消息，仍转发数据报可确保了解隧道状态的变化。
使用这种技术，来自封装路由器的 ICMP 错误消息不会总是与隧道中遇到的错误一一对应，但它们会准确地反映网络的状态。
3.1、 隧道 MTU 发现
当发起方设置 Don't Fragment 位并将其复制到外部 IP 报文头中时，将从报告给封装器的 ICMP（类型 3 代码 4）“数据报太大”错误中获知隧道的正确 MTU。为了支持使用此功能的始发主机，所有实现必须在其隧道内支持路径 MTU 发现 [RFC-1191, RFC-1435]。
作为隧道 MTU 发现的一个好处，由于封装报文头的大小而发生的任何分段在封装后仅执行一次。这防止了单个数据包的多个分片，从而提高了路径路由器和隧道解封装器的处理效率。
3.2、 拥塞
隧道软状态将收集拥塞指示，例如来自解封装器（隧道对等体）的数据报中的 ICMP（类型 4）源抑制。当将另一个数据报转发到隧道中时，将 Source Quench 消息发送给始发者是合适的。
3.3、 路由失败
因为每次封装数据报时都会重置 TTL，所以当隧道内的路由环路再次到达封装器时，它们尤其危险。如果 IP 源与它的任何接口匹配，则实现不得进一步封装。相反，数据包被正常转发。
ICMP (Type 11) Time Exceeded 消息报告隧道本身内的路由环路。ICMP (Type 3) Destination Unreachable 消息向解封装器报告传递失败。这个软状态必须作为（类型 3 代码 0）网络不可达报告给发起者。
3.4、 其他 ICMP 消息
大多数 ICMP 错误消息与隧道的使用无关。特别是，参数问题很可能是封装器配置错误的结果，不得向发起者报告。
4、 安全注意事项
本备忘录简要讨论了安全问题。隧道的使用可以避免一些较旧的 IP 安全选项（标签），但会更好地支持较新的 IP 安全报文头。
5、 参考
[IDM91a] Ioannidis, J., Duchamp, D., Maguire, G., "IP-based protocols for mobile internetworking", Proceedings of SIGCOMM '91, ACM, September 1991. [RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981. [RFC-792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, USC/Information Sciences Institute, September 1981. [RFC-1191] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, DECWRL, Stanford University, November 1990. [RFC-1241] Mills, D., and R. Woodburn, "A Scheme for an Internet Encapsulation Protocol: Version 1", UDEL, July 1991. [RFC-1435] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, FTP Software, March 1993. [RFC-1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [RFC-1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [swIPe] Ioannidis, J., and Blaze, M., "The Architecture and Implementation of Network-Layer Security Under Unix", Fourth Usenix Security Symposium Proceedings, October 1993.
致谢
IP 隧道的这些实现细节在很大程度上源自 Phil Karn 和 TCP-Group 业余爱好者在 1990 年使用 KA9Q NOS 进行的独立工作。
特别感谢 John Ioannidis（当时的哥伦比亚大学）的灵感和实验，开始了最近一轮的 IP 移动性和 IP 安全性开发。部分文本来自 [IDM91a] 和 [swIPe]。
Steve Deering (Xerox PARC) 在“Simple Internet Protocol”中也描述了报文头的链接。
整个组织结构和部分文本来自 [RFC-1241]，由 David Mills（U Delaware）和 Robert Woodburn（SAIC）编写。
一些关于隧道软状态的文本来自 Robert E. Gilligan、Erik Nordmark 和 Bob Hinden（均来自 Sun Microsystems）的“IP 地址封装 (IP Address Encapsulation，IPAE)”。
