[要約] RFC 7690は、ICMPv6パケットが大きすぎる場合の近接ミスに関するものであり、その目的は、ネットワークのパフォーマンスと信頼性を向上させるために、ICMPv6 PTBメッセージの処理方法を改善することです。
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.
このドキュメントでは、ECMPv6タイプ2の "Packet Too Big"（PTB）メッセージを目的の宛先（通常はサーバー）にECMP負荷分散またはエニーキャストネットワークアーキテクチャで配信する際の問題に注意を向けています。このクラスの障害に対処するために使用できる運用上の軽減策について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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].
一般的なインターネットサービスの運営者は、インフラストラクチャの拡張に関連する複雑な課題に直面しています。 1つのスケーリングアプローチは、等コストマルチパス（ECMP）ルーティングを利用して、着信TCPまたはUDPセッションを複数のサーバーまたはロードバランサーなどのミドルボックスにステートレスに配布することです。この方法でトラフィックを分散すると、ICMPシグナリングを処理するときに問題が発生します。具体的には、ICMPエラーは、対応するTCPまたはUDPセッションと同じ宛先にECMPを介してハッシュされることが保証されていません。これが運用上特に問題となるケースは、パス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メッセージは、宛先として負荷分散されたエニーキャストアドレスを持ち、ステートレスに負荷分散されます。サーバーの1つ。 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
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メッセージの頻度はフロー全体に比べて小さいとされています。考えられる結論の1つは、1500 MTUパケットを伝送できないトンネル化されたIPv6展開は比較的まれであるということです。クライアントで採用されている手法（たとえば、Happy Eyeballs [RFC6555]）は、障害として識別される可能性がある場合にIPv4を優先することにより、IPv6クライアントエクスペリエンスの改善に実際に貢献する場合があります。それでも、オペレーターの期待は、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プラットフォームでは、ルートによる識別が可能な場合に、選択した宛先に対してルートごとにadvmss（アドバタイズされた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 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メッセージが誤って配信される可能性の軽減には、ICMPv6エラーメッセージが、エラーが生成されたフローを担当する同じエニーキャストサーバーに配信されるようにすることが含まれます。適切なハードウェアサポートがあれば、ICMPv6メッセージのペイロードを検査することにより、ホストと同じ手法を使用してフローを識別できます。次に、ICMPv6メッセージの内部TCPフローパラメータから識別された値を使用して、ECMPハッシュ計算を実行できます。カプセル化されたIPヘッダーはICMPメッセージの固定オフセットで発生するため、十分なヘッダー処理機能を備えたルーターがその範囲までペイロードを解析できる可能性の範囲外ではありません。ポリシールーティング後または各ロードバランサー/サーバーで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.
別の緩和策は、メッセージが意図されたものがフローと一致し、ルートキャッシュを新しいMTUで更新できること、およびデバイスがそれを実行できないことを前提として、すべてのエニーキャストサーバーにPTBメッセージを配信することを前提としています。フローと一致すると、これらのパケットが破棄されます。このような配布は、注意深く使用しないと、リソースの消費と自己申告によるサービス拒否（DOS）に重大な影響を与える可能性があります。幸いにも、この問題が発生するフローの数は、実際の展開では比較的少ないことがわかっています（たとえば、1 Gbps以上のHTTPSで10 pp以下）。過剰なメッセージ量を破棄する賢明なイングレスレートリミッターを適用して、非常に大規模なエニーキャストサーバー層を保護することもできます。
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.
別の方法として、1280バイトのMTUに対応するために、TCP MSSを1220に下げることが適切な場合があります。ホストはアドレスファミリによってTCP MSSを個別に設定できず、IPv4に影響を与える可能性があるため、またはMSDをエンドシステムから独立してクランプするためにミドルボックスを使用する必要があるため、これは望ましくないと考えています。潜在的に、拡張ヘッダーは、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に一致し、1つ以上のルーターに直接接続されている特定のサブネット上のネクストホップに一致します。フィルターは適切な制限にポリシングされます（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：ff）に転送します。これは、ルーターが（IPv6で）同じパケットを複数のユニキャストネクストホップに転送できないために必要でした。
4. Anycasted servers receive the PTB error and process the packet as needed.
4. エニーキャストサーバーはPTBエラーを受け取り、必要に応じてパケットを処理します。
A simple Python scapy [SCAPY] script that can perform the ICMPv6 proxy reflection is included.
ICMPv6プロキシリフレクションを実行できる単純なPython scapy [SCAPY]スクリプトが含まれています。
#!/usr/bin/python
from scapy.all import *
scapy.allインポートから*
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 main():
sniff(prn=icmp6_callback, filter="icmp6 \
and (ip6[40+0] == 2)", store=0)
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エラーをすべてのインターフェイスでリッスンします。既存のイーサネットソースを削除し、イーサネットブロードキャストアドレスの新しいイーサネット宛先を書き換えます。次に、結果のフレームを、エニーキャストサーバーが存在するVLANに接続されているp2p1およびp2p2インターフェイスに送信します。
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:
icmp6トラフィックに一致し、ブロードキャストトラフィックには一致せず、10 ppsのレート制限を課し、ターゲットの宛先に渡すip6tables / nftablesルールの例は、次のようになります。
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. ルックアッププロセス内に十分な容量があるルーターは、ICMPv6ペイロードのL3またはL4ヘッダーを介して、ICMPヘッダーのビットオフセット32で始まるすべてを解析できます。ハッシュの要素をフローの内側方向に一致するように並べ替えることにより、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（Forwarding Information Base）は、必要なすべてのネクストホップを含むマルチキャスト配信ツリーでプログラムでき、ユニキャスト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、「Path MTU Discovery for IP version 6」、RFC 1981、DOI 10.17487 / RFC1981、1996年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、「Packetization Layer Path MTU Discovery」、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、「Happy Eyeballs：Success with Dual-Stack Hosts」、RFC 6555、DOI 10.17487 / RFC6555、2012年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カポレイ、ハワイ州アメリカ合衆国
Email: suckawha@gmail.com
Matt Hite Evernote Redwood City, CA United States
Matt Hite Evernote Redwood City、CAアメリカ合衆国
Email: mhite@hotmail.com
Joel Jaeggli Fastly Mountain View, CA United States
Joel Jaeggli Fastly Mountain View、CAアメリカ合衆国
Email: joelja@gmail.com