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
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）のために近隣探索で定義された概念ホスト送信アルゴリズムから「オンリンク仮定」の除去の背後にある歴史的な背景情報について説明します。ホストのデフォルトルータリストが空の場合、元々、説明したようなアルゴリズムによると、ホストは、すべての宛先がオンリンクであることを前提としています。これは、オフリンク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]で説明したアルゴリズムのバージョンでは、ホストのデフォルトルータリストが空である場合、ホストはすべての宛先がオンリンクであることを前提としていることを述べています。このメモは、更新近隣探索の仕様[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サービスを持たないネットワークに接続されています。このようなシステムは、AAAAレコードをDNS名を解決し、彼らが到達不能の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上で実行する必要があり、そのリンク層アドレスの解決は、ホストがパケットを送信先のアドレスです。アプリケーションには3秒未満（MAX_MULTICAST_SOLICIT * RETRANS_TIMER）ではありません、少なくともアドレス解決が失敗したまでではなかっオンリンクされている目的地の到達不能の確認応答を受信しません。これは大幅にトランスポートプロトコル遅延によって増幅されます。例えば、[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.
アプリケーションは、少なくとも一つの到達可能なIPv4アドレスに続くオフリンク到達不能なIPv6アドレスの大きなリストを持っている場合、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:
複数のリンクに接続されたノード上の送信アルゴリズムのこの局面を実装するには、no定義された方法はありません。具体的には、問題は、ノードがIPv6宛先アドレスにパケットを送信することに直面しているときに生じることがない経路を有していない、および送信ノードが複数のリンクに取り付けられています。オンリンク仮定すると、このノードは、宛先がオンリンクが、そのリンク上にあることを前提として？ビューの実装の観点から、マルチインタフェースノード上のオンリンク仮定の顔で先にIPv6パケットを送信する処理する3つの方法があります。
1. Attempt to send the packet on a single link (either administratively pre-defined or using some algorithm).
単一のリンク（管理事前定義されたまたはいくつかのアルゴリズムを使用してのいずれか）にパケットを送信するための1試み。
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番目のオプションは、宛先に到達に成功したが、実装がより複雑になり、正しい送信先を選ぶことが保証されていない可能性があります。例えば、同じアドレスで構成さ複数のノード、異なるリンクを介して各到達可能性があります。それ自体でアドレスは、送信者が実際に到達したかった先明確なので、予想される宛先に到達することは保証されません全てのリンクにパケットを送信しようとしません。第三の選択肢は、パケットをドロップし、すべてのリンク上の仮定をしていないことと同じです。目的地へのルートが存在しない場合は、他の言葉では、パケットを送信しようとしません。このように動作の実装は、このように曖昧さを排除し、目的地への到達性を持たせるために目的地へのルートを設定するには、管理者が必要となります。
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近隣探索信頼モデルと脅威の4.2.2項で説明した近隣探索プロトコル[RFC3756]にセキュリティ上の脆弱性を紹介します。ホストのルータが悪意を持って、ホストがオンリンクのすべてのパケットの送信を開始させるために殺されることを恐れがあります。攻撃者は、ホストと同じリンク上にパケットを送信することにより、オフリンクノードになりすますことができます。脆弱性は、[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ソフトウェアソリューションは、（彼らのセキュリティポリシーは、単にIPv6パケットをドロップしません）明らかに地元メディアにIPv6パケットを送信することが観察されています。システムは、特定のパケットを暗号化し、カプセル化するVPNソフトウェアを使用して1つのイーサネットインタフェースを持っているシナリオを考えてみましょう。システムは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."
6.3.6（「デフォルトルータの選択」）での箇条書き項目3）が除去されました。アイテムは、読んで「デフォルトルータリストが空の場合は、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]ブレーデン、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.シンプソン、 "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.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、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.、ケンプ、J.、およびE. Nordmarkと、 "IPv6近隣探索（ND）信頼モデルと脅威"、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.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
Appendix A. Acknowledgments
付録A.謝辞
The authors gratefully acknowledge the contributions of Jim Bound, Spencer Dawkins, Tony Hain, Mika Liljeberg, Erik Nordmark, Pekka Savola, and Ronald van der Pol.
作者は感謝してバウンドジム、スペンサードーキンス、トニーハイン、ミカLiljeberg、エリックNordmarkと、ペッカSavola、およびロナルドファンデルポールの貢献を認めます。
Authors' Addresses
著者のアドレス
Sebastien Roy Sun Microsystems, Inc. 1 Network Drive UBUR02-212 Burlington, MA 01803
セバスチャン・ロイサン・マイクロシステムズ株式会社1ネットワークドライブUBUR02-212バーリントン、MA 01803
EMail: sebastien.roy@sun.com
メールアドレス：sebastien.roy@sun.com
Alain Durand Comcast 1500 Market Street Philadelphia, PA 19102
アラン・デュランComcastの1500マーケットストリートフィラデルフィア、PA 19102
EMail: alain_durand@cable.comcast.com
メールアドレス：alain_durand@cable.comcast.com
James Paugh Nominum, Inc. 2385 Bay Road Redwood City, CA 94063
ジェームズPaughノミナム社2385ベイロードレッドウッドシティー、CA 94063
EMail: jim.paugh@nominum.com
メールアドレス：jim.paugh@nominum.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。