Network Working Group J. Jeong, Ed.
Request for Comments: 4339 ETRI/University of Minnesota
Category: Informational February 2006
Network Working Group J. Jeong, Ed.
Request for Comments: 4339 ETRI/University of Minnesota
Category: Informational February 2006
IPv6 Host Configuration of DNS Server Information Approaches
DNS服务器信息方法的IPv6主机配置
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
IESG Note
IESG注释
This document describes three different approaches for the configuration of DNS name resolution server information in IPv6 hosts.
本文档描述了在IPv6主机中配置DNS名称解析服务器信息的三种不同方法。
There is not an IETF consensus on which approach is preferred. The analysis in this document was developed by the proponents for each approach and does not represent an IETF consensus.
对于首选哪种方法，IETF没有一致意见。本文件中的分析由每种方法的支持者制定，并不代表IETF共识。
The 'RA option' and 'Well-known anycast' approaches described in this document are not standardized. Consequently the analysis for these approaches might not be completely applicable to any specific proposal that might be proposed in the future.
本文件中描述的“RA选项”和“众所周知的选播”方法未标准化。因此，对这些方法的分析可能不完全适用于将来可能提出的任何具体提案。
Abstract
摘要
This document describes three approaches for IPv6 recursive DNS server address configuration. It details the operational attributes of three solutions: RA option, DHCPv6 option, and well-known anycast addresses for recursive DNS servers. Additionally, it suggests the deployment scenarios in four kinds of networks (ISP, enterprise, 3GPP, and unmanaged networks) considering multi-solution resolution.
本文档描述了IPv6递归DNS服务器地址配置的三种方法。它详细介绍了三种解决方案的操作属性：RA选项、DHCPv6选项和递归DNS服务器的著名选播地址。此外，它还提出了考虑多解决方案解决方案的四种网络（ISP、企业、3GPP和非托管网络）中的部署场景。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. IPv6 DNS Configuration Approaches ...............................3
3.1. RA Option ..................................................3
3.1.1. Advantages ..........................................4
3.1.2. Disadvantages .......................................5
3.1.3. Observations ........................................5
3.2. DHCPv6 Option ..............................................6
3.2.1. Advantages ..........................................7
3.2.2. Disadvantages .......................................8
3.2.3. Observations ........................................9
3.3. Well-known Anycast Addresses ...............................9
3.3.1. Advantages .........................................10
3.3.2. Disadvantages ......................................10
3.3.3. Observations .......................................10
4. Interworking among IPv6 DNS Configuration Approaches ...........11
5. Deployment Scenarios ...........................................12
5.1. ISP Network ...............................................12
5.1.1. RA Option Approach .................................13
5.1.2. DHCPv6 Option Approach .............................13
5.1.3. Well-known Anycast Addresses Approach ..............14
5.2. Enterprise Network ........................................14
5.3. 3GPP Network ..............................................15
5.3.1. Currently Available Mechanisms and
Recommendations ....................................15
5.3.2. RA Extension .......................................16
5.3.3. Stateless DHCPv6 ...................................16
5.3.4. Well-known Addresses ...............................17
5.3.5. Recommendations ....................................18
5.4. Unmanaged Network .........................................18
5.4.1. Case A: Gateway Does Not Provide IPv6 at All .......18
5.4.2. Case B: A Dual-stack Gateway Connected to a
Dual-stack ISP .....................................19
5.4.3. Case C: A Dual-stack Gateway Connected to
an IPv4-only ISP ...................................19
5.4.4. Case D: A Gateway Connected to an IPv6-only ISP ....19
6. Security Considerations ........................................19
6.1. RA Option .................................................20
6.2. DHCPv6 Option .............................................21
6.3. Well-known Anycast Addresses ..............................21
7. Contributors ...................................................21
8. Acknowledgements ...............................................23
9. References .....................................................23
9.1. Normative References ......................................23
9.2. Informative References ....................................23
1. Introduction ....................................................3
2. Terminology .....................................................3
3. IPv6 DNS Configuration Approaches ...............................3
3.1. RA Option ..................................................3
3.1.1. Advantages ..........................................4
3.1.2. Disadvantages .......................................5
3.1.3. Observations ........................................5
3.2. DHCPv6 Option ..............................................6
3.2.1. Advantages ..........................................7
3.2.2. Disadvantages .......................................8
3.2.3. Observations ........................................9
3.3. Well-known Anycast Addresses ...............................9
3.3.1. Advantages .........................................10
3.3.2. Disadvantages ......................................10
3.3.3. Observations .......................................10
4. Interworking among IPv6 DNS Configuration Approaches ...........11
5. Deployment Scenarios ...........................................12
5.1. ISP Network ...............................................12
5.1.1. RA Option Approach .................................13
5.1.2. DHCPv6 Option Approach .............................13
5.1.3. Well-known Anycast Addresses Approach ..............14
5.2. Enterprise Network ........................................14
5.3. 3GPP Network ..............................................15
5.3.1. Currently Available Mechanisms and
Recommendations ....................................15
5.3.2. RA Extension .......................................16
5.3.3. Stateless DHCPv6 ...................................16
5.3.4. Well-known Addresses ...............................17
5.3.5. Recommendations ....................................18
5.4. Unmanaged Network .........................................18
5.4.1. Case A: Gateway Does Not Provide IPv6 at All .......18
5.4.2. Case B: A Dual-stack Gateway Connected to a
Dual-stack ISP .....................................19
5.4.3. Case C: A Dual-stack Gateway Connected to
an IPv4-only ISP ...................................19
5.4.4. Case D: A Gateway Connected to an IPv6-only ISP ....19
6. Security Considerations ........................................19
6.1. RA Option .................................................20
6.2. DHCPv6 Option .............................................21
6.3. Well-known Anycast Addresses ..............................21
7. Contributors ...................................................21
8. Acknowledgements ...............................................23
9. References .....................................................23
9.1. Normative References ......................................23
9.2. Informative References ....................................23
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 routes, and some other parameters [1][2]. To support the access to additional services in the Internet that are identified by a DNS name, such as a web server, the configuration of at least one recursive DNS server is also needed for DNS name resolution.
IP版本6和IPv6无状态地址自动配置的邻居发现（ND）提供了使用一个或多个IPv6地址、默认路由和一些其他参数配置固定或移动节点的方法[1][2]。为了支持访问由DNS名称标识的Internet中的附加服务，例如web服务器，还需要至少一个递归DNS服务器的配置来解析DNS名称。
This document describes three approaches of recursive DNS server address configuration for IPv6 host: (a) RA option [6], (b) DHCPv6 option [3]-[5], and (c) well-known anycast addresses for recursive DNS servers [7]. Also, it suggests the applicable scenarios for four kinds of networks: (a) ISP network, (b) enterprise network, (c) 3GPP network, and (d) unmanaged network.
本文档描述了IPv6主机递归DNS服务器地址配置的三种方法：（a）RA选项[6]，（b）DHCPv6选项[3]-[5]，（c）递归DNS服务器的众所周知的选播地址[7]。此外，还提出了四种网络的适用场景：（a）ISP网络，（b）企业网络，（c）3GPP网络，以及（d）非托管网络。
This document is just an analysis of each possible approach, and it does not recommend a particular approach or combination of approaches. Some approaches may even not be adopted at all as a result of further discussion.
本文件仅对每种可能的方法进行了分析，并不推荐特定的方法或方法组合。经过进一步讨论，有些方法甚至可能根本不被采用。
Therefore, the objective of this document is to help the audience select the approaches suitable for IPv6 host configuration of recursive DNS servers.
因此，本文档的目的是帮助读者选择适合递归DNS服务器的IPv6主机配置的方法。
This document uses the terminology described in [1]-[7]. In addition, a new term is defined below:
本文件使用[1]-[7]中描述的术语。此外，新术语定义如下：
o Recursive DNS Server (RDNSS): Server which provides a recursive DNS resolution service.
o 递归DNS服务器（RDNS）：提供递归DNS解析服务的服务器。
In this section, the operational attributes of the three solutions are described in detail.
在本节中，将详细描述这三种解决方案的操作属性。
The RA approach defines a new ND option, called the RDNSS option, that contains a recursive DNS server address [6]. Existing ND transport mechanisms (i.e., advertisements and solicitations) are used. This works in the same way that nodes learn about routers and prefixes. An IPv6 host can configure the IPv6 addresses of one or more RDNSSes via RA message periodically sent by a router or solicited by a Router Solicitation (RS).
RA方法定义了一个新的ND选项，称为RDNSS选项，该选项包含递归DNS服务器地址[6]。使用现有的ND传输机制（即广告和邀约）。这与节点了解路由器和前缀的方式相同。IPv6主机可以通过路由器定期发送或路由器请求（RS）请求的RA消息配置一个或多个RDNSE的IPv6地址。
This approach needs RDNSS information to be configured in the routers doing the advertisements. The configuration of RDNSS addresses can be performed manually by an operator or in other ways, such as automatic configuration through a DHCPv6 client running on the router. An RA message with one RDNSS option can include as many RDNSS addresses as needed [6].
这种方法需要在做广告的路由器中配置RDNS信息。RDNS地址的配置可以由操作员手动执行，也可以通过其他方式执行，例如通过路由器上运行的DHCPv6客户端进行自动配置。带有一个RDNS选项的RA消息可以根据需要包含任意多个RDNS地址[6]。
Through the ND protocol and RDNSS option, along with a prefix information option, an IPv6 host can perform network configuration of its IPv6 address and RDNSS simultaneously [1][2]. The RA option for RDNSS can be used on any network that supports the use of ND.
通过ND协议和RDNS选项以及前缀信息选项，IPv6主机可以同时执行其IPv6地址和RDNS的网络配置[1][2]。RDNS的RA选项可用于支持ND使用的任何网络。
The RA approach is useful in some mobile environments where the addresses of the RDNSSes are changing because the RA option includes a lifetime field that allows client to use RDNSSes nearer to the client. This can be configured to a value that will require the client to time out the entry and switch over to another RDNSS address [6]. However, from the viewpoint of implementation, the lifetime field would seem to make matters a bit more complex. Instead of just writing to a DNS configuration file, such as resolv.conf for the list of RDNSS addresses, we have to have a daemon around (or a program that is called at the defined intervals) that keeps monitoring the lifetime of RDNSSes all the time.
RA方法在某些移动环境中非常有用，因为在这些环境中，RDNSE的地址正在更改，因为RA选项包含一个生存期字段，该字段允许客户端在更靠近客户端的位置使用RDNSE。可以将其配置为一个值，该值要求客户端超时输入并切换到另一个RDNS地址[6]。然而，从实现的角度来看，生命周期字段似乎使问题变得更复杂。我们必须有一个守护进程（或一个按定义的时间间隔调用的程序）随时监视RDNSS的生存期，而不是仅仅写入DNS配置文件，例如用于RDNSS地址列表的resolv.conf。
The preference value of RDNSS, included in the RDNSS option, allows IPv6 hosts to select primary RDNSS among several RDNSSes [6]; this can be used for the load balancing of RDNSSes.
RDNS选项中包含的RDNS首选值允许IPv6主机在多个RDNS中选择主RDNS[6]；这可用于RDNSS的负载平衡。
The RA option for RDNSS has a number of advantages. These include:
RDNS的RA选项有许多优点。这些措施包括：
1. The RA option is an extension of existing ND/Autoconfig mechanisms [1][2] and does not require a change in the base ND protocol.
1. RA选项是现有ND/自动配置机制[1][2]的扩展，不需要更改基本ND协议。
2. This approach, like ND, works well on a variety of link types, including point-to-point links, point-to-multipoint, and multipoint-to-multipoint (i.e., Ethernet LANs). RFC 2461 [1] states, however, that there may be some link types on which ND is not feasible; on such links, some other mechanisms will be needed for DNS configuration.
2. 这种方法与ND一样，适用于各种链路类型，包括点对点链路、点对多点和多点对多点（即以太网LAN）。然而，RFC 2461[1]指出，可能存在一些ND不可行的链路类型；在这样的链路上，DNS配置将需要一些其他机制。
3. All the information a host needs to run the basic Internet applications (such as the email, web, ftp, etc.) can be obtained with the addition of this option to ND and address autoconfiguration. The use of a single mechanism is more reliable and easier to provide than when the RDNSS information is
3. 主机运行基本Internet应用程序（如电子邮件、web、ftp等）所需的所有信息都可以通过在ND和地址自动配置中添加此选项来获得。使用单一机制比使用RDNSS信息时更可靠、更容易提供
learned via another protocol mechanism. Debugging problems when multiple protocol mechanisms are being used is harder and much more complex.
通过另一个协议机制学习。使用多协议机制时的调试问题更加困难和复杂。
4. This mechanism works over a broad range of scenarios and leverages IPv6 ND. This works well on links that are high performance (e.g., Ethernet LANs) and low performance (e.g., cellular networks). In the latter case, by combining the RDNSS information with the other information in the RA, the host can learn all the information needed to use most Internet applications, such as the web, in a single packet. This not only saves bandwidth, but also minimizes the delay needed to learn the RDNSS information.
4. 此机制适用于多种场景，并利用IPv6 ND。这在高性能（如以太网LAN）和低性能（如蜂窝网络）的链路上运行良好。在后一种情况下，通过将rdns信息与RA中的其他信息相结合，主机可以在单个分组中学习使用大多数因特网应用程序（例如web）所需的所有信息。这不仅节省了带宽，而且最大限度地减少了学习RDNS信息所需的延迟。
5. The RA approach could be used as a model for similar types of configuration information. New RA options for other server addresses, such as NTP server address, that are common to all clients on a subnet would be easy to define.
5. RA方法可以用作类似类型配置信息的模型。子网上所有客户端共用的其他服务器地址（如NTP服务器地址）的新RA选项很容易定义。
1. ND is mostly implemented in the kernel of the operating system. Therefore, if ND supports the configuration of some additional services, such as DNS servers, ND should be extended in the kernel and complemented by a user-land process. DHCPv6, however, has more flexibility for the extension of service discovery because it is an application layer protocol.
1. ND主要在操作系统的内核中实现。因此，如果ND支持一些附加服务的配置，例如DNS服务器，那么ND应该在内核中进行扩展，并由用户登录进程进行补充。然而，DHCPv6对于服务发现的扩展具有更大的灵活性，因为它是一种应用层协议。
2. The current ND framework should be modified to facilitate the synchronization between another ND cache for RDNSSes in the kernel space and the DNS configuration file in the user space. Because it is unacceptable to write and rewrite to the DNS configuration file (e.g., resolv.conf) from the kernel, another approach is needed. One simple approach to solve this is to have a daemon listening to what the kernel conveys, and to have the daemon do these steps, but such a daemon is not needed with the current ND framework.
2. 应修改当前的ND框架，以促进内核空间中RDNSs的另一个ND缓存与用户空间中的DNS配置文件之间的同步。因为从内核写入和重写DNS配置文件（例如resolv.conf）是不可接受的，所以需要另一种方法。解决这个问题的一个简单方法是让一个守护进程监听内核传递的内容，并让守护进程执行这些步骤，但是当前的ND框架不需要这样的守护进程。
3. It is necessary to configure RDNSS addresses at least at one router on every link where this information needs to be configured via the RA option.
3. 有必要在每个链路上至少配置一个RDNS地址，其中需要通过RA选项配置此信息。
The proposed RDNSS RA option, along with the IPv6 ND and Autoconfiguration, allows a host to obtain all of the information it needs to access basic Internet services like the web, email, ftp, etc. This is preferable in the environments where hosts use RAs to
建议的RDNSRA选项，以及IPv6 ND和自动配置，允许主机获取访问基本Internet服务（如web、电子邮件、ftp等）所需的所有信息。这在主机使用RAs的环境中更可取
autoconfigure their addresses and all the hosts on the subnet share the same router and server addresses. If the configuration information can be obtained from a single mechanism, it is preferable because it does not add additional delay, and because it uses a minimum of bandwidth. Environments like this include homes, public cellular networks, and enterprise environments where no per host configuration is needed.
自动配置其地址，子网上的所有主机共享相同的路由器和服务器地址。如果可以从单个机制获得配置信息，则更可取，因为它不会增加额外的延迟，并且因为它使用最小的带宽。像这样的环境包括家庭、公共蜂窝网络和不需要每主机配置的企业环境。
DHCPv6 is preferable where it is being used for address configuration and if there is a need for host specific configuration [3]-[5]. Environments like this are most likely to be the enterprise environments where the local administration chooses to have per host configuration control.
如果DHCPv6用于地址配置，并且需要特定于主机的配置[3]-[5]，则最好使用DHCPv6。像这样的环境很可能是企业环境，在这些环境中，本地管理选择对每台主机进行配置控制。
DHCPv6 [3] includes the "DNS Recursive Name Server" option, through which a host can obtain a list of IP addresses of recursive DNS servers [5]. The DNS Recursive Name Server option carries a list of IPv6 addresses of RDNSSes to which the host may send DNS queries. The DNS servers are listed in the order of preference for use by the DNS resolver on the host.
DHCPv6[3]包括“DNS递归名称服务器”选项，通过该选项，主机可以获得递归DNS服务器的IP地址列表[5]。DNS递归名称服务器选项包含主机可以向其发送DNS查询的RDNSE的IPv6地址列表。DNS服务器按首选顺序列出，供主机上的DNS解析程序使用。
The DNS Recursive Name Server option can be carried in any DHCPv6 Reply message, in response to either a Request or an Information request message. Thus, the DNS Recursive Name Server option can be used either when DHCPv6 is used for address assignment, or when DHCPv6 is used only for other configuration information as stateless DHCPv6 [4].
DNS递归名称服务器选项可以在任何DHCPv6回复消息中携带，以响应请求或信息请求消息。因此，当DHCPv6用于地址分配时，或者当DHCPv6仅用于无状态DHCPv6等其他配置信息时，可以使用DNS递归名称服务器选项[4]。
Stateless DHCPv6 can be deployed either by using DHCPv6 servers running on general-purpose computers, or on router hardware. Several router vendors currently implement stateless DHCPv6 servers. Deploying stateless DHCPv6 in routers has the advantage that no special hardware is required, and it should work well for networks where DHCPv6 is needed for very straightforward configuration of network devices.
无状态DHCPv6可以通过使用在通用计算机上运行的DHCPv6服务器或在路由器硬件上进行部署。一些路由器供应商目前实施无状态DHCPv6服务器。在路由器中部署无状态DHCPv6的优点是不需要特殊的硬件，并且对于需要DHCPv6进行非常简单的网络设备配置的网络，它应该可以很好地工作。
However, routers can also act as DHCPv6 relay agents. In this case, the DHCPv6 server need not be on the router; it can be on a general purpose computer. This has the potential to give the operator of the DHCPv6 server more flexibility in how the DHCPv6 server responds to individual clients that can easily be given different configuration information based on their identity, or for any other reason. Nothing precludes adding this flexibility to a router, but generally, in current practice, DHCP servers running on general-purpose hosts tend to have more configuration options than those that are embedded in routers.
但是，路由器也可以充当DHCPv6中继代理。在这种情况下，DHCPv6服务器不需要位于路由器上；它可以在通用计算机上。这有可能使DHCPv6服务器的操作员在DHCPv6服务器如何响应单个客户机方面具有更大的灵活性，这些客户机可以根据其身份或任何其他原因轻松获得不同的配置信息。没有什么能阻止向路由器添加这种灵活性，但在当前实践中，运行在通用主机上的DHCP服务器通常比嵌入在路由器中的服务器具有更多的配置选项。
DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 clients that use a stateful configuration assignment. To do this, the DHCPv6 server sends a Reconfigure message to the client. The client validates the Reconfigure message, and then contacts the DHCPv6 server to obtain updated configuration information. By using this mechanism, it is currently possible to propagate new configuration information to DHCPv6 clients as this information changes.
DHCPv6目前提供了一种机制，用于重新配置使用有状态配置分配的DHCPv6客户端。为此，DHCPv6服务器向客户端发送一条重新配置消息。客户端验证重新配置消息，然后联系DHCPv6服务器以获取更新的配置信息。通过使用此机制，当前可以在DHCPv6客户机上传播新的配置信息。
The DHC Working Group has standardized an additional mechanism through which configuration information, including the list of RDNSSes, can be updated. The lifetime option for DHCPv6 [8] assigns a lifetime to configuration information obtained through DHCPv6. At the expiration of the lifetime, the host contacts the DHCPv6 server to obtain updated configuration information, including the list of RDNSSes. This lifetime gives the network administrator another mechanism to configure hosts with new RDNSSes by controlling the time at which the host refreshes the list.
DHC工作组已经标准化了一个额外的机制，通过该机制可以更新配置信息，包括RDNSE列表。DHCPv6[8]的生存期选项为通过DHCPv6获得的配置信息分配生存期。在生存期到期时，主机联系DHCPv6服务器以获取更新的配置信息，包括RDNSE列表。此生存期为网络管理员提供了另一种机制，通过控制主机刷新列表的时间来配置具有新RDNSE的主机。
The DHC Working Group has also discussed the possibility of defining an extension to DHCPv6 that would allow the use of multicast to provide configuration information to multiple hosts with a single DHCPv6 message. Because of the lack of deployment experience, the WG has deferred consideration of multicast DHCPv6 configuration at this time. Experience with DHCPv4 has not identified a requirement for multicast message delivery, even in large service provider networks with tens of thousands of hosts that may initiate a DHCPv4 message exchange simultaneously.
DHC工作组还讨论了定义DHCPv6扩展的可能性，该扩展将允许使用多播通过单个DHCPv6消息向多个主机提供配置信息。由于缺乏部署经验，工作组暂时推迟了对多播DHCPv6配置的考虑。根据DHCPv4的经验，即使在具有成千上万台主机的大型服务提供商网络中，也没有发现对多播消息传递的要求，这些主机可能同时启动DHCPv4消息交换。
The DHCPv6 option for RDNSS has a number of advantages. These include:
RDNS的DHCPv6选项有许多优点。这些措施包括：
1. DHCPv6 currently provides a general mechanism for conveying network configuration information to clients. Configuring DHCPv6 servers in this way allows the network administrator to configure RDNSSes, the addresses of other network services, and location-specific information, such as time zones.
1. DHCPv6目前提供了一种通用机制，用于向客户端传送网络配置信息。通过这种方式配置DHCPv6服务器，网络管理员可以配置RDNSE、其他网络服务的地址以及特定于位置的信息，如时区。
2. As a consequence, when the network administrator goes to configure DHCPv6, all the configuration information can be managed through a single service, typically with a single user interface and a single configuration database.
2. 因此，当网络管理员开始配置DHCPv6时，所有配置信息都可以通过单个服务进行管理，通常使用单个用户界面和单个配置数据库。
3. DHCPv6 allows for the configuration of a host with information specific to that host, so that hosts on the same link can be configured with different RDNSSes and with other configuration information.
3. DHCPv6允许使用特定于该主机的信息配置主机，以便可以使用不同的RDNSE和其他配置信息配置同一链路上的主机。
4. A mechanism exists for extending DHCPv6 to support the transmission of additional configuration that has not yet been anticipated.
4. 存在一种扩展DHCPv6的机制，以支持尚未预期的附加配置的传输。
5. Hosts that require other configuration information, such as the addresses of SIP servers and NTP servers, are likely to need DHCPv6 for other configuration information.
5. 需要其他配置信息（如SIP服务器和NTP服务器的地址）的主机可能需要DHCPv6来获取其他配置信息。
6. The specification for configuration of RDNSSes through DHCPv6 is available as an RFC. No new protocol extensions (such as new options) are necessary.
6. 通过DHCPv6配置RDNSS的规范可作为RFC提供。不需要新的协议扩展（例如新选项）。
7. Interoperability among independent implementations has been demonstrated.
7. 已经证明了独立实现之间的互操作性。
The DHCPv6 option for RDNSS has a few disadvantages. These include:
RDNS的DHCPv6选项有一些缺点。这些措施包括：
1. Update currently requires a message from server (however, see [8]).
1. 更新当前需要来自服务器的消息（但是，请参见[8]）。
2. Because DNS information is not contained in RA messages, the host must receive two messages from the router and must transmit at least one message to the router. On networks where bandwidth is at a premium, this is a disadvantage, although on most networks it is not a practical concern.
2. 因为DNS信息不包含在RA消息中，所以主机必须从路由器接收两条消息，并且必须至少向路由器发送一条消息。在带宽昂贵的网络上，这是一个缺点，尽管在大多数网络上，这不是一个实际问题。
3. There is an increased latency for initial configuration. In addition to waiting for an RA message, the client must now exchange packets with a DHCPv6 server. Even if it is locally installed on a router, this will slightly extend the time required to configure the client. For clients that are moving rapidly from one network to another, this will be a disadvantage.
3. 初始配置的延迟会增加。除了等待RA消息外，客户机现在还必须与DHCPv6服务器交换数据包。即使它是本地安装在路由器上，这也会略微延长配置客户端所需的时间。对于从一个网络快速移动到另一个网络的客户端来说，这将是一个缺点。
In the general case, on general-purpose networks, stateless DHCPv6 provides significant advantages and no significant disadvantages. Even in the case where bandwidth is at a premium and low latency is desired, if hosts require other configuration information in addition to a list of RDNSSes or if hosts must be configured selectively, those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive name server option will be advantageous.
在一般情况下，在通用网络上，无状态DHCPv6提供了显著的优点，但没有显著的缺点。即使在带宽较高且需要低延迟的情况下，如果主机除了RDNSE列表之外还需要其他配置信息，或者如果必须选择性地配置主机，则这些主机将使用DHCPv6，并且使用DHCPv6 DNS递归名称服务器选项将是有利的。
However, we are aware of some applications where it would be preferable to put the RDNSS information into an RA packet; for example, in a mobile phone network, where bandwidth is at a premium and extremely low latency is desired. The DNS configuration based on RA should be standardized so as to allow these special applications to be handled using DNS information in the RA packet.
然而，我们知道，在某些应用中，最好将RDNS信息放入RA数据包中；例如，在移动电话网络中，带宽非常高，需要极低的延迟。基于RA的DNS配置应标准化，以便允许使用RA数据包中的DNS信息处理这些特殊应用程序。
Anycast uses the same routing system as unicast [9]. However, administrative entities are local ones. The local entities may accept unicast routes (including default routes) to anycast servers from adjacent entities. The administrative entities should not advertise their peer routes to their internal anycast servers, if they want to prohibit external access from some peers to the servers. If some advertisement is inevitable (such as the case with default routes), the packets to the servers should be blocked at the boundary of the entities. Thus, for this anycast, not only unicast routing but also unicast ND protocols can be used as is.
Anycast使用与单播相同的路由系统[9]。然而，行政实体是地方实体。本地实体可以接受从相邻实体到选播服务器的单播路由（包括默认路由）。如果管理实体希望禁止某些对等方对服务器的外部访问，则不应向其内部选播服务器公布其对等路由。如果某些广告是不可避免的（例如使用默认路由的情况），那么到服务器的数据包应该在实体的边界处被阻止。因此，对于该选播，不仅可以按原样使用单播路由，还可以按原样使用单播ND协议。
First of all, the well-known anycast addresses approach is much different from that discussed by the IPv6 Working Group in the past [7]. Note that "anycast" in this memo is simpler than that of RFC 1546 [9] and RFC 3513 [10], where it is assumed to be prohibited to have multiple servers on a single link sharing an anycast address. That is, on a link, an anycast address is assumed to be unique. DNS clients today already have redundancy by having multiple well-known anycast addresses configured as RDNSS addresses. There is no point in having multiple RDNSSes sharing an anycast address on a single link.
首先，众所周知的选播地址方法与IPv6工作组过去讨论的方法有很大不同[7]。请注意，本备忘录中的“选播”比RFC 1546[9]和RFC 3513[10]中的“选播”更简单，在RFC 1546[9]和RFC 3513[10]中，假定禁止在一条链路上有多台服务器共享一个选播地址。也就是说，在链路上，选播地址被假定为唯一的。今天的DNS客户机已经有了冗余，因为有多个众所周知的选播地址被配置为RDNS地址。让多个RDN在单个链路上共享选播地址没有意义。
The approach with well-known anycast addresses is to set multiple well-known anycast addresses in clients' resolver configuration files from the beginning as, say, factory default. Thus, there is no transport mechanism and no packet format [7].
使用已知选播地址的方法是从一开始就在客户端的解析器配置文件中设置多个已知选播地址，例如，出厂默认值。因此，不存在传输机制和分组格式[7]。
An anycast address is an address shared by multiple servers (in this case, the servers are RDNSSes). A request from a client to the
选播地址是由多个服务器共享的地址（在本例中，服务器是RDNSS）。从客户端到服务器的请求
anycast address is routed to a server selected by the routing system. However, it is a bad idea to mandate "site" boundary on anycast addresses, because most users do not have their own servers and want to access their ISPs across their site boundaries. Larger sites may also depend on their ISPs or may have their own RDNSSes within "site" boundaries.
选播地址被路由到路由系统选择的服务器。然而，在选播地址上强制使用“站点”边界是一个坏主意，因为大多数用户没有自己的服务器，希望跨越站点边界访问他们的ISP。较大的站点也可能依赖其ISP，或在“站点”边界内拥有自己的RDNSE。
The basic advantage of the well-known addresses approach is that it uses no transport mechanism. Thus, the following apply:
众所周知的地址方法的基本优点是它不使用传输机制。因此，以下内容适用：
1. There is no delay to get the response and no further delay by packet losses.
1. 没有获得响应的延迟，也没有因数据包丢失而造成的进一步延迟。
2. The approach can be combined with any other configuration mechanisms, such as the RA-based approach and DHCP-based approach, as well as the factory default configuration.
2. 可以将基于工厂的配置方法和其他任何基于DHCP的配置方法结合起来。
3. The approach works over any environment where DNS works.
3. 该方法适用于DNS工作的任何环境。
Another advantage is that this approach only needs configuration of the DNS servers as a router (or configuration of a proxy router). Considering that DNS servers do need configuration, the amount of overall configuration effort is proportional to the number of DNS servers and it scales linearly. Note that, in the simplest case, where a subscriber to an ISP does not have a DNS server, the subscriber naturally accesses DNS servers of the ISP, even though the subscriber and the ISP do nothing and there is no protocol to exchange DNS server information between the subscriber and the ISP.
另一个优点是，这种方法只需要将DNS服务器配置为路由器（或配置代理路由器）。考虑到DNS服务器确实需要配置，总体配置工作量与DNS服务器的数量成正比，并且可以线性扩展。请注意，在最简单的情况下，如果ISP的订户没有DNS服务器，订户自然会访问ISP的DNS服务器，即使订户和ISP什么都不做，并且订户和ISP之间没有交换DNS服务器信息的协议。
The well-known anycast addresses approach requires that DNS servers (or routers near to them as a proxy) act as routers to advertise their anycast addresses to the routing system, which requires some configuration (see the last paragraph of the previous section on the scalability of the effort). In addition, routers at the boundary of the "site" might need the configuration of route filters to prevent providing DNS services for parties outside the "site" and the possibility of denial of service attacks on the internal DNS infrastructure.
众所周知的选播地址方法要求DNS服务器（或其附近的路由器作为代理）充当路由器，向路由系统公布其选播地址，这需要一些配置（请参阅上一节关于工作可伸缩性的最后一段）。此外，“站点”边界处的路由器可能需要配置路由过滤器，以防止为“站点”之外的各方提供DNS服务，并防止对内部DNS基础设施进行拒绝服务攻击的可能性。
If other approaches are used in addition, the well-known anycast addresses should also be set in RA or DHCP configuration files to reduce the configuration effort of users.
如果另外还使用其他方法，则还应在RA或DHCP配置文件中设置众所周知的选播地址，以减少用户的配置工作量。
The redundancy by multiple RDNSSes is better provided by multiple servers with different anycast addresses than by multiple servers sharing the same anycast address, because the former approach allows stale servers to generate routes to their anycast addresses. Thus, in a routing domain (or domains sharing DNS servers), there will be only one server with an anycast address unless the domain is so large that load distribution is necessary.
具有不同选播地址的多个服务器比共享相同选播地址的多个服务器更好地提供多个RDN的冗余，因为前一种方法允许过时的服务器生成到其选播地址的路由。因此，在路由域（或共享DNS服务器的域）中，只有一台服务器具有选播地址，除非该域太大以至于需要进行负载分配。
Small ISPs will operate one RDNSS at each anycast address that is shared by all the subscribers. Large ISPs may operate multiple RDNSSes at each anycast address to distribute and reduce load, where the boundary between RDNSSes may be fixed (redundancy is still provided by multiple addresses) or change dynamically. DNS packets with the well-known anycast addresses are not expected (though not prohibited) to cross ISP boundaries, as ISPs are expected to be able to take care of themselves.
小型ISP将在所有用户共享的每个选播地址运行一个RDNS。大型ISP可能在每个选播地址运行多个RDN，以分配和减少负载，其中RDN之间的边界可能是固定的（冗余仍然由多个地址提供）或动态变化。具有众所周知的选播地址的DNS数据包预计不会（尽管并没有被禁止）跨越ISP边界，因为ISP应该能够照顾自己。
Because "anycast" in this memo is simpler than that of RFC 1546 [9] and RFC 3513 [10], where it is assumed to be administratively prohibited to have multiple servers on a single link sharing an anycast address, anycast in this memo should be implemented as UNICAST of RFC 2461 [1] and RFC 3513 [10]. As a result, ND-related instability disappears. Thus, in the well-known anycast addresses approach, anycast can and should use the anycast address as a source unicast (according to RFC 3513 [10]) address of packets of UDP and TCP responses. With TCP, if a route flips and packets to an anycast address are routed to a new server, it is expected that the flip is detected by ICMP or sequence number inconsistency, and that the TCP connection is reset and retried.
由于本备忘录中的“选播”比RFC 1546[9]和RFC 3513[10]的简单，其中假设在管理上禁止在一条链路上有多台服务器共享一个选播地址，因此本备忘录中的选播应实现为RFC 2461[1]和RFC 3513[10]的单播。结果，钕相关的不稳定性消失。因此，在众所周知的选播地址方法中，选播可以并且应该使用选播地址作为UDP和TCP响应的分组的源单播（根据RFC 3513[10]）地址。对于TCP，如果路由翻转，并且到选播地址的数据包被路由到新服务器，则ICMP或序列号不一致会检测到翻转，并且TCP连接会重置并重试。
Three approaches can work together for IPv6 host configuration of RDNSS. This section shows a consideration on how these approaches can interwork.
三种方法可以一起用于RDNS的IPv6主机配置。本节介绍了这些方法如何相互作用。
For ordering between RA and DHCP approaches, the O (Other stateful configuration) flag in the RA message can be used [6][28]. If no RDNSS option is included, an IPv6 host may perform DNS configuration through DHCPv6 [3]-[5] regardless of whether the O flag is set or not.
对于RA和DHCP方法之间的排序，可以使用RA消息中的O（其他有状态配置）标志[6][28]。如果不包括RDNS选项，则IPv6主机可以通过DHCPv6[3]-[5]执行DNS配置，而不管是否设置了O标志。
The well-known anycast addresses approach fully interworks with the other approaches. That is, the other approaches can remove the configuration effort on servers by using the well-known addresses as the default configuration. Moreover, the clients preconfigured with the well-known anycast addresses can be further configured to use other approaches to override the well-known addresses, if the
众所周知的选播地址方法与其他方法完全相互作用。也就是说，其他方法可以通过使用已知地址作为默认配置来消除服务器上的配置工作。此外，如果
configuration information from other approaches is available. Otherwise, all the clients need to have the well-known anycast addresses preconfigured. In order to use the anycast approach along with two other approaches, there are three choices as follows:
其他方法的配置信息可用。否则，所有客户端都需要预先配置众所周知的选播地址。为了与其他两种方法一起使用选播方法，有以下三种选择：
1. The first choice is that well-known addresses are used as last resort, when an IPv6 host cannot get RDNSS information through RA and DHCP. The well-known anycast addresses have to be preconfigured in all of IPv6 hosts' resolver configuration files.
1. 第一种选择是，当IPv6主机无法通过RA和DHCP获取RDNS信息时，使用已知地址作为最后手段。众所周知的选播地址必须在所有IPv6主机的解析器配置文件中预先配置。
2. The second is that an IPv6 host can configure well-known addresses as the most preferable in its configuration file even though either an RA option or DHCP option is available.
2. 第二，IPv6主机可以将已知地址配置为其配置文件中的首选地址，即使RA选项或DHCP选项可用。
3. The last is that the well-known anycast addresses can be set in RA or DHCP configuration to reduce the configuration effort of users. According to either the RA or DHCP mechanism, the well-known addresses can be obtained by an IPv6 host. Because this approach is the most convenient for users, the last option is recommended.
3. 最后，可以在RA或DHCP配置中设置众所周知的选播地址，以减少用户的配置工作量。根据RA或DHCP机制，IPv6主机可以获得已知地址。因为这种方法对用户来说是最方便的，所以建议使用最后一种方法。
Note: This section does not necessarily mean that this document suggests adopting all of these three approaches and making them interwork in the way described here. In fact, as a result of further discussion some approaches may not even be adopted at all.
注：本节并不一定意味着本文件建议采用所有这三种方法，并以本文所述的方式使它们相互作用。事实上，经过进一步讨论，有些办法甚至可能根本不被采用。
Regarding the DNS configuration on the IPv6 host, several mechanisms are being considered by the DNSOP Working Group, such as RA option, DHCPv6 option, and well-known preconfigured anycast addresses as of today, and this document is a final result from the long thread. In this section, we suggest four applicable scenarios of three approaches for IPv6 DNS configuration.
关于IPv6主机上的DNS配置，DNSOP工作组正在考虑几种机制，例如RA选项、DHCPv6选项和目前已知的预配置选播地址，本文档是长线程的最终结果。在本节中，我们建议了三种IPv6 DNS配置方法的四种适用场景。
Note: In the applicable scenarios, authors do not implicitly push any specific approaches into the restricted environments. No enforcement is in each scenario, and all mentioned scenarios are probable. The main objective of this work is to provide a useful guideline for IPv6 DNS configuration.
注意：在适用的场景中，作者不会隐式地将任何特定方法推送到受限环境中。在每个场景中都没有强制执行，并且所有提到的场景都是可能的。这项工作的主要目标是为IPv6 DNS配置提供有用的指南。
A characteristic of an ISP network is that multiple Customer Premises Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) routers and that each PE connects multiple CPE devices to the backbone network infrastructure [11]. The CPEs may be hosts or routers.
ISP网络的一个特点是，多个客户场所设备（CPE）设备连接到IPv6 PE（提供商边缘）路由器，每个PE将多个CPE设备连接到骨干网络基础设施[11]。cpe可以是主机或路由器。
If the CPE is a router, there is a customer network that is connected to the ISP backbone through the CPE. Typically, each customer network gets a different IPv6 prefix from an IPv6 PE router, but the same RDNSS configuration will be distributed.
如果CPE是路由器，则存在通过CPE连接到ISP主干的客户网络。通常，每个客户网络从IPv6 PE路由器获得不同的IPv6前缀，但将分发相同的RDNS配置。
This section discusses how the different approaches to distributing DNS information are compared in an ISP network.
本节讨论如何在ISP网络中比较分发DNS信息的不同方法。
When the CPE is a host, the RA option for RDNSS can be used to allow the CPE to get RDNSS information and /64 prefix information for stateless address autoconfiguration at the same time when the host is attached to a new subnet [6]. Because an IPv6 host must receive at least one RA message for stateless address autoconfiguration and router configuration, the host could receive RDNSS configuration information in the RA without the overhead of an additional message exchange.
当CPE是主机时，RDNS的RA选项可用于允许CPE在主机连接到新子网的同时获取RDNS信息和/或无状态地址自动配置的64前缀信息[6]。由于IPv6主机必须接收至少一条RA消息以进行无状态地址自动配置和路由器配置，因此主机可以在RA中接收RDNS配置信息，而无需额外的消息交换开销。
When the CPE is a router, the CPE may accept the RDNSS information from the RA on the interface connected to the ISP and copy that information into the RAs advertised in the customer network.
当CPE是路由器时，CPE可以在连接到ISP的接口上接受来自RA的rdns信息，并将该信息复制到客户网络中公布的RAs中。
This approach is more valuable in the mobile host scenario, in which the host must receive at least an RA message for detecting a new network, than in other scenarios generally, although the administrator should configure RDNSS information on the routers. Secure ND [12] can provide extended security when RA messages are used.
这种方法在移动主机场景中更有价值，在移动主机场景中，主机必须接收至少一条RA消息以检测新网络，而在其他场景中，这种方法通常更有用，尽管管理员应该在路由器上配置RDNS信息。当使用RA消息时，安全ND[12]可以提供扩展的安全性。
DHCPv6 can be used for RDNSS configuration through the use of the DNS option, and can provide other configuration information in the same message with RDNSS configuration [3]-[5]. The DHCPv6 DNS option is already in place for DHCPv6, as RFC 3646 [5] and DHCPv6-lite or stateless DHCP [4] is not nearly as complex as a full DHCPv6 implementation. DHCP is a client-server model protocol, so ISPs can handle user identification on its network intentionally; also, authenticated DHCP [13] can be used for secure message exchange.
DHCPv6可通过使用DNS选项用于RDNSS配置，并可在同一消息中提供其他配置信息，包括RDNSS配置[3]-[5]。DHCPv6的DHCPv6 DNS选项已经就位，因为RFC 3646[5]和DHCPv6 lite或无状态DHCP[4]远没有完整的DHCPv6实现那么复杂。DHCP是一种客户机-服务器模型协议，因此ISP可以有意地在其网络上处理用户标识；此外，经过身份验证的DHCP[13]可用于安全消息交换。
The expected model for deployment of IPv6 service by ISPs is to assign a prefix to each customer, which will be used by the customer gateway to assign a /64 prefix to each network in the customer's network. Prefix delegation with DHCP (DHCPv6 PD) has already been adopted by ISPs for automating the assignment of the customer prefix to the customer gateway [15]. DNS configuration can be carried in the same DHCPv6 message exchange used for DHCPv6 to provide that
ISP部署IPv6服务的预期模式是为每个客户分配前缀，客户网关将使用该前缀为客户网络中的每个网络分配/64前缀。ISP已经采用带有DHCP的前缀委派（DHCPv6 PD）来自动将客户前缀分配给客户网关[15]。DNS配置可以在用于DHCPv6的相同DHCPv6消息交换中进行，以提供
information efficiently, along with any other configuration information needed by the customer gateway or customer network. This service model can be useful to Home or SOHO subscribers. The Home or SOHO gateway, which is a customer gateway for ISP, can then pass that RDNSS configuration information to the hosts in the customer network through DHCP.
信息，以及客户网关或客户网络所需的任何其他配置信息。这种服务模式对家庭或SOHO用户很有用。家庭或SOHO网关是ISP的客户网关，然后可以通过DHCP将RDNSS配置信息传递给客户网络中的主机。
The well-known anycast addresses approach is also a feasible and simple mechanism for ISP [7]. The use of well-known anycast addresses avoids some of the security risks in rogue messages sent through an external protocol such as RA or DHCPv6. The configuration of hosts for the use of well-known anycast addresses requires no protocol or manual configuration, but the configuration of routing for the anycast addresses requires intervention on the part of the network administrator. Also, the number of special addresses would be equal to the number of RDNSSes that could be made available to subscribers.
众所周知的选播地址方法也是ISP可行且简单的机制[7]。使用众所周知的选播地址可以避免通过外部协议（如RA或DHCPv6）发送的恶意消息中的一些安全风险。为使用众所周知的选播地址配置主机不需要协议或手动配置，但为选播地址配置路由需要网络管理员的干预。此外，特殊地址的数量将等于可以提供给订阅者的RDNSE的数量。
An enterprise network is defined as a network that has multiple internal links, one or more router connections to one or more providers, and is actively managed by a network operations entity [14]. An enterprise network can get network prefixes from an ISP by either manual configuration or prefix delegation [15]. In most cases, because an enterprise network manages its own DNS domains, it operates its own DNS servers for the domains. These DNS servers within enterprise networks process recursive DNS name resolution requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the enterprise network can be performed as it is in Section 4, in which three approaches can be used together as follows:
企业网络被定义为具有多个内部链路、一个或多个到一个或多个提供商的路由器连接，并由网络运营实体主动管理的网络[14]。企业网络可以通过手动配置或前缀委托从ISP获取网络前缀[15]。在大多数情况下，因为企业网络管理自己的DNS域，所以它为这些域运行自己的DNS服务器。企业网络中的这些DNS服务器将来自IPv6主机的递归DNS名称解析请求作为RDNSs进行处理。企业网络中的RDNSS配置可以按照第4节的要求执行，其中三种方法可以一起使用，如下所示：
1. An IPv6 host can decide which approach is or may be used in its subnet with the O flag in RA message [6][28]. As the first choice in Section 4, well-known anycast addresses can be used as a last resort when RDNSS information cannot be obtained through either an RA option or a DHCP option. This case needs IPv6 hosts to preconfigure the well-known anycast addresses in their DNS configuration files.
1. IPv6主机可以通过RA消息[6][28]中的O标志决定在其子网中使用或可能使用哪种方法。作为第4节中的第一个选择，当无法通过RA选项或DHCP选项获得RDNS信息时，可以使用众所周知的选播地址作为最后手段。这种情况需要IPv6主机在其DNS配置文件中预先配置众所周知的选播地址。
2. When the enterprise prefers the well-known anycast approach to others, IPv6 hosts should preconfigure the well-known anycast addresses as it is in the first choice.
2. 当企业倾向于使用众所周知的选播方法时，IPv6主机应该预先配置众所周知的选播地址，因为它是首选。
3. The last choice, a more convenient and transparent way, does not need IPv6 hosts to preconfigure the well-known anycast addresses
3. 最后一种选择是一种更方便、更透明的方式，它不需要IPv6主机预先配置众所周知的选播地址
because the addresses are delivered to IPv6 hosts via either the RA option or DHCPv6 option as if they were unicast addresses. This way is most recommended for the sake of the user's convenience.
因为地址通过RA选项或DHCPv6选项传递给IPv6主机，就像它们是单播地址一样。为了方便用户，最推荐这种方式。
The IPv6 DNS configuration is a missing part of IPv6 autoconfiguration and an important part of the basic IPv6 functionality in the 3GPP User Equipment (UE). The higher-level description of the 3GPP architecture can be found in [16], and transition to IPv6 in 3GPP networks is analyzed in [17] and [18].
IPv6 DNS配置是IPv6自动配置中缺失的一部分，也是3GPP用户设备（UE）中基本IPv6功能的重要组成部分。[16]中对3GPP体系结构进行了更高层次的描述，在[17]和[18]中分析了3GPP网络向IPv6的过渡。
In the 3GPP architecture, there is a dedicated link between the UE and the GGSN called the Packet Data Protocol (PDP) Context. This link is created through the PDP Context activation procedure [19]. There is a separate PDP context type for IPv4 and IPv6 traffic. If a 3GPP UE user is communicating by using IPv6 (i.e., by having an active IPv6 PDP context), it cannot be assumed that the user simultaneously has an active IPv4 PDP context, and DNS queries could be done using IPv4. A 3GPP UE can thus be an IPv6 node, and somehow it needs to discover the address of the RDNSS. Before IP-based services (e.g., web browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS addresses need to be discovered in the 3GPP UE.
在3GPP体系结构中，UE和GGSN之间存在称为分组数据协议（PDP）上下文的专用链路。此链接通过PDP上下文激活过程创建[19]。IPv4和IPv6流量有单独的PDP上下文类型。如果3GPP UE用户通过使用IPv6（即，通过具有活动IPv6-PDP上下文）进行通信，则不能假设该用户同时具有活动IPv4-PDP上下文，并且可以使用IPv4完成DNS查询。因此，3GPP UE可以是IPv6节点，并且不知何故它需要发现rdns的地址。在可以使用基于IP的服务（例如，web浏览或电子邮件）之前，需要在3GPP UE中发现IPv6（和IPv4）rdss地址。
Section 5.3.1 briefly summarizes currently available mechanisms in 3GPP networks and recommendations. 5.3.2 analyzes the Router Advertisement-based solution, 5.3.3 analyzes the Stateless DHCPv6 mechanism, and 5.3.4 analyzes the well-known addresses approach. Section 5.3.5 summarizes the recommendations.
第5.3.1节简要总结了3GPP网络中当前可用的机制和建议。5.3.2分析了基于路由器广告的解决方案，5.3.3分析了无状态DHCPv6机制，5.3.4分析了众所周知的地址方法。第5.3.5节总结了建议。
3GPP has defined a mechanism in which RDNSS addresses can be received in the PDP context activation (a control plane mechanism). That is called the Protocol Configuration Options Information Element (PCO-IE) mechanism [20]. The RDNSS addresses can also be received over the air (using text messages) or typed in manually in the UE. Note that the two last mechanisms are not very well scalable. The UE user most probably does not want to type IPv6 RDNSS addresses manually in the user's UE. The use of well-known addresses is briefly discussed in section 5.3.4.
3GPP已经定义了一种机制，其中rdss地址可以在PDP上下文激活中接收（控制平面机制）。这称为协议配置选项信息元素（PCO-IE）机制[20]。RDNS地址也可以通过无线方式接收（使用文本消息）或在UE中手动键入。请注意，最后两种机制的可伸缩性不是很好。UE用户很可能不希望在用户的UE中手动键入IPv6 rdss地址。第5.3.4节简要讨论了知名地址的使用。
It is seen that the mechanisms above most probably are not sufficient for the 3GPP environment. IPv6 is intended to operate in a zero-configuration manner, no matter what the underlying network infrastructure is. Typically, the RDNSS address is needed to make an IPv6 node operational, and the DNS configuration should be as simple
可以看出，上述机制对于3GPP环境来说很可能是不够的。IPv6旨在以零配置方式运行，无论底层网络基础设施是什么。通常，需要RDNS地址才能使IPv6节点运行，并且DNS配置应尽可能简单
as the address autoconfiguration mechanism. Note that there will be additional IP interfaces in some near-future 3GPP UEs; e.g., 3GPP-specific DNS configuration mechanisms (such as PCO-IE [20]) do not work for those IP interfaces. In other words, a good IPv6 DNS configuration mechanism should also work in a multi-access network environment.
作为地址自动配置机制。注意，在一些不久的将来的3GPP ue中将有额外的IP接口；e、 例如，3GPP特定的DNS配置机制（例如PCO-IE[20]）不适用于那些IP接口。换句话说，一个好的IPv6 DNS配置机制也应该在多址网络环境中工作。
From a 3GPP point of view, the best IPv6 DNS configuration solution is feasible for a very large number of IPv6-capable UEs (even hundreds of millions in one operator's network), is automatic, and thus requires no user action. It is suggested that a lightweight, stateless mechanism be standardized for use in all network environments. The solution could then be used for 3GPP, 3GPP2, and other access network technologies. Thus, not only is a light, stateless IPv6 DNS configuration mechanism needed in 3GPP networks, but also 3GPP networks and UEs would certainly benefit from the new mechanism.
从3GPP的角度来看，最好的IPv6 DNS配置解决方案对于大量支持IPv6的ue（甚至在一个运营商的网络中有数亿个）是可行的，是自动的，因此不需要用户操作。建议对轻量级无状态机制进行标准化，以便在所有网络环境中使用。然后，该解决方案可用于3GPP、3GPP2和其他接入网络技术。因此，不仅3GPP网络中需要一种轻量、无状态的IPv6 DNS配置机制，而且3GPP网络和UE肯定也会从新机制中受益。
Router Advertisement extension [6] is a lightweight IPv6 DNS configuration mechanism that requires minor changes in the 3GPP UE IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in the 3GPP architecture) IPv6 stack. This solution can be specified in the IETF (no action is needed in the 3GPP) and taken in use in 3GPP UEs and GGSNs.
路由器广告扩展[6]是一种轻量级IPv6 DNS配置机制，需要对3GPP UE IPv6堆栈和网关GPRS支持节点（GGSN，3GPP体系结构中的默认路由器）IPv6堆栈进行细微更改。该解决方案可以在IETF中指定（在3GPP中不需要任何操作），并在3GPP UE和GGSN中使用。
In this solution, an IPv6-capable UE configures DNS information via an RA message sent by its default router (GGSN); i.e., the RDNSS option for a recursive DNS server is included in the RA message. This solution is easily scalable for a very large number of UEs. The operator can configure the RDNSS addresses in the GGSN as a part of normal GGSN configuration. The IPv6 RDNSS address is received in the Router Advertisement, and an extra Round Trip Time (RTT) for asking RDNSS addresses can be avoided.
在该解决方案中，支持IPv6的UE通过其默认路由器（GGSN）发送的RA消息来配置DNS信息；i、 例如，RA消息中包含递归DNS服务器的RDNSS选项。该解决方案对于大量的UE易于扩展。操作员可以将GGSN中的RDNS地址配置为正常GGSN配置的一部分。在路由器公告中接收IPv6 RDNS地址，可以避免请求RDNS地址的额外往返时间（RTT）。
When one considers the cons, this mechanism still requires standardization effort in the IETF, and the end nodes and routers need to support this mechanism. The equipment software update should, however, be pretty straightforward, and new IPv6 equipment could support RA extension already from the beginning.
考虑到缺点，这种机制仍然需要IETF中的标准化工作，并且终端节点和路由器需要支持这种机制。然而，设备软件更新应该非常简单，新的IPv6设备从一开始就可以支持RA扩展。
A DHCPv6-based solution needs the implementation of Stateless DHCP [4] and DHCPv6 DNS options [5] in the UE, and a DHCPv6 server in the operator's network. A possible configuration is such that the GGSN works as a DHCP relay.
基于DHCPv6的解决方案需要在UE中实现无状态DHCP[4]和DHCPv6 DNS选项[5]，并在运营商的网络中实现DHCPv6服务器。一种可能的配置是GGSN作为DHCP中继工作。
The pros of a stateless DHCPv6-based solution are:
基于无状态DHCPv6的解决方案的优点是：
1. Stateless DHCPv6 is a standardized mechanism.
1. 无状态DHCPv6是一种标准化机制。
2. DHCPv6 can be used for receiving configuration information other than RDNSS addresses; e.g., SIP server addresses.
2. DHCPv6可用于接收RDNS地址以外的配置信息；e、 例如，SIP服务器地址。
3. DHCPv6 works in different network environments.
3. DHCPv6在不同的网络环境中工作。
4. When DHCPv6 service is deployed through a single, centralized server, the RDNSS configuration information can be updated by the network administrator at a single source.
4. 当通过单个集中式服务器部署DHCPv6服务时，网络管理员可以在单个源上更新RDNSS配置信息。
Some issues with DHCPv6 in 3GPP networks are listed below:
3GPP网络中DHCPv6的一些问题如下所示：
1. DHCPv6 requires an additional server in the network unless the (Stateless) DHCPv6 functionality is integrated into an existing router. This means that there might be one additional server to be maintained.
1. 除非（无状态）DHCPv6功能集成到现有路由器中，否则DHCPv6需要网络中的附加服务器。这意味着可能需要维护一个额外的服务器。
2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing (3GPP Stateless Address Autoconfiguration is typically used) and is not automatically implemented in 3GPP IPv6 UEs.
2. 3GPP UE IPv6寻址不一定需要DHCPv6（通常使用3GPP无状态地址自动配置），并且不会在3GPP IPv6 UE中自动实现。
3. Scalability and reliability of DHCPv6 in very large 3GPP networks (with tens or hundreds of millions of UEs) may be an issue; at least the redundancy needs to be taken care of. However, if the DHCPv6 service is integrated into the network elements, such as a router operating system, scalability and reliability is comparable with other DNS configuration approaches.
3. DHCPv6在非常大的3GPP网络（具有数千万或数亿个UE）中的可伸缩性和可靠性可能是一个问题；至少需要注意冗余。但是，如果将DHCPv6服务集成到网络元件（如路由器操作系统）中，则可扩展性和可靠性与其他DNS配置方法相当。
4. It is sub-optimal to utilize the radio resources in 3GPP networks for DHCPv6 messages if there is a simpler alternative is available.
4. 如果有更简单的替代方案可用，则利用3GPP网络中的无线电资源用于DHCPv6消息是次优的。
* The use of stateless DHCPv6 adds one round-trip delay to the case in which the UE can start transmitting data right after the Router Advertisement.
* 无状态DHCPv6的使用增加了一个往返延迟，使得UE可以在路由器公告之后立即开始传输数据。
5. If the DNS information (suddenly) changes, Stateless DHCPv6 cannot automatically update the UE; see [21].
5. 如果DNS信息（突然）改变，无状态DHCPv6无法自动更新UE；见[21]。
Using well-known addresses is also a feasible and light mechanism for 3GPP UEs. Those well-known addresses can be preconfigured in the UE software and the operator can make the corresponding configuration on the network side. Thus, this is a very easy mechanism for the UE,
对于3GPP ue，使用已知地址也是一种可行且轻便的机制。这些众所周知的地址可以在UE软件中预配置，并且运营商可以在网络侧进行相应的配置。因此，这对于UE来说是非常容易的机制，
but it requires some configuration work in the network. When using well-known addresses, UE forwards queries to any of the preconfigured addresses. In the current proposal [7], IPv6 anycast addresses are suggested.
但它需要在网络中进行一些配置工作。当使用已知地址时，UE将查询转发到任何预配置的地址。在当前方案[7]中，建议使用IPv6选播地址。
Note: An IPv6 DNS configuration proposal, based on the use of well-known site-local addresses, was developed by the IPv6 Working Group; it was seen as a feasible mechanism for 3GPP UEs, although no IETF consensus was reached on this proposal. In the end, the deprecation of IPv6 site-local addresses made it impossible to standardize a mechanism that uses site-local addresses as well-known addresses. However, as of this writing, this mechanism is implemented in some operating systems and 3GPP UEs as a last resort of IPv6 DNS configuration.
注：IPv6工作组根据众所周知的站点本地地址制定了IPv6 DNS配置建议；它被视为3GPP UEs的一种可行机制，尽管尚未就此提案达成IETF共识。最后，IPv6站点本地地址的弃用使使用站点本地地址作为已知地址的机制无法标准化。然而，在撰写本文时，该机制在一些操作系统和3GPP ue中实现，作为IPv6 DNS配置的最后手段。
It is suggested that a lightweight, stateless DNS configuration mechanism be specified as soon as possible. From a 3GPP UE and network point of view, the Router Advertisement-based mechanism looks most promising. The sooner a light, stateless mechanism is specified, the sooner we can stop using well-known site-local addresses for IPv6 DNS configuration.
建议尽快指定轻量级、无状态DNS配置机制。从3GPP UE和网络的角度来看，基于路由器广告的机制看起来最有前途。越早指定轻型无状态机制，我们就越早停止使用众所周知的站点本地地址进行IPv6 DNS配置。
There are four deployment scenarios of interest in unmanaged networks [22]:
非托管网络中有四种重要的部署场景[22]：
1. A gateway that does not provide IPv6 at all,
1. 根本不提供IPv6的网关，
2. A dual-stack gateway connected to a dual-stack ISP,
2. 连接到双栈ISP的双栈网关，
3. A dual-stack gateway connected to an IPv4-only ISP, and
3. 连接到仅IPv4的ISP的双栈网关，以及
4. A gateway connected to an IPv6-only ISP.
4. 连接到仅限IPv6的ISP的网关。
In this case, the gateway does not provide IPv6; the ISP may or may not provide IPv6. Automatic or Configured tunnels are the recommended transition mechanisms for this scenario.
在这种情况下，网关不提供IPv6；ISP可能提供也可能不提供IPv6。对于此场景，建议使用自动或配置的隧道过渡机制。
The case where dual-stack hosts behind an NAT need access to an IPv6 RDNSS cannot be entirely ruled out. The DNS configuration mechanism has to work over the tunnel, and the underlying tunneling mechanism could implement NAT traversal. The tunnel server assumes the role of a relay (for both DHCP and well-known anycast addresses approaches).
不能完全排除NAT后面的双栈主机需要访问IPv6 RDNS的情况。DNS配置机制必须在隧道上工作，而底层隧道机制可以实现NAT遍历。隧道服务器承担中继的角色（对于DHCP和众所周知的选播地址方法）。
The RA-based mechanism is relatively straightforward in its operation, assuming the tunnel server is also the IPv6 router emitting RAs. The well-known anycast addresses approach also seems simple in operation across the tunnel, but the deployment model using well-known anycast addresses in a tunneled environment is unclear or not well understood.
基于RA的机制在操作上相对简单，假设隧道服务器也是发出RA的IPv6路由器。众所周知的选播地址方法在整个隧道中的操作似乎也很简单，但在隧道环境中使用众所周知的选播地址的部署模型不清楚或不清楚。
This is similar to a typical IPv4 home user scenario, where DNS configuration parameters are obtained using DHCP. The exception is that Stateless DHCPv6 is used, as opposed to the IPv4 scenario, where the DHCP server is stateful (it maintains the state for clients).
这类似于典型的IPv4家庭用户场景，其中使用DHCP获取DNS配置参数。例外情况是使用无状态DHCPv6，与IPv4场景相反，在IPv4场景中，DHCP服务器是有状态的（它维护客户端的状态）。
This is similar to Case B. If a gateway provides IPv6 connectivity by managing tunnels, then it is also supposed to provide access to an RDNSS. Like this, the tunnel for IPv6 connectivity originates from the dual-stack gateway instead of from the host.
这与案例B类似。如果网关通过管理隧道来提供IPv6连接，那么它还应该提供对RDNS的访问。与此类似，IPv6连接的隧道源于双堆栈网关，而不是主机。
This is similar to Case B.
这与案例B类似。
As security requirements depend solely on applications and differ from application to application, there can be no generic requirement defined at the IP or application layer for DNS.
由于安全要求完全取决于应用程序，并且不同的应用程序不同，因此在IP或应用程序层不能为DNS定义通用要求。
However, note that cryptographic security requires configured secret information and that full autoconfiguration and cryptographic security are mutually exclusive. People insisting on secure, full autoconfiguration will get false security, false autoconfiguration, or both.
但是，请注意，加密安全性需要配置的机密信息，并且完全自动配置和加密安全性是互斥的。坚持安全、完全自动配置的人将获得虚假安全、虚假自动配置，或者两者兼而有之。
In some deployment scenarios [17], where cryptographic security is required for applications, the secret information for the cryptographic security is preconfigured, through which application-specific configuration data, including those for DNS, can be securely configured. Note that if applications requiring cryptographic security depend on DNS, the applications also require cryptographic security to DNS. Therefore, the full autoconfiguration of DNS is not acceptable.
在某些部署场景[17]中，应用程序需要加密安全性，加密安全性的机密信息是预配置的，通过预配置，可以安全地配置特定于应用程序的配置数据，包括DNS的配置数据。请注意，如果需要加密安全性的应用程序依赖于DNS，则这些应用程序也需要DNS的加密安全性。因此，DNS的完全自动配置是不可接受的。
However, with full autoconfiguration, weaker but still reasonable security is being widely accepted and will continue to be acceptable.
然而，随着全自动配置，较弱但仍然合理的安全性正在被广泛接受，并将继续被接受。
That is, with full autoconfiguration, which means there is no cryptographic security for the autoconfiguration, it is already assumed that the local environment is secure enough that the information from the local autoconfiguration server has acceptable security even without cryptographic security. Thus, the communication between the local DNS client and local DNS server has acceptable security.
也就是说，对于完全自动配置（这意味着自动配置没有密码安全性），已经假设本地环境足够安全，即使没有密码安全性，来自本地自动配置服务器的信息也具有可接受的安全性。因此，本地DNS客户端和本地DNS服务器之间的通信具有可接受的安全性。
In autoconfiguring recursive servers, DNSSEC may be overkill, because DNSSEC [23]-[25] needs the configuration and reconfiguration of clients at root key roll-over [26][27]. Even if additional keys for secure key roll-over are added at the initial configuration, they are as vulnerable as the original keys to some forms of attack, such as social hacking. Another problem of using DNSSEC and autoconfiguration together is that DNSSEC requires secure time, which means secure communication with autoconfigured time servers, which requires configured secret information. Therefore, in order that the autoconfiguration may be secure, configured secret information is required.
在自动配置递归服务器时，DNSSEC可能有些过分，因为DNSSEC[23]-[25]需要在根密钥转移时配置和重新配置客户端[26][27]。即使在初始配置时添加了用于安全密钥滚动的附加密钥，它们也与原始密钥一样容易受到某些形式的攻击，例如社交黑客攻击。同时使用DNSSEC和自动配置的另一个问题是，DNSSEC需要安全时间，这意味着与自动配置的时间服务器进行安全通信，这需要配置的机密信息。因此，为了使自动配置安全，需要配置的机密信息。
If DNSSEC [23]-[25] is used and the signatures are verified on the client host, the misconfiguration of a DNS server may simply be denial of service. Also, if local routing environment is not reliable, clients may be directed to a false resolver with the same IP address as the true one.
如果使用DNSSEC[23]-[25]，并且在客户端主机上验证签名，则DNS服务器的错误配置可能只是拒绝服务。此外，如果本地路由环境不可靠，客户端可能会被定向到与真实解析程序具有相同IP地址的错误解析程序。
The security of RA option for RDNSS is the same as the ND protocol security [1][6]. The RA option does not add any new vulnerability.
RDNS的RA选项的安全性与ND协议安全性相同[1][6]。RA选项不会添加任何新漏洞。
Note 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, the 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 NA replies, answer RS or NS requests, etc. All of this can be done independently of implementing ND. Therefore, the RA option for RDNSS does not add to the vulnerability.
请注意，ND的漏洞并不更严重，而是连接到LAN的任何节点都可以独立于ND进行的攻击的子集。局域网上的恶意节点可以任意接收任何路由器MAC地址的数据包，并在L2报头中发送以路由器MAC地址作为源MAC地址的数据包。因此，L2交换机将发送到路由器的数据包发送到恶意节点。此外，此攻击还可以发送重定向，通知主机将其流量发送到其他地方。恶意节点可以发送未经请求的RA或NA回复、应答RS或NS请求等。所有这些都可以独立于实现ND来完成。因此，RDNS的RA选项不会增加漏洞。
Security issues regarding the ND protocol were discussed by the IETF SEND (Securing Neighbor Discovery) Working Group, and RFC 3971 for the ND security has been published [12].
IETF SEND（安全邻居发现）工作组讨论了与ND协议有关的安全问题，并发布了ND安全的RFC 3971[12]。
The DNS Recursive Name Server option may be used by an intruder DHCP server to cause DHCP clients to send DNS queries to an intruder DNS recursive name server [5]. The results of these misdirected DNS queries may be used to spoof DNS names.
入侵者DHCP服务器可使用DNS递归名称服务器选项，使DHCP客户端向入侵者DNS递归名称服务器发送DNS查询[5]。这些定向错误的DNS查询的结果可用于伪造DNS名称。
To avoid attacks through the DNS Recursive Name Server option, the DHCP client SHOULD require DHCP authentication (see "Authentication of DHCP messages" in RFC 3315 [3][13]) before installing a list of DNS recursive name servers obtained through authenticated DHCP.
为避免通过DNS递归名称服务器选项进行攻击，DHCP客户端在安装通过已验证DHCP获得的DNS递归名称服务器列表之前，应要求进行DHCP验证（请参阅RFC 3315[3][13]中的“DHCP消息验证”）。
The well-known anycast addresses approach is not a protocol, thus there is no need to secure the protocol itself.
众所周知的选播地址方法不是协议，因此不需要保护协议本身。
However, denial of service attacks on the DNS resolver system might be easier to achieve as the anycast addresses used are by definition well known.
但是，DNS解析程序系统上的拒绝服务攻击可能更容易实现，因为根据定义，所使用的选播地址是众所周知的。
Ralph Droms Cisco Systems, Inc. 1414 Massachusetts Ave. Boxboro, MA 01719 US
Ralph Droms Cisco Systems，Inc.美国马萨诸塞州Boxboro大道1414号，邮编01719
Phone: +1 978 936 1674
EMail: rdroms@cisco.com
Phone: +1 978 936 1674
EMail: rdroms@cisco.com
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 US
Robert M.Hinden诺基亚313飞兆半导体山景大道，美国加利福尼亚州94043
Phone: +1 650 625 2004
EMail: bob.hinden@nokia.com
Phone: +1 650 625 2004
EMail: bob.hinden@nokia.com
Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 US
Ted Lemon Nominum，Inc.美国加利福尼亚州红木市Charter Street 950号，邮编94043
EMail: Ted.Lemon@nominum.com
EMail: Ted.Lemon@nominum.com
Masataka Ohta Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku Tokyo 152-8552 Japan
大田正贺东京理工学院2-12-1，日本东京Meguro ku okayama 152-8552
Phone: +81 3 5734 3299
Fax: +81 3 5734 3299
EMail: mohta@necom830.hpcl.titech.ac.jp
Phone: +81 3 5734 3299
Fax: +81 3 5734 3299
EMail: mohta@necom830.hpcl.titech.ac.jp
Soohong Daniel Park Mobile Platform 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
Suresh Satapati Cisco Systems, Inc. San Jose, CA 95134 US
Suresh Satapati思科系统公司，加利福尼亚州圣何塞，美国95134
EMail: satapati@cisco.com
EMail: satapati@cisco.com
Juha Wiljakka Nokia Visiokatu 3 FIN-33720, TAMPERE Finland
Juha Wiljakka诺基亚Visiokatu 3 FIN-33720，芬兰坦佩雷
Phone: +358 7180 48372
EMail: juha.wiljakka@nokia.com
Phone: +358 7180 48372
EMail: juha.wiljakka@nokia.com
This document has greatly benefited from inputs by David Meyer, Rob Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. Also, Tony Bonanno proofread this document. The authors appreciate their contribution.
本文件得益于David Meyer、Rob Austein、Tatuya Jinmei、Pekka Savola、Tim Chown、Luc Beloil、Christian Huitema、Thomas Narten、Pascal Thubert和Greg Daley的投入。另外，托尼·博南诺校对了这份文件。作者感谢他们的贡献。
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[1] Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC24611998年12月。
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[2] Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年12月。
[3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[3] Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[4] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[4] Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[5] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[5] Droms，R.，“IPv6动态主机配置协议（DHCPv6）的DNS配置选项”，RFC 3646，2003年12月。
[6] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Option for DNS Configuration", Work in Progress, September 2005.
[6] Jeong，J.，Park，S.，Beloeil，L.，和S.Madanapalli，“DNS配置的IPv6路由器广告选项”，正在进行的工作，2005年9月。
[7] Ohta, M., "Preconfigured DNS Server Addresses", Work in Progress, February 2004.
[7] Ohta，M.，“预先配置的DNS服务器地址”，正在进行的工作，2004年2月。
[8] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4242, November 2005.
[8] Venaas，S.，Chown，T.，和B.Volz，“IPv6动态主机配置协议（DHCPv6）的信息刷新时间选项”，RFC 42422005年11月。
[9] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[9] 帕特里奇，C.，门德斯，T.，和W.米利肯，“主持任意广播服务”，RFC15461993年11月。
[10] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[10] Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[11] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[11] Lind，M.，Ksinant，V.，Park，S.，Baudot，A.，和P.Savola，“将IPv6引入ISP网络的场景和分析”，RFC 40292005年3月。
[12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[12] Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[13] Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[14] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[14] Bound，J.，“IPv6企业网络场景”，RFC 4057，2005年6月。
[15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[15] Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[16] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[16] Wasserman，M.，“第三代合作伙伴项目（3GPP）标准中IPv6的建议”，RFC 3314，2002年9月。
[17] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC 3574, August 2003.
[17] Soininen，J.，“3GPP网络的过渡场景”，RFC 3574，2003年8月。
[18] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[18] Wiljakka，J.，“第三代合作伙伴计划（3GPP）网络中IPv6过渡的分析”，RFC 4215，2005年10月。
[19] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); Service description; Stage 2 (Release 5)", December 2002.
[19] 3GPP TS 23.060 V5.4.0，“通用分组无线业务（GPRS）；业务描述；第2阶段（第5版）”，2002年12月。
[20] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 5)", June 2003.
[20] 3GPP TS 24.008 V5.8.0，“移动无线电接口第3层规范；核心网络协议；第3阶段（第5版）”，2003年6月。
[21] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.
[21] Chown，T.，Venaas，S.，和A.Vijayabhaskar，“IPv6无状态动态主机配置协议（DHCPv6）的重新编号要求”，RFC 4076，2005年5月。
[22] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April 2004.
[22] Huitema，C.，Austein，R.，Satapati，S.，和R.van der Pol，“非托管网络IPv6过渡场景”，RFC 37502004年4月。
[23] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[23] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[24] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[24] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[25] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[25] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[26] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", Work in Progress, October 2005.
[26] Kolkman，O.和R.Gieben，“DNSSEC运营实践”，正在进行的工作，2005年10月。
[27] Guette, G. and O. Courtay, "Requirements for Automated Key Rollover in DNSSEC", Work in Progress, January 2005.
[27] Guette，G.和O.Courtay，“DNSSEC中自动钥匙翻转的要求”，正在进行的工作，2005年1月。
[28] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M and O Flags of IPv6 Router Advertisement", Work in Progress, March 2005.
[28] Park，S.，Madanapalli，S.，和T.Jinmei，“关于IPv6路由器广告M和O标志的考虑”，正在进行的工作，2005年3月。
Author's Address
作者地址
Jaehoon Paul Jeong (editor) ETRI/Department of Computer Science and Engineering University of Minnesota 117 Pleasant Street SE Minneapolis, MN 55455 US
Jaehoon Paul Jeong（编辑）ETRIE /明尼苏达大学计算机科学与工程系，明尼阿波利斯117美林街，MN 55455美国
Phone: +1 651 587 7774
Fax: +1 612 625 2002
EMail: jjeong@cs.umn.edu
URI: http://www.cs.umn.edu/~jjeong/
Phone: +1 651 587 7774
Fax: +1 612 625 2002
EMail: jjeong@cs.umn.edu
URI: http://www.cs.umn.edu/~jjeong/
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。