Network Working Group T. Chown
Request for Comments: 4076 University of Southampton
Category: Informational S. Venaas
UNINETT
A. Vijayabhaskar
Cisco Systems (India) Private Limited
May 2005
Network Working Group T. Chown
Request for Comments: 4076 University of Southampton
Category: Informational S. Venaas
UNINETT
A. Vijayabhaskar
Cisco Systems (India) Private Limited
May 2005
Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
IPv6（DHCPv6）无状态动态主机配置协议的重新编号要求
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document.
使用无状态地址自动配置的IPv6主机能够自动配置其IPv6地址和默认路由器设置。但是，其他设置不可用。如果这些主机希望自动配置其DNS、NTP或其他特定设置，则可以使用IPv6动态主机配置协议（DHCPv6）的无状态变体。这种无状态地址自动配置和无状态DHCPv6的组合在IPv6网络中非常常用。但是，使用此组合的主机目前无法通知无状态DHCPv6选项设置的更改；e、 例如，添加新的NTP服务器地址、更改DNS搜索路径或对整个站点重新编号。本文件以问题陈述的形式呈现，应在后续文件中提出解决方案。
Table of Contents
目录
1. Introduction ...................................................2
2. Problem Statement ..............................................3
3. Renumbering Scenarios ..........................................3
3.1. Site Renumbering .........................................4
3.2. Changes to a DHCPv6-assigned Setting .....................4
4. Renumbering Requirements .......................................4
5. Considerations in Choosing a Solution ..........................4
6. Solution Space .................................................5
7. Summary ........................................................5
8. Security Considerations ........................................6
9. Acknowledgements ...............................................6
10. References .....................................................6
10.1. Normative References .....................................6
10.2. Informative References ...................................6
1. Introduction ...................................................2
2. Problem Statement ..............................................3
3. Renumbering Scenarios ..........................................3
3.1. Site Renumbering .........................................4
3.2. Changes to a DHCPv6-assigned Setting .....................4
4. Renumbering Requirements .......................................4
5. Considerations in Choosing a Solution ..........................4
6. Solution Space .................................................5
7. Summary ........................................................5
8. Security Considerations ........................................6
9. Acknowledgements ...............................................6
10. References .....................................................6
10.1. Normative References .....................................6
10.2. Informative References ...................................6
IPv6 hosts using Stateless Address Autoconfiguration [2] are able to configure their IPv6 address and default router settings automatically. Although Stateless Address Autoconfiguration for IPv6 allows automatic configuration of these settings, it does not provide a mechanism for additional non IP-address settings to be configured automatically.
使用无状态地址自动配置[2]的IPv6主机能够自动配置其IPv6地址和默认路由器设置。尽管IPv6的无状态地址自动配置允许自动配置这些设置，但它不提供自动配置其他非IP地址设置的机制。
The full version of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [3] is designed to provide both stateful address assignment to IPv6 hosts, as well as additional (non IP-address) configuration including DNS, NTP, and other specific settings. A full stateful DHCPv6 server allocates the addresses and maintains the clients' bindings to keep track of client leases.
IPv6动态主机配置协议（DHCPv6）[3]的完整版本旨在为IPv6主机提供有状态地址分配，以及其他（非IP地址）配置，包括DNS、NTP和其他特定设置。一个完全有状态的DHCPv6服务器分配地址并维护客户端的绑定，以跟踪客户端租约。
If hosts using Stateless Address Autoconfiguration for IPv6 wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant [4] of DHCPv6 could be used. This variant is more lightweight. It does not do address assignment; instead, it only provides additional configuration parameters, such as DNS resolver addresses. It does not maintain dynamic state about the information assigned to clients, and therefore there is no need to maintain dynamic per-client state on the server.
如果使用IPv6无状态地址自动配置的主机希望自动配置其DNS、NTP或其他特定设置，则可以使用DHCPv6的无状态变体[4]。这种变体更轻。它不进行地址分配；相反，它只提供额外的配置参数，例如DNS解析程序地址。它不维护分配给客户机的信息的动态状态，因此不需要在服务器上维护每个客户机的动态状态。
This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks.
这种无状态地址自动配置和无状态DHCPv6的组合在IPv6网络中非常常用。
A problem, however, lies in the ability, or lack of ability, of clients using this combination to be informed of (or to deduce) changes in DHCPv6-assigned settings.
然而，问题在于使用此组合的客户机有能力（或缺乏能力）获知（或推断）DHCPv6分配设置中的更改。
While a DHCPv6 server unicasts Reconfigure messages to individual clients to trigger them to initiate Information-request/reply configuration exchanges to update their configuration settings, the stateless variant of DHCPv6 cannot use the Reconfigure mechanism because it does not maintain a list of IP addresses (leases) to send the unicast messages to. Note that in DHCPv6, Reconfigure messages must be unicast; multicast is not allowed.
当DHCPv6服务器单播将消息重新配置到各个客户端以触发它们启动信息请求/应答配置交换以更新其配置设置时，DHCPv6的无状态变体无法使用重新配置机制，因为它不维护IP地址（租约）列表将单播消息发送到。注意，在DHCPv6中，重新配置消息必须是单播的；不允许多播。
Thus, events including the following cannot be handled:
因此，无法处理包括以下内容的事件：
o Full site renumbering
o 全站重新编号
o DNS server change of address
o DNS服务器地址更改
o NTP server change of address
o NTP服务器地址更改
o A change in DNS search paths
o DNS搜索路径中的更改
It would be highly desirable that a host using the combination of Stateless Address Autoconfiguration and stateless DHCPv6 could handle a renumbering or reconfiguration event, whether planned or unplanned by the network administrator.
非常希望结合使用无状态地址自动配置和无状态DHCPv6的主机能够处理重新编号或重新配置事件，无论是由网络管理员计划的还是非计划的。
Note that the scope of the problem could extend beyond Stateless DHCPv6, since only IP address options have a lifetime; i.e., there is no mechanism even in the full DHCPv6 that "expires" old information or otherwise forces a client to recheck that new/updated information is available. However, with full DHCPv6, a node may learn of updates to non-address options when renewing its address lease.
请注意，问题的范围可能超出无状态DHCPv6，因为只有IP地址选项具有生存期；i、 例如，即使在完整的DHCPv6中，也没有机制“过期”旧信息或以其他方式强制客户机重新检查新的/更新的信息是否可用。但是，使用完整的DHCPv6，节点在续订其地址租约时可能会了解到对非地址选项的更新。
There are two main scenarios for changes to DHCPv6-assigned settings that would require the client to initiate an Information-request/ reply exchange to update the configuration.
更改DHCPv6分配的设置有两种主要方案，需要客户端启动信息请求/回复交换以更新配置。
One of the fundamental principles of IPv6 is that sites receive their IPv6 address allocations from an ISP using provider-assigned (PA) address space. There is currently no provider-independent (PI) address space in IPv6. Therefore, a site changing its ISP must renumber its network. Any such site renumbering will require hosts to reconfigure both their own address and default router settings and their stateless DHCPv6-assigned settings.
IPv6的基本原则之一是，站点使用提供商分配（PA）的地址空间从ISP接收其IPv6地址分配。IPv6中当前没有独立于提供程序（PI）的地址空间。因此，更改ISP的站点必须对其网络重新编号。任何此类站点重新编号都需要主机重新配置自己的地址和默认路由器设置以及无状态DHCPv6分配的设置。
An administrator may need to change one or more stateless DHCPv6-assigned settings; e.g., an NTP server, DNS server, or the DNS search path. This may be required if a new, additional DNS server is brought online and is moved to a new network (prefix), or if an existing server is decommissioned or known to be unavailable.
管理员可能需要更改一个或多个无状态DHCPv6分配的设置；e、 例如，NTP服务器、DNS服务器或DNS搜索路径。如果新的附加DNS服务器联机并移动到新网络（前缀），或者如果现有服务器已停用或已知不可用，则可能需要执行此操作。
Ideally, any of the above scenarios should be handled automatically by the hosts on the network. For this to be realised, a method is required whereby the hosts are informed that they should request new stateless DHCPv6-assigned setting information.
理想情况下，上述任何场景都应该由网络上的主机自动处理。为了实现这一点，需要一种方法，通过该方法，主机将被告知应该请求新的无状态DHCPv6分配的设置信息。
The solution to the problem may depend on whether the renumbering or configuration change is planned or unplanned, from the perspective of the network administrator. There is already work underway toward understanding the planned renumbering [5] scenario for IPv6 networks. However, there is currently no mechanism in stateless DHCPv6 for handling planned renumbering events.
从网络管理员的角度来看，问题的解决方案可能取决于重新编号或配置更改是计划内的还是计划外的。在理解IPv6网络计划中的重新编号[5]方案方面，已经有工作在进行中。但是，目前在无状态DHCPv6中没有处理计划重新编号事件的机制。
A number of considerations could be listed for a desirable solution:
对于理想的解决方案，可以列出一些考虑因素：
o The solution should support planned renumbering; it is desirable that it also supports unplanned renumbering.
o 解决方案应支持有计划的重新编号；它还支持计划外的重新编号，这是可取的。
o Security is important. No new security concerns should be introduced to Stateless DHCPv6 by the solution.
o 安全很重要。解决方案不应向无状态DHCPv6引入新的安全问题。
o It must be possible to update options, even if the network is not renumbered.
o 即使网络未重新编号，也必须能够更新选项。
o It is desirable to maintain the "stateless" property; i.e., no per-client state should need to be kept in the server.
o 维持“无国籍”财产是可取的；i、 例如，不需要在服务器中保留每个客户端的状态。
Solutions should be designed and presented in a separate document. An initial brief set of candidate solutions might include the following:
应在单独的文件中设计和提出解决方案。候选解决方案的初始简短集合可能包括以下内容：
o Add a Reconfigure message mechanism that would work in the stateless DHCPv6 environment. This could enable planned or unplanned events, but may require a multicast mechanism in order to be realised.
o 添加可在无状态DHCPv6环境中工作的重新配置消息机制。这可能会启用计划内或计划外事件，但可能需要多播机制才能实现。
o Convey a valid lifetime timer to clients for stateless DHCPv6- assigned settings. This could primarily enable planned events, but with a small time-out it could handle unplanned events to some extent at the expense of the additional request traffic. The selection of recommended lifetime values/ranges would be the subject of future work.
o 为无状态DHCPv6分配的设置向客户端传递有效的生存期计时器。这可能主要是启用计划事件，但通过一个小的超时，它可以在一定程度上处理计划外事件，而以牺牲额外的请求流量为代价。建议寿命值/范围的选择将是今后工作的主题。
o Use some form of Router Advertisement (RA) [1] as a hint to request new stateless DHCPv6-assigned settings. Using only an observed new RA prefix as a hint to re-request settings would not handle changes that are purely to NTP, DNS, or other options. Other possible means of detection of network (re)attachment could also be used as cues (e.g., see Goals of Detecting Network Attachment (DNA) in IPv6 [6]).
o 使用某种形式的路由器公告（RA）[1]作为提示，请求新的无状态DHCPv6分配的设置。仅使用观察到的新RA前缀作为重新请求设置的提示不会处理纯粹针对NTP、DNS或其他选项的更改。其他可能的网络（重新）连接检测手段也可用作线索（例如，参见IPv6中检测网络连接（DNA）的目标[6]）。
o Change the semantics of the 'O' flag in RAs [2] so that toggling its value may trigger an Information-request message.
o 更改RAs[2]中“O”标志的语义，以便切换其值可能触发信息请求消息。
There will also be conditions under which a client should send an Information-request, such as reconnection to a link. Recommendations for these cases are outside the scope of this document, but we expect ongoing work in the DNA WG (as scoped in Goals of Detecting Network Attachment (DNA) in IPv6 [6]) to yield recommendations.
在某些情况下，客户端应该发送信息请求，例如重新连接到链接。针对这些情况的建议不在本文件的范围内，但我们希望DNA工作组正在进行的工作（如IPv6中检测网络连接（DNA）的目标[6]所述）能够产生建议。
This document presents a problem statement for how IPv6 hosts that use the combination of Stateless Address Autoconfiguration and stateless DHCPv6 may be informed of renumbering events or other changes to the settings that they originally learned through stateless DHCPv6. A short list of candidate solutions is presented, which the authors hope will be expanded upon in subsequent documents.
本文档提供了一个问题陈述，说明了如何通知使用无状态地址自动配置和无状态DHCPv6组合的IPv6主机重新编号事件或其最初通过无状态DHCPv6了解到的其他设置更改。给出了候选解决方案的简短列表，作者希望在后续文档中对此进行扩展。
There are no security considerations in this problem statement per se. However, whatever mechanism is designed or chosen to address this problem should avoid introducing new security concerns for (stateless) DHCPv6.
这个问题陈述本身没有安全考虑。然而，无论设计或选择何种机制来解决这个问题，都应该避免为（无状态）DHCPv6引入新的安全问题。
The issues of maintaining appropriate security through a renumbering event are outside the scope of this document (if specific servers within the network are being added or removed, firewall configurations and ACLs, for example, will need to reflect this). However, this is an important area for further work.
通过重新编号事件维护适当安全性的问题超出了本文档的范围（例如，如果正在添加或删除网络中的特定服务器，则防火墙配置和ACL需要反映这一点）。然而，这是进一步工作的一个重要领域。
The authors would like to thank Ralph Droms, Bernie Volz, and other individuals on the DHC mail list for their comments on this document, as well as colleagues on the 6NET project. We also thank the review comments, particularly those from Thomas Narten.
作者要感谢拉尔夫·德罗姆斯、伯尼·沃尔兹和DHC邮件列表上的其他个人对本文件的评论，以及6NET项目的同事。我们还感谢审查意见，特别是托马斯·纳滕的意见。
[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] Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", Work in Progress, July 2004.
[5] Baker，F.，Lear，E.和R.Droms，“在没有国旗日的情况下重新编号IPv6网络的程序”，正在进行的工作，2004年7月。
[6] Choi, J., "Goals of Detecting Network Attachment (DNA) in IPv6", Work in Progress, October 2004.
[6] Choi，J.，“IPv6中检测网络连接（DNA）的目标”，进展中的工作，2004年10月。
Authors' Addresses
作者地址
Tim Chown University of Southampton School of Electronics and Computer Science Southampton, Hampshire SO17 1BJ United Kingdom
提姆南安普敦大学南安普顿电子与计算机科学学院，英国
EMail: tjc@ecs.soton.ac.uk
EMail: tjc@ecs.soton.ac.uk
Stig Venaas UNINETT Trondheim NO 7465 Norway
挪威第7465号特隆赫姆施蒂格·维纳斯酒店
EMail: venaas@uninett.no
EMail: venaas@uninett.no
Vijayabhaskar A Kalusivalingam Cisco Systems (India) Private Limited 9, Brunton Road Bangalore 560025 India
印度班加罗尔布伦顿路9号Vijayabhaskar A Kalusialingam思科系统（印度）私人有限公司560025
EMail: vibhaska@cisco.com
EMail: vibhaska@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。