[要約] RFC 5006は、IPv6ルータ広告オプションを使用してDNS構成を行うための仕様です。このRFCの目的は、IPv6ネットワークでのDNS設定を効率的かつ一貫性のある方法で提供することです。
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
DNS構成のIPv6ルーター広告オプション
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Abstract
概要
This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses to IPv6 hosts.
このドキュメントは、IPv6ルーターがDNS再帰サーバーアドレスをIPv6ホストに宣伝できるようにする新しい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のステートレスアドレスAutoconfigurationのNeighbor Discovery（ND）は、1つ以上のIPv6アドレス、デフォルトルーター、およびその他のパラメーター[2] [3]で固定またはモバイルノードを構成する方法を提供します。WebサーバーなどのDNS名で識別されるインターネット内の追加サービスへのアクセスをサポートするために、DNS名の解像度には少なくとも1つの再帰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 a/b/g [12] - [15]などの異なるワイヤレスLAN（WLAN）に接続するたびに、DNSリゾルバーで手動で構成することは不可能です。通常、DHCP [6] - [8]は、そのようなリゾルバーを見つけるために使用されます。このドキュメントは、IPv6ルーターがDNS再帰サーバーアドレスをIPv6ホストに宣伝できるようにするために、新しい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ステートレスアドレスAutoconfigurationを介して自動化され、サーバーアドレスの取得とサーバーとの通信の遅延が重要であるネットワークで便利でオプションの代替品です。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ベースのアプローチの利点と短所については、[9]と、DHCPやよく知られたAnycastアドレスなどの他のアプローチとともに説明されています。
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アプローチを注文するには、RAメッセージ[2]でO（その他のステートフル構成）フラグを使用できます。RDNSSオプションがRAメッセージに含まれていない場合、IPv6ホストは、Oフラグが設定されているかどうかにかかわらず、DHCPV6 [6] - [8]を介してDNS構成を実行できます。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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）：[4]および[5]で定義されているように、ドメイン名をIPアドレスに変換するための再帰的なDNS解像度サービスを提供するサーバー。
o RDNSS Option: IPv6 RA option to deliver the RDNSS information to IPv6 hosts [2].
o RDNSSオプション：RDNSS情報をIPv6ホストに配信する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].
o DNSサーバーリスト：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 Resolver Repository：RDNSS付きの構成リポジトリは、ホストのDNSリゾルバーがDNS名解像度に使用することに対処します。たとえば、UNIX Resolverファイル（つまり、 /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ホストは、ルーターによって定期的に送信されるRAメッセージまたはルーター勧誘（RS）によって定期的に送信されたRAメッセージを介して、1つ以上のRDNSSEの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.
RDNSSオプションを介して、NDプロトコル（[2]および[3]）に基づくプレフィックス情報オプションとともに、IPv6ホストは、RDNSS情報の個別のメッセージ交換を必要とせずに同時にIPv6アドレスとRDNSのネットワーク構成を実行できます。。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情報の自動構成または再配布は、ルーター[6] - [8]でDHCPV6クライアントを実行することで可能です。ルーター内のRDNSSアドレスの自動構成は、このドキュメントの範囲外です。
The IPv6 DNS configuration mechanism in this document needs a new ND option in Neighbor Discovery: the Recursive DNS Server (RDNSS) option.
このドキュメントのIPv6 DNS構成メカニズムには、Neighbor Discovery：The Recursive DNS Server（RDNSS）オプションで新しい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です。追加のRDNSアドレスはすべて、長さを2回増加させます。長さフィールドは、受信機によって使用され、オプションのIPv6アドレスの数を決定します。
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サービスを提供し、モバイルホストがリモートRDNSSEよりローカルRDNSSEを好むことを可能にするために、生涯の価値は、RFC 4861の最大RA間隔（MaxrTradvinterval）と同じくらい長く、そして最大である必要があります。Maxrtradvintervalの2倍。寿命は次のように制限されるべきです：maxrtradvinterval <= lifetime <= 2*maxrtradvinterval。すべての1ビット（0xffffffffff）の値は無限を表します。ゼロの値は、RDNSアドレスを使用しなくなる必要があることを意味します。
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サーバーの1つ以上の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.
o RDNSSオプションが有効な場合、ホストは、長さフィールドの値が最小値（3）以上である限り、オプションの値をDNSサーバーリストとリゾルバーリポジトリにコピーする必要があります。ホストは、十分な数のRDNSSアドレスを収集した場合、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.
o RDNSSオプションが無効である場合（たとえば、長さフィールドの値は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サーバーリストとResolverリポジトリの両方に保存および管理できます。
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情報がユーザースペースに保存され、カーネルで動作している環境では、カーネルスペースのRDNSSアドレスのDNSサーバーリストとユーザースペースのリゾルバーリポジトリを同期する必要があります。同期の場合、カーネルでNDが機能する実装は、カーネルからリゾルバーリポジトリにRDNSS情報を更新するための書き込み操作を提供する必要があります。簡単なアプローチの1つは、RDNSSの寿命を常に監視し続けるデーモン（または定義された間隔で呼ばれるプログラム）を持つことです。DNSサーバーリストに期限切れのエントリがあるときはいつでも、デーモンはResolverリポジトリから対応するエントリを削除できます。
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:
カーネルまたはユーザー空間プロセス（RAが処理される場所に応じて）は、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アドレスの情報を受信すると、RDNSSアドレスをDNSサーバーリストとリゾルバーリポジトリの両方に保存します。RAメッセージに含まれるRDNSSオプションの処理は次のとおりです。
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アドレスの場合、ステップ（b）からステップ（d）を実行します。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オプションのライフタイムフィールドがゼロに設定されている場合、DNSサーバーリストとリゾルバの両方から対応するRDNSエントリを削除します。リポジトリ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）：各RDNSアドレスについて、DNSサーバーリストに既に存在する場合は、セクション6.1の2番目の弾丸で指定された手順に従って、有効期限フィールドの値を更新するだけです。それ以外の場合は、ステップ（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）：各RDNSアドレスについて、DNSサーバーリストに存在しない場合は、RDNSSアドレスと寿命をDNSサーバーリストに登録し、RDNSSアドレスをResolverリポジトリの前に挿入します。DNSサーバーリストのデータ構造がRDNSSエントリでいっぱいになっている場合、DNSサーバーから削除エントリを最短の有効期間（つまり、最初に期限切れにするエントリ）があります。対応するRDNSSアドレスもResolverリポジトリから削除されます。RDNSSオプションの順序で、RESOLVERリポジトリの前に新しく追加されたRDNSSアドレスを配置して、DNS名解像度のRDNSSオプションの注文に応じて新しいRDNSSアドレスを優先することができます。これらのRDNSアドレスの処理はここで終了します。サブネットにRDNSSオプションを広告するいくつかのルーターがある場合、最近発表されたRDNSSが推奨されることに注意してください。
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サーバーリストから期限切れの各エントリを削除し、Resolverリポジトリからのエントリに対応する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またはNeighbor Advertisement（NA）返信を送信したり、RSまたはNeighbor Solicitation（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.
Secure Neighbor Discovery（送信）プロトコルがNDのセキュリティメカニズムとして使用される場合、RDNSSオプションを含むすべてのNDオプションが署名[11]に自動的に含まれるため、RDNSSトランスポートは整合性保護されています。ただし、有効な送信ノードは引き続きRDNSSオプションを挿入できるため、Sendはオプションを送信する権限を与えられている、または許可されていないことを確認できません。
The IANA has assigned a new IPv6 Neighbor Discovery Option type for the RDNSS option defined in this document.
IANAは、このドキュメントで定義されているRDNSSオプションに新しいIPv6 Neighter Discoveryオプションタイプを割り当てました。
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.
この文書は、ロバート・ヒンデン、ペッカ・サヴォラ、イルジッチ・ヴァン・ベイニュム、ブライアン・ハーバーマン、ティム・チャウンによるインプットから大きな恩恵を受けています。著者は、彼らの貢献に感謝しています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[3] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[3] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6ステートレスアドレスAutoconfiguration」、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.、ed。、「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.、ed。、「IPv6（DHCPV6）の動的ホスト構成プロトコルのDNS構成オプション」、RFC 3646、2003年12月。
[9] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server Information Approaches", RFC 4339, February 2006.
[9] Jeong、J.、ed。、「DNSサーバー情報アプローチのIPv6ホスト構成」、RFC 4339、2006年2月。
[10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[10] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[11] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[11] Arkko、J.、ed。、「Secure Neighbor Discovery（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 STD 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 STD 802.11a、「パート11：ワイヤレスLANメディアアクセス制御（MAC）および物理層（PHY）仕様：5 GHzバンドの高速物理層」、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 STD 802.11b、「パート11：ワイヤレスLANメディアアクセス制御（MAC）および物理層（PHY）仕様：2.4 GHzバンドのより高いスピードの物理層拡張」、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）仕様：2003年4月、2.4 GHzバンドのさらに高いデータレート拡張」。
[16] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", Work in Progress, July 2007.
[16] Damas、J。およびF. Neves、「リフレクター攻撃での再帰的な名前の使用を防止する」、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] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、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
ジェフーンポールジョン（編集者）エトリ/ミネソタ州コンピュータサイエンスエンジニアリング大学117プレザントストリートSEミネアポリス、ミネソタ州55455米国
Phone: +1 651 587 7774
Fax: +1 612 625 0572
EMail: 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
スーホンダニエルパークモバイルコンバージェンスラボラトリーサムスンエレクトロニクス416 Maetan-3dong、Yeongtong-gu Suwon、Gyeonggi-Do 443-742 Korea
Phone: +82 31 200 4508
EMail: soohong.park@samsung.com
Luc Beloeil France Telecom R&D 42, rue des coutures BP 6243 14066 CAEN Cedex 4 France
Luc Beloeil France Telecom R＆D 42、Rue des Coutures BP 6243 14066 Caen Cedex 4 France
Phone: +33 02 3175 9391
EMail: luc.beloeil@orange-ftgroup.com
Syam Madanapalli Ordyn Technologies 1st Floor, Creator Building, ITPL Bangalore - 560066 India
Syam Madanapalli Ordyn Technologies 1st Floor、Creator Building、ITPL Bangalore -560066 India
Phone: +91-80-40383000
EMail: smadanapalli@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。