Internet Engineering Task Force (IETF) M. Byerly
Request for Comments: 7690 Fastly
Category: Informational M. Hite
ISSN: 2070-1721 Evernote
J. Jaeggli
Fastly
January 2016
Internet Engineering Task Force (IETF) M. Byerly
Request for Comments: 7690 Fastly
Category: Informational M. Hite
ISSN: 2070-1721 Evernote
J. Jaeggli
Fastly
January 2016
Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB))
ICMP类型2的近距离接触（ICMPv6数据包太大（PTB））的未遂事件）
Abstract
摘要
This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination (typically the server) in ECMP load-balanced or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failures.
本文档提请注意在ECMP负载平衡或选播网络体系结构中，将ICMPv6类型2“数据包太大”（PTB）消息传递到预期目的地（通常是服务器）的问题。它讨论了可用于解决此类故障的操作缓解措施。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7690.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7690.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Alternative Mitigations . . . . . . . . . . . . . . . . . 5
3.2. Implementation . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Alternative Implementation . . . . . . . . . . . . . 6
4. Improvements . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Informative References . . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Alternative Mitigations . . . . . . . . . . . . . . . . . 5
3.2. Implementation . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Alternative Implementation . . . . . . . . . . . . . 6
4. Improvements . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Informative References . . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
Operators of popular Internet services face complex challenges associated with scaling their infrastructure. One scaling approach is to utilize equal-cost multipath (ECMP) routing to perform stateless distribution of incoming TCP or UDP sessions to multiple servers or to middle boxes such as load balancers. Distribution of traffic in this manner presents a problem when dealing with ICMP signaling. Specifically, an ICMP error is not guaranteed to hash via ECMP to the same destination as its corresponding TCP or UDP session. A case where this is particularly problematic operationally is path MTU discovery (PMTUD) [RFC1981].
流行互联网服务的运营商面临着与扩展其基础设施相关的复杂挑战。一种扩展方法是利用等成本多路径（ECMP）路由将传入的TCP或UDP会话无状态分发到多个服务器或负载平衡器等中间设备。在处理ICMP信令时，以这种方式分配流量会出现问题。具体地说，ICMP错误不保证通过ECMP散列到与其对应的TCP或UDP会话相同的目标。这在操作上特别有问题的一种情况是路径MTU发现（PMTUD）[RFC1981]。
A common application for stateless load balancing of TCP or UDP flows is to perform an initial subdivision of flows in front of a stateful load-balancer tier or multiple servers so that the workload becomes divided into manageable fractions of the total number of flows. The flow division is performed using ECMP forwarding and a stateless but sticky algorithm for hashing across the available paths (see [RFC2991] for background on ECMP routing). For the purposes of flow distribution, this next-hop selection is a constrained form of anycast topology, where all anycast destinations are equidistant from the upstream router responsible for making the last next-hop forwarding decision before the flow arrives on the destination device. In this approach, the hash is performed across some set of available protocol headers. Typically, these headers may include all or a subset of (IPv6) Flow-Label, IP-source, IP-destination, protocol, source-port, destination-port, and potentially others such as ingress interface.
TCP或UDP流的无状态负载平衡的常见应用程序是在有状态负载平衡器层或多个服务器前面执行流的初始细分，以便将工作负载划分为流总数中可管理的部分。使用ECMP转发和无状态但粘性的算法在可用路径上进行散列来执行流划分（有关ECMP路由的背景信息，请参阅[RFC2991]）。为了流分布的目的，该下一跳选择是选播拓扑的约束形式，其中所有选播目的地与负责在流到达目的地设备之前做出最后一跳转发决策的上游路由器的距离相等。在这种方法中，哈希是跨一些可用的协议头集执行的。通常，这些报头可能包括（IPv6）流标签、IP源、IP目的地、协议、源端口、目的地端口的全部或子集，以及可能的其他，例如入口接口。
A problem common to this approach of distribution through hashing is impact on path MTU discovery. An ICMPv6 type 2 PTB message generated on an intermediate device for a packet sent from a server that is part of an ECMP load-balanced service to a client will have the load-balanced anycast address as the destination and hence will be statelessly load balanced to one of the servers. While the ICMPv6 PTB message contains as much of the packet that could not be forwarded as possible, the payload headers are not considered in the forwarding decision and are ignored. Because the PTB message is not identifiable as part of the original flow by the IP or upper-layer packet headers, the results of the ICMPv6 ECMP hash calculation are unlikely to be hashed to the same next hop as packets matching the TCP or UDP ECMP hash of the flow.
这种通过散列进行分发的方法的一个常见问题是对路径MTU发现的影响。在中间设备上为作为ECMP负载平衡服务一部分的服务器发送到客户端的数据包生成的ICMPv6 2类PTB消息将以负载平衡选播地址作为目的地，因此将无状态地负载平衡到其中一台服务器。虽然ICMPv6 PTB消息包含尽可能多的无法转发的数据包，但在转发决策中不考虑有效负载标头，因此会忽略这些标头。由于PTB消息无法通过IP或上层数据包头识别为原始流的一部分，因此ICMPv6 ECMP哈希计算的结果不太可能散列到与流的TCP或UDP ECMP哈希匹配的数据包相同的下一跳。
An example packet flow and topology follow. The packet for which the PTB message was generated was intended for the client.
下面是一个示例数据包流和拓扑。为其生成PTB消息的数据包是针对客户端的。
ptb -> router ecmp -> next hop L4/L7 load balancer -> destination
ptb -> router ecmp -> next hop L4/L7 load balancer -> destination
router --> load balancer 1 --->
\\--> load balancer 2 ---> load-balanced service
\--> load balancer N --->
router --> load balancer 1 --->
\\--> load balancer 2 ---> load-balanced service
\--> load balancer N --->
Figure 1
图1
The router ECMP decision is used because it is part of the forwarding architecture, can be performed at line rate, and does not depend on shared state or coordination across a distributed forwarding system that may include multiple linecards or routers. The ECMP routing decision is deterministic with respect to packets having the same computed hash.
使用路由器ECMP决策是因为它是转发架构的一部分，可以以线路速率执行，并且不依赖于可能包括多个线路卡或路由器的分布式转发系统的共享状态或协调。ECMP路由决定对于具有相同计算哈希的数据包是确定的。
A typical case in which ICMPv6 PTB messages are received at the load balancer is where the path MTU from the client to the load balancer is limited by a tunnel of which the client itself is not aware.
在负载平衡器处接收ICMPv6 PTB消息的典型情况是，从客户端到负载平衡器的路径MTU受到客户端本身不知道的隧道的限制。
Direct experience says that the frequency of PTB messages is small compared to total flows. One possible conclusion is that tunneled IPv6 deployments that cannot carry 1500 MTU packets are relatively rare. Techniques employed by clients (e.g., Happy Eyeballs [RFC6555]) may actually contribute some amelioration to the IPv6 client experience by preferring IPv4 in cases that might be identified as failures. Still, the expectation of operators is that PMTUD should work and that unnecessary breakage of client traffic should be avoided.
直接经验表明，与总流量相比，PTB消息的频率很低。一个可能的结论是，无法承载1500 MTU数据包的隧道式IPv6部署相对较少。客户端采用的技术（例如，Happy Eyball[RFC6555]）实际上可能有助于改善IPv6客户端体验，因为在可能被确定为失败的情况下，它们更倾向于使用IPv4。不过，运营商的期望是PMTUD应该工作，并且应该避免不必要的客户端流量中断。
A final observation regarding server tuning is that it is not always possible, even if it is potentially desirable to be able to independently set the TCP MSS (Maximum Segment Size) for different address families on some end systems. On Linux platforms, advmss (advertised mss) may be set on a per-route basis for selected destinations in cases where discrimination by route is possible.
关于服务器调优的最后一个观察结果是，即使可能希望能够为某些终端系统上的不同地址族独立设置TCP MSS（最大段大小），也并非总是可能的。在Linux平台上，在可能存在路由歧视的情况下，可以为选定的目的地按路由设置ADVMS（广告mss）。
The problem as described does also impact IPv4; however, implementation of RFC 4821 [RFC4821] TCP MTU probing, the ability to fragment on the wire at tunnel ingress points, and the relative rarity of sub-1500-byte MTUs that are not coupled to changes in client behavior (for example, endpoint VPN clients set the tunnel interface MTU accordingly to avoid fragmentation for performance reasons) makes the problem sufficiently rare that some existing deployments have chosen to ignore it.
上述问题也会影响IPv4；然而，RFC 4821[RFC4821]TCP MTU探测的实现、在隧道入口点在线路上分段的能力，以及与客户端行为变化无关的子1500字节MTU的相对稀少性（例如，端点VPN客户端相应地设置隧道接口MTU，以避免因性能原因而分段）使问题变得非常罕见，以至于一些现有部署选择忽略它。
Mitigation of the potential for PTB messages to be misdelivered involves ensuring that an ICMPv6 error message is distributed to the same anycast server responsible for the flow for which the error is generated. With appropriate hardware support, flows could be identified using the same technique as hosts by inspecting the payload of the ICMPv6 message. The ECMP hash calculation can then be performed using values identified from the inner TCP flow parameters of the ICMPv6 message. Because the encapsulated IP header occurs at a fixed offset in the ICMP message, it is not outside the realm of
减少PTB消息误发的可能性包括确保将ICMPv6错误消息分发到负责生成错误的流的同一选播服务器。通过适当的硬件支持，可以使用与主机相同的技术，通过检查ICMPv6消息的有效负载来识别流。然后，可以使用从ICMPv6消息的内部TCP流参数识别的值来执行ECMP哈希计算。由于封装的IP报头出现在ICMP消息中的固定偏移量处，因此它不在
possibility that routers with sufficient header processing capability could parse that far into the payload. Employing a mediation device that handles the parsing and distribution of PTB messages after policy routing or on each load balancer / server is a possibility.
具有足够报头处理能力的路由器可能会将其解析到有效负载中。在策略路由之后或在每个负载平衡器/服务器上使用中介设备来处理PTB消息的解析和分发是一种可能性。
Another mitigation approach is predicated upon distributing the PTB message to all anycast servers under the assumption that the one for which the message was intended will be able to match it to the flow and update the route cache with the new MTU and that devices not able to match the flow will discard these packets. Such distribution has potentially significant implications for resource consumption and for self-inflicted denial of service (DOS) if not carefully employed. Fortunately, we have observed that the number of flows for which this problem occurs is relatively small in real-world deployments (for example, 10 or fewer pps on 1 Gbit/s or more worth of HTTPS); sensible ingress rate limiters that will discard excessive message volume can be applied to protect even very large anycast server tiers with the potential for fallout limited to circumstances of deliberate duress.
另一种缓解方法基于将PTB消息分发到所有选播服务器，前提是消息所针对的服务器将能够将其与流匹配，并使用新的MTU更新路由缓存，并且不能与流匹配的设备将丢弃这些包。如果不小心使用，这种分布可能会对资源消耗和自我造成的拒绝服务（DOS）产生重大影响。幸运的是，我们观察到，在实际部署中，出现此问题的流的数量相对较少（例如，在1 Gbit/s或更高价值的HTTPS上，10个或更少的pps）；可应用可丢弃过多消息量的合理进入速率限制器来保护即使是非常大的选播服务器层，其潜在影响仅限于故意胁迫的情况。
As an alternative, it may be appropriate to lower the TCP MSS to 1220 in order to accommodate 1280-byte MTU. We consider this undesirable, as hosts may not be able to independently set TCP MSS by address family thereby impacting IPv4, or alternatively that middle-boxes need to be employed to clamp the MSS independently from the end systems. Potentially, extension headers might further alter the lower bound that the MSS would have to be set to, making clamping even more undesirable.
作为替代方案，可能适合将TCP MSS降低到1220以容纳1280字节的MTU。我们认为这是不希望的，因为主机可能无法独立地通过地址族来设置TCP MSS从而影响IPv4，或者替代地，需要使用中间盒来独立地从终端系统钳位MSS。扩展头可能会进一步改变MSS必须设置的下限，从而使箝位更加不受欢迎。
1. Filter-based forwarding matches next-header ICMPv6 type 2 and matches a next hop on a particular subnet directly attached to one or more routers. The filter is policed to reasonable limits (we chose 1000 pps; more conservative rates might be required in other implementations).
1. 基于筛选器的转发匹配下一个标头ICMPv6类型2，并匹配直接连接到一个或多个路由器的特定子网上的下一个跃点。过滤器被控制在合理的限度内（我们选择1000 pps；在其他实现中可能需要更保守的速率）。
2. The filter is applied on the input side of all external (Internet- or customer-facing) interfaces.
2. 过滤器应用于所有外部（互联网或面向客户）接口的输入端。
3. A proxy located at the next hop forwards ICMPv6 type 2 packets it receives to an Ethernet broadcast address (example ff:ff:ff:ff:ff:ff) on all specified subnets. This was necessitated by router inability (in IPv6) to forward the same packet to multiple unicast next hops.
3. 位于下一跳的代理将接收到的ICMPv6类型2数据包转发到所有指定子网上的以太网广播地址（例如ff:ff:ff:ff:ff）。这是由于路由器无法（在IPv6中）将同一数据包转发到多个单播下一跳所必需的。
4. Anycasted servers receive the PTB error and process the packet as needed.
4. Anycasted服务器接收PTB错误并根据需要处理数据包。
A simple Python scapy [SCAPY] script that can perform the ICMPv6 proxy reflection is included.
包含一个简单的Python scapy[scapy]脚本，可以执行ICMPv6代理反射。
#!/usr/bin/python
#!/usr/bin/python
from scapy.all import *
从斯卡皮来的，都是进口货*
IFACE_OUT = ["p2p1", "p2p2"]
IFACE_OUT = ["p2p1", "p2p2"]
def icmp6_callback(pkt):
if pkt.haslayer(IPv6) and (ICMPv6PacketTooBig in pkt) \
and pkt[Ether].dst != 'ff:ff:ff:ff:ff:ff':
del(pkt[Ether].src)
pkt[Ether].dst = 'ff:ff:ff:ff:ff:ff'
pkt.show()
for iface in IFACE_OUT:
sendp(pkt, iface=iface)
def icmp6_callback(pkt):
if pkt.haslayer(IPv6) and (ICMPv6PacketTooBig in pkt) \
and pkt[Ether].dst != 'ff:ff:ff:ff:ff:ff':
del(pkt[Ether].src)
pkt[Ether].dst = 'ff:ff:ff:ff:ff:ff'
pkt.show()
for iface in IFACE_OUT:
sendp(pkt, iface=iface)
def main():
sniff(prn=icmp6_callback, filter="icmp6 \
and (ip6[40+0] == 2)", store=0)
def main():
sniff(prn=icmp6_callback, filter="icmp6 \
and (ip6[40+0] == 2)", store=0)
if __name__ == '__main__':
main()
if __name__ == '__main__':
main()
This example script listens on all interfaces for IPv6 PTB errors being forwarded using filter-based forwarding. It removes the existing Ethernet source and rewrites a new Ethernet destination of the Ethernet broadcast address. It then sends the resulting frame out the p2p1 and p2p2 interfaces that are attached to VLANs where our anycast servers reside.
此示例脚本在所有接口上侦听使用基于筛选器的转发转发的IPv6 PTB错误。它删除现有的以太网源并重写以太网广播地址的新以太网目标。然后，它将生成的帧发送到p2p1和p2p2接口，这些接口连接到我们的选播服务器所在的VLAN。
Alternatively, network designs in which a common layer 2 network exists on the ECMP hop could distribute the proxy onto the end systems, eliminating the need for policy routing. They could then rewrite the destination -- for example, using iptables before forwarding the packet back to the network containing all of the server or load-balancer interfaces. This implementation can be done entirely within the Linux iptables firewall. Because of the distributed nature of the filter, more conservative rate limits are required than when a global rate limit can be employed.
或者，ECMP跃点上存在公共第2层网络的网络设计可以将代理分发到终端系统，从而消除策略路由的需要。然后，他们可以重写目的地——例如，在将数据包转发回包含所有服务器或负载平衡器接口的网络之前，使用iptables。此实现完全可以在Linux iptables防火墙内完成。由于滤波器的分布特性，需要比使用全局速率限制时更保守的速率限制。
An example ip6tables/nftables rule to match icmp6 traffic, not match broadcast traffic, impose a rate limit of 10 pps, and pass to a target destination would resemble:
示例ip6tables/nftables规则匹配icmp6流量，不匹配广播流量，施加10 pps的速率限制，并传递到目标目的地，类似于：
ip6tables -I INPUT -i lo -p icmpv6 -m icmpv6 --icmpv6-type 2/0 \
-m pkttype ! --pkt-type broadcast -m limit --limit 10/second \
-j TEE 2001:DB8::1
ip6tables -I INPUT -i lo -p icmpv6 -m icmpv6 --icmpv6-type 2/0 \
-m pkttype ! --pkt-type broadcast -m limit --limit 10/second \
-j TEE 2001:DB8::1
As with the scapy example, once the destination has been rewritten from a hardcoded ND entry to an Ethernet broadcast address -- in this case to an IPv6 documentation address -- the traffic will be reflected to all the hosts on the subnet.
与scapy示例一样，一旦目的地从硬编码的ND条目重写为以太网广播地址（在本例中为IPv6文档地址），流量将反映到子网上的所有主机。
There are several ways that improvements could be made to improve handling ECMP load balancing of ICMPv6 PTB messages. Little in the way of change to the Internet protocol specification is required; rather, we foresee practical implementation change, which, insofar as we are aware, does not exist in current router, switch, or layer 3/4 load balancers. Alternatively, improved behavior on the part of client/server detection of path MTU in band could render the behavior of devices in the path irrelevant.
有几种方法可以改进ICMPv6 PTB消息的ECMP负载平衡处理。几乎不需要对互联网协议规范进行更改；相反，我们预见到实际的实现变化，就我们所知，这在当前的路由器、交换机或3/4层负载平衡器中并不存在。或者，客户机/服务器检测带内路径MTU的行为改进可能会导致路径中设备的行为不相关。
1. Routers with sufficient capacity within the lookup process could parse all the way through the L3 or L4 header in the ICMPv6 payload beginning at bit offset 32 of the ICMP header. By reordering the elements of the hash to match the inward direction of the flow, the PTB error could be directed to the same next hop as the incoming packets in the flow.
1. 在查找过程中具有足够容量的路由器可以从ICMP报头的位偏移量32开始解析ICMPv6有效负载中的L3或L4报头。通过重新排序散列元素以匹配流的向内方向，PTB错误可以被定向到与流中的传入数据包相同的下一跳。
2. The FIB (Forwarding Information Base) on the router could be programmed with a multicast distribution tree that includes all of the necessary next hops, and unicast ICMPv6 packets could be policy routed to these destinations.
2. 路由器上的FIB（转发信息库）可以编程为包含所有必要下一跳的多播分发树，单播ICMPv6数据包可以策略路由到这些目的地。
3. Ubiquitous implementation of RFC 4821 [RFC4821] Packetization Layer Path MTU Discovery would probably go a long way towards reducing dependence on ICMPv6 PTB by end systems.
3. RFC 4821[RFC4821]打包层路径MTU发现的普遍实现可能会大大减少终端系统对ICMPv6 PTB的依赖。
The employed mitigation has the potential to greatly amplify the impact of a deliberately malicious sending of ICMPv6 PTB messages. Sensible ingress rate limiting can reduce the potential for impact; legitimate PMTUD messages may be lost once the rate limit is reached. The scenario where drops of legitimate traffic occur is analogous to other cases where DOS traffic can crowd out legitimate traffic, however only a limited subset of overall traffic is impacted.
所采用的缓解措施有可能大大放大故意恶意发送ICMPv6 PTB消息的影响。合理的入口速率限制可以降低潜在的影响；一旦达到速率限制，合法的PMTUD消息可能会丢失。发生合法流量下降的场景类似于DOS流量可以挤出合法流量的其他情况，但是只影响总流量的有限子集。
The proxy replication results in all devices on the subnet receiving ICMPv6 PTB errors, even those not associated with the flow. This could arguably result in information disclosure due to the wide replication of the ICMPv6 PTB error on the subnet and the large fragment of the offending IP packet embedded in the ICMPv6 error. Because of this, recipient machines should be in a common administrative domain.
代理复制会导致子网上的所有设备接收到ICMPv6 PTB错误，即使是与流无关的设备。由于ICMPv6 PTB错误在子网上广泛复制，且ICMPv6错误中嵌入了大量有问题的IP数据包，因此这可能会导致信息泄露。因此，收件人计算机应位于公共管理域中。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，DOI 10.17487/RFC19811996年8月<http://www.rfc-editor.org/info/rfc1981>.
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/RFC2991, November 2000, <http://www.rfc-editor.org/info/rfc2991>.
[RFC2991]Thaler，D.和C.Hopps，“单播和多播下一跳选择中的多路径问题”，RFC 2991，DOI 10.17487/RFC2991，2000年11月<http://www.rfc-editor.org/info/rfc2991>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 4821，DOI 10.17487/RFC4821，2007年3月<http://www.rfc-editor.org/info/rfc4821>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012, <http://www.rfc-editor.org/info/rfc6555>.
[RFC6555]Wing，D.和A.Yourtchenko，“快乐眼球：双堆栈主机的成功”，RFC 6555，DOI 10.17487/RFC65552012年4月<http://www.rfc-editor.org/info/rfc6555>.
[SCAPY] Scapy, <http://www.secdev.org/projects/scapy/>.
[SCAPY]SCAPY<http://www.secdev.org/projects/scapy/>.
Acknowledgements
致谢
The authors thank Marak Majkowsiki for contributing text, examples, and a very thorough review. The authors would like to thank Mark Andrews, Brian Carpenter, Nick Hilliard, and Ray Hunter, for review.
作者感谢Marak Majkowsiki提供的文本、示例和非常透彻的评论。作者要感谢马克·安德鲁斯、布赖恩·卡彭特、尼克·希利亚德和雷·亨特的评论。
Authors' Addresses
作者地址
Matt Byerly Fastly Kapolei, HI United States
Matt Byerly Fastly Kapolei，你好，美国
Email: suckawha@gmail.com
Email: suckawha@gmail.com
Matt Hite Evernote Redwood City, CA United States
Matt Hite Evernote美国加利福尼亚州红木市
Email: mhite@hotmail.com
Email: mhite@hotmail.com
Joel Jaeggli Fastly Mountain View, CA United States
乔尔·贾格利·法斯特利山景，美国加利福尼亚州
Email: joelja@gmail.com
Email: joelja@gmail.com