--- 1/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05.txt 2017-03-31 23:13:07.995334832 -0700 +++ 2/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06.txt 2017-03-31 23:13:08.015335306 -0700 @@ -1,19 +1,19 @@ DHC Working Group T. Li Internet-Draft C. Liu Intended status: Standards Track Y. Cui -Expires: July 29, 2017 Tsinghua University - January 25, 2017 +Expires: October 2, 2017 Tsinghua University + March 31, 2017 DHCPv6 Prefix Length Hint Issues - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05 + draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06 Abstract DHCPv6 Prefix Delegation (RFC3633) 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 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. @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 29, 2017. + This Internet-Draft will expire on October 2, 2017. 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 @@ -51,41 +51,41 @@ described in the Simplified BSD License. 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 . . . . . . . . . . . . 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. Contributors List . . . . . . . . . . . . . . . . . . . . . . 8 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction 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 which length is + degraded state) when they're provided with a prefix whose length is different from what they requested. E.g. 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 should be given more consideration. [RFC3633] is unclear about how the client and server should act in @@ -115,50 +115,52 @@ 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 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 servers usually has a record of the prefix it gave to the client + The server usually has a record of the prefix it gave to the client during previous interactions. The best way to assure a completely - new delegated prefix is to send a new IAID in the IA_PD. However, - this would require the client device to have persistent storage, - since rebooting the device would cause the client to use the original - IAID in the IA_PD. + 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, since rebooting the device would cause the client + to use the original IAID in the IA_PD. Solution: When the client prefers a prefix of specific length from the server, the client MUST send a Solicit message using the same IAID in the IAPD, 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 had gotten before. When the client wants the same prefix back from the server, it MUST send a Solicit message using the same IAID in the IAPD, include the previously delegated prefix value in the "IPv6 prefix" field of the IAPREFIX option, and 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 + When the client wants the same prefix back from the server and would prefer to accept a prefix of specified length in case the requested prefix is not available, the client MUST send a Solicit message using the same IAID in the IAPD, include the previously delegated prefix in one IAPREFIX option, and include the prefix-length hint in another - IAPREFIX option. + IAPREFIX option. There is no requirement to the order of the two + IAPREFIX options. 3.2. Receipt of Solicit message Problem: [RFC3633] allows a client to include a prefix-length hint in the Solicit message, to signal its preference to the server. It is unclear about how the prefix-length hint should be handled by the server. The client might want a different prefix length due to configuration changes or it might just want the same prefix again @@ -171,44 +173,50 @@ 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 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 length matching the prefix-length hint value, then the server SHOULD provide - the prefix with the shortest length possible which is closest to the - prefix-length hint value. + 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 - try to provide a prefix matching the prefix-length value, or the - prefix with the shortest length possible which is closest to the - prefix-length hint value. + check its prefix pool for a prefix with length matching the prefix- + length hint value. If the server does not have a prefix with 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]. 3.3. Receipt of Advertise Message 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 where the client could not operate properly if it used a - prefix which length is different from what it requested in the + 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. Solution: If the client could use the prefixes included in the Advertise messages despite being different from the prefix-length hint, the @@ -304,24 +312,24 @@ 2. Extend 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 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 - short non-zero valid-lifetime, and assign a new prefix of requested - length. This allows the client to finish up existing connections - with the original prefix, and use the new prefix to establish new - connections. + specific non-zero valid-lifetime depending on actual requirement, and + assign a new prefix of 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 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 requested length. @@ -340,41 +348,49 @@ 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 at least the hint length (or shorter) if one is available. Whether a server favors the hint or avoiding a renumbering event is a matter of server policy. 4. Security Considerations - This document introduces no new security considerations over those - already discussed in section 15 of RFC3633, as this document provides - guidance on how the clients and servers interact with regard to the - prefix-length hint mechanism introduced in RFC3633. + 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]. 5. IANA Considerations This document does not include an IANA request. -6. Contributors List +6. Acknowledgements Many thanks to Qi Sun, Bernie Volz, Ole Troan, Sunil Gandhewar, - Marcin Siodelski. + Marcin Siodelski, Ted Lemon, Roni Even, Benoit Claise, Mirja + Kuehlewind, Kathleen Moriarty, Eric Rescorla, Alvaro Retana, Susan + Hares, Hilarie Orman for their review and comments. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . + [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, . + [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, . [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 2013, . [RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and