DHCPv6 Prefix Length Hint Issues
draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-03
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8168.
|
|
---|---|---|---|
Authors | Tianxiang Li , Cong Liu , Yong Cui | ||
Last updated | 2016-10-14 (Latest revision 2016-07-26) | ||
Replaces | draft-cui-dhc-dhcpv6-prefix-length-hint-issue | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Last Call review
(of
-05)
by Roni Even
Almost ready
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Consensus: Waiting for Write-Up | |
Document shepherd | Bernie Volz | ||
IESG | IESG state | Became RFC 8168 (Proposed Standard) | |
Consensus boilerplate | Yes | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | "Bernie Volz" <volz@cisco.com> |
draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-03
quot; 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 specified length in case the requested prefix is not avaiable, 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. 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 after reboot. The server should interpret these cases differently. Many servers are configured to provide only prefixes of specific lengths to the client. E.g. If the client requested for a /54, and 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 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. 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. Li, et al. Expires January 27, 2017 [Page 4] Internet-Draft DHCPv6 prefix-length hint Issues July 2016 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-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 client SHOULD choose the shortest prefix length which is closest to the prefix-length hint. The client SHOULD continue requesting for the preferred prefix in the subsequent DHCPv6 messages as defined in section 3.4 of this document If the client Solicted for 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 for the desired IA_PD prefix in subsequent DHCPv6 messages as specified in [RFC7550]. 3.4. Creation of Renew/Rebind Message Problem: servers might not be able to provide a prefix with length equal or shorter than the prefix-length hint. If the client decided to use the prefix provided by the server despite being longer than the prefix-length hint, but would still prefer the prefix-length hint it originally requested in the Solicit message, there should be some way Li, et al. Expires January 27, 2017 [Page 5] Internet-Draft DHCPv6 prefix-length hint Issues July 2016 for the client to express this preference during Renew/Rebind. E.g. 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. Solution: During Renew/Rebind, if the client prefers a prefix length 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 and also 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. 3.5. Receipt of Renew/Rebind Message Problem: The prefix preferred by the client might become available in the server's prefix pool during Renew/Rebind, but was unavailable during Solicit. This might be due to 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 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. The current specification is unclear about what the server should do if the client also included in the Renew/Rebind message a prefix-length hint value, and whether the server could provide a different prefix to the client during Renew/Rebind. Li, et al. Expires January 27, 2017 [Page 6] Internet-Draft DHCPv6 prefix-length hint Issues July 2016 Solution: Upon the receipt of Renew/Rebind, 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 to see whether it could extend the lifetime of the original delegated prefix and whether it has any available prefix matching the prefix-length hint, or as close a possible to the prefix-length hint, within the server's 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 lifetime of the original delegated prefix. 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. 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 it's 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. 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. Li, et al. Expires January 27, 2017 [Page 7] Internet-Draft DHCPv6 prefix-length hint Issues July 2016 3.6. General Recommendation 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 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. 5. IANA Considerations This document does not include an IANA request. 6. Contributors List Many thanks to Qi Sun, Bernie Volz, Ole Troan, Sunil Gandhewar, Marcin Siodelski. 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, <http://www.rfc-editor.org/info/rfc2119>. [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>. Li, et al. Expires January 27, 2017 [Page 8] Internet-Draft DHCPv6 prefix-length hint Issues July 2016 [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>. Authors' Addresses Tianxiang Li Tsinghua University Beijing 100084 P.R.China Phone: +86-18301185866 Email: peter416733@gmail.com Cong Liu Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: gnocuil@gmail.com Yong Cui Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6260-3059 Email: yong@csnet1.cs.tsinghua.edu.cn Li, et al. Expires January 27, 2017 [Page 9]