DHCPv6 Prefix-Length Hint Issues
RFC 8168

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]