Internet Engineering Task Force (IETF) T. Li
Request for Comments: 8168 C. Liu
Category: Standards Track Y. Cui
ISSN: 2070-1721 Tsinghua University
May 2017
Internet Engineering Task Force (IETF) T. Li
Request for Comments: 8168 C. Liu
Category: Standards Track Y. Cui
ISSN: 2070-1721 Tsinghua University
May 2017
DHCPv6 Prefix-Length Hint Issues
DHCPv6前缀长度提示问题
Abstract
摘要
DHCPv6 Prefix Delegation allows a client to include a prefix-length hint value in the IA_PD option to indicate a preference for the size of the prefix to be delegated, but it is unclear about how the client and server should act in different situations involving the prefix-length hint. This document provides a summary of the existing problems with the prefix-length hint and guidance on what the client and server could do in different situations.
DHCPv6前缀委派允许客户端在IA_PD选项中包含前缀长度提示值，以指示要委派的前缀大小的首选项，但不清楚客户端和服务器在涉及前缀长度提示的不同情况下应如何操作。本文档总结了前缀长度提示存在的问题，并提供了客户机和服务器在不同情况下可以做什么的指导。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8168.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8168.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Problem Description and Proposed Solutions . . . . . . . . . 3
3.1. Creation of Solicit Message . . . . . . . . . . . . . . . 3
3.2. Receipt of Solicit Message . . . . . . . . . . . . . . . 4
3.3. Receipt of Advertise Message . . . . . . . . . . . . . . 5
3.4. Creation of Renew/Rebind Message . . . . . . . . . . . . 6
3.5. Receipt of Renew/Rebind Message . . . . . . . . . . . . . 6
3.6. General Recommendation . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Normative References . . . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Problem Description and Proposed Solutions . . . . . . . . . 3
3.1. Creation of Solicit Message . . . . . . . . . . . . . . . 3
3.2. Receipt of Solicit Message . . . . . . . . . . . . . . . 4
3.3. Receipt of Advertise Message . . . . . . . . . . . . . . 5
3.4. Creation of Renew/Rebind Message . . . . . . . . . . . . 6
3.5. Receipt of Renew/Rebind Message . . . . . . . . . . . . . 6
3.6. General Recommendation . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Normative References . . . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
DHCPv6 Prefix Delegation [RFC3633] allows a client to include a prefix-length hint value in the message sent to the server to indicate a preference for the size of the prefix to be delegated. A prefix-length hint is communicated by a client to the server by including an IA_PD Prefix Option (IAPREFIX option), encapsulated in an IA_PD option, with the "IPv6 prefix" field set to zero and the "prefix-length" field set to a non-zero value. The servers are free to ignore the prefix-length hint values depending on server policy. However, some clients may not be able to function (or only in a degraded state) when they're provided with a prefix whose length is different from what they requested. For example, if the client is asking for a /56 and the server returns a /64, the functionality of the client might be limited because it might not be able to split the prefix for all its interfaces. For other hints, such as requesting for an explicit address, this might be less critical, as it just helps a client that wishes to continue using what it used last time. The prefix-length hint directly impacts the operational capability of the client; thus, it should be given more consideration.
DHCPv6前缀委派[RFC3633]允许客户端在发送到服务器的消息中包含前缀长度提示值，以指示要委派的前缀大小的首选项。前缀长度提示由客户端通过包括IA_PD前缀选项（IAPREFIX选项）传递给服务器，该选项封装在IA_PD选项中，“IPv6前缀”字段设置为零，“前缀长度”字段设置为非零值。根据服务器策略，服务器可以自由忽略前缀长度提示值。但是，如果为某些客户端提供了长度不同于其请求长度的前缀，则它们可能无法运行（或仅在降级状态下）。例如，如果客户端请求a/56，而服务器返回a/64，则客户端的功能可能会受到限制，因为它可能无法拆分其所有接口的前缀。对于其他提示，例如请求显式地址，这可能不那么重要，因为它只会帮助希望继续使用上次使用的内容的客户机。前缀长度提示直接影响客户端的操作能力；因此，应该给予更多的考虑。
[RFC3633] is unclear about how the client and server should act in different situations involving the prefix-length hint. From the client perspective, it should be able to use the prefix-length hint to signal to the server its real-time need and should be able to handle prefixes with lengths different from the prefix-length hint. This document provides guidance on what a client should do in different situations to help it operate properly. From the server perspective, the server is free to ignore the prefix-length hints depending on server policy; however, in cases where the server has a
[RFC3633]不清楚客户端和服务器在涉及前缀长度提示的不同情况下应如何操作。从客户端的角度来看，它应该能够使用前缀长度提示向服务器发出实时需要的信号，并且应该能够处理长度不同于前缀长度提示的前缀。本文件提供了客户在不同情况下应如何帮助其正常运行的指导。从服务器的角度来看，服务器可以根据服务器策略自由忽略前缀长度提示；但是，如果服务器具有
policy for considering the hint, this document provides guidance on how the prefix-length hint should be handled by the server in different situations.
考虑提示的策略，本文档提供了在不同情况下服务器应如何处理前缀长度提示的指导。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Problem:
问题:
The Solicit message allows a client to ask servers for prefixes and other configuration parameters. The client might want a different prefix length due to configuration changes, or it might just want the same prefix again after reboot. The client might also prefer a prefix of a specific length in case the requested prefix is not available. The server could decide whether to provide the client with the preferred prefix depending on server policy, but the client should be able to signal to the server its real-time need.
请求消息允许客户端向服务器请求前缀和其他配置参数。由于配置更改，客户端可能需要不同的前缀长度，或者可能只是在重新启动后需要相同的前缀。在请求的前缀不可用的情况下，客户机可能还希望使用特定长度的前缀。服务器可以根据服务器策略决定是否向客户机提供首选前缀，但客户机应该能够向服务器发出实时需要的信号。
The server usually has a record of the prefix it gave to the client during its most recent interaction. The best way to assure a completely new delegated prefix is to send a new IAID (Identity Association IDentifier) in the IA_PD (Identity Association for Prefix Delegation). However, this would require the client device to have persistent storage, because rebooting the device would cause the client to use the original IAID in the IA_PD.
服务器通常有一个在其最近的交互期间提供给客户端的前缀的记录。确保全新委派前缀的最佳方法是在IA_PD（前缀委派的标识关联）中发送新的IAID（标识关联标识符）。但是，这将要求客户机设备具有持久性存储，因为重新启动设备将导致客户机使用IA_PD中的原始IAID。
Solution:
解决方案：
When the client prefers a prefix of a specific length from the server, the client MUST send a Solicit message using the same IAID in the IA_PD, include the preferred prefix-length value in the "prefix-length" field of the IAPREFIX option, and set the "IPv6 prefix" field to zero. This is an indication to the server that the client prefers a prefix of the specified length, regardless of what it received before.
当客户端首选来自服务器的特定长度的前缀时，客户端必须在IA_PD中使用相同的IAID发送请求消息，在IAPREFIX选项的“prefix length”字段中包含首选前缀长度值，并将“IPv6 prefix”字段设置为零。这是对服务器的一种指示，表明客户端更喜欢指定长度的前缀，而不管它以前收到了什么。
When the client wants the same prefix back from the server, it MUST send a Solicit message using the same IAID in the IA_PD, include the previously delegated prefix value in the "IPv6 prefix" field of the
当客户端希望从服务器返回相同的前缀时，它必须在IA_PD中使用相同的IAID发送请求消息，并将以前委派的前缀值包含在
IAPREFIX option, and include the length of the prefix in the "prefix-length" field. This is an indication to the server that the client wants the same prefix back.
IAPREFIX选项，并在“prefix length”字段中包含前缀的长度。这是对服务器的一个指示，表明客户端希望返回相同的前缀。
When the client wants the same prefix back from the server and would prefer to accept a prefix of a specified length in case the requested prefix is not available, the client MUST send a Solicit message using the same IAID in the IA_PD, include the previously delegated prefix in one IAPREFIX option, and include the prefix-length hint in another IAPREFIX option. There is no requirement regarding the order of the two IAPREFIX options.
如果客户端希望从服务器返回相同的前缀，并且希望在请求的前缀不可用的情况下接受指定长度的前缀，则客户端必须在IA_PD中使用相同的IAID发送请求消息，并在一个IAPREFIX选项中包括先前委派的前缀，并在另一个IAPREFIX选项中包含前缀长度提示。这两个选项的顺序没有要求。
Problem:
问题:
[RFC3633] allows a client to include a prefix-length hint in the Solicit message to signal its preference to the server. How the prefix-length hint should be handled by the server is unclear. The client might want a different prefix length due to configuration changes or it might just want the same prefix again after reboot. The server should interpret these cases differently.
[RFC3633]允许客户端在请求消息中包含前缀长度提示，以向服务器发送其首选项信号。服务器应该如何处理前缀长度提示尚不清楚。由于配置更改，客户端可能需要不同的前缀长度，或者可能只是在重新启动后需要相同的前缀。服务器应该以不同的方式解释这些情况。
Many servers are configured to provide only prefixes of specific lengths to the client, for example, if the client requested for a /54 but the server could only provide /30, /48, and /56. How should these servers decide which prefix to give to the client based on the prefix-length hint?
许多服务器配置为仅向客户端提供特定长度的前缀，例如，如果客户端请求a/54，但服务器只能提供/30、/48和/56。这些服务器应该如何根据前缀长度提示决定给客户端哪个前缀？
Solution:
解决方案：
Upon the receipt of Solicit message, if the client included only a prefix-length hint in the message, the server SHOULD first check its prefix pool for a prefix with a length matching the prefix-length hint value, regardless of the prefix record from previous interactions with the client. If the server does not have a prefix with a length matching the prefix-length hint value, then the server SHOULD provide the prefix whose length is shorter and closest to the prefix-length hint value.
收到请求消息后，如果客户端在消息中仅包含前缀长度提示，则服务器应首先检查其前缀池中长度与前缀长度提示值匹配的前缀，而不考虑以前与客户端交互的前缀记录。如果服务器没有长度与前缀长度提示值匹配的前缀，则服务器应提供长度较短且最接近前缀长度提示值的前缀。
If the client included a specific prefix value in the Solicit message, the server SHOULD check its prefix pool for a prefix matching the requested prefix value. If the requested prefix is not available in the server's prefix pool, and the client also included a prefix-length hint in the same IA_PD option, then the server SHOULD check its prefix pool for a prefix with a length matching the prefix-length hint value. If the server does not have a prefix with a length matching the prefix-length hint value, the server SHOULD
如果客户端在请求消息中包含特定的前缀值，则服务器应检查其前缀池中是否有与请求的前缀值匹配的前缀。如果请求的前缀在服务器的前缀池中不可用，并且客户端还在同一IA_PD选项中包含前缀长度提示，则服务器应检查其前缀池中是否有长度与前缀长度提示值匹配的前缀。如果服务器没有长度与前缀长度提示值匹配的前缀，则服务器应
provide the prefix whose length is shorter and closest to the prefix-length hint value.
提供长度较短且最接近前缀长度提示值的前缀。
If the server will not assign any prefixes to any IA_PDs in a subsequent Request from the client, the server MUST send an Advertise message to the client as described in Section 11.2 of [RFC3633].
如果服务器不会在客户端的后续请求中为任何IA_PDs分配任何前缀，则服务器必须按照[RFC3633]第11.2节中的说明向客户端发送播发消息。
Problem:
问题:
The server might not be able to honor the prefix-length hint due to server policy or lack of resources in its prefix pool. If the prefix length provided by the server in the Advertise message is different from what the client requested in the Solicit message, the question would be whether the client should use the provided prefix length or continue to ask for its preferred prefix length. There are certain situations in which the client could not operate properly if it used a prefix whose length is different from what it requested in the prefix-length hint. However, if the client ignores the Advertise messages and continues to solicit for the preferred prefix length, the client might be stuck in the DHCP process. Another question is whether the client should ignore other configuration parameters such as available addresses.
由于服务器策略或其前缀池中缺少资源，服务器可能无法接受前缀长度提示。如果服务器在播发消息中提供的前缀长度与客户端在请求消息中请求的前缀长度不同，那么问题将是客户端是应该使用提供的前缀长度，还是继续请求其首选前缀长度。在某些情况下，如果客户端使用的前缀长度与其在前缀长度提示中请求的长度不同，则客户端无法正常运行。但是，如果客户端忽略播发消息并继续请求首选前缀长度，则客户端可能会卡在DHCP进程中。另一个问题是客户端是否应该忽略其他配置参数，例如可用地址。
Solution:
解决方案：
If the client could use the prefixes included in the Advertise messages despite being different from the prefix-length hint, the client SHOULD choose the shortest prefix length that is closest to the prefix-length hint. The client SHOULD continue requesting the preferred prefix in the subsequent DHCPv6 messages as defined in Section 3.4 of this document.
如果客户机可以使用播发消息中包含的前缀（尽管与前缀长度提示不同），则客户机应选择最短的前缀长度，该前缀长度最接近前缀长度提示。客户应继续在本文件第3.4节中定义的后续DHCPv6消息中请求首选前缀。
If the client sent a Solicit with only IA_PDs and cannot use the prefixes included in the Advertise messages, it MUST ignore the Advertise messages and continue to send Solicit messages until it gets the preferred prefix. To avoid traffic congestion, the client MUST send Solicit messages at defined intervals, as specified in [RFC7083].
如果客户端仅使用IA_PDs发送请求，并且无法使用播发消息中包含的前缀，则必须忽略播发消息并继续发送请求消息，直到获得首选前缀。为了避免通信阻塞，客户端必须按照[RFC7083]中的规定，以规定的间隔发送请求消息。
If the client also solicited for other stateful configuration options such as IA_NAs and the client cannot use the prefixes included in the Advertise messages, the client SHOULD accept the other stateful configuration options and continue to request the desired IA_PD prefix in subsequent DHCPv6 messages as specified in [RFC7550].
如果客户端还请求其他有状态配置选项，如IA_NAs，并且客户端无法使用播发消息中包含的前缀，则客户端应接受其他有状态配置选项，并按照[RFC7550]中的规定，继续在后续DHCPv6消息中请求所需的IA_PD前缀。
Problem:
问题:
Servers might not be able to provide a prefix with the length equal to or shorter than the prefix-length hint. If the client decided to use the prefix provided by the server despite it being longer than the prefix-length hint but would still prefer the prefix-length hint originally requested in the Solicit message, there should be some way for the client to express this preference during Renew/Rebind. For example, if the client requested for a /60 but got a /64, the client should be able to signal to the server during Renew/Rebind that it would still prefer a /60. This is to see whether the server has the prefix preferred by the client available in its prefix pool during Renew/Rebind. [RFC3633] is not completely clear on whether the client is allowed to include a prefix-length hint in the Renew/Rebind message.
服务器可能无法提供长度等于或小于前缀长度提示的前缀。如果客户机决定使用服务器提供的前缀，尽管它比前缀长度提示长，但仍然希望使用请求消息中最初请求的前缀长度提示，则在续订/重新绑定期间，客户机应该有某种方式来表示此偏好。例如，如果客户机请求a/60，但得到了a/64，则客户机应能够在续订/重新绑定期间向服务器发出信号，表示它仍然希望使用a/60。这是为了查看在续订/重新绑定期间，服务器的前缀池中是否有客户端首选的前缀。[RFC3633]不完全清楚是否允许客户端在续订/重新绑定消息中包含前缀长度提示。
Solution:
解决方案：
During Renew/Rebind, if the client prefers a prefix length that is different from the prefix it is currently using, then the client SHOULD send the Renew/Rebind message with the same IA_PD, and include two IAPREFIX options, one containing the currently delegated prefix and the other containing the prefix-length hint. This is to extend the lifetime of the prefix the client is currently using, get the prefix the client prefers, and go through a graceful switch over.
在续订/重新绑定期间，如果客户端希望前缀长度与其当前使用的前缀不同，则客户端应发送具有相同IA_PD的续订/重新绑定消息，并包括两个IAPREFIX选项，一个包含当前委派的前缀，另一个包含前缀长度提示。这是为了延长客户端当前使用的前缀的生存期，获取客户端喜欢的前缀，并进行优雅的切换。
If the server is unable to provide the client with the newly requested prefix, but is able to extend lifetime of the old prefix, the client SHOULD continue using the old prefix.
如果服务器无法向客户端提供新请求的前缀，但能够延长旧前缀的生存期，则客户端应继续使用旧前缀。
Problem:
问题:
The prefix preferred by the client might become available in the server's prefix pool during Renew/Rebind, even though it was unavailable during Solicit. This might be due to a server configuration change or because some other client stopped using the prefix.
客户端首选的前缀可能在续订/重新绑定期间在服务器的前缀池中可用，即使在请求期间不可用。这可能是由于服务器配置更改或其他客户端停止使用前缀造成的。
The question is whether the server should remember the prefix-length hint the client originally included in the Solicit message and check it during Renew/Rebind to see if it has the prefix length the client preferred. This would require the server to keep extra information about the client. There is also the possibility that the client's preference for the prefix length might have changed during this time
问题是服务器是否应该记住客户机最初包含在请求消息中的前缀长度提示，并在续订/重新绑定期间检查它是否具有客户机首选的前缀长度。这将要求服务器保留有关客户端的额外信息。在此期间，客户端对前缀长度的偏好也可能发生了变化
interval, so the prefix-length hint remembered by the server might not be what the client prefers during Renew/Rebind.
间隔，因此服务器记住的前缀长度提示可能不是客户机在续订/重新绑定期间喜欢的。
Instead of having the server remember the prefix-length hint of the client, another option is for the client to include the prefix-length hint in the Renew/Rebind message. [RFC3633] is unclear about what the server should do if the client also included a prefix-length hint value in the Renew/Rebind message and whether the server could provide a different prefix to the client during Renew/Rebind.
与让服务器记住客户端的前缀长度提示不同，另一个选项是让客户端在续订/重新绑定消息中包含前缀长度提示。[RFC3633]不清楚如果客户端在续订/重新绑定消息中还包含前缀长度提示值，服务器应该做什么，以及服务器是否可以在续订/重新绑定期间向客户端提供不同的前缀。
Solution:
解决方案：
Upon the receipt of a Renew/Rebind message, if the client included in the IA_PD both an IAPREFIX option with the delegated prefix value and an IAPREFIX option with a prefix-length hint value, the server SHOULD check whether it could extend the lifetime of the original delegated prefix and whether it has any available prefix matching the prefix-length hint (or determine the closest possible to the prefix-length hint) within its limit.
在收到续订/重新绑定消息后，如果客户机在IA_PD中包括具有委派前缀值的IAPREFIX选项和具有前缀长度提示值的IAPREFIX选项，服务器应检查是否可以延长原始委派前缀的生存期，以及在其限制范围内是否有任何与前缀长度提示匹配的可用前缀（或确定最接近前缀长度提示的前缀）。
If the server assigned the prefix included in IA_PD to the client, the server SHOULD do one of the following, depending on its policy:
如果服务器将IA_PD中包含的前缀分配给客户端，则服务器应根据其策略执行以下操作之一：
1. Extend the lifetime of the original delegated prefix.
1. 延长原始委派前缀的生存期。
2. Extend the lifetime of the original delegated prefix and assign a new prefix of the requested length.
2. 延长原始委派前缀的生存期，并分配请求长度的新前缀。
3. Mark the original delegated prefix as invalid by giving it 0 lifetimes, and assign a new prefix of the requested length. This avoids the complexity of handling multiple delegated prefixes but may break all the existing connections of the client.
3. 通过为原始委派前缀指定0个生存期，将其标记为无效，并指定一个请求长度的新前缀。这避免了处理多个委托前缀的复杂性，但可能会中断客户端的所有现有连接。
4. Assign the original delegated prefix with 0 preferred-lifetime, a specific non-zero valid-lifetime depending on actual requirement, and assign a new prefix of the requested length. This allows the client to finish up existing connections with the original prefix and use the new prefix to establish new connections.
4. 为原始委派前缀分配0个首选生存期，根据实际需求分配一个特定的非零有效生存期，并为请求的长度分配一个新前缀。这允许客户端使用原始前缀完成现有连接，并使用新前缀建立新连接。
5. Do not include the original delegated prefix in the Reply message, and assign a new prefix of the requested length. The original prefix would be valid until its lifetime expires. This avoids sudden renumbering on the client.
5. 不要在回复消息中包含原始委派前缀，并为请求的长度分配一个新前缀。原始前缀将一直有效，直到其生存期到期。这样可以避免在客户端上突然重新编号。
If the server does not know the client's bindings (e.g., a different server receiving the message during Rebind), then the server SHOULD ignore the original delegated prefix and try to assign a new prefix of the requested length.
如果服务器不知道客户端的绑定（例如，在重新绑定期间接收消息的不同服务器），则服务器应忽略原始委派前缀，并尝试分配请求长度的新前缀。
It's unnecessary for the server to remember the prefix-length hint the client requested during Solicit. It is possible that the client's preference for the prefix length might have changed during this time interval, so the prefix-length hint in the Renew message is reflecting what the client prefers at the time.
服务器不需要记住客户端在请求期间请求的前缀长度提示。客户端对前缀长度的首选项可能在此时间间隔内发生了更改，因此续订消息中的前缀长度提示反映了客户端当时的首选项。
The recommendation to address the issues discussed in this document is for a client that wants (at least) to have a delegated prefix of a specific prefix length to always include an IAPREFIX option with just the prefix-length hint in addition to any IAPREFIX options it has included for each IA_PD in any Solicit, Request, Renew, and Rebind messages it sends. While a server is free to ignore the hint, servers that do not choose to ignore the hint should attempt to assign a prefix of the hint length (or assign the next closest length that does not exceed the hint) if one is available. Whether a server favors the hint or avoiding a renumbering event is a matter of server policy.
解决本文件中讨论的问题的建议适用于希望（至少）具有特定前缀长度的委托前缀的客户，该客户在任何请求、请求、续约中，除了为每个IA_PD包含的任何IAPREFIX选项之外，始终包括仅包含前缀长度提示的IAPREFIX选项，并重新绑定它发送的消息。虽然服务器可以随意忽略提示，但不选择忽略提示的服务器应尝试分配提示长度的前缀（或分配不超过提示的下一个最近长度，如果有）。服务器是支持提示还是避免重新编号事件取决于服务器策略。
This document provides guidance on how the clients and servers interact with regard to the DHCPv6 prefix-length hint. Security considerations in DHCP are described in Section 23 of [RFC3315]. Security considerations regarding DHCPv6 prefix delegation are described in Section 15 of [RFC3633].
本文档提供了有关客户端和服务器如何根据DHCPv6前缀长度提示进行交互的指导。[RFC3315]第23节描述了DHCP中的安全注意事项。[RFC3633]第15节描述了有关DHCPv6前缀委派的安全注意事项。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, <http://www.rfc-editor.org/info/rfc3633>.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，DOI 10.17487/RFC3633，2003年12月<http://www.rfc-editor.org/info/rfc3633>.
[RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 2013, <http://www.rfc-editor.org/info/rfc7083>.
[RFC7083]Droms，R.，“修改SOL_MAX_RT和INF_MAX_RT的默认值”，RFC 7083，DOI 10.17487/RFC7083，2013年11月<http://www.rfc-editor.org/info/rfc7083>.
[RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and Recommendations with Multiple Stateful DHCPv6 Options", RFC 7550, DOI 10.17487/RFC7550, May 2015, <http://www.rfc-editor.org/info/rfc7550>.
[RFC7550]Troan，O.，Volz，B.，和M.Siodelski，“多状态DHCPv6选项的问题和建议”，RFC 7550，DOI 10.17487/RFC7550，2015年5月<http://www.rfc-editor.org/info/rfc7550>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
Acknowledgements
致谢
Many thanks to Qi Sun, Bernie Volz, Ole Troan, Sunil Gandhewar, Marcin Siodelski, Ted Lemon, Roni Even, Benoit Claise, Mirja Kuehlewind, Kathleen Moriarty, Eric Rescorla, Alvaro Retana, Susan Hares, and Hilarie Orman for their review and comments.
非常感谢齐孙、伯尼·沃尔兹、奥勒·特隆、苏尼尔·甘德瓦尔、马辛·西奥德尔斯基、特德·莱蒙、甚至罗尼、贝诺特·克莱斯、米佳·库勒温德、凯瑟琳·莫里亚蒂、埃里克·雷索拉、阿尔瓦罗·雷塔纳、苏珊·哈雷斯和希拉里·奥曼的评论和评论。
Authors' Addresses
作者地址
Tianxiang Li Tsinghua University Beijing 100084 China
李天祥清华大学北京100084
Phone: +86-18301185866
Email: peter416733@gmail.com
Phone: +86-18301185866
Email: peter416733@gmail.com
Cong Liu Tsinghua University Beijing 100084 China
刘聪清华大学北京100084
Phone: +86-10-6278-5822
Email: gnocuil@gmail.com
Phone: +86-10-6278-5822
Email: gnocuil@gmail.com
Yong Cui Tsinghua University Beijing 100084 China
清华大学崔勇中国北京100084
Phone: +86-10-6260-3059
Email: yong.cui.thu@gmail.com
Phone: +86-10-6260-3059
Email: yong.cui.thu@gmail.com