[要約] 要約：RFC 6104は、IPv6ネットワークにおける不正なルーター広告の問題を説明しています。 目的：このRFCの目的は、不正なルーター広告による攻撃やネットワークの混乱を防ぐために、IPv6ネットワークの管理者に対して対策を提案することです。
Internet Engineering Task Force (IETF) T. Chown
Request for Comments: 6104 University of Southampton
Category: Informational S. Venaas
ISSN: 2070-1721 Cisco Systems
February 2011
Rogue IPv6 Router Advertisement Problem Statement
Rogue IPv6ルーター広告問題ステートメント
Abstract
概要
When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements (RAs) to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the RA message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this document, we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed.
IPv6のみを展開するとき、IPv6のみであろうとデュアルスタックであろうと、ルーターはIPv6ルーター広告（RAS）を送信するように構成されており、ネットワーク上で自動構成できるノードに情報を伝達します。この情報には、RAメッセージの観測されたソースアドレスから取得した暗黙のデフォルトルーターアドレスと、オンリンクプレフィックス情報が含まれます。ただし、ユーザーまたは管理者による意図しない誤解、またはネットワークに対する悪意のある攻撃は、偽のRAが存在する可能性があり、ネットワーク上のホストの運用上の問題を引き起こす可能性があります。このドキュメントでは、不正なRAが観察されるシナリオを要約し、問題に対する可能な解決策のリストを提示します。テキストの不正なRAの意図しない原因に焦点を当てています。このテキストの目標は、情報を提供することであり、そのため、ソリューションを提案および議論できるフレームワークを提示することです。
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/rfc6104.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6104で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
2. Bogus RA Scenarios ..............................................4
2.1. Administrator Misconfiguration .............................5
2.2. User Misconfiguration ......................................5
2.3. Malicious Misconfiguration .................................5
3. Methods to Mitigate against Rogue RAs ...........................6
3.1. Manual Configuration .......................................6
3.2. Introducing RA Snooping ....................................6
3.3. Using ACLs on Managed Switches .............................7
3.4. SEcure Neighbor Discovery (SEND) ...........................7
3.5. Router Preference Option ...................................8
3.6. Relying on Layer 2 Admission Control .......................8
3.7. Using Host-Based Packet Filters ............................8
3.8. Using an "Intelligent" Deprecation Tool ....................8
3.9. Using Layer 2 Partitioning .................................9
3.10. Adding Default Gateway/Prefix Options to DHCPv6 ...........9
4. Scenarios and Mitigations ......................................10
5. Other Related Considerations ...................................11
5.1. Unicast RAs ...............................................11
5.2. The DHCP versus RA Threat Model ...........................11
5.3. IPv4-Only Networks ........................................12
5.4. Network Monitoring Tools ..................................12
5.5. Recovering from Bad Configuration State ...................12
5.6. Isolating the Offending Rogue RA Source ...................13
6. Conclusions ....................................................13
7. Security Considerations ........................................14
8. Acknowledgments ................................................14
9. Informative References .........................................15
The Neighbor Discovery protocol [RFC4861] describes the operation of IPv6 Router Advertisements (RAs) that are used to determine node configuration information during the IPv6 autoconfiguration process, whether that node's configuration is stateful, via the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] or stateless, as per [RFC4862], possibly in combination with DHCPv6 Light [RFC3736].
Neighbor Discovery Protocol [RFC4861]は、IPv6の構成がIPv6（DHCPV6）の動的ホスト構成プロトコルを介して、Nodeの構成がステートフルであるかどうかにかかわらず、IPv6 Autoconfigurationプロセス中にノード構成情報を決定するために使用されるIPv6ルーター広告（RAS）の動作を説明しています[DHCPV6）[[RFC4862]によると、RFC3315]またはステートレス、おそらくDHCPV6光[RFC3736]と組み合わせて。
In observing the operation of deployed IPv6 networks, it is apparent that there is a problem with undesired or "bogus" IPv6 RAs appearing on network links or subnets. By "bogus" we mean RAs that were not the intended configured RAs, but rather RAs that have appeared for some other reason. While the problem appears more common in shared wireless environments, it is also seen on wired enterprise networks.
展開されたIPv6ネットワークの操作を観察する際に、ネットワークリンクまたはサブネットに表示される望ましくないまたは「偽物」IPv6 RAに問題があることは明らかです。「偽物」とは、意図された構成されたRASではなく、他の理由で現れたRASであったRAを意味します。この問題は共有ワイヤレス環境でより一般的であるように見えますが、有線エンタープライズネットワークでも見られます。
The problem with rogue RAs is that they can cause partial or complete failure of operation of hosts on an IPv6 link. For example, the default router address is drawn directly from the source address of the RA message. In addition, rogue RAs can cause hosts to assume wrong prefixes to be used for stateless address autoconfiguration. In a case where there may be mixing of "good" and "bad" RAs, a host might keep on using the "good" default gateway, but pick a wrong source address, leading to egress filtering problems. As such, rogue RAs are an operational issue for which solution(s) are required, and for which best practice needs to be conveyed. This not only includes preventing or detecting rogue RAs, but also where necessary ensuring the network (and hosts on the network) have the ability to quickly recover from a state where host configuration is incorrect as a result of processing such an RA.
Rogue RASの問題は、IPv6リンクでホストの操作の部分的または完全な操作の故障を引き起こす可能性があることです。たとえば、デフォルトのルーターアドレスは、RAメッセージのソースアドレスから直接描画されます。さらに、Rogue RAは、ホストが間違ったプレフィックスを使用して、ステートレスアドレスの自動構成に使用されると仮定することができます。「良い」と「悪い」RASを混合している場合がある場合、ホストは「良い」デフォルトゲートウェイを使用し続けるかもしれませんが、間違ったソースアドレスを選択して、出口フィルタリングの問題につながります。そのため、Rogue RAは、解決策が必要であり、ベストプラクティスを伝える必要がある運用上の問題です。これには、不正なRAの防止または検出が含まれるだけでなく、必要に応じてネットワーク（およびネットワーク上のホスト）がそのようなRAを処理した結果、ホスト構成が正しくない状態から迅速に回復することができるようにすることも含まれます。
In the next section, we discuss the scenarios that may give rise to rogue RAs being present. In the following section, we present some candidate solutions for the problem, some of which may be more practical to deploy than others. This document focuses on "accidental" rogue RAs; while malicious RAs are of course also possible, the common problem today lies with unintended RAs. In addition, a network experiencing malicious attack of this kind is likely to also experience malicious Neighbor Advertisement (NA) and related messages.
次のセクションでは、Rogue Rasが存在する可能性のあるシナリオについて説明します。次のセクションでは、問題の候補ソリューションをいくつか紹介しますが、その一部は他のものよりも展開するのがより実用的かもしれません。このドキュメントは、「偶発的な」不正なRasに焦点を当てています。もちろん、悪意のあるRAも可能ですが、今日の一般的な問題は意図しないRAにあります。さらに、この種の悪意のある攻撃を経験しているネットワークは、悪意のある隣人広告（NA）および関連するメッセージを経験する可能性があります。
There are three broad classes of scenario in which bogus RAs may be introduced to an IPv6 network.
Fogus RASがIPv6ネットワークに導入される可能性のある3つの幅広いクラスのシナリオがあります。
Here an administrator incorrectly configures RAs on a router interface, causing incorrect RAs to appear on links and causing hosts to generate incorrect or unintended IPv6 address, gateway, or other information. In such a case, the default gateway may be correct, but a host might for example become multiaddressed, possibly with a correct and incorrect address based on a correct and incorrect prefix. There is also the possibility of other configuration information being misconfigured, such as the lifetime option.
ここで、管理者はルーターインターフェイスにRASを誤って構成し、誤ったRAがリンクに表示され、ホストが間違ったまたは意図しないIPv6アドレス、ゲートウェイ、またはその他の情報を生成します。そのような場合、デフォルトのゲートウェイは正しい場合がありますが、たとえば、ホストは多面化されている場合があります。おそらく、正しい接頭辞に基づいて正しく誤ったアドレスがあります。また、Lifetimeオプションなど、他の構成情報が誤解される可能性もあります。
In the case of a Layer 2 IEEE 802.1Q Virtual LAN (VLAN) misconfiguration, RAs may "flood" to unintended links, causing hosts or more than one link to potentially become incorrectly multiaddressed, with possibly two different default routers available.
レイヤー2 IEEE 802.1Q仮想LAN（VLAN）の誤解の場合、RASは意図しないリンクに「浸水」し、ホストまたは複数のリンクが潜在的に誤って多重化される可能性があり、おそらく2つの異なるデフォルトのルーターが利用可能になります。
In this case, a user's device "accidentally" transmits RAs onto the local link, potentially adding an additional default gateway and associated prefix information.
この場合、ユーザーのデバイスは「誤って」RAをローカルリンクに送信し、追加のデフォルトゲートウェイと関連するプレフィックス情報を追加する可能性があります。
This seems to typically be seen on wireless (though sometimes wired) networks where a laptop has enabled the Windows Internet Connection Sharing (ICS) service, which can turn a host into a 6to4 [RFC3056] gateway; this can be a useful feature, unless of course it is run when not intended. This service can also cause IPv4 problems, as it will typically start a "rogue" DHCPv4 server on the host.
これは通常、ラップトップがWindowsインターネット接続共有（ICS）サービスを有効にしたワイヤレス（時には有線）ネットワークで見られるようです。もちろん、意図していないときに実行されない限り、これは有用な機能になります。また、このサービスはIPv4の問題を引き起こす可能性があります。これは、通常、ホストで「Rogue」DHCPV4サーバーを起動するためです。
We have also had reports that hosts may not see genuine IPv6 RAs on a link due to host firewalls, causing them to turn on a connection-sharing service and 6to4 as a result. In some cases, more technical users may also use a laptop as a home gateway (e.g., again a 6to4 gateway) and then connect to another network, forgetting their previous gateway configuration is still active.
また、ホストファイアウォールのためにホストがリンクに本物のIPv6 RASが表示されない可能性があるという報告があり、結果として接続共有サービスと6to4をオンにすることができます。場合によっては、より多くのテクニカルユーザーがホームゲートウェイとしてラップトップを使用し（たとえば、再び6to4ゲートウェイ）、別のネットワークに接続して、以前のゲートウェイ構成を忘れることもアクティブです。
There are also reported incidents in enterprise networks of users physically plugging Ethernet cables into the wrong sockets and bridging two subnets together, causing a problem similar to VLAN flooding.
また、ユーザーのエンタープライズネットワークには、イーサネットケーブルを間違ったソケットに物理的にプラグインし、2つのサブネットを一緒に橋渡しすることが報告されており、VLAN洪水と同様の問題が発生します。
Here an attacker is deliberately generating RAs on the local network in an attempt to perform some form of denial-of-service or man-in-the-middle attack.
ここで、攻撃者は、何らかの形のサービス拒否または中間攻撃を実行するために、ローカルネットワーク上で意図的にRAを生成しています。
As stated above, while this is a genuine concern for network administrators, there have been few if any reports of such activity, while in contrast reports of accidental rogue RAs are very commonplace. In writing this text, and with the feedback of the v6ops working group, we came to the conclusion that the issue of malicious attack, due to the other complementary attacks that are likely to be launched using rogue NA and similar messages, are best considered by further work and document(s). As a result, this text intends to provide informational guidance for operators looking for practical measures to take to avoid "accidental" rogue RAs on their own networks.
上記のように、これはネットワーク管理者にとって真の関心事ですが、そのような活動の報告はほとんどありませんが、対照的に偶発的な不正なRAの報告は非常に一般的です。このテキストを書く際、およびV6OPSワーキンググループのフィードバックにより、Rogue NAおよび同様のメッセージを使用して起動する可能性のある他の補完的な攻撃により、悪意のある攻撃の問題は、それによって最もよく考慮されるという結論に達しました。さらなる作業と文書。その結果、このテキストは、独自のネットワークで「偶発的な」不正なRAを避けるために取るための実用的な手段を探しているオペレーターに情報ガイダンスを提供する予定です。
In this section, we present a summary of methods suggested to date for reducing or removing the possibility of rogue RAs being seen on a network.
このセクションでは、ネットワークでRogue Rasが見られる可能性を減らすか削除するために、これまで提案された方法の概要を示します。
The default gateway and host address can usually be manually configured on a node. This of course can be a resource intensive solution, and also prone to administrative mistakes in itself.
通常、デフォルトゲートウェイとホストアドレスは、ノードで手動で構成できます。もちろん、これはリソース集中的なソリューションであり、それ自体が管理上の間違いになりやすくなります。
Manual configuration implies that RA processing is disabled. Most operating systems allow RA messages to be ignored, such that if an IPv6 address is manually configured on a system, an additional global autoconfigured address will not be added should an unexpected RA appear on the link.
手動構成は、RA処理が無効になっていることを意味します。ほとんどのオペレーティングシステムにより、RAメッセージを無視することができます。これにより、IPv6アドレスがシステム上で手動で構成されている場合、リンクに予期しないRAが表示された場合、追加のグローバルオートコンチュートアドレスが追加されません。
It should be possible to implement "RA snooping" in Layer 2 switches in a similar way to DHCP snooping, such that RAs observed from incorrect sources are blocked or dropped, and not propagated through a subnet. One candidate solution in this space, called "RA-Guard" [RFC6105], has been proposed. This type of solution has appeal because it is a familiar model for enterprise network managers, but it can also be used to complement SEcure Neighbor Discovery (SEND) [RFC3971], by a switch acting as a SEND proxy for hosts.
誤ったソースから観察されたRAがブロックまたはドロップされ、サブネットを介して伝播されないように、DHCPスヌーピングと同様の方法でレイヤー2スイッチに「RAスヌーピング」を実装することができるはずです。「RA-Guard」[RFC6105]と呼ばれるこのスペースの1つの候補ソリューションが提案されています。このタイプのソリューションには、エンタープライズネットワークマネージャーにとって馴染みのあるモデルであるため、アピールがありますが、ホストの送信プロキシとして機能するスイッチによって、安全な近隣発見（送信）[RFC3971]を補完するためにも使用できます。
This type of solution may not be applicable everywhere, e.g., in environments where there are not centrally controlled or manageable switches.
このタイプのソリューションは、中央制御または管理可能なスイッチがない環境では、どこにでも適用できない場合があります。
Certain switch platforms can already implement some level of rogue RA filtering by the administrator configuring Access Control Lists (ACLs) that block RA ICMP messages that might be inbound on "user" ports. Again this type of "solution" depends on the presence of such configurable switches.
特定のスイッチプラットフォームは、「ユーザー」ポートにインバウンドする可能性のあるRA ICMPメッセージをブロックするアクセス制御リスト（ACL）を構成する管理者によるある程度のRogue RAフィルタリングを既に実装できます。繰り返しますが、このタイプの「ソリューション」は、そのような構成可能なスイッチの存在に依存します。
A recent document describes the RA message format(s) for filtering [IPv6-AUTOCFG-FILTER]. The document also notes requirements for DHCPv6 snooping, which can then be implemented similarly to DHCPv4 snooping.
最近のドキュメントでは、[IPv6-Autocfg-filter]をフィルタリングするためのRAメッセージ形式について説明しています。このドキュメントは、DHCPV6スヌーピングの要件も記録しており、DHCPV4スヌーピングと同様に実装できます。
The SEcure Neighbor Discovery (SEND) [RFC3971] protocol provides a method for hosts and routers to perform secure Neighbor Discovery. Thus, it can in principle protect a network against rogue RAs.
Secure Neighbor Discovery（SEND）[RFC3971]プロトコルは、ホストとルーターが安全な隣接発見を実行する方法を提供します。したがって、原則として、ローグRASからネットワークを保護できます。
SEND is not yet widely used at the time of writing, in part because there are very few implementations of the protocol. Some other deployment issues have been raised, though these are likely to be resolved in due course. For example, routers probably don't want to use autogenerated addresses (which might need to be protected by ACLs), so SEND needs to be shown to work with non-autogenerated addresses. Also, it has been argued that there are "bootstrapping" issues, in that hosts wanting to validate router credentials (e.g., to a certificate server or Network Time Protocol (NTP) server) are likely to need to communicate via the router for that information.
Sendは、執筆時点ではまだ広く使用されていません。これは、プロトコルの実装が非常に少ないためです。他のいくつかの展開の問題が提起されていますが、これらはやがて解決される可能性があります。たとえば、ルーターはおそらく自動生成アドレスを使用したくない（ACLSによって保護する必要がある場合がある）ため、送信は非自称アドレスで動作するように表示する必要があります。また、ルーターの資格情報を検証したいホスト（例：証明書サーバーまたはネットワークタイムプロトコル（NTP）サーバー）では、その情報についてはルーターを介して通信する必要がある可能性が高いと主張されています。。
Further, it's not wholly clear how widely adopted SEND could or would be in site networks with "lightweight" security (e.g., many campus networks), especially where hosts are managed by users and not administratively. Public or conference wireless networks may face similar challenges. There may also be networks, like perhaps sensor networks, where use of SEND is less practical. These networks still require rogue RA protection.
さらに、特にホストがユーザーによって管理されており、管理上ではなく、「軽量」セキュリティ（多くのキャンパスネットワークなど）を備えたサイトネットワークに広く採用されている送信がどれほど広く採用されるか、またはどの程度広く採用されるか、またはどの程度採用されるかは完全に明確ではありません。パブリックまたは会議のワイヤレスネットワークも同様の課題に直面する可能性があります。おそらくセンサーネットワークのようなネットワークもあり、送信の使用はそれほど実用的ではありません。これらのネットワークには、Rogue RA保護が依然として必要です。
While SEND clearly can provide a good, longer-term solution, especially in networks where malicious activity is a significant concern, there is a requirement today for practical solutions, and/or solutions more readily applicable in more "relaxed" environments. In the latter case, solutions like "RA snooping" or applied ACLs are more attractive now.
特に悪意のあるアクティビティが重大な懸念事項であるネットワークでは、明確で長期的なソリューションを提供できますが、今日の実用的なソリューションや、より「リラックスした」環境でより容易に適用できるソリューションには今日必要があります。後者の場合、「Ra Snooping」やApplied ACLSのようなソリューションは、現在より魅力的です。
[RFC4191] introduced a Router Preference option, such that an RA could carry one of three Router Preference values: High, Medium (default), or Low. Thus, an administrator could use "High" settings for managed RAs, and hope that "accidental" RAs would be medium priority. This of course would only work in some scenarios -- if the user who accidentally sends out a rogue RA on the network has configured their device with "High" precedence for their own intended usage, the priorities would clash. But for accidental rogue RAs caused by software like Windows ICS and 6to4, which would use the default precedence, it could be useful. Obviously this solution would also rely on clients (and routers) having implementations of the Router Preference option.
[RFC4191]は、RAが3つのルーター選好値のいずれかを搭載できるように、ルーター設定オプションを導入しました。したがって、管理者は管理されたRAに「ハイ」設定を使用し、「偶発的な」RAが中程度の優先度があることを期待できます。もちろん、これはいくつかのシナリオでのみ機能します。ネットワーク上のRogue RAを誤って送信するユーザーが、意図した使用法に対して「高い」優先順位でデバイスを構成した場合、優先順位は衝突します。しかし、Windows ICSや6TO4などのソフトウェアによって引き起こされる偶発的な不正なRAの場合、デフォルトの優先順位を使用すると、有用です。明らかに、このソリューションは、ルーター優先オプションの実装を持つクライアント（およびルーター）にも依存します。
In principle, if a technology such as IEEE 802.1x is used, devices would first need to authenticate to the network before being able to send or receive IPv6 traffic. Ideally, authentication would be mutual. Deployment of 802.1x, with mutual authentication, may however be seen as somewhat "heavyweight", akin to SEND, for some deployments.
原則として、IEEE 802.1xなどのテクノロジーを使用する場合、IPv6トラフィックを送信または受信する前に、デバイスが最初にネットワークに認証する必要があります。理想的には、認証は相互になります。しかし、相互認証を伴う802.1xの展開は、いくつかの展開のために、送信するような「ヘビー級」と見なされる場合があります。
Improving Layer 2 security may help to mitigate against an attacker's capability to join the network to send RAs, but it doesn't prevent misconfiguration issues. A user can happily authenticate and still launch a Windows ICS service, for example.
レイヤー2セキュリティの改善は、攻撃者のネットワークに参加してRASを送信する能力に対して緩和するのに役立つ場合がありますが、誤解の問題を防ぐことはできません。ユーザーは、たとえばWindows ICSサービスを喜んで認証し、引き続き起動できます。
In a managed environment, hosts could be configured via their "personal firewall" to only accept RAs from trusted sources. Hosts could also potentially be configured to discard 6to4-based RAs in a managed enterprise environment.
管理された環境では、ホストを「個人的なファイアウォール」を介して構成して、信頼できるソースからのRAのみを受け入れることができます。また、マネージドエンタープライズ環境で6to4ベースのRAを破棄するようにホストを構成する可能性があります。
However, the problem is then pushed to keeping this configuration maintained and correct. If a router fails and is replaced, possibly with a new Layer 2 interface address, the link local source address in the filter may become incorrect, and thus no method would be available to push the new information to the host over the network.
ただし、問題は、この構成を維持し、修正し続けるように推進されます。ルーターが故障して交換され、おそらく新しいレイヤー2インターフェイスアドレスに置き換えられた場合、フィルター内のリンクローカルソースアドレスが間違っている可能性があるため、ネットワーク上で新しい情報をホストにプッシュする方法はありません。
It is possible to run a daemon on a link (perhaps on the router on the link) to watch for incorrect RAs and to send a deprecating RA with a router lifetime of zero when such an RA is observed. The KAME rafixd is an example of such a tool, which has been used at IETF meetings with some success. A slightly enhanced tool called RAMOND has since been developed from this code, and is now available as a Sourceforge project. As with host-based firewalling, the daemon would need to somehow know what "good" and "bad" RAs are, from some combination of known good sources and/or link prefixes. In an environment with native IPv6, though, 6to4-based RAs would certainly be known to be rogue.
リンク（おそらくリンクのルーター）でデーモンを実行して、誤ったRAを監視し、そのようなRAが観察された場合、ルーターの寿命がゼロで廃止されたRAを送信することができます。Kame RafixDは、そのようなツールの例であり、IETF会議でいくつかの成功を収めて使用されています。ラモンドと呼ばれるわずかに拡張されたツールは、このコードから開発されており、SourceForgeプロジェクトとして利用可能になりました。ホストベースのファイアウォールと同様に、デーモンは、既知の良いソースやリンクプレフィックスの組み合わせから、「良い」と「悪い」RAが何であるかを何らかの形で知る必要があります。ただし、ネイティブIPv6の環境では、6to4ベースのRASは確かに不正であることが知られています。
Whether or not use of such a tool is the preferred method, monitoring a link for observed RAs seems prudent from a network management perspective. Some such tools exist already, e.g., NDPMon, which can also detect other undesirable behaviour.
このようなツールの使用が好ましい方法であるかどうかにかかわらず、観測されたRAのリンクを監視することは、ネットワーク管理の観点から慎重に思えます。そのようなツールはすでに存在しています。たとえば、NDPMONは、他の望ましくない動作を検出することもできます。
If each system or user on a network is partitioned into a different Layer 2 medium, then the impact of rogue RAs can be limited. In broadband networks, bridging [RFC2684] may be available, for example. The benefit may be scenario-specific, e.g., whether a given user or customer has their own network prefix or whether the provisioning is in a shared subnet or link. It is certainly desirable that any given user or customer's system(s) are unable to see RAs that may be generated by other users or customers.
ネットワーク上の各システムまたはユーザーが別のレイヤー2メディアに分割されている場合、Rogue RAの影響は制限されます。ブロードバンドネットワークでは、たとえばブリッジング[RFC2684]が利用可能になる場合があります。利点は、たとえば、特定のユーザーまたは顧客が独自のネットワークプレフィックスを持っているか、プロビジョニングが共有サブネットまたはリンクにあるかどうか、シナリオ固有のものです。特定のユーザーまたは顧客のシステムが、他のユーザーまたは顧客によって生成される可能性のあるRAを見ることができないことが確かに望ましいです。
However, such partitioning would probably increase address space consumption significantly if applied in enterprise networks, and in many cases, hardware costs and software licensing costs to enable routing to the edge can be quite significant.
ただし、このようなパーティションは、エンタープライズネットワークに適用されると、住所スペースの消費を大幅に増加させる可能性があります。多くの場合、エッジへのルーティングを有効にするためのハードウェアコストとソフトウェアライセンスコストは非常に重要です。
Adding Default Gateway and Prefix options for DHCPv6 would allow network administrators to configure hosts to only use DHCPv6 for default gateway and prefix configuration in managed networks, where RAs would be required today. A new document has proposed such a default router option, along with prefix advertisement options for DHCPv6 [DHCPv6-DEFAULT-RTR]. Even with such options added to DHCPv6, an RA is in principle still required to inform hosts to use DHCPv6.
DHCPV6のデフォルトゲートウェイとプレフィックスオプションを追加すると、ネットワーク管理者は、現在RASが必要になるマネージャーネットワークでデフォルトゲートウェイとプレフィックス構成にDHCPV6のみを使用するようにホストを構成できます。新しいドキュメントは、DHCPV6 [DHCPV6-DEFAULT-RTR]のプレフィックス広告オプションとともに、このようなデフォルトのルーターオプションを提案しています。このようなオプションがDHCPV6に追加されていても、RAは原則として、ホストにDHCPV6を使用するように通知するために必要です。
An advantage of DHCPv6 is that should an error be introduced, only hosts that have refreshed their DHCP information since that time are affected, while a multicast rogue RA will most likely affect all hosts immediately. DHCPv6 also allows different answers to be given to different hosts.
DHCPV6の利点は、エラーが導入されることであり、その間にDHCP情報を更新したホストのみが影響を受けていることですが、マルチキャストの不正なRAはすべてのホストにすぐに影響する可能性が高いことです。DHCPV6では、異なるホストに異なる回答を与えることもできます。
While making host configuration possible via DHCPv6 alone is a viable option that would allow IPv6 configuration to be done in a way similar to IPv4 today, the problem has only been shifted: rather than rogue RAs being the problem, rogue DHCPv6 servers would be an equivalent issue. As with IPv4, a network would then still require use of Authenticated DHCP, or DHCP(v6) snooping, as suggested in [IPv6-AUTOCFG-FILTER].
DHCPV6を介してホスト構成を可能にすることは、今日のIPv4と同様の方法でIPv6構成を実行できるようにする実行可能なオプションですが、問題はシフトされています。ローグRASが問題であるのではなく、Rogue DHCPV6サーバーは同等です。問題。IPv4と同様に、[IPv6-Autocfg-filter]で示唆されているように、ネットワークは認証されたDHCPまたはDHCP（V6）スヌーピングの使用が必要になります。
There is certainly some demand in the community for DHCPv6-only host configuration. While this may mitigate the rogue RA issue, it simply moves the trust problem elsewhere, albeit to a place administrators are familiar with today.
DHCPV6のみのホスト構成に対するコミュニティには確かにある程度の需要があります。これはRogue RAの問題を軽減するかもしれませんが、管理者は今日に精通しているにもかかわらず、単に他の場所で信頼の問題を移動します。
In this section, we summarise the error/misconfiguration scenarios and practical mitigation methods described above in a matrix format. We consider, for the case of a rogue multicast RA, which of the mitigation methods helps protect against administrator and user errors. For the administrator error, we discount an error in configuring the countermeasure itself; rather, we consider an administrator error to be an error in configuration elsewhere in the network.
このセクションでは、上記のマトリックス形式で説明されているエラー/ミス構成シナリオと実用的な緩和方法を要約します。不正なマルチキャストRAの場合、どの緩和方法が管理者やユーザーエラーから保護するのに役立つかを検討します。管理者エラーの場合、対策自体を構成する際のエラーを割引きます。むしろ、管理者エラーは、ネットワーク内の他の場所での構成のエラーであると考えています。
+------------------------+---------------------------+
| | Scenario |
| Mitigation |---------------------------|
| Method | Admin Error | User Error |
+------------------------+-------------+-------------+
| Manual configuration | Y | Y |
+------------------------+-------------+-------------+
| SEND | Y | Y |
+------------------------+-------------+-------------+
| RA snooping | Y | Y |
+------------------------+-------------+-------------+
| Use switch ACLs | Y | Y |
+------------------------+-------------+-------------+
| Router preference | N | Y |
+------------------------+-------------+-------------+
| Layer 2 admission | N | N |
+------------------------+-------------+-------------+
| Host firewall | Y | Y |
+------------------------+-------------+-------------+
| Deprecation daemon | Y | Y |
+------------------------+-------------+-------------+
| Layer 2 partition | N | Y |
+------------------------+-------------+-------------+
| DHCPv6 gateway option | Partly | If Auth |
+------------------------+-------------+-------------+
What the above summary does not consider is the practicality of deploying the measure. An easy-to-deploy method that buys improved resilience to rogue RAs without significant administrative overhead is attractive. On that basis, the RA snooping proposal, e.g., RA-Guard, has merit, while approaches like manual configuration are less appealing. However, RA-Guard is not yet fully defined or available, while only certain managed switch equipment may support the required ACLs.
上記の要約が考慮していないのは、測定を展開することの実用性です。重要な管理オーバーヘッドなしで、Rogue RASの回復力が改善された簡単に展開できる方法は魅力的です。それに基づいて、RAスヌーピングの提案、たとえばRa-Guardにはメリットがありますが、手動構成のようなアプローチはあまり魅力的ではありません。ただし、RA-Guardはまだ完全に定義されていないか、利用可能ではありませんが、特定の管理されたスイッチ機器のみが必要なACLをサポートする可能性があります。
There are a number of related issues that have come out of discussions on the rogue RA topic, which the authors believe are worth capturing in this document.
Rogue RAトピックに関する議論から出てきた多くの関連する問題があります。著者は、この文書で把握する価値があると考えています。
The above discussion was initially held on the assumption that rogue multicast RAs were the cause of problems on a shared network subnet. However, the specifications for Router Advertisements allow them to be sent unicast to a host, as per Section 6.2.6 of RFC 4861. If a host sending rogue RAs sends them unicast to the soliciting host, that RA may not be seen by other hosts on the shared medium, e.g., by a monitoring daemon. In most cases, though, an accidental rogue RA is likely to be multicast.
上記の議論は、Rogue Multicast RAが共有ネットワークサブネットの問題の原因であるという仮定で最初に行われました。ただし、ルーター広告の仕様により、RFC 4861のセクション6.2.6に従って、ホストにユニキャストを送信することができます。ホストがRogue RASを送信するホストが誘導ホストにユニキャストを送信すると、RAは他のホストには見えない場合があります。共有媒体、例えば、監視デーモンによる。ただし、ほとんどの場合、偶発的なローグRAはマルチキャストになる可能性があります。
Comparing the threat model for rogue RAs and rogue DHCPv6 servers is an interesting exercise. In the case of Windows ICS causing rogue 6to4-based RAs to appear on a network, it is very likely that the same host is also acting as a rogue IPv4 DHCP server. The rogue DHCPv4 server can allocate a default gateway and an address to hosts, just as a rogue RA can lead hosts to learning of a new (additional) default gateway, prefix(es), and address. In the case of multicast rogue RAs, however, the impact is potentially immediate to all hosts, while the rogue DHCP server's impact will depend on lease timers for hosts.
Rogue RasとRogue Dhcpv6サーバーの脅威モデルを比較することは、興味深い演習です。Rogue 6to4ベースのRASがネットワークに表示されるWindows ICSの場合、同じホストがRogue IPv4 DHCPサーバーとしても機能している可能性が非常に高いです。Rogue DHCPV4サーバーは、Rogue RAがホストを新しい（追加の）デフォルトゲートウェイ、プレフィックス（ES）、およびアドレスの学習に導くことができるように、デフォルトゲートウェイとホストにアドレスを割り当てることができます。ただし、マルチキャストRogue RASの場合、その影響はすべてのホストにとって潜在的に即時になりますが、Rogue DHCPサーバーの影響はホストのリースタイマーに依存します。
In principle, Authenticated DHCP can be used to protect against rogue DHCPv4 (and DHCPv6) servers, just as SEND could be used to protect against rogue IPv6 RAs. However, actual use of Authenticated DHCP in typical networks is currently minimal. Were new DHCPv6 default gateway and prefix options to be standardised as described above, then without Authenticated DHCP the (lack of) security is just pushed to another place.
原則として、認証されたDHCPを使用して、Rogue DHCPV4（およびDHCPV6）サーバーから保護することができます。ただし、一般的なネットワークでの認証されたDHCPの実際の使用は現在最小限です。上記のように標準化される新しいDHCPV6デフォルトゲートウェイとプレフィックスオプションが、認証されたDHCPなしでは、（欠如）セキュリティが別の場所に押し込まれました。
The RA-Guard approach is essentially using a similar model to DHCP message snooping to protect against rogue RAs in network (switch) equipment. As noted above, DHCPv6 message snooping would also be very desirable in IPv6 networks.
RAガードアプローチは、基本的にDHCPメッセージスヌーピングと同様のモデルを使用して、ネットワーク（スイッチ）機器のRogue Rasから保護しています。上記のように、DHCPV6メッセージスヌーピングもIPv6ネットワークで非常に望ましいでしょう。
The rogue RA problem should also be considered by administrators and operators of IPv4-only networks, where IPv6 monitoring, firewalling, and other related mechanisms may not be in place.
Rogue RAの問題は、IPv4のみのネットワークの管理者とオペレーターが考慮する必要があります。このネットワークでは、IPv6の監視、ファイアウォール、およびその他の関連メカニズムが整っていない場合があります。
For example, a comment has been made that in the case of 6to4 being run by a host on a subnet that is not administratively configured with IPv6, some OSes or applications may begin using IPv6 to the 6to4 host (router) rather than IPv4 to the intended default IPv4 router, because they have IPv6 enabled by default and some applications prefer IPv6 by default. Technically aware users may also deliberately choose to use IPv6, possibly for subversive reasons. Mitigating against this condition can also be seen to be important.
たとえば、6to4がIPv6で管理上構成されていないサブネット上のホストによって実行されている場合、一部のOSまたはアプリケーションがIPv6にIPv4にIPv4ではなく6to4ホスト（Router）を使用し始める可能性があるというコメントが行われました。意図したデフォルトのIPv4ルーターは、デフォルトでIPv6を有効にし、一部のアプリケーションがデフォルトでIPv6を好むためです。技術的に認識しているユーザーは、おそらく破壊的な理由でIPv6を使用することを意図的に選択することもできます。この状態に対する緩和は、重要であることも見られます。
It would generally be prudent for network monitoring or management platforms to be able to observe and report on observed RAs, and whether unintended RAs (possibly from unintended sources) are present on a network. Further, it may be useful for individual hosts to be able to report their address status (assuming their configuration status allowed it, of course), e.g., this could be useful during an IPv6 renumbering phased process as described in RFC 4192 [RFC4192].
一般に、ネットワーク監視プラットフォームや管理プラットフォームが観察されたRAを観察および報告できること、および意図しないRA（おそらく意図しないソースから）がネットワークに存在するかどうかを報告できることが賢明です。さらに、個々のホストがアドレスステータスを報告できるように役立つ場合があります（もちろん、構成ステータスが許可されていると仮定します）。たとえば、これはRFC 4192 [RFC4192]に記載されているIPv6の変更プロセスの変更中に役立つ可能性があります。
The above assumes, of course, that what defines a "good" (or "bad") RA can be configured in a trustworthy manner within the network's management framework.
上記は、もちろん、「良い」（または「悪い」）RAを定義するものは、ネットワークの管理フレームワーク内で信頼できる方法で構成できると仮定しています。
After a host receives and processes a rogue RA, it may have multiple default gateways, global addresses, and potentially clashing RA options (e.g., M/O bits [RFC4861]). The host's behaviour may then be unpredictable, in terms of the default router that is used, and the (source) address(es) used in communications. A host that is aware of protocols such as Shim6 [RFC5533] may believe it is genuinely multihomed.
ホストがRogue RAを受信して処理した後、複数のデフォルトゲートウェイ、グローバルアドレス、および潜在的にRAオプションを衝突させる可能性があります（例：M/Oビット[RFC4861]）。ホストの動作は、使用されるデフォルトのルーター、および通信で使用される（ソース）アドレスの観点から、予測不可能な場合があります。SHIM6 [RFC5533]などのプロトコルを認識しているホストは、それが本当にマルチホームされていると信じているかもしれません。
An important issue is how readily a host can recover from receiving and processing bad configuration information, e.g., considering the "2 hour rule" mentioned in Section 5.5.3 of RFC 4862 (though this applies to the valid address lifetime and not the router lifetime). We should ensure that methods exist for a network administrator to correct bad configuration information on a link or subnet, and that OS platforms support these methods. At least if the problem can be detected, and corrected promptly, the impact is minimised.
重要な問題は、ホストが不良な構成情報の受信と処理から容易に回復できることです。たとえば、RFC 4862のセクション5.5.3で言及されている「2時間ルール」を考慮します（ただし、これはルーターの寿命ではなく有効なアドレス寿命に適用されます。）。ネットワーク管理者がリンクまたはサブネット上の不良な構成情報を修正する方法と、OSプラットフォームがこれらのメソッドをサポートすることを確認する必要があります。少なくとも問題を検出し、迅速に修正できる場合、影響は最小限に抑えられます。
In addition to issuing a deprecating RA, it would be desirable to isolate the offending source of the rogue RA from the network. It may be possible to use Network Access Control methods to quarantine the offending host, or rather the network point of attachment or port that it is using.
非推奨RAを発行することに加えて、ネットワークからRogue RAの問題のあるソースを隔離することが望ましいでしょう。ネットワークアクセス制御方法を使用して、問題のあるホスト、または使用している添付ファイルまたはポートのネットワークポイントを隔離することが可能かもしれません。
In this text we have described scenarios via which rogue Router Advertisements (RAs) may appear on a network, and some measures that could be used to mitigate against these. We have also noted some related issues that have arisen in the rogue RA discussions. Our discussion is generally focused on the assumption that rogue RAs are appearing as a result of accidental misconfiguration on the network, by a user or administrator.
このテキストでは、Rogue Router Advertisements（RAS）がネットワークに表示されるシナリオと、これらに対して緩和するために使用できるいくつかの測定値を説明しました。また、Rogue RAの議論で発生したいくつかの関連する問題にも注目しています。私たちの議論は一般に、ユーザーまたは管理者によるネットワーク上の偶発的な誤解の結果としてRogue Rasが現れているという仮定に焦点を当てています。
While SEND perhaps offers the most robust solution, implementations and deployment guidelines are not yet widely available. SEND is very likely to be a good, longer-term solution, but many administrators are seeking solutions today. Such administrators are also often in networks with security models for which SEND is a "heavyweight" solution, e.g., campus networks, or wireless conference or public networks. For such scenarios, simpler measures are desirable.
Sendはおそらく最も堅牢なソリューションを提供しますが、実装と展開ガイドラインはまだ広く利用できません。Sendは優れた長期的な解決策である可能性が非常に高いですが、多くの管理者は今日ソリューションを求めています。このような管理者は、多くの場合、Sendが「ヘビー級」ソリューション、たとえばキャンパスネットワーク、ワイヤレス会議、またはパブリックネットワークであるセキュリティモデルを備えたネットワークにあります。このようなシナリオでは、より単純な測定が望ましいです。
Adding new DHCPv6 Default Gateway and Prefix options would allow IPv6 host configuration by DHCP only and would be a method that IPv4 administrators are comfortable with (for better or worse), but this simply shifts the robustness issue elsewhere.
新しいDHCPV6デフォルトゲートウェイとプレフィックスオプションを追加すると、DHCPのみでIPv6ホストの構成が可能になり、IPv4管理者が（良くも悪くも）快適である方法になりますが、これは単に堅牢性の問題を他の場所にシフトします。
While a number of the mitigations described above have their appeal, the simplest solutions probably lie in switch-based ACLs and RA-Guard-style approaches. Where managed switches are not available, use of the Router Preference option and (more so in managed desktop environments) host firewalls may be appropriate.
上記の多くの緩和には魅力がありますが、最も単純なソリューションはおそらくスイッチベースのACLとRAガードスタイルのアプローチにあります。管理されたスイッチが利用できない場合、ルーター設定オプションを使用し、（管理されたデスクトップ環境では）ホストファイアウォールが適切かもしれません。
In the longer term, wider experience of SEND will be beneficial, while the use of RA snooping will remain useful either to complement SEND (where a switch running RA-Guard can potentially be a SEND proxy) or to assist in scenarios for which SEND is not deployed.
長期的には、送信の幅広いエクスペリエンスが有益であり、RAスヌーピングの使用は送信（スイッチを実行しているRAガードが潜在的に送信プロキシになる可能性がある場合）または送信のシナリオを支援するために有用なままです。展開されていません。
This Informational document is focused on discussing solutions to operational problems caused by rogue RAs resulting from unintended misconfiguration by users or administrators. Earlier versions of this text included some analysis of rogue RAs introduced maliciously; e.g., the text included an extra column in the matrix in Section 4. However, the consensus of the v6ops working group feedback was to instead focus on the common operational problem of "accidental" rogue RAs seen today.
この情報文書は、ユーザーまたは管理者による意図しない誤解に起因する不正なRAによって引き起こされる運用上の問題の解決策を議論することに焦点を当てています。このテキストの以前のバージョンには、悪意を持って導入された不正なRAの分析が含まれていました。たとえば、テキストにはセクション4のマトリックスに追加の列が含まれていましたが、V6OPSワーキンググループのフィードバックのコンセンサスは、代わりに今日見た「偶発的な」不正なRasの一般的な運用上の問題に焦点を当てることでした。
Thus, the final version of this text does not address attacks on a network where rogue RAs are intentionally introduced as part of a broader attack, e.g., including malicious NA messages. On the wire, malicious rogue RAs will generally look the same as "accidental" ones, though they are more likely, for example, to spoof the Media Access Control (MAC) or IPv6 source address of the genuine router, or to use a "High" Router Preference option. It is also likely that malicious rogue RAs will be accompanied by other attacks on the IPv6 infrastructure, making discussion of mitigations more complex. Administrators may be able to detect such activity by the use of tools such as NDPMon.
したがって、このテキストの最終バージョンは、悪意のあるNAメッセージを含む、より広範な攻撃の一部として不正なRAが意図的に導入されるネットワークへの攻撃に対処しません。ワイヤーでは、悪意のあるローグRAは一般に「偶発的な」ものと同じように見えますが、たとえば、本物のルーターのメディアアクセスコントロール（MAC）またはIPv6ソースアドレスをスプーフィングしたり、使用したりする可能性が高くなります。高い「ルーター設定オプション。また、悪意のある不正なRASには、IPv6インフラストラクチャに対する他の攻撃が伴い、軽減の議論がより複雑になる可能性があります。管理者は、NDPMONなどのツールを使用することにより、そのようなアクティビティを検出できる場合があります。
It is worth noting that the deprecation daemon could be used as part of a denial-of-service attack, should the tool be used to deprecate the genuine RA.
ツールを使用して本物のRAを非難した場合、非推奨デーモンをサービス拒否攻撃の一部として使用できることは注目に値します。
Thanks are due to members of the IETF IPv6 Operations and DHCP working groups for their inputs on this topic, as well as some comments from various operational mailing lists, and private comments, including but not limited to: Iljitsch van Beijnum, Dale Carder, Remi Denis-Courmont, Tony Hain, Bob Hinden, Christian Huitema, Tatuya Jinmei, Eric Levy-Abegnoli, David Malone, Thomas Narten, Chip Popoviciu, Dave Thaler, Gunter Van de Velde, Goeran Weinholt, and Dan White.
このトピックに関する入力については、IETF IPv6オペレーションとDHCPワーキンググループのメンバー、さまざまな運用メーリングリストからのコメント、およびIljitsch van Beijnum、Dale Carder、Remiを含むがこれらに限定されないプライベートコメントのメンバーに感謝します。デニス・コールモント、トニー・ハイン、ボブ・ヒンデン、クリスチャン・フイテマ、タトゥヤ・ジンメイ、エリック・レヴィー・アベノリ、デビッド・マローン、トーマス・ナルテン、チップ・ポポビチウ、デイブ・ターラー、ガンター・ヴァン・デ・ヴェルデ、ゴーラン・ワインホルト、ダン・ホワイト。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684] Grossman、D。およびJ. Heinanen、「ATM適応層5に対するマルチプロトコルカプセル化」、RFC 2684、1999年9月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] DROMS、R。、「IPv6用のステートレス動的ホスト構成プロトコル（DHCP）サービス」、RFC 3736、2004年4月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191] Draves、R。およびD. Thaler、「デフォルトのルーター設定とより固有のルート」、RFC 4191、2005年11月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192] Baker、F.、Lear、E。、およびR. Droms、「フラグデーなしでIPv6ネットワークを変更するための手順」、RFC 4192、2005年9月。
[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月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533] Nordmark、E。およびM. Bagnulo、「SHIM6：IPv6のレベル3マルチホミングシムプロトコル」、RFC 5533、2009年6月。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.
[RFC6105] Levy-Abegnoli、E.、Van de Velde、G.、Popoviciu、C。、およびJ. Mohacsi、「IPv6ルーター広告ガード」、RFC 6105、2011年2月。
[IPv6-AUTOCFG-FILTER] Ward, N., "IPv6 Autoconfig Filtering on Ethernet Switches", Work in Progress, March 2009.
[IPv6-Autocfg-Filter] Ward、N。、「イーサネットスイッチでのIPv6 Autoconfigフィルタリング」、2009年3月、進行中の作業。
[DHCPv6-DEFAULT-RTR] Droms, R. and T. Narten, "Default Router and Prefix Advertisement Options for DHCPv6", Work in Progress, March 2009.
[DHCPV6-DEFAULT-RTR] DROMS、R。およびT. NARTEN、「DHCPV6のデフォルトルーターおよびプレフィックス広告オプション」、2009年3月、進行中の作業。
Authors' Addresses
著者のアドレス
Tim Chown University of Southampton Highfield Southampton, Hampshire SO17 1BJ United Kingdom
ティムチャウン大学サウサンプトン大学ハイフィールドサウサンプトン、ハンプシャーSO17 1BJイギリス
EMail: tjc@ecs.soton.ac.uk
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA
Stig Venaas Cisco Systems Tasman Drive San Jose、CA 95134 USA
EMail: stig@cisco.com