diff options
Diffstat (limited to 'doc/rfc/rfc8168.txt')
| -rw-r--r-- | doc/rfc/rfc8168.txt | 507 |
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc8168.txt b/doc/rfc/rfc8168.txt new file mode 100644 index 0000000..76d6f61 --- /dev/null +++ b/doc/rfc/rfc8168.txt @@ -0,0 +1,507 @@ + + + + + + +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 + +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. + +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. + + + + +Li, et al. Standards Track [Page 1] + +RFC 8168 DHCPv6 Prefix-Length Hint Issues May 2017 + + +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 + + 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. + + [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 + + + + +Li, et al. Standards Track [Page 2] + +RFC 8168 DHCPv6 Prefix-Length Hint Issues May 2017 + + + policy for considering the hint, this document provides guidance on + how the prefix-length hint should be handled by the server in + different situations. + +2. Requirements Language + + 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. + +3. Problem Description and Proposed Solutions + +3.1. Creation of Solicit Message + + 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. + + 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. + + 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 + + + +Li, et al. Standards Track [Page 3] + +RFC 8168 DHCPv6 Prefix-Length Hint Issues May 2017 + + + 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. + +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. 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 + + + +Li, et al. Standards Track [Page 4] + +RFC 8168 DHCPv6 Prefix-Length Hint Issues May 2017 + + + 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 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. + + 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. + + 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]. + + + + + +Li, et al. Standards Track [Page 5] + +RFC 8168 DHCPv6 Prefix-Length Hint Issues May 2017 + + +3.4. Creation of Renew/Rebind Message + + 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. + + 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. + +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, 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 + + + +Li, et al. Standards Track [Page 6] + +RFC 8168 DHCPv6 Prefix-Length Hint Issues May 2017 + + + 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. + + + +Li, et al. Standards Track [Page 7] + +RFC 8168 DHCPv6 Prefix-Length Hint Issues May 2017 + + + 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. + +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 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. + +4. Security Considerations + + 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 require any IANA actions. + +6. 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>. + + [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>. + + + +Li, et al. Standards Track [Page 8] + +RFC 8168 DHCPv6 Prefix-Length Hint Issues May 2017 + + + [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>. + +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 + + Phone: +86-18301185866 + Email: peter416733@gmail.com + + + Cong Liu + Tsinghua University + Beijing 100084 + China + + Phone: +86-10-6278-5822 + Email: gnocuil@gmail.com + + + Yong Cui + Tsinghua University + Beijing 100084 + China + + Phone: +86-10-6260-3059 + Email: yong.cui.thu@gmail.com + + + + +Li, et al. Standards Track [Page 9] + |