Network Working Group S. Venaas
Request for Comments: 4242 UNINETT
Category: Standards Track T. Chown
University of Southampton
B. Volz
Cisco Systems, Inc.
November 2005
Network Working Group S. Venaas
Request for Comments: 4242 UNINETT
Category: Standards Track T. Chown
University of Southampton
B. Volz
Cisco Systems, Inc.
November 2005
Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
IPv6（DHCPv6）动态主机配置协议的信息刷新时间选项
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration.
本文档描述了IPv6动态主机配置协议（DHCPv6）选项，用于指定刷新从DHCPv6检索到的信息之前客户端应等待的时间上限。它与无状态DHCPv6一起使用，因为没有地址或其他具有生存期的实体可以告诉客户端何时联系DHCPv6服务器以刷新其配置。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Information Refresh Time Option Definition ......................2
3.1. Constants ..................................................3
3.2. Client Behaviour ...........................................3
3.3. Server Behaviour ...........................................4
3.4. Option Format ..............................................5
4. IANA Considerations .............................................5
5. Acknowledgements ................................................5
6. Security Considerations .........................................5
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Information Refresh Time Option Definition ......................2
3.1. Constants ..................................................3
3.2. Client Behaviour ...........................................3
3.3. Server Behaviour ...........................................4
3.4. Option Format ..............................................5
4. IANA Considerations .............................................5
5. Acknowledgements ................................................5
6. Security Considerations .........................................5
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
DHCPv6 [RFC3315] specifies stateful autoconfiguration for IPv6 hosts. However, many hosts will use stateless autoconfiguration as specified in [RFC2462] for address assignment, and use DHCPv6 only for other configuration data; see [RFC3736]. This other configuration data will typically have no associated lifetime, hence there may be no information telling a host when to refresh its DHCPv6 configuration data. Therefore, an option that can be used from server to client to inform the client when it should refresh the other configuration data is needed.
DHCPv6[RFC3315]指定IPv6主机的有状态自动配置。但是，许多主机将使用[RFC2462]中指定的无状态自动配置进行地址分配，而DHCPv6仅用于其他配置数据；参见[RFC3736]。此其他配置数据通常没有关联的生存期，因此可能没有信息告诉主机何时刷新其DHCPv6配置数据。因此，需要一个选项，可以在服务器到客户端之间使用该选项来通知客户端何时应该刷新其他配置数据。
This option is useful in many situations:
此选项在许多情况下都很有用：
- Unstable environments where unexpected changes are likely to occur.
- 可能发生意外变化的不稳定环境。
- For planned changes, including renumbering. An administrator can gradually decrease the time as the event nears.
- 用于计划的更改，包括重新编号。随着事件的临近，管理员可以逐渐缩短时间。
- Limit the amount of time before new services or servers are available to the client, such as the addition of a new NTP server or a change of address of a DNS server. See [RFC4076].
- 限制客户端可以使用新服务或服务器之前的时间，例如添加新的NTP服务器或更改DNS服务器的地址。参见[RFC4076]。
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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
The information refresh time option specifies an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is only used in Reply messages in response to Information-Request messages. In other messages there will usually be other options that indicate when the client should contact the server, e.g., addresses with lifetimes.
information refresh time选项指定客户端在刷新从DHCPv6检索的信息之前应等待的时间上限。它仅用于响应信息请求消息的回复消息。在其他消息中，通常会有其他选项指示客户端何时应与服务器联系，例如，具有生存期的地址。
Note that it is only an upper bound. If the client has any reason to make a DHCPv6 request before the refresh time expires, it should attempt to refresh all the data.
请注意，它只是一个上限。如果客户端有任何理由在刷新时间到期之前发出DHCPv6请求，它应该尝试刷新所有数据。
A client may contact the server before the refresh time expires. Reasons it may do this include the need for additional configuration
客户端可能会在刷新时间到期之前联系服务器。这样做的原因包括需要额外的配置
parameters (such as by an application), a new IPv6 prefix announced by a router, or that it has an indication that it may have moved to a new link.
参数（例如由应用程序）、路由器宣布的新IPv6前缀，或者它有可能已移动到新链路的指示。
The refresh time option specifies a common refresh time for all the data. It doesn't make sense to have different refresh time values for different data, since when the client has reason to refresh some of its data, it should also refresh the remaining data. Because of this, the option must only appear in the options area of the Reply message.
刷新时间选项为所有数据指定公共刷新时间。对于不同的数据使用不同的刷新时间值是没有意义的，因为当客户端有理由刷新某些数据时，它还应该刷新其余的数据。因此，该选项只能出现在回复消息的选项区域中。
The expiry of the refresh time in itself does not in any way mean that the client should remove the data. The client should keep its current data while attempting to refresh it. However, the client is free to fall back to mechanisms other than DHCPv6 if it cannot refresh the data within a reasonable amount of time.
刷新时间的到期本身并不意味着客户端应该删除数据。客户端应在尝试刷新数据时保留其当前数据。但是，如果客户机无法在合理的时间内刷新数据，则可以自由地使用DHCPv6以外的机制。
When a client receives a Reply to an Information-Request that contains configuration information, it should install that new configuration information after removing any previously received configuration information. It should also remove information that is missing from the new information set, e.g., an option might be left out or contain only a subset of what it did previously.
当客户端收到对包含配置信息的信息请求的答复时，它应该在删除以前收到的任何配置信息后安装新的配置信息。它还应删除新信息集中缺少的信息，例如，选项可能被遗漏或仅包含其先前所做操作的子集。
We define two constants for use by the protocol. How they are used is specified in the sections below.
我们定义了两个常量供协议使用。如何使用它们在以下章节中有详细说明。
IRT_DEFAULT 86400 In some cases the client uses a default refresh time IRT_DEFAULT. The recommended value for IRT_DEFAULT is 86400 (24 hours). The client implementation SHOULD allow for this value to be configurable.
IRT_DEFAULT 86400在某些情况下，客户端使用默认刷新时间IRT_DEFAULT。IRT_默认值的建议值为86400（24小时）。客户端实现应允许配置此值。
IRT_MINIMUM 600 This defines a minimum value for the refresh time.
IRT_MINIMUM 600这定义了刷新时间的最小值。
A client MUST request this option in the Option Request Option (ORO) when sending Information-Request messages to the DHCPv6 server. A client MUST NOT request this option in the ORO in any other messages.
向DHCPv6服务器发送信息请求消息时，客户端必须在选项请求选项（ORO）中请求此选项。客户端不得在任何其他消息中请求ORO中的此选项。
If the Reply to an Information-Request message does not contain this option, the client MUST behave as if the option with value IRT_DEFAULT was provided.
如果对信息请求消息的回复不包含此选项，则客户端必须表现为提供了值为IRT_DEFAULT的选项。
A client MUST use the refresh time IRT_MINIMUM if it receives the option with a value less than IRT_MINIMUM.
如果客户端收到的选项值小于IRT_最小值，则必须使用刷新时间IRT_最小值。
As per section 5.6 of [RFC3315], the value 0xffffffff is taken to mean "infinity" and implies that the client should not refresh its configuration data without some other trigger (such as detecting movement to a new link).
根据[RFC3315]第5.6节，值0xFFFFFF表示“无穷大”，并表示客户端不应在没有其他触发（如检测到新链路的移动）的情况下刷新其配置数据。
If a client contacts the server to obtain new data or refresh some existing data before the refresh time expires, then it SHOULD also refresh all data covered by this option.
如果客户机在刷新时间到期之前联系服务器以获取新数据或刷新某些现有数据，则它还应刷新此选项涵盖的所有数据。
When the client detects that the refresh time has expired, it SHOULD try to update its configuration data by sending an Information-Request as specified in section 18.1.5 of [RFC3315], except that the client MUST delay sending the first Information-Request by a random amount of time between 0 and INF_MAX_DELAY.
当客户机检测到刷新时间已过期时，应尝试通过发送[RFC3315]第18.1.5节中规定的信息请求来更新其配置数据，但客户机必须将发送第一个信息请求的时间延迟0到INF_MAX_delay之间的随机时间量。
A client MAY have a maximum value for the refresh time, where that value is used whenever the client receives this option with a value higher than the maximum. This also means that the maximum value is used when the received value is "infinity". A maximum value might make the client less vulnerable to attacks based on forged DHCP messages. Without a maximum value, a client may be made to use wrong information for a possibly infinite period of time. There may however be reasons for having a very long refresh time, so it may be useful for this maximum value to be configurable.
客户机可能具有刷新时间的最大值，每当客户机接收到该选项的值高于最大值时，就会使用该值。这也意味着，当接收值为“无穷大”时，使用最大值。最大值可能使客户端不易受到基于伪造DHCP消息的攻击。如果没有最大值，客户可能会在无限的时间内使用错误的信息。但是，刷新时间很长可能是有原因的，因此可配置此最大值可能很有用。
A server sending a Reply to an Information-Request message SHOULD include this option if it is requested in the ORO of the Information-Request.
如果在信息请求的ORO中请求回复，则发送回复信息请求消息的服务器应包括此选项。
The option value MUST NOT be smaller than IRT_MINIMUM. The server SHOULD give a warning if it is configured with a smaller value.
选项值不得小于IRT_最小值。如果服务器配置了较小的值，则应发出警告。
The option MUST only appear in the options area of Reply messages.
该选项只能出现在回复消息的选项区域中。
The format of the information refresh time option is:
信息刷新时间选项的格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| information-refresh-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| information-refresh-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_INFORMATION_REFRESH_TIME (32)
选项代码选项信息刷新时间（32）
option-len 4
选项len 4
information-refresh-time Time duration relative to the current time, expressed in units of seconds
信息刷新时间相对于当前时间的持续时间，以秒为单位
The IANA has assigned an option code for the information refresh time option from the DHCPv6 option-code space [RFC3315].
IANA已从DHCPv6选项代码空间[RFC3315]为信息刷新时间选项分配了选项代码。
The authors thank Mat Ford, Tatuya Jinmei, Ted Lemon, Thomas Narten, Joe Quanaim, and A.K. Vijayabhaskar for valuable discussions and comments.
作者感谢Mat Ford、Tatuya Jinmei、Ted Lemon、Thomas Narten、Joe Quanaim和A.K.Vijayabhaskar的宝贵讨论和评论。
Section 23 of [RFC3315] outlines the DHCPv6 security considerations. This option does not change these in any significant way. An attacker could send faked Reply messages with a low information refresh time value, which would trigger use of IRT_MINIMUM to minimize this threat. Another attack might be to send a very large value, to make the client use forged information for a long period of time. A possible maximum limit at the client is suggested, which would reduce this problem.
[RFC3315]第23节概述了DHCPv6安全注意事项。此选项不会以任何显著方式改变这些。攻击者可以发送具有较低信息刷新时间值的伪造回复消息，这将触发使用IRT_MINIMUM来最小化此威胁。另一种攻击可能是发送非常大的值，使客户端长期使用伪造信息。建议在客户端设置一个可能的最大限制，这将减少此问题。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，1998年12月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[RFC4076] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.
[RFC4076]Chown，T.，Venaas，S.，和A.Vijayabhaskar，“IPv6（DHCPv6）无状态动态主机配置协议的重新编号要求”，RFC 4076，2005年5月。
Authors' Addresses
作者地址
Stig Venaas UNINETT Trondheim NO 7465 Norway
挪威第7465号特隆赫姆施蒂格·维纳斯酒店
EMail: venaas@uninett.no
EMail: venaas@uninett.no
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
Bernard Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
伯纳德·沃兹思科系统公司，美国马萨诸塞州博克斯伯勒马萨诸塞大道1414号，邮编01719
EMail: volz@cisco.com
EMail: volz@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编辑功能的资金目前由互联网协会提供。