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
AbstractDHCPv6 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. 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. 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. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. 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.
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 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. [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
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. 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. 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. 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? 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
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]. Section 3.4 of this document. 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]. 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].
RFC3633] is not completely clear on whether the client is allowed to include a prefix-length hint in the Renew/Rebind message. 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. 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.
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. 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. 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: 1. Extend the lifetime of the original delegated prefix. 2. Extend the lifetime of the original delegated prefix and assign a new prefix of the requested length. 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. 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. 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. 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. Section 23 of [RFC3315]. Security considerations regarding DHCPv6 prefix delegation are described in Section 15 of [RFC3633]. [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>. [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>. [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>.
[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>. [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>. [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>.