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
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路由器播发选项，以允许IPv6路由器向IPv6主机播发DNS递归服务器地址。
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
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的邻居发现（ND）和IPv6无状态地址自动配置提供了使用一个或多个IPv6地址、默认路由器和一些其他参数配置固定或移动节点的方法[2][3]。为了支持访问由DNS名称标识的Internet中的附加服务，例如web服务器，还需要至少一个递归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.
游牧主机（如笔记本电脑）每次连接到不同的无线局域网（WLAN）时，都不可能手动配置DNS解析器，如IEEE 802.11 a/b/g[12]-[15]。通常，DHCP[6]-[8]用于定位此类解析器。本文档提供了另一种实验性机制，该机制使用新的IPv6路由器公告（RA）选项，允许IPv6路由器向IPv6主机公告DNS递归服务器地址。
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].
在通过IPv6无状态地址自动配置自动配置IPv6主机地址的网络中，以及在获取服务器地址和与服务器通信的延迟非常关键的网络中，基于RA的DNS配置是一种有用的可选选择。基于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.
[9]中讨论了基于RA的方法的优缺点以及其他方法，如DHCP和众所周知的选播地址方法。
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消息中使用O（其他有状态配置）标志[2]。如果RA消息中不包括RDNS选项，则IPv6主机可以通过DHCPv6[6]-[8]执行DNS配置，而不管是否设置了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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。
This document uses the terminology described in [2] and [3]. In addition, four new terms are defined below:
本文件使用[2]和[3]中描述的术语。此外，以下定义了四个新术语：
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服务器（RDNS）：提供递归DNS解析服务的服务器，用于将域名转换为[4]和[5]中定义的IP地址。
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 解析程序存储库：具有RDNS地址的配置存储库，主机上的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).
本文档定义了一个名为RDNSOption的新ND选项，该选项包含递归DNS服务器的地址。使用现有的ND传输机制（即广告和邀约）。这与主机了解路由器和前缀的方式相同。IPv6主机可以通过路由器定期发送或路由器请求（RS）请求的RA消息配置一个或多个RDNSE的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.
通过RDNS选项以及基于ND协议（[2]和[3]）的前缀信息选项，IPv6主机可以同时执行其IPv6地址和RDNS的网络配置，而无需对RDNS信息进行单独的消息交换。RDNS的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
这种方法要求在发送广告的路由器中配置RDNS信息。路由器中RDNS地址的配置可以通过手动配置完成。RDNSS信息的自动配置或重新分发是必要的
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.
通过在路由器[6]-[8]上运行DHCPv6客户机可以实现。路由器中RDNS地址的自动配置超出了本文档的范围。
The IPv6 DNS configuration mechanism in this document needs a new ND option in Neighbor Discovery: the Recursive DNS Server (RDNSS) option.
本文档中的IPv6 DNS配置机制需要邻居发现中的新ND选项：递归DNS服务器（RDNS）选项。
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服务器的一个或多个IPv6地址。所有地址共享相同的生存期值。如果希望具有不同的生存期值，则可以使用多个RDNS选项。图1显示了RDNS选项的格式。
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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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分配的RDNS选项类型的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个八位字节为单位。如果选项中包含一个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位无符号整数。此RDNS地址可用于名称解析的最长时间，以秒为单位（相对于发送数据包的时间）。主机可以发送路由器请求，以确保在间隔到期之前RDNS信息是新的。为了向固定主机提供稳定的DNS服务，并允许移动主机更喜欢本地RDNSE而不是远程RDNSE，生存期的值应至少与RFC 4861中的最大RA间隔（MaxRtrAdvInterval）一样长，最多为MaxRtrAdvInterval的两倍；生存期的范围应如下所示：MaxRtrAdvInterval<=生存期<=2*MaxRtrAdvInterval。所有一位的值（0xFFFFFF）表示无穷大。值为零表示不能再使用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服务器的一个或多个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接收RDNS选项时，它会检查该选项是否有效。
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服务器列表和冲突解决程序存储库中。当主机收集了足够数量的RDNS地址时，可以忽略RDNS选项中的其他RDNS地址和/或RA中的其他RDNS选项。
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主机中实现RDNS选项处理的一些提示。
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.
对于RDNS信息的配置和管理，可以在DNS服务器列表和解析程序存储库中存储和管理播发的RDNS地址。
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.
在RDNS信息存储在用户空间且ND在内核中运行的环境中，需要同步内核空间中RDNS地址的DNS服务器列表和用户空间中的解析器存储库。对于同步，ND在内核中工作的实现应该提供一个写操作，用于将RDNS信息从内核更新到解析器存储库。一种简单的方法是使用一个守护进程（或一个按定义的时间间隔调用的程序），该守护进程始终监视RDNS地址的生存期。每当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的位置）应该维护一个称为DNS服务器列表的数据结构，它保存RDNS地址列表。DNS服务器列表中的每个条目由RDNS地址和过期时间组成，如下所示：
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地址：递归DNS服务器的IPv6地址，可用于发布RDNSS选项的网络中的递归DNS解析服务；这种网络在本文件中称为站点。
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 过期时间：此条目变为无效的时间。过期时间设置为RDNS选项的生存期字段值加上当前系统时间。每当收到具有相同地址的新RDNS选项时，此字段将更新为具有新的过期时间。当过期时间小于当前系统时间时，此条目被视为过期。
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]).
注意：只有在RA路由器生存期和RDNSS选项生存期均未过期时，才能使用RDNSS地址。原因是RDNS当前可能无法访问，或者可能无法向主机的当前地址提供服务（例如，由于网络入口过滤[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消息中包含的RDNS选项的处理如下：
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选项。对于每个RDNS选项中的RDNS地址，执行步骤（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）：对于每个RDNS地址，检查以下内容：如果DNS服务器列表中已经存在RDNS地址，并且RDNS选项的生存期字段设置为零，从DNS服务器列表和解析程序存储库中删除相应的RDNS条目，以防止由于网络管理中的某些原因（例如RDNS故障或重新编号情况）而再次使用RDNS地址。此RDNS地址的处理在此完成。否则，转至步骤（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节第二个项目符号中指定的程序更新过期时间字段的值。否则，转至步骤（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服务器列表中，则向DNS服务器列表注册RDNS地址和生存期，然后将RDNS地址插入解析程序存储库前面。如果DNS服务器列表的数据结构中满是RDNS条目，请从DNS服务器列表中删除过期时间最短的条目（即首先过期的条目）。相应的RDNS地址也将从冲突解决程序存储库中删除。按照RDNSS选项中的顺序，将新添加的RDNSS地址放置在解析程序存储库前面，以便新的RDNSS地址可以根据其在DNS名称解析的RDNSS选项中的顺序优先使用。这些RDNS地址的处理在此完成。请注意，在子网中有多个路由器宣传RDNS选项的情况下，首选最近宣布的RDNS。
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服务器列表中删除每个过期条目，并从解析器存储库中删除与该条目对应的RDNS地址。
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.
RDNS的RA选项的安全性可能比ND协议安全性差[2]。但是，此RA选项中的任何新漏洞尚不清楚。在这种情况下，可以声称ND的漏洞并不严重，而是连接到LAN的任何节点都可以独立于ND进行的攻击的子集。局域网上的恶意节点可以任意接收任何路由器MAC地址的数据包，并在L2报头中发送以路由器MAC地址作为源MAC地址的数据包。因此，L2交换机将发送到路由器的数据包发送到恶意节点。此外，此攻击还可以发送重定向，通知主机将其流量发送到其他地方。恶意节点可以发送未经请求的RA或邻居公告（NA）回复、应答RS或邻居请求（NS）请求等。此外，攻击者还可以配置主机发送带有欺诈性RDNS地址的RA，这大概比成为一个流氓路由器并必须处理子网的所有流量更容易受到攻击。为了避免这个问题，有必要在路由器和客户端管理上禁用RA RDNSS选项。所有这些都可以独立于ND的实现来完成。因此，可以说RDNS的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的安全机制，则所有ND选项（包括RDNSS选项）都会自动包含在签名中[11]，因此RDNSS传输受到完整性保护。但是，由于任何有效的发送节点仍然可以插入RDNS选项，因此发送无法验证谁有权或没有权发送选项。
The IANA has assigned a new IPv6 Neighbor Discovery Option type for the RDNSS option defined in this document.
IANA已为本文档中定义的RDNS选项分配了新的IPv6邻居发现选项类型。
Option Name Type RDNSS option 25
选项名称类型RDNSOPTION 25
The IANA registry for these options is:
这些选项的IANA注册表为：
http://www.iana.org/assignments/icmpv6-parameters
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.
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.translate error, please retry
[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 48612007年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无状态地址自动配置”，RFC 48622007年9月。
[4] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987.
[4] Mockapetris，P.，“域名-概念和设施”，RFC1034，1987年11月。
[5] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987.
[5] Mockapetris，P.，“域名-实现和规范”，RFC10351987年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 37752004年6月。
[11] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[11] Arkko，J.，编辑，“安全邻居发现（SEND）”，RFC 39712005年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部分：无线局域网介质访问控制（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.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部分：无线局域网介质访问控制（MAC）和物理层（PHY）规范：在2.4 GHz频段进一步提高数据速率扩展”，2003年4月。
[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
Jaehoon Paul Jeong（编辑）ETRIE /明尼苏达大学计算机科学与工程系117明尼阿波利斯MN 55455街宜人街，美国
Phone: +1 651 587 7774
Fax: +1 612 625 0572
EMail: jjeong@cs.umn.edu
URI: http://www.cs.umn.edu/~jjeong/
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
Soohong Daniel Park移动融合实验室三星电子416 Maetan-3dong，永通谷水原，韩国京畿道443-742
Phone: +82 31 200 4508
EMail: soohong.park@samsung.com
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法国电信研发部，法国邮政街42号BP 6243 14066卡恩塞德克斯4号
Phone: +33 02 3175 9391
EMail: luc.beloeil@orange-ftgroup.com
Phone: +33 02 3175 9391
EMail: luc.beloeil@orange-ftgroup.com
Syam Madanapalli Ordyn Technologies 1st Floor, Creator Building, ITPL Bangalore - 560066 India
印度班加罗尔ITPL创造者大厦1楼Syam Madanapalli Ordyn Technologies-560066
Phone: +91-80-40383000
EMail: smadanapalli@gmail.com
Phone: +91-80-40383000
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.