Network Working Group J. Jeong, Ed.
Request for Comments: 5006 ETRI/University of Minnesota
Category: Experimental S. Park
SAMSUNG Electronics
L. Beloeil
France Telecom R&D
S. Madanapalli
Ordyn Technologies
September 2007
IPv6 Router Advertisement Option for DNS Configuration
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Abstract
抽象
This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses to IPv6 hosts.
この文書は、IPv6ルーターがIPv6ホストにDNSの再帰的サーバーのアドレスを宣伝することを可能にする新しいIPv6ルーター広告オプションを指定します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Applicability Statements . . . . . . . . . . . . . . . . . 2
1.2. Coexistence of RDNSS Option and DHCP Option . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Neighbor Discovery Extension . . . . . . . . . . . . . . . . . 4
5.1. Recursive DNS Server Option . . . . . . . . . . . . . . . 4
5.2. Procedure of DNS Configuration . . . . . . . . . . . . . . 5
5.2.1. Procedure in IPv6 Host . . . . . . . . . . . . . . . . 5
6. Implementation Considerations . . . . . . . . . . . . . . . . 6
6.1. DNS Server List Management . . . . . . . . . . . . . . . . 6
6.2. Synchronization between DNS Server List and Resolver
Repository . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address Autoconfiguration provide ways to configure either fixed or mobile nodes with one or more IPv6 addresses, default routers and some other parameters [2][3]. To support the access to additional services in the Internet that are identified by a DNS name, such as a web server, the configuration of at least one recursive DNS server is also needed for DNS name resolution.
IPバージョン6およびIPv6ステートレスアドレス自動設定のための近隣探索（ND）は、1つのまたは複数のIPv6アドレス、デフォルトルータおよびいくつかの他のパラメータとの固定または移動のいずれかのノードを構成する方法を提供する[2] [3]。 WebサーバなどDNS名で識別され、インターネットでの追加サービスへのアクセスをサポートするために、少なくとも一つの再帰的なDNSサーバーの設定もDNSの名前解決のために必要とされています。
It is infeasible for nomadic hosts, such as laptops, to be configured manually with a DNS resolver each time they connect to a different wireless LAN (WLAN) such as IEEE 802.11 a/b/g [12]-[15]. Normally, DHCP [6]-[8] is used to locate such resolvers. This document provides an alternate, experimental mechanism which uses a new IPv6 Router Advertisement (RA) option to allow IPv6 routers to advertise DNS recursive server addresses to IPv6 hosts.
それはラップトップなどノマディックホストのため実行不可能である、IEEE 802.11 / B / GとしてDNSリゾルバを使用して手動でそれらは、異なる無線LAN（WLAN）に接続するたびに設定する[12] - [15]。通常、DHCP [6] - [8]このようなレゾルバの位置を特定するために使用されます。この文書は、IPv6ルーターがIPv6ホストにDNSの再帰的サーバーのアドレスを宣伝することを可能にする新しいIPv6ルーター広告（RA）オプションを使用する代替、実験的なメカニズムを提供します。
The only standards-track DNS configuration mechanism in the IETF is DHCP, and its support in hosts and routers is necessary for reasons of interoperability.
IETFにおける唯一の標準トラックDNS設定メカニズムはDHCPで、ホストとルータでのサポートは、相互運用性の理由のために必要です。
RA-based DNS configuration is a useful, optional alternative in networks where an IPv6 host's address is autoconfigured through IPv6 stateless address autoconfiguration, and where the delays in acquiring server addresses and communicating with the servers are critical. RA-based DNS configuration allows the host to acquire the nearest server addresses on every link. Furthermore, it learns these addresses from the same RA message that provides configuration information for the link, thereby avoiding an additional protocol run. This can be beneficial in some mobile environments, such as with Mobile IPv6 [10].
RAベースのDNSの設定は、IPv6ホストのアドレスがIPv6ステートレスアドレス自動設定による自動設定されるネットワークで有用で、オプションの代替であり、サーバのアドレスを取得し、サーバとの通信に遅延が極めて重要であるところ。 RAベースのDNSの設定は、ホストがすべてのリンクに最も近いサーバーアドレスを取得することができます。さらに、それによって追加のプロトコルの実行を回避する、リンクの構成情報を提供するのと同じRAメッセージから、これらのアドレスを学習します。これは、モバイルIPv6 [10]と同様に、いくつかのモバイル環境において有益であり得ます。
The advantages and disadvantages of the RA-based approach are discussed in [9] along with other approaches, such as the DHCP and well-known anycast addresses approaches.
RAベースのアプローチの長所と短所は、DHCPなどの他の手法、及び周知のエニーキャストアドレスアプローチと共に[9]に記載されています。
The RDNSS (Recursive DNS Server) option and DHCP option can be used together [9]. To order the RA and DHCP approaches, the O (Other stateful configuration) flag can be used in the RA message [2]. If no RDNSS option is included in the RA messages, an IPv6 host may perform DNS configuration through DHCPv6 [6]-[8] regardless of whether the O flag is set or not.
RDNSS（再帰DNSサーバ）オプションとDHCPオプションを一緒に使用することができる[9]。 RAとDHCPアプローチを注文するために、O（その他のステートフル設定）フラグがRAメッセージで使用することができる[2]。何RDNSSオプションがRAメッセージに含まれていない場合、IPv6ホストは、DHCPv6のを通してDNS設定を行うことができる[6] - [8]にかかわらず、Oフラグがセットされているか否かの。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[1]に記載のように解釈されます。
This document uses the terminology described in [2] and [3]. In addition, four new terms are defined below:
この文書では、[2]に記載の用語を使用し、[3]。また、4つの新しい用語を以下に定義されています。
o Recursive DNS Server (RDNSS): Server which provides a recursive DNS resolution service for translating domain names into IP addresses as defined in [4] and [5].
O再帰的DNSサーバ（RDNSS）で定義されているドメイン名をIPアドレスに変換するための再帰的DNS解決サービスを提供するサーバ[4]及び[5]。
o RDNSS Option: IPv6 RA option to deliver the RDNSS information to IPv6 hosts [2].
RDNSSオプションO：IPv6ホストにRDNSS情報を提供するためのIPv6 RAオプション[2]。
o DNS Server List: A data structure for managing DNS Server Information in the IPv6 protocol stack in addition to the Neighbor Cache and Destination Cache for Neighbor Discovery [2].
DNSサーバー一覧○：近隣探索のための近隣キャッシュとDestinationキャッシュに加えて、IPv6プロトコルスタックのDNSサーバ情報を管理するためのデータ構造[2]。
o Resolver Repository: Configuration repository with RDNSS addresses that a DNS resolver on the host uses for DNS name resolution; for example, the Unix resolver file (i.e., /etc/resolv.conf) and Windows registry.
Oリゾルバ倉庫：RDNSSで構成リポジトリは、ホスト上のDNSリゾルバは、DNSの名前解決に使用するアドレス。例えば、Unixのリゾルバファイル（すなわち、/etc/resolv.confの）およびWindowsのレジストリ。
This document defines a new ND option called RDNSS option that contains the addresses of recursive DNS servers. Existing ND transport mechanisms (i.e., advertisements and solicitations) are used. This works in the same way that hosts learn about routers and prefixes. An IPv6 host can configure the IPv6 addresses of one or more RDNSSes via RA messages periodically sent by a router or solicited by a Router Solicitation (RS).
この文書では、再帰的なDNSサーバのアドレスが含まれているRDNSSオプションと呼ばれる新しいNDオプションを定義します。既存のND輸送機構（すなわち、広告及び勧誘）が使用されています。これは、ホストがルーターとプレフィックスを学ぶのと同じように動作します。 IPv6ホストは、定期的にルータによって送信またはルーター要請（RS）によって勧誘RAメッセージを介して、1つ以上のRDNSSesのIPv6アドレスを設定することができます。
Through the RDNSS option, along with the prefix information option based on the ND protocol ([2] and [3]), an IPv6 host can perform network configuration of its IPv6 address and RDNSS simultaneously without needing a separate message exchange for the RDNSS information. The RA option for RDNSS can be used on any network that supports the use of ND.
NDプロトコルに基づいて、プレフィックス情報オプションと共に、RDNSSオプションを介して（[2]及び[3]）、IPv6ホストはRDNSS情報のための別個のメッセージ交換を必要とせず、同時に、そのIPv6アドレスとRDNSSのネットワーク設定を行うことができ。 RDNSSのためのRAオプションは、NDの使用をサポートする任意のネットワーク上で使用することができます。
This approach requires RDNSS information to be configured in the routers sending the advertisements. The configuration of RDNSS addresses in the routers can be done by manual configuration. The automatic configuration or redistribution of RDNSS information is possible by running a DHCPv6 client on the router [6]-[8]. The automatic configuration of RDNSS addresses in routers is out of scope for this document.
このアプローチは、広告を送信して、ルータに設定するRDNSS情報が必要です。ルータでのRDNSSアドレスの設定は手動設定で行うことができます。 RDNSS情報の自動設定または再配布は、ルータ上のDHCPv6クライアントを実行することが可能である[6] - [8]。ルータでのRDNSSアドレスの自動設定はこの文書の範囲外です。
The IPv6 DNS configuration mechanism in this document needs a new ND option in Neighbor Discovery: the Recursive DNS Server (RDNSS) option.
再帰DNSサーバ（RDNSS）オプション：この文書に記載されているIPv6のDNS構成メカニズムは、近隣探索の新しいNDオプションを必要とします。
The RDNSS option contains one or more IPv6 addresses of recursive DNS servers. All of the addresses share the same lifetime value. If it is desirable to have different lifetime values, multiple RDNSS options can be used. Figure 1 shows the format of the RDNSS option.
RDNSSオプションは、再帰的なDNSサーバの1つの以上のIPv6アドレスが含まれています。アドレスのすべてが同じ生涯価値を共有しています。それは別の寿命値を有することが望ましい場合は、複数のRDNSSオプションを使用することができます。図1は、RDNSSオプションのフォーマットを示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Addresses of IPv6 Recursive DNS Servers :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Recursive DNS Server (RDNSS) Option Format
図1：再帰DNSサーバ（RDNSS）オプションフォーマット
Fields:
フィールド：
Type 8-bit identifier of the RDNSS option type as assigned by the IANA: 25
IANAによって割り当てられるRDNSSオプションタイプの8ビットの識別子を入力します。25
Length 8-bit unsigned integer. The length of the option (including the Type and Length fields) is in units of 8 octets. The minimum value is 3 if one IPv6 address is contained in the option. Every additional RDNSS address increases the length by 2. The Length field is used by the receiver to determine the number of IPv6 addresses in the option.
長さ8ビットの符号なし整数。 （タイプと長さフィールドを含む）オプションの長さは8つのオクテット単位です。 1つのIPv6アドレスがオプションに含まれている場合、最小値は3です。すべての追加のRDNSSアドレスは、長さフィールドはオプションでIPv6アドレスの数を決定するために受信機によって使用される2により長さを増加させます。
Lifetime 32-bit unsigned integer. The maximum time, in seconds (relative to the time the packet is sent), over which this RDNSS address MAY be used for name resolution. Hosts MAY send a Router Solicitation to ensure the RDNSS information is fresh before the interval expires. In order to provide fixed hosts with stable DNS service and allow mobile hosts to prefer local RDNSSes to remote RDNSSes, the value of Lifetime should be at least as long as the Maximum RA Interval (MaxRtrAdvInterval) in RFC 4861, and be at most as long as two times MaxRtrAdvInterval; Lifetime SHOULD be bounded as follows: MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval. A value of all one bits (0xffffffff) represents infinity. A value of zero means that the RDNSS address MUST no longer be used.
寿命32ビット符号なし整数。このRDNSSアドレスを名前解決に使用することができる上に、（パケットが送信される時間と比較して）秒の最大時間。ホストは間隔が切れる前にRDNSS情報が新鮮であることを確認するためにルータ要請を送信することができます。安定したDNSサービスと固定ホストに提供し、モバイルホストがリモートRDNSSesローカルRDNSSesを好むことを可能にするために、ライフタイムの値は、RFC 4861で、少なくとも限り最大RA間隔（MaxRtrAdvInterval）としてもよく、最大であればなければなりません2倍のMaxRtrAdvInterval。 MaxRtrAdvInterval <=寿命<= 2 * MaxRtrAdvInterval次のように寿命が境界されるべきです。全ての1つのビット（0xFFFFFFFFを）の値は無限を表します。ゼロの値はRDNSSアドレスがもはや使用されなければならないことを意味します。
Addresses of IPv6 Recursive DNS Servers One or more 128-bit IPv6 addresses of the recursive DNS servers. The number of addresses is determined by the Length field. That is, the number of addresses is equal to (Length - 1) / 2.
IPv6の再帰的なDNSサーバーのアドレスを再帰的なDNSサーバの一つ以上の128ビットのIPv6アドレス。アドレスの数は、長さフィールドによって決定されます。すなわち、アドレスの数に等しいである（長さ - 1）/ 2。
The procedure of DNS configuration through the RDNSS option is the same as with any other ND option [2].
RDNSSオプションを介して、DNS設定の手順は、他のNDオプション[2]と同様です。
When an IPv6 host receives an RDNSS option through RA, it checks whether the option is valid.
IPv6ホストは、RAを通じてRDNSSオプションを受信すると、オプションが有効であるかどうかをチェックします。
o If the RDNSS option is valid, the host SHOULD copy the option's value into the DNS Server List and the Resolver Repository as long as the value of the Length field is greater than or equal to the minimum value (3). The host MAY ignore additional RDNSS addresses within an RDNSS option and/or additional RDNSS options within an RA when it has gathered a sufficient number of RDNSS addresses.
RDNSSオプションが有効な場合は、O、長さフィールドの値限り、DNSサーバーのリストとリゾルバ倉庫にオプションの値をコピーする必要があり、ホストが最小値以上である（3）。それはRDNSSアドレスの十分な数を集めているとき、ホストは、RA内のRDNSSオプションおよび/または追加のRDNSSオプションの中に追加のRDNSSアドレスを無視するかもしれません。
o If the RDNSS option is invalid (e.g., the Length field has a value less than 3), the host SHOULD discard the option.
RDNSSオプションが無効である場合、O（例えば、長さフィールドは、3未満の値を有する）、ホストオプションを破棄すべきです。
Note: This non-normative section gives some hints for implementing the processing of the RDNSS option in an IPv6 host.
注：この非標準セクションでは、IPv6ホストにRDNSSオプションの処理を実装するためのいくつかのヒントを提供します。
For the configuration and management of RDNSS information, the advertised RDNSS addresses can be stored and managed in both the DNS Server List and the Resolver Repository.
RDNSS情報の設定と管理のために、広告を出してRDNSSアドレスは、DNSサーバーのリストとリゾルバ倉庫の両方に格納して管理することができます。
In environments where the RDNSS information is stored in user space and ND runs in the kernel, it is necessary to synchronize the DNS Server List of RDNSS addresses in kernel space and the Resolver Repository in user space. For the synchronization, an implementation where ND works in the kernel should provide a write operation for updating RDNSS information from the kernel to the Resolver Repository. One simple approach is to have a daemon (or a program that is called at defined intervals) that keeps monitoring the lifetime of RDNSS addresses all the time. Whenever there is an expired entry in the DNS Server List, the daemon can delete the corresponding entry from the Resolver Repository.
RDNSS情報がユーザ空間に保存されているとNDは、カーネル内で実行される環境では、カーネル空間とユーザ空間のリゾルバ倉庫にRDNSSアドレスのDNSサーバーのリストを同期させる必要があります。同期では、NDがカーネルで動作する実装はリゾルバ倉庫にカーネルからRDNSS情報を更新するための書き込み動作を提供する必要があります。一つの簡単な方法は、すべての時間を扱うRDNSSの寿命を監視し続けるデーモン（または定義された間隔で呼び出されたプログラム）を持つことです。 DNSサーバーリストの期限切れのエントリがあるたびに、デーモンはリゾルバ倉庫から対応するエントリを削除することができます。
The kernel or user-space process (depending on where RAs are processed) should maintain a data structure called a DNS Server List which keeps the list of RDNSS addresses. Each entry in the DNS Server List consists of an RDNSS address and Expiration-time as follows:
データ構造を維持する必要があります（RASが処理されている場所に応じて）カーネルやユーザー空間プロセスがRDNSSアドレスのリストを保持しますDNSサーバーのリストと呼ばれます。次のようにDNSサーバーのリストの各エントリはRDNSSアドレスと有効期限タイムで構成されています。
o RDNSS address: IPv6 address of the Recursive DNS Server, which is available for recursive DNS resolution service in the network advertising the RDNSS option; such a network is called site in this document.
O RDNSSアドレス：RDNSSオプションを宣伝し、ネットワーク内の再帰的なDNS解決サービスのために利用可能である再帰DNSサーバのIPv6アドレス。そのようなネットワークは、この文書に記載されているサイトと呼ばれています。
o Expiration-time: The time when this entry becomes invalid. Expiration-time is set to the value of the Lifetime field of the RDNSS option plus the current system time. Whenever a new RDNSS option with the same address is received, this field is updated to have a new expiration time. When Expiration-time becomes less than the current system time, this entry is regarded as expired.
Oの有効期限時刻：このエントリは無効になる時間。有効期限時刻はRDNSSオプションに加えて、現在のシステム時刻の寿命フィールドの値に設定されています。同じアドレスを持つ新しいRDNSSオプションを受信するたびに、このフィールドには、新しい有効期限を持っているように更新されます。満了時間は、現在のシステム時間未満になると、このエントリは期限切れとみなされます。
Note: An RDNSS address MUST be used only as long as both the RA router lifetime and the RDNSS option lifetime have not expired. The reason is that the RDNSS may not be currently reachable or may not provide service to the host's current address (e.g., due to network ingress filtering [16][17]).
注意：RDNSSアドレスは限りRAルータ寿命とRDNSSオプションの寿命の両方の期限が切れていないとして使用しなければなりません。理由はRDNSSが現在到達可能でないか、またはホストの現在のアドレスにサービスを提供しないかもしれないということである（例えば、イングレスフィルタリングをネットワークに起因する[16] [17]）。
When an IPv6 host receives the information of multiple RDNSS addresses within a site through an RA message with RDNSS option(s), it stores the RDNSS addresses (in order) into both the DNS Server List and the Resolver Repository. The processing of the RDNSS option(s) included in an RA message is as follows:
IPv6ホストがRDNSSオプション（複数可）を有するRAメッセージを介してサイト内の複数のRDNSSアドレスの情報を受信すると、DNSサーバリストとリゾルバリポジトリの両方に（順番に）RDNSSアドレスを格納します。 RDNSSオプション（複数可）の処理は、RAメッセージに含まれる以下の通りであります：
Step (a): Receive and parse the RDNSS option(s). For the RDNSS addresses in each RDNSS option, perform Step (b) through Step (d). Note that Step (e) is performed whenever an entry expires in the DNS Server List.
（a）工程：RDNSSオプション（複数可）を受信して解析します。各RDNSSオプションでRDNSSアドレスのために、ステップ（d）を工程（b）を行います。エントリはDNSサーバーの一覧に期限が切れるたびに実行される工程（e）に注意してください。
Step (b): For each RDNSS address, check the following: If the RDNSS address already exists in the DNS Server List and the RDNSS option's Lifetime field is set to zero, delete the corresponding RDNSS entry from both the DNS Server List and the Resolver Repository in order to prevent the RDNSS address from being used any more for certain reasons in network management, e.g., the breakdown of the RDNSS or a renumbering situation. The processing of this RDNSS address is finished here. Otherwise, go to Step (c).
工程（b）：各RDNSSアドレスについては、以下を確認してください。RDNSSアドレスはすでにDNSサーバリストに存在し、RDNSSオプションのLifetimeフィールドがゼロに設定されている場合は、DNSサーバーのリストとリゾルバの両方から対応するRDNSSエントリを削除RDNSSアドレスを防止するために、リポジトリは、ネットワーク管理、例えば、RDNSSまたはリナンバリング状況の内訳では、特定の理由のために、それ以上使用されています。このRDNSSアドレスの処理はここで終了します。それ以外の場合は、（c）のステップに進んでください。
Step (c): For each RDNSS address, if it already exists in the DNS Server List, then just update the value of the Expiration-time field according to the procedure specified in the second bullet of Section 6.1. Otherwise, go to Step (d).
工程（c）：それはすでにDNSサーバリストに存在する場合、各RDNSSアドレスについては、その後、ちょうど6.1節の第二の箇条書きで指定された手順に従って有効期限タイムフィールドの値を更新します。それ以外の場合は、（d）をステップに進んでください。
Step (d): For each RDNSS address, if it does not exist in the DNS Server List, register the RDNSS address and lifetime with the DNS Server List and then insert the RDNSS address in front of the Resolver Repository. In the case where the data structure for the DNS Server List is full of RDNSS entries, delete from the DNS Server List the entry with the shortest expiration time (i.e., the entry that will expire first). The corresponding RDNSS address is also deleted from the Resolver Repository. In the order in the RDNSS option, position the newly added RDNSS addresses in front of the Resolver Repository so that the new RDNSS addresses may be preferred according to their order in the RDNSS option for the DNS name resolution. The processing of these RDNSS addresses is finished here. Note that, in the case where there are several routers advertising RDNSS option(s) in a subnet, the RDNSSes that have been announced recently are preferred.
工程（d）：それはDNSサーバーの一覧に存在しない場合は、各RDNSSアドレスの場合は、DNSサーバーの一覧でRDNSSアドレスと寿命を登録して、リゾルバ倉庫の前でRDNSSアドレスを挿入します。 DNSサーバのリストのためのデータ構造はRDNSSエントリに満ちている場合には、DNSサーバー一覧から最短有効期限のエントリ（最初の期限切れとなる、すなわち、エントリ）を削除します。対応するRDNSSアドレスもリゾルバリポジトリから削除されます。新しいRDNSSアドレスがDNS名前解決のためのRDNSSオプションでそれらの順序に従って好まれ得るようにRDNSSオプション順に、リゾルバリポジトリの前に新たに追加されたRDNSSアドレスを位置付けます。これらのRDNSSアドレスの処理はここで終了します。サブネット内の複数のルータ広告RDNSSオプション（複数可）が存在する場合には、最近発表されているRDNSSesが好ましい、ということに注意してください。
Step (e): Delete each expired entry from the DNS Server List, and delete the RDNSS address corresponding to the entry from the Resolver Repository.
工程（e）：DNSサーバリストから各期限切れのエントリを削除し、リゾルバ倉庫からのエントリに対応するRDNSSアドレスを削除します。
The security of the RA option for RDNSS might be worse than ND protocol security [2]. However, any new vulnerability in this RA option is not known yet. In this context, it can be claimed that the vulnerability of ND is not worse and is a subset of the attacks that any node attached to a LAN can do independently of ND. A malicious node on a LAN can promiscuously receive packets for any router's MAC address and send packets with the router's MAC address as the source MAC address in the L2 header. As a result, L2 switches send packets addressed to the router to the malicious node. Also, this attack can send redirects that tell the hosts to send their traffic somewhere else. The malicious node can send unsolicited RA or Neighbor Advertisement (NA) replies, answer RS or Neighbor Solicitation (NS) requests, etc. Also, an attacker could configure a host to send out an RA with a fraudulent RDNSS address, which is presumably an easier avenue of attack than becoming a rogue router and having to process all traffic for the subnet. It is necessary to disable the RA RDNSS option in both routers and clients administratively to avoid this problem. All of this can be done independently of implementing ND. Therefore, it can be claimed that the RA option for RDNSS has vulnerabilities similar to those existing in current mechanisms.
RDNSSのためのRAオプションのセキュリティは、NDプロトコルセキュリティ[2]より悪いかもしれません。しかし、このRAオプションのいずれかの新しい脆弱性は、まだ知られていません。この文脈では、NDの脆弱性が悪化していないと、LANに接続されているすべてのノードはNDとは独立して行うことができます攻撃のサブセットであることを主張することができます。 LAN上の悪意のあるノードは、無差別任意のルータのMACアドレスのパケットを受信すると、L2ヘッダ内の送信元MACアドレスとしてルータのMACアドレスを持つパケットを送信することができます。結果として、L2スイッチは、悪意のあるノードへのルータ宛のパケットを送信します。また、この攻撃は、どこか自分のトラフィックを送信するホストを伝えるリダイレクトを送ることができます。悪意のあるノード迷惑RAや近隣広告（NA）応答を送信することができ、攻撃者はおそらくある詐欺RDNSSアドレス、とRAを送信するホストを設定することができ、また、などRSまたは近隣要請（NS）の要求に答えます不正なルータになることやサブネットのすべてのトラフィックを処理するよりも、攻撃の容易な道。この問題を回避するために、管理上のルーターとクライアントの両方でRA RDNSSオプションを無効にする必要があります。このすべてが独立してNDを実装するのに行うことができます。したがって、RDNSSのためのRAオプションは現在のメカニズムに存在するものと同様の脆弱性を持っていると主張することができます。
If the Secure Neighbor Discovery (SEND) protocol is used as a security mechanism for ND, all the ND options including the RDNSS option are automatically included in the signatures [11], so the RDNSS transport is integrity-protected. However, since any valid SEND node can still insert RDNSS options, SEND cannot verify who is or is not authorized to send the options.
セキュア近隣探索（SEND）プロトコルはNDのセキュリティメカニズムとして使用される場合、RDNSSオプションを含むすべてのNDオプションが自動的に署名[11]に含まれているので、RDNSS輸送は完全性保護されています。任意の有効なSENDノードがまだRDNSSオプションを挿入することができますので、SENDがあるかのオプションを送信することを許可されていない者を確認することはできません。
The IANA has assigned a new IPv6 Neighbor Discovery Option type for the RDNSS option defined in this document.
IANAは、この文書で定義されたRDNSSオプションの新しいIPv6近隣探索オプションタイプが割り当てられています。
Option Name Type
RDNSS option 25
The IANA registry for these options is:
これらのオプションのIANAレジストリは次のとおりです。
http://www.iana.org/assignments/icmpv6-parameters
ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／いｃｍｐｖ６ーぱらめてｒｓ
This document has greatly benefited from inputs by Robert Hinden, Pekka Savola, Iljitsch van Beijnum, Brian Haberman and Tim Chown. The authors appreciate their contributions.
この文書では、大幅ロバートHindenとペッカSavola、IljitschバンBeijnum、ブライアンハーバーマンとティムchownコマンドで入力から恩恵を受けています。作者は彼らの貢献に感謝しています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[2] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、RFC 4861 "IPバージョン6（IPv6）のための近隣探索" 2007年9月。
[3] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[3]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。
[4] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987.
[4] Mockapetris、P.、 "ドメイン名 - 概念と施設"、RFC 1034、1987年11月。
[5] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987.
[5] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、RFC 1035、1987年11月。
[6] Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[6] Droms、R.、エド。、 "IPv6の動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[7] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[7] Droms、R.、 "IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス"、RFC 3736、2004年4月。
[8] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[8] Droms、R.、エド。、RFC 3646、2003年12月、 "IPv6の動的ホスト構成プロトコル（DHCPv6）のためのDNSの設定オプション"。
[9] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server Information Approaches", RFC 4339, February 2006.
[9]チョン、J.、エド。、 "DNSサーバ情報のアプローチのIPv6ホストの設定"、RFC 4339、2006年2月を。
[10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[10]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[11] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[11] Arkko、J.、編、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[12] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", March 1999.
[12] ANSI / IEEE規格802.11、 "パート11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様"、1999年3月。
[13] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: High-speed Physical Layer in the 5 GHZ Band", September 1999.
[13] IEEE標準の802.11aの、「パート11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様：5GHz帯における高速物理層」、1999年9月。
[14] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Higher-Speed Physical Layer Extension in the 2.4 GHz Band", September 1999.
[14] IEEE規格の802.11bの、「パート11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様：2.4GHz帯における高速物理層の拡張」、1999年9月。
[15] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Further Higher Data Rate Extension in the 2.4 GHz Band", April 2003.
[15] IEEE P802.11g / D8.2、 "パート11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様：2.4GHz帯におけるより高いデータレート拡張"、2003年4月。
[16] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", Work in Progress, July 2007.
[16]ダマス、J.およびF.ネヴェス、進歩、2007年7月の作業「反射攻撃に再帰ネームサーバの使用を防止します」。
[17] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[17]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス拒否攻撃を破り"、BCP 38、RFC 2827、2000年5月。
Authors' Addresses
著者のアドレス
Jaehoon Paul Jeong (editor) ETRI/Department of Computer Science and Engineering University of Minnesota 117 Pleasant Street SE Minneapolis, MN 55455 USA
Jaehoonポール・チョン（エディタ）コンピュータサイエンスとミネソタ117プレザントストリートSEミネアポリス、MN 55455 USAのエンジニアリング大学のETRI /教室
Phone: +1 651 587 7774 Fax: +1 612 625 0572 EMail: jjeong@cs.umn.edu URI: http://www.cs.umn.edu/~jjeong/
電話：+1 651 587 7774ファックス：+1 612 625 0572 Eメール：jjeong@cs.umn.edu URI：http://www.cs.umn.edu/~jjeong/
Soohong Daniel Park Mobile Convergence Laboratory SAMSUNG Electronics 416 Maetan-3dong, Yeongtong-Gu Suwon, Gyeonggi-Do 443-742 Korea
Soohongダニエル・パークモバイルコンバージェンス研究所三星電子416 Maetan-3dong、霊通区水原、京畿道443から742韓国
Phone: +82 31 200 4508 EMail: soohong.park@samsung.com
電話：+82 31 200 4508 Eメール：soohong.park@samsung.com
Luc Beloeil France Telecom R&D 42, rue des coutures BP 6243 14066 CAEN Cedex 4 France
ルカBeloeilのフランステレコムR＆D 42、縫合通りBP 6243 14066カーンセデックス4フランス
Phone: +33 02 3175 9391 EMail: luc.beloeil@orange-ftgroup.com
電話：+33 02 3175 9391 Eメール：luc.beloeil@orange-ftgroup.com
Syam Madanapalli Ordyn Technologies 1st Floor, Creator Building, ITPL Bangalore - 560066 India
1つのサム服フロアmadanapalli ordhyam技術、創造主の建物、バンガロールaitipil - 560066、インド
Phone: +91-80-40383000 EMail: smadanapalli@gmail.com
電話：+ 91-80-40383000 Eメール：smadanapalli@gmail.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に情報を記述してください。