[要約] RFC 6106は、IPv6ルータ広告オプションを使用してDNS構成を行うための仕様です。このRFCの目的は、IPv6ネットワークでのDNS設定を効率的かつ自動化することです。
Internet Engineering Task Force (IETF) J. Jeong
Request for Comments: 6106 Brocade/ETRI
Obsoletes: 5006 S. Park
Category: Standards Track SAMSUNG Electronics
ISSN: 2070-1721 L. Beloeil
France Telecom R&D
S. Madanapalli
iRam Technologies
November 2010
IPv6 Router Advertisement Options for DNS Configuration
DNS構成のIPv6ルーター広告オプション
Abstract
概要
This document specifies IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts.
このドキュメントは、IPv6ルーター広告オプションを指定して、IPv6ルーターがDNS再帰サーバーアドレスのリストとDNS検索リストをIPv6ホストに宣伝できるようにします。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6106.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6106で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Applicability Statements ...................................3
1.2. Coexistence of RA Options and DHCP Options for DNS
Configuration ..............................................4
2. Requirements Language ...........................................4
3. Terminology .....................................................4
4. Overview ........................................................5
5. Neighbor Discovery Extension ....................................5
5.1. Recursive DNS Server Option ................................6
5.2. DNS Search List Option .....................................7
5.3. Procedure of DNS Configuration .............................8
5.3.1. Procedure in IPv6 Host ..............................8
5.3.2. Warnings for DNS Options Configuration .............10
6. Implementation Considerations ..................................10
6.1. DNS Repository Management .................................10
6.2. Synchronization between DNS Server List and
Resolver Repository .......................................11
6.3. Synchronization between DNS Search List and
Resolver Repository .......................................12
7. Security Considerations ........................................13
7.1. Security Threats ..........................................13
7.2. Recommendations ...........................................14
8. IANA Considerations ............................................15
9. Acknowledgements ...............................................15
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................16
Appendix A. Changes from RFC 5006 ................................18
The purpose of this document is to standardize an IPv6 Router Advertisement (RA) option for DNS Recursive Server Addresses used for the DNS name resolution in IPv6 hosts. This RA option was specified in an earlier Experimental specification [RFC5006]. This document is also to define a new RA option for Domain Name Search Lists for an enhanced DNS configuration. Thus, this document obsoletes [RFC5006], which only defines the RA option for DNS Recursive Server Addresses.
このドキュメントの目的は、IPv6ホストのDNS名解像度に使用されるDNS再帰サーバーアドレスのIPv6ルーター広告（RA）オプションを標準化することです。このRAオプションは、以前の実験仕様[RFC5006]で指定されていました。このドキュメントは、拡張されたDNS構成のドメイン名検索リストの新しいRAオプションを定義します。したがって、このドキュメントは、DNS再帰サーバーアドレスのRAオプションのみを定義するものである[RFC5006]を廃止します。
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 [RFC4861][RFC4862]. Most Internet services are identified by using a DNS name. The two RA options defined in this document provide the DNS information needed for an IPv6 host to reach Internet services.
IPバージョン6およびIPv6ステートレスアドレスの近隣発見（ND）Autoconfigurationは、1つ以上のIPv6アドレス、デフォルトルーター、およびその他のパラメーター[RFC4861] [RFC4862]で固定またはモバイルノードを構成する方法を提供します。ほとんどのインターネットサービスは、DNS名を使用して識別されます。このドキュメントで定義されている2つのRAオプションは、IPv6ホストがインターネットサービスに到達するために必要なDNS情報を提供します。
It is infeasible to manually configure nomadic hosts each time they connect to a different network. While a one-time static configuration is possible, it is generally not desirable on general-purpose hosts such as laptops. For instance, locally defined name spaces would not be available to the host if it were to run its own name server software directly connected to the global DNS.
異なるネットワークに接続するたびに、Nomadicホストを手動で構成することは不可能です。1回限りの静的構成は可能ですが、一般的にラップトップなどの汎用ホストでは望ましくありません。たとえば、グローバルDNSに直接接続された独自の名前サーバーソフトウェアを実行する場合、ホストはローカルで定義された名前スペースを使用できません。
The DNS information can also be provided through DHCP [RFC3315][RFC3736][RFC3646]. However, the access to DNS is a fundamental requirement for almost all hosts, so IPv6 stateless autoconfiguration cannot stand on its own as an alternative deployment model in any practical network without any support for DNS configuration.
DNS情報は、DHCP [RFC3315] [RFC3736] [RFC3646]を介して提供することもできます。ただし、DNSへのアクセスはほぼすべてのホストにとって基本的な要件であるため、IPv6 Stateless Autoconfigurationは、DNS構成をサポートすることなく、実用的なネットワークの代替展開モデルとして独自に耐えることはできません。
These issues are not pressing in dual-stack networks as long as a DNS server is available on the IPv4 side, but they become more critical with the deployment of IPv6-only networks. As a result, this document defines a mechanism based on IPv6 RA options to allow IPv6 hosts to perform the automatic DNS configuration.
これらの問題は、DNSサーバーがIPv4側で利用できる限り、デュアルスタックネットワークでは押し付けられていませんが、IPv6のみのネットワークの展開によりより重要になります。その結果、このドキュメントでは、IPv6 RAオプションに基づいたメカニズムを定義して、IPv6ホストが自動DNS構成を実行できるようにします。
RA-based DNS configuration is a useful alternative in networks where an IPv6 host's address is autoconfigured through IPv6 stateless address autoconfiguration and where there is either no DHCPv6 infrastructure at all or some hosts do not have a DHCPv6 client. The intention is to enable the full configuration of basic networking information for hosts without requiring DHCPv6. However, when in many networks some additional information needs to be distributed, those networks are likely to employ DHCPv6. In these networks, RA-based DNS configuration may not be needed.
RAベースのDNS構成は、IPv6ホストのアドレスがIPv6ステートレスアドレスAutoconfigurationを介して自動化され、DHCPV6インフラストラクチャがまったくないか、一部のホストがDHCPV6クライアントを持っていない場合、ネットワークで有用な代替品です。意図は、DHCPV6を必要とせずにホストの基本的なネットワーキング情報の完全な構成を可能にすることです。ただし、多くのネットワークでは、いくつかの追加情報を配布する必要がある場合、それらのネットワークはDHCPV6を使用する可能性があります。これらのネットワークでは、RAベースのDNS構成は必要ない場合があります。
RA-based DNS configuration allows an IPv6 host to acquire the DNS configuration (i.e., DNS recursive server addresses and DNS Search List) for the link(s) to which the host is connected. Furthermore, the host learns this DNS configuration from the same RA message that provides configuration information for the link, thereby avoiding also running DHCPv6.
RAベースのDNS構成により、IPv6ホストは、ホストが接続されているリンクのDNS構成（つまり、DNS再帰サーバーアドレスとDNS検索リスト）を取得できます。さらに、ホストは、リンクの構成情報を提供する同じRAメッセージからこのDNS構成を学習し、DHCPV6の実行も回避します。
The advantages and disadvantages of the RA-based approach are discussed in [RFC4339] along with other approaches, such as the DHCP and well-known anycast address approaches.
RAベースのアプローチの利点と欠点は、[RFC4339]と、DHCPやよく知られたAnycastアドレスアプローチなどの他のアプローチとともに説明されています。
Two protocols exist to configure the DNS information on a host, the Router Advertisement options described in this document and the DHCPv6 options described in [RFC3646]. They can be used together. The rules governing the decision to use stateful configuration mechanisms are specified in [RFC4861]. Hosts conforming to this specification MUST extract DNS information from Router Advertisement messages, unless static DNS configuration has been specified by the user. If there is DNS information available from multiple Router Advertisements and/or from DHCP, the host MUST maintain an ordered list of this information as specified in Section 5.3.1.
ホストに関するDNS情報、このドキュメントで説明されているルーター広告オプションと[RFC3646]で説明されているDHCPV6オプションを構成するために、2つのプロトコルが存在します。それらは一緒に使用できます。ステートフルな構成メカニズムを使用する決定を管理する規則は、[RFC4861]で指定されています。この仕様に準拠しているホストは、ユーザーが静的DNS構成が指定されていない限り、ルーター広告メッセージからDNS情報を抽出する必要があります。複数のルーター広告および/またはDHCPから利用可能なDNS情報がある場合、ホストはセクション5.3.1で指定されているように、この情報の順序付けリストを維持する必要があります。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This document uses the terminology described in [RFC4861] and [RFC4862]. In addition, four new terms are defined below:
この文書は、[RFC4861]および[RFC4862]で説明されている用語を使用しています。さらに、4つの新しい用語を以下に定義します。
o Recursive DNS Server (RDNSS): Server that provides a recursive DNS resolution service for translating domain names into IP addresses as defined in [RFC1034] and [RFC1035].
o 再帰DNSサーバー（RDNSS）：[RFC1034]および[RFC1035]で定義されているように、ドメイン名をIPアドレスに変換するための再帰DNS解像度サービスを提供するサーバー。
o RDNSS Option: IPv6 RA option to deliver the RDNSS information to IPv6 hosts [RFC4861].
o RDNSSオプション：RDNSS情報をIPv6ホスト[RFC4861]に配信するIPv6 RAオプション。
o DNS Search List (DNSSL): The list of DNS suffix domain names used by IPv6 hosts when they perform DNS query searches for short, unqualified domain names.
o DNS検索リスト（DNSSL）：IPv6ホストが使用するDNSサフィックスドメイン名のリストは、短い、資格のないドメイン名のDNSクエリ検索を実行するときに使用します。
o DNSSL Option: IPv6 RA option to deliver the DNSSL information to IPv6 hosts.
o DNSSLオプション：DNSSL情報をIPv6ホストに配信するIPv6 RAオプション。
o DNS Repository: Two data structures for managing DNS Configuration Information in the IPv6 protocol stack in addition to Neighbor Cache and Destination Cache for Neighbor Discovery [RFC4861]. The first data structure is the DNS Server List for RDNSS addresses and the second is the DNS Search List for DNS search domain names.
o DNSリポジトリ：IPv6プロトコルスタックでDNS構成情報を管理するための2つのデータ構造と、近隣発見のための近隣キャッシュと宛先キャッシュ[RFC4861]に加えて。最初のデータ構造は、RDNSSアドレスのDNSサーバーリストであり、2番目はDNS検索ドメイン名のDNS検索リストです。
o Resolver Repository: Configuration repository with RDNSS addresses and a DNS Search List 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 ResolverがDNS名解像度に使用するDNS検索リスト。たとえば、UNIX Resolverファイル（つまり、 / etc / Resolv.conf）およびWindowsレジストリ。
This document standardizes the ND option called the RDNSS option defined in [RFC5006] that contains the addresses of recursive DNS servers. This document also defines a new ND option called the DNSSL option for the Domain Search List. This is to maintain parity with the DHCPv6 options and to ensure that there is necessary functionality to determine the search domains.
このドキュメントは、再帰的なDNSサーバーのアドレスを含む[RFC5006]で定義されたRDNSSオプションと呼ばれるNDオプションを標準化しています。このドキュメントでは、ドメイン検索リストのDNSSLオプションと呼ばれる新しいNDオプションも定義されています。これは、DHCPV6オプションのパリティを維持し、検索ドメインを決定するために必要な機能があることを確認するためです。
The existing ND message (i.e., Router Advertisement) is used to carry this information. An IPv6 host can configure the IPv6 addresses of one or more RDNSSes via RA messages. Through the RDNSS and DNSSL options, along with the prefix information option based on the ND protocol ([RFC4861] and [RFC4862]), an IPv6 host can perform the network configuration of its IPv6 address and the DNS information simultaneously without needing DHCPv6 for the DNS configuration. The RA options for RDNSS and DNSSL can be used on any network that supports the use of ND.
既存のNDメッセージ（つまり、ルーター広告）は、この情報を携帯するために使用されます。IPv6ホストは、RAメッセージを介して1つ以上のRDNSSEのIPv6アドレスを構成できます。NDプロトコル（[RFC4861]および[RFC4862]）に基づくRDNSSおよびDNSSLオプションと、DHCPV6を必要とすることなくIPv6アドレスのネットワーク構成とDNS情報を同時に実行できます。DNS構成。RDNSSおよびDNSSLのRAオプションは、NDの使用をサポートする任意のネットワークで使用できます。
This approach requires the manual configuration or other automatic mechanisms (e.g., DHCPv6 or vendor proprietary configuration mechanisms) to configure the DNS information in routers sending the advertisements. The automatic configuration of RDNSS addresses and a DNS Search List in routers is out of scope for this document.
このアプローチでは、広告を送信するルーターでDNS情報を構成するために、手動構成またはその他の自動メカニズム（DHCPV6またはベンダー独自の構成メカニズムなど）が必要です。RDNSSアドレスの自動構成とルーターのDNS検索リストは、このドキュメントの範囲外です。
The IPv6 DNS configuration mechanism in this document needs two new ND options in Neighbor Discovery: (i) the Recursive DNS Server (RDNSS) option and (ii) the DNS Search List (DNSSL) option.
このドキュメントのIPv6 DNS構成メカニズムには、近隣発見に2つの新しい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 bounded as MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval where MaxRtrAdvInterval is the Maximum RA Interval defined in [RFC4861]. 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よりローカルRDNSSを好むことを可能にするために、寿命の価値はmaxrtradvinterval <= 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 DNSSL option contains one or more domain names of DNS suffixes. All of the domain names share the same Lifetime value. If it is desirable to have different Lifetime values, multiple DNSSL options can be used. Figure 2 shows the format of the DNSSL option.
DNSSLオプションには、DNSサフィックスの1つ以上のドメイン名が含まれています。すべてのドメイン名は同じ生涯値を共有します。異なる生涯値を持つことが望ましい場合は、複数のDNSSLオプションを使用できます。図2は、DNSSLオプションの形式を示しています。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Domain Names of DNS Search List :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: DNS Search List (DNSSL) Option Format
図2：DNS検索リスト（DNSSL）オプション形式
Fields: Type 8-bit identifier of the DNSSL option type as assigned by the IANA: 31
フィールド：IANAによって割り当てられたDNSSLオプションタイプのタイプ8ビット識別子：31
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 2 if at least one domain name is contained in the option. The Length field is set to a multiple of 8 octets to accommodate all the domain names in the field of Domain Names of DNS Search List.
長さ8ビット符号なし整数。オプションの長さ（タイプフィールドと長さフィールドを含む）は、8オクテットの単位です。少なくとも1つのドメイン名がオプションに含まれている場合、最小値は2です。長さフィールドは、DNS検索リストのドメイン名のフィールドにあるすべてのドメイン名に対応するために、8オクテットの倍数に設定されています。
Lifetime 32-bit unsigned integer. The maximum time, in seconds (relative to the time the packet is sent), over which this DNSSL domain name MAY be used for name resolution. The Lifetime value has the same semantics as with the RDNSS option. That is, Lifetime SHOULD be bounded as follows: MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval.
生涯32ビットの符号なし整数。最大時間、秒単位（パケットが送信される時間と比較して）で、このDNSSLドメイン名を名前の解決に使用できます。生涯値は、RDNSSオプションと同じセマンティクスを持っています。つまり、寿命は次のように制限されるべきです：maxrtradvinterval <= lifetime <= 2*maxrtradvinterval。
A value of all one bits (0xffffffff) represents infinity. A value of zero means that the DNSSL domain name MUST no longer be used.
すべての1ビット（0xffffffffff）の値は無限を表します。ゼロの値は、DNSSLドメイン名を使用しなくなる必要があることを意味します。
Domain Names of DNS Search List One or more domain names of DNS Search List that MUST be encoded using the technique described in Section 3.1 of [RFC1035]. By this technique, each domain name is represented as a sequence of labels ending in a zero octet, defined as domain name representation. For more than one domain name, the corresponding domain name representations are concatenated as they are. Note that for the simple decoding, the domain names MUST NOT be encoded in a compressed form, as described in Section 4.1.4 of [RFC1035]. Because the size of this field MUST be a multiple of 8 octets, for the minimum multiple including the domain name representations, the remaining octets other than the encoding parts of the domain name representations MUST be padded with zeros.
DNS検索リストのドメイン名[RFC1035]のセクション3.1で説明されている手法を使用してエンコードする必要があるDNS検索リストの1つ以上のドメイン名。この手法により、各ドメイン名は、ドメイン名表現として定義されたゼロオクテットで終わる一連のラベルとして表されます。複数のドメイン名の場合、対応するドメイン名表現はそのまま連結されます。単純なデコードの場合、[RFC1035]のセクション4.1.4で説明されているように、ドメイン名を圧縮形式でエンコードする必要はないことに注意してください。このフィールドのサイズは8オクテットの倍数である必要があるため、ドメイン名表現を含む最小倍数の場合、ドメイン名表現のエンコーディング部分以外の残りのオクテットはゼロで埋められなければなりません。
Note: An RDNSS address or a DNSSL domain name MUST be used only as long as both the RA router Lifetime (advertised by a Router Advertisement message [RFC4861]) and the corresponding option Lifetime have not expired. The reason is that in the current network to which an IPv6 host is connected, the RDNSS may not be currently reachable, that the DNSSL domain name is not valid any more, or that these options do not provide service to the host's current address (e.g., due to network ingress filtering [RFC2827][RFC5358]).
注：RDNSSアドレスまたはDNSSLドメイン名は、RAルーターの寿命（ルーター広告メッセージ[RFC4861]によって宣伝されている）と対応するオプションの寿命が切れていない限りのみ使用する必要があります。その理由は、IPv6ホストが接続されている現在のネットワークでは、RDNSSが現在到達できない可能性があるか、DNSSLドメイン名がもう有効ではないこと、またはこれらのオプションがホストの現在のアドレスにサービスを提供しないためです（例：、ネットワークイングレスフィルタリングのため[RFC2827] [RFC5358]）。
The procedure of DNS configuration through the RDNSS and DNSSL options is the same as with any other ND option [RFC4861].
RDNSSおよびDNSSLオプションを介したDNS構成の手順は、他のNDオプション[RFC4861]と同じです。
When an IPv6 host receives DNS options (i.e., RDNSS option and DNSSL option) through RA messages, it processes the options as follows:
IPv6ホストがRAメッセージを介してDNSオプション（つまり、RDNSSオプションとDNSSLオプション）を受信すると、次のようにオプションを処理します。
o The validity of DNS options is checked with the Length field; that is, the value of the Length field in the RDNSS option is greater than or equal to the minimum value (3), and the value of the Length field in the DNSSL option is greater than or equal to the minimum value (2).
o DNSオプションの有効性は、長さフィールドでチェックされます。つまり、RDNSSオプションの長さフィールドの値は最小値（3）以上であり、DNSSLオプションの長さフィールドの値は最小値（2）以上です。
o If the DNS options are valid, the host SHOULD copy the values of the options into the DNS Repository and the Resolver Repository in order. Otherwise, the host MUST discard the options. Refer to Section 6 for the detailed procedure.
o DNSオプションが有効な場合、ホストはオプションの値をDNSリポジトリとリゾルバーリポジトリに順番にコピーする必要があります。それ以外の場合、ホストはオプションを破棄する必要があります。詳細な手順については、セクション6を参照してください。
When the IPv6 host has gathered a sufficient number (e.g., three) of RDNSS addresses (or DNS search domain names), it SHOULD maintain RDNSS addresses (or DNS search domain names) by the sufficient number such that the latest received RDNSS or DNSSL is more preferred to the old ones; that is, when the number of RDNSS addresses (or DNS search domain names) is already the sufficient number, the new one replaces the old one that will expire first in terms of Lifetime. As an exceptional case, if the received RDNSS addresses (or DNS search domain names) already exist in the IPv6 host, their Lifetime fields update their Expiration-time, that is, when the corresponding DNS information expires in the IPv6 host; note that when the Lifetime field has zero, the corresponding RDNSS (or DNS search domain name) is deleted from the IPv6 host. Except for this update, the IPv6 host SHOULD ignore other RDNSS addresses (or DNS search domain names) within an RDNSS (or a DNSSL) option and/or additional RDNSS (or DNSSL) options within an RA. Refer to Section 6 for the detailed procedure. Note that the sufficient number is a system parameter, so it can be determined by a local policy. Also, separate parameters can be specified for the sufficient number of RDNSS addresses and that of DNS search domain names, respectively. In this document, three is RECOMMENDED as a sufficient number considering both the robust DNS query and the reasonably time-bounded recognition of the unreachability of DNS servers.
IPv6ホストがRDNSSアドレス（またはDNS検索ドメイン名）の十分な数（3つ）を収集した場合、最新のRDNSSまたはDNSSLが十分な数字でRDNSSアドレス（またはDNS検索ドメイン名）を維持する必要があります。古いものよりもより好まれています。つまり、RDNSのアドレスの数（またはDNS検索ドメイン名）の数がすでに十分な数である場合、新しいものは生涯で最初に期限切れになる古いものを置き換えます。例外的なケースとして、受信したRDNSSアドレス（またはDNS検索ドメイン名）がすでにIPv6ホストに存在する場合、生涯フィールドは有効期限を更新します。つまり、対応するDNS情報がIPv6ホストで期限切れになる場合です。Lifetimeフィールドがゼロの場合、対応するRDNS（またはDNS検索ドメイン名）がIPv6ホストから削除されることに注意してください。この更新を除き、IPv6ホストは、RDNSS（またはDNSL）オプション内の他のRDNSSアドレス（またはDNS検索ドメイン名）を無視する必要があります。詳細な手順については、セクション6を参照してください。十分な数字がシステムパラメーターであるため、ローカルポリシーによって決定できることに注意してください。また、十分な数のRDNSアドレスとDNS検索ドメイン名のパラメーターをそれぞれ指定できます。このドキュメントでは、堅牢なDNSクエリとDNSサーバーの耐え付け性の合理的な時間に縛られた認識の両方を考慮すると、3つが十分な数として推奨されます。
In the case where the DNS options of RDNSS and DNSSL can be obtained from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep some DNS options from all sources. Unless explicitly specified for the discovery mechanism, the exact number of addresses and domain names to keep is a matter of local policy and implementation choice. However, the ability to store at least three RDNSS addresses (or DNSSL domain names) from at least two different sources is RECOMMENDED. The DNS options from Router Advertisements and DHCP SHOULD be stored into the DNS Repository and Resolver Repository so that information from DHCP appears there first and therefore takes precedence. Thus, the DNS information from DHCP takes precedence over that from RA for DNS queries. On the other hand, for DNS options announced by RA, if some RAs use the Secure Neighbor Discovery (SEND) protocol [RFC3971] for RA security, they MUST be preferred over those that do not use SEND. Refer to Section 7 for the detailed discussion on SEND for RA DNS options.
RDNSSおよびDNSSLのDNSオプションをRAやDHCPなどの複数のソースから取得できる場合、IPv6ホストはすべてのソースからDNSオプションを維持する必要があります。発見メカニズムに明示的に指定されていない限り、保持するアドレスとドメイン名の正確な数は、ローカルポリシーと実装の選択の問題です。ただし、少なくとも2つの異なるソースから少なくとも3つのRDNSアドレス（またはDNSSLドメイン名）を保存する機能が推奨されます。ルーター広告とDHCPからのDNSオプションは、DNSリポジトリとリゾルバーリポジトリに保存され、DHCPからの情報が最初に表示され、したがって優先されるようにする必要があります。したがって、DHCPからのDNS情報は、DNSクエリのRAのDNS情報よりも優先されます。一方、RAによって発表されたDNSオプションの場合、一部のRAがRAセキュリティに安全な近隣発見（送信）プロトコル[RFC3971]を使用している場合、送信を使用しないものよりも優先する必要があります。RA DNSオプションの送信に関する詳細な説明については、セクション7を参照してください。
There are two warnings for DNS options configuration: (i) warning for multiple sources of DNS options and (ii) warning for multiple network interfaces. First, in the case of multiple sources for DNS options (e.g., RA and DHCP), an IPv6 host can configure its IP addresses from these sources. In this case, it is not possible to control how the host uses DNS information and what source addresses it uses to send DNS queries. As a result, configurations where different information is provided by different sources may lead to problems. Therefore, the network administrator needs to configure DNS options in multiple sources in order to prevent such problems from happening.
DNSオプションの構成には2つの警告があります。（i）DNSオプションの複数のソースに対する警告と（ii）複数のネットワークインターフェイスの警告。まず、DNSオプションの複数のソース（RAやDHCPなど）の場合、IPv6ホストはこれらのソースからIPアドレスを構成できます。この場合、ホストがDNS情報を使用する方法と、DNSクエリを送信するために使用するソースアドレスを制御することはできません。その結果、さまざまなソースによって異なる情報が提供される構成が問題につながる可能性があります。したがって、ネットワーク管理者は、そのような問題が発生するのを防ぐために、複数のソースでDNSオプションを構成する必要があります。
Second, if different DNS information is provided on different network interfaces, this can lead to inconsistent behavior. The IETF is working on solving this problem for both DNS and other information obtained by multiple interfaces [MIF-PROBLEM][MIF-PRACTICE].
第二に、異なるDNS情報が異なるネットワークインターフェイスで提供されている場合、これは一貫性のない動作につながる可能性があります。IETFは、DNSと複数のインターフェイス[MIF-Problem] [MIF-Practice]で得られた他の情報の両方についてこの問題の解決に取り組んでいます。
Note: This non-normative section gives some hints for implementing the processing of the RDNSS and DNSSL options in an IPv6 host.
注：この非規範的なセクションでは、IPv6ホストにRDNSSおよびDNSSLオプションの処理を実装するためのヒントを提供します。
For the configuration and management of DNS information, the advertised DNS configuration information can be stored and managed in both the DNS Repository and the Resolver Repository.
DNS情報の構成と管理のために、広告されたDNS構成情報は、DNSリポジトリとResolverリポジトリの両方に保存および管理できます。
In environments where the DNS information is stored in user space and ND runs in the kernel, it is necessary to synchronize the DNS information (i.e., RDNSS addresses and DNS search domain names) 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 DNS 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 Lifetimes of RDNSS addresses and DNS search domain names all the time. Whenever there is an expired entry in the DNS Repository, the daemon can delete the corresponding entry from the Resolver Repository.
DNS情報がユーザースペースに保存され、カーネルで動作する環境では、カーネルスペースのDNS情報（つまり、RDNSSアドレスとDNS検索ドメイン名）を同期する必要があります。同期の場合、カーネルでNDが機能する実装は、カーネルからリゾルバーリポジトリにDNS情報を更新するための書き込み操作を提供する必要があります。簡単なアプローチの1つは、RDNSアドレスの寿命とDNS検索ドメイン名の監視を常に監視し続けるデーモン（または定義された間隔で呼ばれるプログラム）を持つことです。DNSリポジトリに期限切れのエントリがあるときはいつでも、デーモンはResolverリポジトリから対応するエントリを削除できます。
For DNS repository management, the kernel or user-space process (depending on where RAs are processed) should maintain two data structures: (i) DNS Server List that keeps the list of RDNSS addresses and (ii) DNS Search List that keeps the list of DNS search domain names. Each entry in these two lists consists of a pair of an RDNSS address (or DNSSL domain name) and Expiration-time as follows: o RDNSS address for DNS Server List: IPv6 address of the Recursive DNS Server, which is available for recursive DNS resolution service in the network advertising the RDNSS option.
DNSリポジトリ管理の場合、カーネルまたはユーザー空間プロセス（RAが処理される場所に依存）は、2つのデータ構造を維持する必要があります。（i）RDNSSアドレスのリストを保持するDNSサーバーリストと（ii）リストを保持するDNS検索リストDNS検索ドメイン名の。これら2つのリストの各エントリは、RDNSSアドレスのペア（またはDNSSLドメイン名）と有効期限のペアで構成されています。DNSサーバーリストのO RDNSSアドレス：再帰DNSサーバーのIPv6アドレス。RDNSSオプションを宣伝するネットワークでのサービス。
o DNSSL domain name for DNS Search List: DNS suffix domain names, which are used to perform DNS query searches for short, unqualified domain names in the network advertising the DNSSL option.
o DNS検索リストのDNSSLドメイン名：DNSサフィックスドメイン名。これは、DNSSLオプションを宣伝するネットワークで短くて資格のないドメイン名のDNSクエリ検索を実行するために使用されます。
o Expiration-time for DNS Server List or DNS Search List: The time when this entry becomes invalid. Expiration-time is set to the value of the Lifetime field of the RDNSS option or DNSSL option plus the current system time. Whenever a new RDNSS option with the same address (or DNSSL option with the same domain name) is received on the same interface as a previous RDNSS option (or DNSSL option), 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 DNSサーバーリストまたはDNS検索リストの有効期間：このエントリが無効になる時間。有効期限は、RDNSSオプションまたはDNSSLオプションと現在のシステム時間の生涯フィールドの値に設定されます。同じアドレス（または同じドメイン名を持つDNSSLオプション）を持つ新しいRDNSSオプションが以前のRDNSSオプション（またはDNSSLオプション）と同じインターフェイスで受信される場合、このフィールドは新しい有効期間を持つように更新されます。有効期限が現在のシステム時間よりも短くなると、このエントリは期限切れと見なされます。
When an IPv6 host receives the information of multiple RDNSS addresses within a network (e.g., campus network and company network) 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 consists of (i) the processing of RDNSS option(s) included in an RA message and (ii) the handling of expired RDNSSes. The processing of RDNSS option(s) is as follows:
IPv6ホストが、RDNSSオプションを使用したRAメッセージを介してネットワーク内の複数のRDNSSアドレス（キャンパスネットワークおよび会社ネットワークなど）の情報を受信すると、RDNSアドレスをDNSサーバーリストとDNSサーバーリストの両方に保存します。リゾルバーリポジトリ。RDNSSの処理は、（i）RAメッセージに含まれるRDNSSオプションの処理と（ii）期限切れのRDNSSEの処理で構成されています。RDNSSオプションの処理は次のとおりです。
Step (a): Receive and parse the RDNSS option(s). For the RDNSS addresses in each RDNSS option, perform Steps (b) through (d).
ステップ（a）：RDNSSオプションを受信して解析します。各RDNSSオプションのRDNSSアドレスの場合、手順（b）から（d）を実行します。
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 termination of the RDNSS or a renumbering situation. That is, the RDNSS can resign from its DNS service because the machine running the RDNSS is out of service intentionally or unintentionally. Also, under the renumbering situation, the RDNSS's IPv6 address will be changed, so the previous RDNSS address should not be used any more. The processing of this RDNSS address is finished here. Otherwise, go to Step (c).
ステップ（b）：各RDNSSアドレスについて、以下を確認してください。RDNSSアドレスがDNSサーバーリストに既に存在し、RDNSSオプションのライフタイムフィールドがゼロに設定されている場合、DNSサーバーリストとリゾルバの両方から対応するRDNSエントリを削除しますリポジトリRDNSSアドレスがネットワーク管理の特定の理由でこれ以上使用されないようにするため、たとえばRDNSSの終了や変更状況。つまり、RDNSSを実行しているマシンが意図的または意図せずにサービスを停止しているため、RDNSSはDNSサービスを辞任する可能性があります。また、変更状況の下では、RDNSSのIPv6アドレスが変更されるため、以前の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 third bullet of Section 6.1. Otherwise, go to Step (d).
ステップ（c）：各RDNSアドレスについて、DNSサーバーリストに既に存在する場合は、セクション6.1の3番目の弾丸で指定された手順に従って有効期限フィールドの値を更新するだけです。それ以外の場合は、ステップ（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 (that is, has more RDNSSes than the sufficient number discussed in Section 5.3.1), 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. For the ordering of RDNSS addresses in an RDNSS option, position the first RDNSS address in the RDNSS option as the first one in the Resolver Repository, the second RDNSS address in the option as the second one in the repository, and so on. This ordering allows the RDNSS addresses in the RDNSS option to be preferred according to their order in the RDNSS option for the DNS name resolution. The processing of these RDNSS addresses is finished here.
ステップ（d）：各RDNSアドレスについて、DNSサーバーリストに存在しない場合は、RDNSSアドレスと寿命をDNSサーバーリストに登録し、RDNSSアドレスをResolverリポジトリの前に挿入します。DNSサーバーリストのデータ構造がRDNSSエントリでいっぱいになっている場合（つまり、セクション5.3.1で説明した十分な数値よりもRDNSSEが多い）、DNSサーバーから削除エントリを最短の有効期間でリストに削除します（つまり、最初に期限切れになるエントリ）。対応するRDNSSアドレスも、Resolverリポジトリから削除されます。RDNSSアドレスのRDNSSオプションの順序付けの場合、RDNSSアドレスをRDNSSアドレスの最初のオプションにリゾルバーリポジトリの最初のオプション、オプションの2番目のRDNSアドレスはリポジトリの2番目のRDNSSアドレスとして配置します。この注文により、RDNSSオプションのRDNSSアドレスは、DNS名解決のRDNSSオプションの注文に従って優先されることができます。これらのRDNSアドレスの処理はここで終了します。
The handling of expired RDNSSes is as follows: Whenever an entry expires in the DNS Server List, the expired entry is deleted from the DNS Server List, and also the RDNSS address corresponding to the entry is deleted from the Resolver Repository.
期限切れのRDNSSEの取り扱いは次のとおりです。DNSサーバーリストでエントリが期限切れになると、期限切れのエントリがDNSサーバーリストから削除され、エントリに対応するRDNSSアドレスはResolver Repositoryから削除されます。
When an IPv6 host receives the information of multiple DNSSL domain names within a network (e.g., campus network and company network) through an RA message with DNSSL option(s), it stores the DNSSL domain names (in order) into both the DNS Search List and the Resolver Repository. The processing of the DNSSL consists of (i) the processing of DNSSL option(s) included in an RA message and (ii) the handling of expired DNSSLs. The processing of DNSSL option(s) is as follows:
IPv6ホストが、DNSSLオプションを使用したRAメッセージを介してネットワーク内の複数のDNSSLドメイン名（キャンパスネットワークおよび会社ネットワークなど）の情報を受信すると、DNSSLドメイン名を両方のDNS検索に保存します。リストとリゾルバーリポジトリ。DNSSLの処理は、（i）RAメッセージに含まれるDNSSLオプションの処理と（ii）期限切れのDNSSLの処理で構成されています。DNSSLオプションの処理は次のとおりです。
Step (a): Receive and parse the DNSSL option(s). For the DNSSL domain names in each DNSSL option, perform Steps (b) through (d).
ステップ（a）：DNSSLオプションを受信して解析します。各DNSSLオプションのDNSSLドメイン名の場合、手順（b）から（d）を実行します。
Step (b): For each DNSSL domain name, check the following: If the DNSSL domain name already exists in the DNS Search List and the DNSSL option's Lifetime field is set to zero, delete the corresponding DNSSL entry from both the DNS Search List and the Resolver Repository in order to prevent the DNSSL domain name from being used any more for certain reasons in network management, e.g., the termination of the RDNSS or a renaming situation. That is, the RDNSS can resign from its DNS service because the machine running the RDNSS is out of service intentionally or unintentionally. Also, under the renaming situation, the DNSSL domain names will be changed, so the previous domain names should not be used any more. The processing of this DNSSL domain name is finished here. Otherwise, go to Step (c).
ステップ（b）：各DNSSLドメイン名について、以下を確認します。DNSSLドメイン名がDNS検索リストに既に存在し、DNSSLオプションのライフタイムフィールドがゼロに設定されている場合、DNS検索リストと両方のDNSSLエントリを削除します。DNSSLドメイン名がネットワーク管理の特定の理由でこれ以上使用されないようにするためのリゾルバーリポジトリ（たとえば、RDNSの終了や改名の状況）。つまり、RDNSSを実行しているマシンが意図的または意図せずにサービスを停止しているため、RDNSSはDNSサービスを辞任する可能性があります。また、改名の状況では、DNSSLドメイン名が変更されるため、以前のドメイン名をもう使用しないでください。このDNSSLドメイン名の処理はここで終了します。それ以外の場合は、ステップ（c）に移動します。
Step (c): For each DNSSL domain name, 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 third bullet of Section 6.1. Otherwise, go to Step (d).
ステップ（c）：各DNSSLドメイン名について、DNSサーバーリストに既に存在する場合は、セクション6.1の3番目の弾丸で指定された手順に従って、有効期限フィールドの値を更新するだけです。それ以外の場合は、ステップ（d）に移動します。
Step (d): For each DNSSL domain name, if it does not exist in the DNS Search List, register the DNSSL domain name and Lifetime with the DNS Search List and then insert the DNSSL domain name in front of the Resolver Repository. In the case where the data structure for the DNS Search List is full of DNSSL domain name entries (that is, has more DNSSL domain names than the sufficient number discussed in Section 5.3.1), delete from the DNS Server List the entry with the shortest Expiration-time (i.e., the entry that will expire first). The corresponding DNSSL domain name is also deleted from the Resolver Repository. For the ordering of DNSSL domain names in a DNSSL option, position the first DNSSL domain name in the DNSSL option as the first one in the Resolver Repository, the second DNSSL domain name in the option as the second one in the repository, and so on. This ordering allows the DNSSL domain names in the DNSSL option to be preferred according to their order in the DNSSL option for the DNS domain name used by the DNS query. The processing of these DNSSL domain name is finished here.
ステップ（D）：各DNSSLドメイン名について、DNS検索リストに存在しない場合は、DNSSLドメイン名とLifetimeをDNS検索リストに登録し、Resolverリポジトリの前にDNSSLドメイン名を挿入します。DNS検索リストのデータ構造がDNSSLドメイン名エントリでいっぱいである場合（つまり、セクション5.3.1で説明した十分な数値よりもDNSSLドメイン名が多くあります）、DNSサーバーから削除エントリを削除します。最短の有効期間（つまり、最初に期限切れになるエントリ）。対応するDNSSLドメイン名もResolverリポジトリから削除されます。DNSSLオプションでのDNSSLドメイン名の順序付けの場合、DNSSLドメイン名をDNSSLオプションの最初のDNSSLドメイン名をリゾルバーリポジトリの最初のオプション、2番目のDNSSLドメイン名をリポジトリの2番目のDNSSLドメイン名などに配置します。。この順序付けにより、DNSSLオプションのDNSSLドメイン名は、DNSクエリで使用されるDNSドメイン名のDNSSLオプションの注文に従って優先されることができます。これらのDNSSLドメイン名の処理はここで終了します。
The handling of expired DNSSLs is as follows: Whenever an entry expires in the DNS Search List, the expired entry is deleted from the DNS Search List, and also the DNSSL domain name corresponding to the entry is deleted from the Resolver Repository.
期限切れのDNSSLSの取り扱いは次のとおりです。DNS検索リストでエントリが期限切れになると、期限切れのエントリがDNS検索リストから削除され、エントリに対応するDNSSLドメイン名はResolverリポジトリから削除されます。
In this section, we analyze security threats related to DNS options and then suggest recommendations to cope with such security threats.
このセクションでは、DNSオプションに関連するセキュリティの脅威を分析し、そのようなセキュリティの脅威に対処するための推奨事項を提案します。
For the RDNSS option, an attacker could send an RA with a fraudulent RDNSS address, misleading IPv6 hosts into contacting an unintended DNS server for DNS name resolution. Also, for the DNSSL option, an attacker can let IPv6 hosts resolve a host name without a DNS suffix into an unintended host's IP address with a fraudulent DNS Search List.
RDNSSオプションの場合、攻撃者は不正なRDNSSアドレスを持つRAを送信し、IPv6ホストを誤解させ、DNS名解決のために意図しないDNSサーバーに連絡します。また、DNSSLオプションの場合、攻撃者はIPv6ホストがDNSサフィックスなしでホスト名を解決して、不正なDNS検索リストを使用して意図しないホストのIPアドレスに解決できます。
These attacks are similar to Neighbor Discovery attacks that use Redirect or Neighbor Advertisement messages to redirect traffic to individual addresses of malicious parties. That is, as a rogue router, a malicious node on a LAN can promiscuously receive packets for any router's Media Access Control (MAC) address and send packets with the router's MAC address as the source MAC address in the Layer 2 (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. Thus, the attacks related to RDNSS and DNSSL are similar to both Neighbor Discovery attacks and attacks against unauthenticated DHCP, as both can be used for both "wholesale" traffic redirection and more specific attacks.
これらの攻撃は、リダイレクトまたはネイバーの広告メッセージを使用して、悪意のある当事者の個々の住所にトラフィックをリダイレクトする近隣発見攻撃に似ています。つまり、不正なルーターとして、LAN上の悪意のあるノードは、レイヤー2（L2）ヘッダーのソースMACアドレスとしてルーターのMACアドレスを持つルーターのメディアアクセスコントロール（MAC）アドレスのパケットを無差別に受信できます。その結果、L2スイッチは、ルーターにアドレス指定されたパケットを悪意のあるノードに送信します。また、この攻撃は、ホストに他のどこかにトラフィックを送信するように指示するリダイレクトを送信する可能性があります。悪意のあるノードは、未承諾のRAまたはNeighbor Advertisement（NA）返信を送信したり、RSまたはNeighbor Solicitation（NS）リクエストに応答したりできます。どちらも、「卸売」トラフィックリダイレクトとより具体的な攻撃の両方に使用できます。
However, the security of these RA options for DNS configuration does not affect ND protocol security [RFC4861]. This is because learning DNS information via the RA options cannot be worse than learning bad router information via the RA options. Therefore, 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.
ただし、DNS構成のこれらのRAオプションのセキュリティは、NDプロトコルセキュリティ[RFC4861]に影響しません。これは、RAオプションを介してDNS情報を学習することは、RAオプションを介して悪いルーター情報を学習することよりも悪くないためです。したがって、NDの脆弱性は悪くなく、LANに接続されたノードがNDとは独立して行うことができる攻撃のサブセットです。
The Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as a security mechanism for ND. It is RECOMMENDED that ND use SEND to allow all the ND options including the RDNSS and DNSSL options to be automatically included in the signatures. Through SEND, the transport for the RA options is integrity protected; that is, SEND can prevent the spoofing of these DNS options with signatures. Also, SEND enables an IPv6 host to verify that the sender of an RA is actually a router authorized to act as a router. However, since any valid SEND router can still insert RDNSS and DNSSL options, the current SEND cannot verify which one is or is not authorized to send the options. Thus, this verification of the authorized routers for ND options will be required. [CSI-SEND-CERT] specifies the usage of extended key for the certificate deployed in SEND. This document defines the roles of routers (i.e., routers acting as proxy and address owner) and explains the authorization of the roles. The mechanism in this document can be extended to verify which routers are authorized to insert RDNSS and DNSSL options.
Secure Neighbor Discovery（SEND）プロトコル[RFC3971]は、NDのセキュリティメカニズムとして使用されます。ND使用SEND SENDを使用して、RDNSSやDNSSLオプションを含むすべてのNDオプションを署名に自動的に含めることをお勧めします。送信を通じて、RAオプションの輸送は整合性保護されています。つまり、sendは、これらのDNSオプションの署名を使用してスプーフィングを防ぐことができます。また、IPv6ホストを有効にして、RAの送信者が実際にルーターとして機能することを許可されたルーターであることを確認できます。ただし、有効な送信ルーターはまだRDNSとDNSSLオプションを挿入できるため、現在の送信では、オプションの送信が許可されていないかを確認できません。したがって、NDオプション用の承認されたルーターのこの検証が必要です。[CSI-SEND-CERT]送信に展開された証明書の拡張キーの使用法を指定します。このドキュメントは、ルーターの役割（つまり、プロキシおよびアドレス所有者として機能するルーター）の役割を定義し、役割の承認を説明します。このドキュメントのメカニズムを拡張して、RDNSとDNSSLオプションを挿入することが許可されているルーターを確認できます。
It is common for network devices such as switches to include mechanisms to block unauthorized ports from running a DHCPv6 server to provide protection from rogue DHCP servers. That means that an attacker on other ports cannot insert bogus DNS servers using DHCPv6. The corresponding technique for network devices is RECOMMENDED to block rogue Router Advertisement messages including the RDNSS and DNSSL options from unauthorized nodes.
スイッチなどのネットワークデバイスは、不正なポートがDHCPV6サーバーの実行をブロックしてRogue DHCPサーバーからの保護を提供するメカニズムを含めることが一般的です。つまり、他のポートへの攻撃者は、DHCPV6を使用して偽のDNSサーバーを挿入できません。ネットワークデバイスの対応する手法は、不正なノードからのRDNSSやDNSSLオプションを含む不正なルーター広告メッセージをブロックするために推奨されます。
An attacker may provide a bogus DNS Search List option in order to cause the victim to send DNS queries to a specific DNS server when the victim queries non-FQDNs (fully qualified domain names). For this attack, the DNS resolver in IPv6 hosts can mitigate the vulnerability with the recommendations mentioned in [RFC1535], [RFC1536], and [RFC3646].
攻撃者は、被害者が非FQDNS（完全に適格なドメイン名）をクエリしたときに、被害者が特定のDNSサーバーにDNSクエリを送信させるために、偽のDNS検索リストオプションを提供する場合があります。この攻撃では、IPv6ホストのDNSリゾルバーは、[RFC1535]、[RFC1536]、および[RFC3646]に記載されている推奨事項で脆弱性を軽減できます。
The RDNSS option defined in this document uses the IPv6 Neighbor Discovery Option type defined in RFC 5006 [RFC5006], which was assigned by the IANA as follows:
このドキュメントで定義されているRDNSSオプションでは、RFC 5006 [RFC5006]で定義されたIPv6 Neighbor Discoveryオプションタイプを使用します。これは、次のようにIANAによって割り当てられました。
Option Name Type Recursive DNS Server Option 25
オプション名のタイプ再帰DNSサーバーオプション25
The IANA has assigned a new IPv6 Neighbor Discovery Option type for the DNSSL option defined in this document:
IANAは、このドキュメントで定義されているDNSSLオプションに新しいIPv6 Neighter Discoveryオプションタイプを割り当てました。
Option Name Type DNS Search List Option 31
オプション名のタイプDNS検索リストオプション31
These options have been registered in the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry (http://www.iana.org).
これらのオプションは、「インターネットコントロールメッセージプロトコルバージョン6（ICMPV6）パラメーター」レジストリ（http://www.iana.org）に登録されています。
This document has greatly benefited from inputs by Robert Hinden, Pekka Savola, Iljitsch van Beijnum, Brian Haberman, Tim Chown, Erik Nordmark, Dan Wing, Jari Arkko, Ben Campbell, Vincent Roca, and Tony Cheneau. The authors sincerely appreciate their contributions.
この文書は、ロバート・ヒンデン、ペッカ・サヴォラ、イルジッチ・ヴァン・ベイナム、ブライアン・ハーバーマン、ティム・チャウン、エリック・ノードマーク、ダン・ウィング、ジャリ・アークコ、ベン・キャンベル、ヴィンセント・ロカ、トニー・チェノーによる意見から大きな恩恵を受けています。著者は、彼らの貢献に心から感謝しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] DROMS、R。、「IPv6用のステートレス動的ホスト構成プロトコル（DHCP）サービス」、RFC 3736、2004年4月。
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646] DROMS、R。、「IPv6（DHCPV6）の動的ホスト構成プロトコルのDNS構成オプション」、RFC 3646、2003年12月。
[RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Option for DNS Configuration", RFC 5006, September 2007.
[RFC5006] Jeong、J.、Park、S.、Beloeil、L。、およびS. Madanapalli、「DNS構成のIPv6ルーター広告オプション」、RFC 5006、2007年9月。
[RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server Information Approaches", RFC 4339, February 2006.
[RFC4339] Jeong、J。、「DNSサーバー情報アプローチのIPv6ホスト構成」、RFC 4339、2006年2月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, October 2008.
[RFC5358] Damas、J。およびF. Neves、「リフレクター攻撃での再帰的な名前の使用の防止」、BCP 140、RFC 5358、2008年10月。
[RFC2827] 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.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, October 1993.
[RFC1535] Gavron、E。、「セキュリティ問題と広く展開されたDNSソフトウェアによる修正の提案」、RFC 1535、1993年10月。
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller, "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, October 1993.
[RFC1536] Kumar、A.、Postel、J.、Neuman、C.、Danzig、P。、およびS. Miller、「一般的なDNS実装エラーと提案された修正」、RFC 1536、1993年10月。
[MIF-PROBLEM] Blanchet, M. and P. Seite, "Multiple Interfaces Problem Statement", Work in Progress, August 2010.
[Mif-Problem] Blanchet、M。およびP. Seite、「複数のインターフェイス問題ステートメント」、2010年8月の作業。
[MIF-PRACTICE] Wasserman, M. and P. Seite, "Current Practices for Multiple Interface Hosts", Work in Progress, August 2010.
[MIF-Practice] Wasserman、M。およびP. Seite、「複数のインターフェイスホストの現在の慣行」、2010年8月の作業。
[CSI-SEND-CERT] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate profile and certificate management for SEND", Work in Progress, October 2010.
[CSI-SEND-CERT] Gagliano、R.、Krishnan、S。、およびA. Kukec、「SEMTERINCE PROFEMERTおよび証明書管理」、2010年10月の作業。
The following changes were made from RFC 5006 "IPv6 Router Advertisement Option for DNS Configuration":
以下の変更は、DNS構成のRFC 5006「IPv6ルーター広告オプション」から行われました。
o Added the DNS Search List (DNSSL) option to support the advertisement of DNS suffixes used in the DNS search along with RDNSS option in RFC 5006.
o DNS検索リスト（DNSSL）オプションを追加して、RFC 5006のRDNSSオプションとともにDNS検索で使用されるDNSサフィックスの広告をサポートしました。
o Clarified the coexistence of RA options and DHCP options for DNS configuration.
o DNS構成のRAオプションとDHCPオプションの共存を明確にしました。
o Modified the procedure in IPv6 host:
o IPv6ホストの手順を変更しました：
* Clarified the procedure for DNS options in an IPv6 host.
* IPv6ホストのDNSオプションの手順を明確にしました。
* Specified a sufficient number of RDNSS addresses or DNS search domain names as three.
* 十分な数のRDNSアドレスまたはDNS検索ドメイン名を3つとして指定しました。
* Specified a way to deal with DNS options from multiple sources, such as RA and DHCP.
* RAやDHCPなどの複数のソースからDNSオプションを処理する方法を指定しました。
o Modified the implementation considerations for DNSSL option handling.
o DNSSLオプション処理の実装に関する考慮事項を変更しました。
o Modified the security considerations to consider more attack scenarios and the corresponding possible solutions.
o より多くの攻撃シナリオと対応する可能なソリューションを検討するために、セキュリティ上の考慮事項を変更しました。
o Modified the IANA considerations to require another IPv6 Neighbor Discovery Option type for the DNSSL option.
o DNSSLオプションには、別のIPv6 Neighbor Discoveryオプションタイプが必要になるようにIANAの考慮事項を変更しました。
Authors' Addresses
著者のアドレス
Jaehoon Paul Jeong Brocade Communications Systems/ETRI 6000 Nathan Ln N Plymouth, MN 55442 USA
Jaehoon Paul Jeong Brocade Communications Systems/Etri 6000 Nathan Ln N Plymouth、MN 55442 USA
Phone: +1 763 268 7173
Fax: +1 763 268 6800
EMail: pjeong@brocade.com
URI: http://www.cs.umn.edu/~jjeong/
Soohong Daniel Park Digital Media & Communications R&D Center SAMSUNG Electronics 416 Maetan-3dong, Yeongtong-Gu Suwon, Gyeonggi-Do 443-742 Korea
スーホンダニエルパークデジタルメディア＆コミュニケーションR＆Dセンターサムスンエレクトロニクス416 Maetan-3dong、Yeongtong-Gu Suwon、Gyeonggi-Do 443-742 Korea
Phone: +82 31 279 8876
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 2 40 44 97 40
EMail: luc.beloeil@orange-ftgroup.com
Syam Madanapalli iRam Technologies #H304, Shriram Samruddhi, Thubarahalli Bangalore - 560066 India
Syam Madanapalli IRAM Technologies＃H304、Shriram Samruddhi、Thubarahalli Bangalore -560066 India
EMail: smadanapalli@gmail.com