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
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メッセージの送信元アドレスだけでなく、オンリンクプレフィックス情報から取られた暗黙のデフォルトルータアドレスを含んでいます。ただし、ユーザーや管理者、またはおそらくネットワーク上の悪意ある攻撃によって、意図しない設定ミスは、今度はネットワーク上のホストの運用問題が発生する可能性があり、偽のRASが存在することにつながる可能性があります。この文書では、我々は不正RASが観察可能なシナリオを要約し、問題の可能な解決策のリストを提示します。私たちは、テキスト内の不正なRasの意図しない要因に焦点を当てます。このテキストの目的は通知されるべきであり、そのように溶液が提案され、議論されることができるの周りにフレームワークを提示します。
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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].
近隣探索プロトコル[RFC4861]は、動的ホストIPv6の構成プロトコル（DHCPv6の）を介して、そのノードの構成は、ステートフルであるか否か、IPv6自動設定処理中にノード構成情報を決定するために使用されたIPv6ルータ広告（RAS）の動作について説明しますRFC3315]または] RFC4862 [当たりとして、おそらく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は、ネットワークリンクまたはサブネット上に表示さに問題があることは明らかです。意図したように構成RAのではなく、他のいくつかの理由のために登場したのRAはありませんでした「偽」我々は意味の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.
不正なバーRASの問題点は、IPv6リンク上のホストの動作の部分的または完全な故障を引き起こすことができるということです。例えば、デフォルトルータアドレスがRAメッセージの送信元アドレスから直接引き出されます。また、不正RAはホストがステートレスアドレス自動設定のために使用されるように間違った接頭辞を想定することがあります。 「良い」と「悪い」のRASが混入することができる場合には、ホストは、「良い」デフォルトゲートウェイを使用し続けるかもしれないが、出力フィルタリングの問題につながる、間違った送信元アドレスを取得します。そのため、不正RAはその解決策（複数可）の運用課題である必要があり、そのためのベストプラクティスを搬送する必要がありますされています。これは、予防または検出不正バーRASをするだけでなく、必要な場合には、ネットワークを確保する（ネットワーク上のホスト）を含むだけでなく、迅速にホスト構成は、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.
次のセクションでは、不正なRASが存在することを生じ得るシナリオを議論します。次のセクションでは、我々は他の人よりも展開がより実用的かもしれそのうちのいくつかの問題のためのいくつかの候補解を提示します。この文書では、「偶然の」ならず者のRAに焦点を当てて。悪質なRASはまた、もちろん可能でありながら、一般的な問題今日は、意図しないRAのです。また、この種の悪質な攻撃を経験したネットワークは、悪意のある近隣広告（NA）と関連メッセージを経験する可能性があります。
There are three broad classes of scenario in which bogus RAs may be introduced to an IPv6 network.
偽の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が正しくないか、意図しないIPv6アドレス、ゲートウェイ、または他の情報を生成するリンクや原因ホスト上に表示させ、ルータインターフェイス上でのRAを構成します。このような場合には、デフォルトゲートウェイは正しいかもしれないが、例えば、ホストかもしれないが、おそらく正しいと誤ったプレフィックスに基づいて正しいと誤ったアドレスと、同報なります。こうした生涯オプションとして、誤って構成されている他の構成情報の可能性もあります。
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）設定ミスの場合に、RAは意図しないリンクに「洪水」、潜在的可能性の二つの異なるデフォルトのルータが利用可能で、同報不正確になるにホストまたは複数のリンクを原因かもしれません。
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.
これは、ラップトップは6to4の[RFC3056]ゲートウェイにホストを変えることができ、Windowsのインターネット接続の共有（ICS）サービスを、有効になっているネットワーク（時々有線が）一般的に無線で見ているようです。意図していないときの、もちろん、それは実行されない限り、これは、便利な機能することができます。それは通常、ホスト上の「ローグ」DHCPv4サーバを起動しますと、このサービスは、IPv4の問題を引き起こす可能性があります。
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.
我々はまた、彼らは結果として、接続共有サービスと6to4をオンさせ、原因ホストファイアウォールへのリンクを本物のIPv6のRAが表示されないことがありホストがレポートを持っていました。いくつかのケースでは、より技術的なユーザーは、ホームゲートウェイ（例えば、再度の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.
ここでは、攻撃者が意図的にサービス拒否やman-in-the-middle攻撃のいくつかのフォームを実行するための試みで、ローカルネットワーク上の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.
これは、ネットワーク管理者のための本物の関心事である一方で、上述したように対照的で偶発不正RASのレポートは非常に一般的である一方で、このような活動のいずれかのレポート場合、いくつかありました。このテキストを書いて、そしてv6opsワーキンググループのフィードバックを、私たちは、不正な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.
この節では、ネットワーク上で見られる不正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処理が無効になっていることを意味します。ほとんどのオペレーティングシステムでは、IPv6アドレスを手動でシステム上で構成されている場合、予期しないRAはリンクに表示され、追加のグローバル自動構成アドレスが追加されないように、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.
間違った情報源から観測RASがブロックされたか、廃棄、およびサブネットを介して伝播されないように、レイヤーでDHCPスヌーピングと同様に2つのスイッチを「RAスヌーピング」を実装することが可能でなければなりません。 「RA-ガード」[RFC6105]と呼ばれるこの空間で一つの解候補は、提案されています。このタイプのソリューションは、企業のネットワーク管理者のためにおなじみのモデルであるため、魅力を持っているが、それはまた、ホストに対してSENDプロキシとして動作するスイッチによってセキュア近隣探索（SEND）[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）を設定し、管理者が不正な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メッセージのフォーマットを記述する。文書はまた、その後のDHCPv4スヌーピングと同様に実装することができたDHCPv6スヌーピングの要件を、指摘しています。
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.
セキュア近隣探索（SEND）[RFC3971]プロトコルは、セキュア近隣探索を実行するホストとルータのための方法を提供します。したがって、原則的に不正のRAに対してネットワークを保護することができます。
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.
プロトコルの非常にいくつかの実装があるので、まだ広く部分には、書き込み時に使用されていません送信します。これらは、やがて解決される可能性が高いものの、いくつかの他の展開に関する問題は、提起されています。例えば、ルータは、おそらく（ACLで保護する必要があるかもしれません）自動生成されたアドレスを使用したいので、非自動生成されたアドレスで動作するように表示する必要が送信されません。また、それで（証明書サーバーやネットワークタイムプロトコル（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.
さらに、それが広く採用されているか、完全に明確ではありませんSENDができたか、ホストが管理上のユーザーによって管理されておらず、特に「軽量」セキュリティ（例えば、多くのキャンパスネットワーク）を持つサイトネットワークになります。公共や会議のワイヤレスネットワークは、同様の課題に直面する可能性があります。また、SENDの使用はあまり実用的であり、おそらく、センサネットワークのようなネットワークが存在してもよいです。これらのネットワークは、まだ不正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.
SENDは明らかに、特に悪質な活動が重要な関心事であるネットワークでは、優れた、より長期的なソリューションを提供することができるが、より容易に適用可能な、より「リラックス」の環境で実用的なソリューション、および/またはソリューションの要件今日があります。後者の場合は、「RAスヌーピング」または適用されたACLのようなソリューションは、今より魅力的です。
[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つのルータの嗜好値のいずれか：高、中（デフォルト）、またはLow。このため、管理者は、管理対象のRAのための「高」設定を使用し、「偶発」RASが中位の優先順位になることを願っています可能性があります。もちろん、これは、いくつかのシナリオで動作します - 誤ってネットワーク上の不正なRAを送信し、ユーザーが自分の意図した使用のための「高」優先で自分のデバイスを構成した場合、優先順位が衝突するでしょう。しかし、デフォルトの優先順位を使用するWindowsのICSと6to4のようなソフトウェアに起因する偶発不正のRAS、のために、それが役に立つかもしれません。明らかに、このソリューションは、ルータの優先オプションの実装を持つクライアント（およびルータ）に依存しています。
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セキュリティを改善することのRAを送信するためにネットワークに参加するために、攻撃者の能力を軽減するのに役立つかもしれないが、それは設定ミスの問題を防ぐことはできません。ユーザーは喜んで認証を行い、それでも例えば、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会議で使用されているようなツールの一例です。 RAMONDと呼ばれるやや強化ツールは、以来、このコードから開発され、現在はSourceforgeのプロジェクトとして提供されています。ホストベースのファイアウォールと同じように、デーモンが知られている良い情報源および/またはリンクプレフィックスのいくつかの組み合わせから、何らかの形で「良い」と「悪い」のRAが何であるかを知っている必要があります。ネイティブIPv6を使用する環境では、しかし、6to4のベースRAは確かに不正であることが知られることになります。
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の媒体に分割されている場合、不正なRasの影響を制限することができます。ブロードバンドネットワークでは、ブリッジ[RFC2684]は、例えば、利用可能であってもよいです。利点は、与えられたユーザまたは顧客が自分のネットワークプレフィックスを有するか、またはプロビジョニングが共有サブネットへのリンクであるかどうかかどうか、例えば、シナリオ固有であってもよいです。任意のユーザーや顧客のシステム（s）は、他のユーザや顧客によって生成することができるの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.
マルチキャスト不正RAが最も可能性の高い、すぐにすべてのホストに影響を与えますしながらのDHCPv6の利点は、それがエラーを導入する必要があり、その時以来のDHCP情報をリフレッシュしているホストのみが影響を受けています。 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のを介してホストの設定が可能となっている間だけでIPv6構成が今日のIPv4と同様の方法で行うことができるようになる実行可能なオプションがあり、問題がシフトされた：不正RASが問題点ではなく、不正のDHCPv6サーバが同等になります問題。 [IPv6にAUTOCFG-FILTER]に示唆されるようにIPv4の場合と同様に、ネットワークは依然として、認証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の専用ホスト構成のためのコミュニティのいくつかの需要は確かにあります。これは不正な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.
どのような上記の概要は考慮していないと、対策を展開する実用性です。重要な管理オーバーヘッドなしに不正のRAに改善回復力を買う簡単にデプロイ方法が魅力的です。手動設定のようなアプローチはあまり魅力的でありながら、それに基づいて、提案をスヌーピングRAは、例えば、RA-Guardは、メリットがあります。のみ、特定の管理対象スイッチの機器が必要なACLをサポートするかもしれないがしかし、RA-Guardは、まだ完全に定義されたか、使用できません。
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.
著者は、この文書に取り込む価値があると信じて不正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.
上記の議論は、最初は不正なマルチキャストRASは、共有ネットワークのサブネット上の問題の原因だったと仮定して開催されました。不正のRAを送信するホストは、RAは、他のホストに見られないかもしれないことを、彼らは勧誘ホストにユニキャスト送信する場合ただし、ルータ広告の仕様は、彼らがRFC 4861.の6.2.6項に従って、ホストにユニキャストを送信することを可能にします監視デーモンによって共有メディア、例えば、上。ほとんどの場合、しかし、偶然の不正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.
不正なRasおよび不正のDHCPv6サーバ用の脅威モデルを比較すると興味深い運動です。不正の6to4ベースのRASがネットワーク上に表示させるWindowsのICSの場合は、同じホストでも不正なIPv4のDHCPサーバとして機能している可能性が非常に高いです。不正なDHCPv4サーバが不正RAは、新たな（追加の）デフォルトゲートウェイ、接頭語（ES）、およびアドレスの学習にホストを導くことができると同じように、デフォルトゲートウェイとホストにアドレスを割り当てることができます。不正なDHCPサーバーの影響はホストのリースタイマーに依存しながら、マルチキャスト不正なRASの場合は、しかし、影響は、すべてのホストに対して潜在的に即時です。
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は、SENDが不正のIPv6のRAから保護するために使用することができ同じように、不正の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-Guardのアプローチは、本質的に、ネットワーク内の不正なバーRASから保護するために、DHCPスヌーピングメッセージ（スイッチ）機器と同様のモデルを使用しています。上述したように、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.
不正RA問題はまた、IPv6の監視、ファイアウォール、およびその他の関連機構が適所にないかもしれないIPv4のみのネットワークの管理者やオペレータによって考慮されるべきです。
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.
例えば、コメントは管理IPv6で構成されていないサブネット上のホストによって実行された6to4の場合、いくつかのOS又はアプリケーションがにかなりのIPv4よりの6to4ホスト（ルータ）にIPv6を使用して開始することができると判断されました彼らはIPv6のデフォルトで有効になっていると、いくつかのアプリケーションは、デフォルトでIPv6を好むので、デフォルトのIPv4ルーターを意図しました。技術的に認識し、ユーザーも意図的に、おそらく破壊的な理由のために、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.
ホストが受信すると、不正な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を発行することに加えて、ネットワークからの不正な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.
このテキストでは、ネットワーク上で表示されることがありますルータ広告（RAS）を不正これを介してシナリオ、およびこれらを軽減するために使用できるいくつかの対策を説明してきました。また、不正なRAの議論に生じたいくつかの関連の問題を指摘しています。私たちの議論は、一般的に不正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は良い、長期的な解決策になる可能性が非常に高いですが、多くの管理者は、今日のソリューションを求めています。このような管理者は、送信が「ヘビー級」解決策、例えば、キャンパスネットワーク、またはワイヤレス会議や公共ネットワークであるため、セキュリティモデルとのネットワークで、多くの場合もあります。このようなシナリオの場合、単純な対策が望まれています。
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.
唯一のDHCPによってIPv6ホストの設定を可能にする新しいDHCPv6のデフォルトゲートウェイとプレフィックスオプションを追加し、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スヌーピングの使用が有用残るいずれかのSENDを補完する（スイッチの実行RA-Guardは、潜在的にSENDプロキシとすることができる場合）、またはさSENDれるシナリオを支援するためながら、長期的には、SENDの広い経験は、有益であろう展開されていません。
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によって引き起こされる操作上の問題に対する解決策を議論に焦点を当てています。このテキストの以前のバージョンでは、悪意を持って導入された不正なRasのいくつかの分析を含め、例えば、テキストは、しかし、第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.
したがって、このテキストの最終版は、不正のRASが意図的に悪意のあるNAメッセージを含むより広範な攻撃、例えば、の一部として導入されているネットワークへの攻撃に対処していません。ワイヤ上で、悪意のある不正RASが、彼らはより多くの可能性があるものの、一般的に本物のルーターのメディアアクセス制御（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バンBeijnum、デールカーダーレミデニス・Courmont、トニーハイン、ボブHindenとクリスチャンのHuitema、達也神明、エリック・レヴィ・Abegnoli、デビッド・マローン、トーマスNarten氏、チップPopoviciu、デーブターラー、ギュンター・ヴァン・デ・ヴェルデ、Goeran Weinholt、そしてダン・ホワイト。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684]グロスマン、D.とJ. Heinanen、RFC 2684、1999年9月 "ATMアダプテーションレイヤ5以上のマルチプロトコルカプセル化"。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、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.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（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.ターラー、 "デフォルトルータの設定と、より詳細なルート"、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]ベイカー、F.、リア、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.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、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]レヴィ - Abegnoli、E.、ヴァン・デ・ヴェルデ、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]ウォード、N.、 "イーサネットスイッチ上のIPv6自動設定のフィルタリング"、進歩、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イギリスのティムのchown大学
EMail: tjc@ecs.soton.ac.uk
メールアドレス：tjc@ecs.soton.ac.uk
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA
スティグVenaasシスコシステムズタスマン・ドライブサンノゼ、CA 95134 USA
EMail: stig@cisco.com
メールアドレス：stig@cisco.com