[要約] 要約：RFC 4943は、IPv6ネイバー発見におけるオンリンク前提の問題を指摘し、改善策を提案している。 目的：IPv6ネットワークにおけるネイバー発見の信頼性とセキュリティを向上させるため、オンリンク前提の問題を解決することを目指している。
Network Working Group S. Roy
Request for Comments: 4943 Sun Microsystems, Inc.
Category: Informational A. Durand
Comcast
J. Paugh
Nominum, Inc.
September 2007
IPv6 Neighbor Discovery On-Link Assumption Considered Harmful
IPv6 Neighbor Discovery On-Link仮定は有害と見なされます
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems and how these problems outweigh the benefits of this part of the conceptual sending algorithm.
このドキュメントでは、IPバージョン6（IPv6）の近隣発見で定義された概念ホストを送信する概念ホストからの「オンリンクの仮定」の削除の背後にある履歴および背景情報について説明します。最初に説明したアルゴリズムによると、ホストのデフォルトルーターリストが空の場合、ホストはすべての宛先がリンクしていると想定しています。これは、Off-Link IPv6接続（デフォルトのルーターなし）を持たないIPv6対応ノードで特に問題があります。このドキュメントでは、この仮定を行うことで問題を引き起こす方法と、これらの問題が概念送信アルゴリズムのこの部分の利点をどのように上回るかについて説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background on the On-link Assumption . . . . . . . . . . . . . 2
3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. First Rule of Destination Address Selection . . . . . . . . 3
3.2. Delays Associated with Address Resolution . . . . . . . . . 3
3.3. Multi-interface Ambiguity . . . . . . . . . . . . . . . . . 4
3.4. Security-Related Issues . . . . . . . . . . . . . . . . . . 4
4. Changes to RFC 2461 . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7
Neighbor Discovery for IPv6 [RFC4861] defines a conceptual sending algorithm for hosts. The version of the algorithm described in [RFC2461] states that if a host's default router list is empty, then the host assumes that all destinations are on-link. This memo documents the removal of this assumption in the updated Neighbor Discovery specification [RFC4861] and describes the reasons why this assumption was removed.
IPv6 [RFC4861]の近隣発見は、ホストの概念送信アルゴリズムを定義します。[RFC2461]で説明されているアルゴリズムのバージョンは、ホストのデフォルトルーターリストが空である場合、ホストはすべての目的地がリンクであると想定していると述べています。このメモは、更新されたNeighbor Discovery Specification [RFC4861]におけるこの仮定の削除を文書化し、この仮定が削除された理由を説明しています。
This assumption is problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity. This is typical when systems that have IPv6 enabled on their network interfaces (either on by default or administratively configured that way) are attached to networks that have no IPv6 services such as off-link routing. Such systems will resolve DNS names to AAAA and A records, and they may attempt to connect to unreachable IPv6 off-link nodes.
この仮定は、オフリンクIPv6接続を持たないIPv6対応ノードで問題があります。これは、ネットワークインターフェイスでIPv6が有効になっているシステム（デフォルトではその方法で管理上に構成されている）がオフリンクルーティングなどのIPv6サービスを持たないネットワークに添付されている場合に典型的です。このようなシステムは、DNS名をAAAAおよびレコードに解決し、到達不可能なIPv6オフリンクノードに接続しようとする場合があります。
The on-link assumption creates problems for destination address selection as defined in [RFC3484], and it adds connection delays associated with unnecessary address resolution and neighbor unreachability detection. The behavior associated with the assumption is undefined on multi-interface nodes and has some subtle security implications. All of these issues are discussed in this document.
オンリンクの仮定は、[RFC3484]で定義されている宛先アドレスの選択の問題を作成し、不必要なアドレス解像度と近隣の到達可能性検出に関連する接続遅延を追加します。仮定に関連する動作は、マルチインターフェイスノードで未定義であり、いくつかの微妙なセキュリティへの影響があります。これらの問題はすべて、このドキュメントで説明されています。
This part of Neighbor Discovery's [RFC2461] conceptual sending algorithm was created to facilitate communication on a single link between systems configured with different global prefixes in the absence of an IPv6 router. For example, consider the case where two systems on separate links are manually configured with global addresses and are then plugged in back-to-back. They can still communicate with each other via their global addresses because they'll correctly assume that each is on-link.
近隣ディスカバリーの[RFC2461]の概念送信アルゴリズムのこの部分は、IPv6ルーターの存在下で異なるグローバルプレフィックスで構成されたシステム間の単一のリンクでの通信を容易にするために作成されました。たとえば、個別のリンク上の2つのシステムがグローバルアドレスで手動で構成され、その後バックツーバックに接続される場合を検討してください。彼らはそれぞれがリンクしていると正しく想定するため、彼らのグローバルアドレスを介して互いに通信することができます。
Without the on-link assumption, the above scenario wouldn't work, and the systems would need to be configured to share a common prefix such as the link-local prefix. On the other hand, the on-link assumption introduces several problems to various parts of the networking stack described in Section 3. As such, this document points out that the problems introduced by the on-link assumption outweigh the benefit that the assumption lends to this scenario. It is more beneficial to the end user to remove the on-link assumption from Neighbor Discovery and declare this scenario illegitimate (or a misconfiguration).
オンリンクの仮定がなければ、上記のシナリオは機能しません。また、システムは、リンクローカルプレフィックスなどの共通のプレフィックスを共有するように構成する必要があります。一方、オンリンクの仮定は、セクション3で説明されているネットワークスタックのさまざまな部分にいくつかの問題を導入します。そのため、この文書は、オンリンクの仮定によって導入された問題が、仮定が貸す利益を上回ることを指摘しています。このシナリオ。エンドユーザーにとって、近隣の発見からオンリンクの仮定を削除し、このシナリオを非合法（または誤解）と宣言することがより有益です。
The on-link assumption causes the following problems.
オンリンクの仮定は、次の問題を引き起こします。
Default Address Selection for IPv6 [RFC3484] defines a destination address selection algorithm that takes an unordered list of destination addresses as input and produces a sorted list of destination addresses as output. The algorithm consists of destination address sorting rules, the first of which is "Avoid unusable destinations". The idea behind this rule is to place unreachable destinations at the end of the sorted list so that applications will be least likely to try to communicate with those addresses first.
IPv6 [RFC3484]のデフォルトアドレスの選択は、宛先アドレスの順序付けられていないリストを入力として取得し、宛先アドレスのソート付きリストを出力として作成する宛先アドレス選択アルゴリズムを定義します。アルゴリズムは、宛先アドレスの並べ替えルールで構成されており、最初は「使用不可能な目的地を避ける」ことです。このルールの背後にあるアイデアは、ソートされたリストの最後に到達不可能な目的地を配置することで、アプリケーションが最初にそれらのアドレスと通信しようとする可能性が最も低くなることです。
The on-link assumption could potentially cause false positives when attempting unreachability determination for this rule. On a network where there is no IPv6 router (all off-link IPv6 destinations are unreachable), the on-link assumption states that destinations are assumed to be on-link. An implementation could interpret that as, if the default router list is empty, then all destinations are reachable on-link. This may cause the rule to prefer an unreachable IPv6 destination over a reachable IPv4 destination.
この規則の到達不能の決定を試みる場合、リンク上の仮定は、潜在的に誤検知を引き起こす可能性があります。IPv6ルーターがないネットワーク（すべてのオフリンクIPv6宛先は到達不可能です）では、オンリンクの仮定は、目的地がオンリンクであると想定されていると述べています。実装では、デフォルトのルーターリストが空の場合、すべての宛先がリンクで到達可能であると解釈できます。これにより、ルールは到達可能なIPv4宛先よりも到達不可能なIPv6宛先を好む可能性があります。
Users expect that applications quickly connect to a given destination regardless of the number of IP addresses assigned to that destination. If a destination name resolves to multiple addresses and the application attempts to communicate to each address until one succeeds, this process shouldn't take an unreasonable amount of time. It is therefore important that the system quickly determine if IPv6 destinations are unreachable so that the application can try other destinations when those IPv6 destinations are unreachable.
ユーザーは、アプリケーションがその宛先に割り当てられたIPアドレスの数に関係なく、特定の宛先にすばやく接続することを期待しています。宛先名が複数のアドレスに解決し、アプリケーションが成功するまで各アドレスと通信しようとする場合、このプロセスは不合理な時間をかけるべきではありません。したがって、システムは、IPv6の宛先が到達できないかどうかを迅速に判断することが重要です。これにより、これらのIPv6の宛先が到達できない場合にアプリケーションが他の宛先を試すことができます。
For an IPv6-enabled host deployed on a network that has no IPv6 routers, the result of the on-link assumption is that link-layer address resolution must be performed on all IPv6 addresses to which the host sends packets. The application will not receive acknowledgment of the unreachability of destinations that are not on-link until at least address resolution has failed, which is no less than 3 seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER). This is greatly amplified by transport protocol delays. For example, [RFC1122] Section 4.2.3.5 requires that TCP retransmit for at least 3 minutes before aborting the connection attempt.
IPv6ルーターを持たないネットワークに展開されたIPv6対応ホストの場合、オンリンクの仮定の結果は、ホストがパケットを送信するすべてのIPv6アドレスでリンク層アドレス解像度を実行する必要があることです。アプリケーションは、少なくとも住所解決が失敗するまでリンクしていない目的地の到達不能性の認識を受け取りません。これは、輸送プロトコルの遅延によって大幅に増幅されます。たとえば、[RFC1122]セクション4.2.3.5では、接続試行を中止する前に少なくとも3分間TCPの再送信を要求します。
When the application has a large list of off-link unreachable IPv6 addresses followed by at least one reachable IPv4 address, the delay associated with Neighbor Unreachability Detection (NUD) of each IPv6 address before successful communication with the IPv4 address is unacceptable.
アプリケーションにオフリンクの到達不可能なIPv6アドレスの大きなリストが続いて少なくとも1つの到達可能なIPv4アドレスが続く場合、IPv4アドレスとの通信が成功する前に、各IPv6アドレスの近隣の到達性検出（NUD）に関連する遅延は受け入れられません。
There is no defined way to implement this aspect of the sending algorithm on a node that is attached to multiple links. Specifically, a problem arises when a node is faced with sending a packet to an IPv6 destination address to which it has no route, and the sending node is attached to multiple links. With the on-link assumption, this node assumes that the destination is on-link, but on which link? From an implementor's point of view, there are three ways to handle sending an IPv6 packet to a destination in the face of the on-link assumption on a multi-interface node:
複数のリンクに接続されているノードに送信アルゴリズムのこの側面を実装する定義された方法はありません。具体的には、ノードがルートのないIPv6宛先アドレスにパケットを送信することに直面し、送信ノードが複数のリンクに接続されている場合に問題が発生します。オンリンクの仮定により、このノードは、宛先がオンリンクであると想定していますが、どのリンクですか？実装者の観点から、マルチインターフェイスノードのオンリンク仮定に直面して、IPv6パケットの送信を宛先に処理する3つの方法があります。
1. Attempt to send the packet on a single link (either administratively pre-defined or using some algorithm).
1. パケットを単一のリンクで送信しようとします（管理上定義されているか、アルゴリズムを使用して）。
2. Attempt to send the packet on every link.
2. すべてのリンクでパケットを送信しようとします。
3. Drop the packet.
3. パケットをドロップします。
If the destination is indeed on-link, the first option might not succeed since the wrong link could be picked. The second option might succeed in reaching the destination but is more complex to implement and isn't guaranteed to pick the correct destination. For example, there could be more than one node configured with the same address, each reachable through a different link. The address by itself does not disambiguate which destination the sender actually wanted to reach, so attempting to send the packet to every link is not guaranteed to reach the anticipated destination. The third option, dropping the packet, is equivalent to not making the on-link assumption at all. In other words, if there is no route to the destination, don't attempt to send the packet. An implementation that behaves this way would require an administrator to configure routes to the destination in order to have reachability to the destination, thus eliminating the ambiguity.
宛先が実際にリンクしている場合、間違ったリンクを選択できるため、最初のオプションが成功しない可能性があります。2番目のオプションは目的地に到達することに成功する可能性がありますが、実装がより複雑であり、正しい目的地を選択することは保証されていません。たとえば、同じアドレスで構成された複数のノードがあり、それぞれが異なるリンクを介して到達可能です。住所自体は、送信者が実際にどのような目的地に到達したいかを明確にしないため、すべてのリンクにパケットを送信しようとすると、予想される目的地に到達することは保証されません。3番目のオプションであるパケットを削除することは、オンリンクの仮定をまったく作成しないことと同等です。言い換えれば、目的地へのルートがない場合は、パケットを送信しようとしないでください。この方法で動作する実装では、管理者が目的地に到達可能性を持つために宛先へのルートを構成する必要があり、曖昧さを排除します。
The on-link assumption discussed here introduces a security vulnerability to the Neighbor Discovery protocol described in Section 4.2.2 of IPv6 Neighbor Discovery Trust Models and Threats [RFC3756] titled "Default router is 'killed'". There is a threat that a host's router can be maliciously killed in order to cause the host to start sending all packets on-link. The attacker can then spoof off-link nodes by sending packets on the same link as the host. The vulnerability is discussed in detail in [RFC3756].
ここで説明するリンクの仮定は、「デフォルトルーターは「殺された」」というタイトルのIPv6 Neighbor Discovery Trustモデルと脅威[RFC3756]のセクション4.2.2で説明されている近隣発見プロトコルにセキュリティの脆弱性を導入します。ホストがリンクですべてのパケットの送信を開始するために、ホストのルーターが悪意を持って殺される可能性があるという脅威があります。攻撃者は、ホストと同じリンクにパケットを送信することにより、オフリンクノードをスプーフィングできます。脆弱性については、[RFC3756]で詳しく説明しています。
Another security-related side-effect of the on-link assumption has to do with virtual private networks (VPNs). It has been observed that some commercially available VPN software solutions that don't support IPv6 send IPv6 packets to the local media in the clear (their security policy doesn't simply drop IPv6 packets). Consider a scenario where a system has a single Ethernet interface with VPN software that encrypts and encapsulates certain packets. The system attempts to send a packet to an IPv6 destination that it obtained by doing a DNS lookup, and the packet ends up going in the clear to the local media. A malicious third party could then spoof the destination on-link.
オンリンクの仮定の別のセキュリティ関連の副作用は、仮想プライベートネットワーク（VPN）に関係しています。IPv6をサポートしない市販のVPNソフトウェアソリューションは、ClearでIPv6パケットをローカルメディアに送信することが観察されています（セキュリティポリシーは単にIPv6パケットをドロップするわけではありません）。システムに、特定のパケットを暗号化およびカプセル化するVPNソフトウェアを使用した単一のイーサネットインターフェイスがあるシナリオを考えてみましょう。システムは、DNSルックアップを行うことで取得したIPv6宛先にパケットを送信しようとし、パケットは地元のメディアにクリアになります。悪意のあるサードパーティは、リンクで目的地を吹き込むことができます。
The following changes have been made to the Neighbor Discovery specification between [RFC2461] and [RFC4861]:
[RFC2461]と[RFC4861]の間の近隣発見仕様に以下の変更が加えられました。
The last sentence of the second paragraph of Section 5.2 ("Conceptual Sending Algorithm") was removed. This sentence was, "If the Default Router List is empty, the sender assumes that the destination is on-link."
セクション5.2（「概念送信アルゴリズム」）の2番目の段落の最後の文が削除されました。この文は、「デフォルトのルーターリストが空の場合、送信者は宛先がオンリンクであると想定しています。」
Bullet item 3) in Section 6.3.6 ("Default Router Selection") was removed. The item read, "If the Default Router List is empty, assume that all destinations are on-link as specified in Section 5.2."
弾丸項目3）セクション6.3.6（「デフォルトルーターの選択」）が削除されました。アイテムには、「デフォルトのルーターリストが空の場合、すべての宛先がセクション5.2で指定されているようにリンクがオンになっていると仮定します。」
APPENDIX A was modified to remove on-link assumption related text in bullet item 1) under the discussion on what happens when a multihomed host fails to receive Router Advertisements.
付録Aは、弾丸項目1）のリンクの仮定関連のテキストを削除するように変更されました。
The result of these changes is that destinations are considered unreachable when there is no routing information for that destination (through a default router or otherwise). Instead of attempting link-layer address resolution when sending to such a destination, a node should send an ICMPv6 Destination Unreachable message (code 0 - no route to destination) message up the stack.
これらの変更の結果、その宛先のルーティング情報がない場合（デフォルトのルーターなど）、目的地は到達不能と見なされます。このような宛先に送信するときにリンク層アドレス解像度を試みる代わりに、ノードはICMPV6宛先の到達不可能なメッセージ（コード0-宛先へのルートなし）をスタックに送信する必要があります。
The removal of the on-link assumption from Neighbor Discovery addresses all of the security-related vulnerabilities of the protocol as described in Section 3.4.
近隣発見からのオンリンク仮定の削除は、セクション3.4で説明されているように、プロトコルのセキュリティ関連の脆弱性のすべてに対処します。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756] Nikander、P.、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trustモデルと脅威」、RFC 3756、2004年5月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
The authors gratefully acknowledge the contributions of Jim Bound, Spencer Dawkins, Tony Hain, Mika Liljeberg, Erik Nordmark, Pekka Savola, and Ronald van der Pol.
著者は、ジム・バウンド、スペンサー・ドーキンス、トニー・ハイン、ミカ・リルジェバーグ、エリック・ノードマーク、ペッカ・サヴォラ、ロナルド・ファン・デル・ポルの貢献に感謝します。
Authors' Addresses
著者のアドレス
Sebastien Roy Sun Microsystems, Inc. 1 Network Drive UBUR02-212 Burlington, MA 01803
Sebastien Roy Sun Systems、Inc。1ネットワークドライブUBUR02-212バーリントン、マサチューセッツ州01803
EMail: sebastien.roy@sun.com
Alain Durand Comcast 1500 Market Street Philadelphia, PA 19102
Alain Durand Comcast 1500 Market Street Philadelphia、PA 19102
EMail: alain_durand@cable.comcast.com
James Paugh Nominum, Inc. 2385 Bay Road Redwood City, CA 94063
James Paugh Nominum、Inc。2385 Bay Road Redwood City、CA 94063
EMail: jim.paugh@nominum.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。