DHC Working Group                                                 Y. Cui
Internet-Draft                                                  T. Li
Internet-Draft                                                    C. Liu
Intended status: Standards Track                                  C. Liu                                  Y. Cui
Expires: December 21, 2016 January 27, 2017                            Tsinghua University
                                                           June 19,
                                                           July 26, 2016

                    DHCPv6 Prefix Length Hint Issues
           draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-02
           draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-03

Abstract

   DHCPv6 Prefix Delegation [RFC3633] allows a requesting router 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 requesting router client and delegating router 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 requesting router client and delegating router server could do in different situations.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 December 21, 2016. January 27, 2017.

Copyright Notice

   Copyright (c) 2016 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.

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.5.  Receipt of Renew/Rebind Message . . . . . . . . . . . . .   6
     3.6.  General Recommendation  . . . . . . . . . . . . . . . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Contributors List . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   DHCPv6 Prefix Delegation [RFC3633] allows a requesting router client to include a
   prefix-length hint value in the message sent to the
   delegating router, server, to
   indicate a preference for the size of the prefix to be delegated.  A
   prefix-length hint is communicated by a
   requesting router client to the delegating router server by
   including an IA_PD Prefix Option(OPTION_IAPREFIX), 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 delegating routers servers are free
   to ignore the prefix-length hint values depending on server policy.
   However, some
   requesting routers clients may not be able to function (or only in a
   degraded state) when they're provided with a prefix which length is
   different from what they requested.  E.g.  If the requesting router client is asking
   for a /56 and the delegating router server returns a /64, the functionality of the requesting router
   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 a explicit address or lifetime, address, this might be less critical as it just help helps
   a client that wishes to continue using what it used last time, or a client that wants to Renew its lease for
   a certain period of time.  The
   prefix-length hint directly impacts the operational capability of the requesting router,
   client, thus should be given more consideration.

   [RFC3633] is unclear about how the requesting router client and delegating
   router server should act in
   different situations involving the prefix-length hint.  From the requesting router
   client perspective, it should be able to use the prefix-length hint
   to signal to the delegating router server its real time need and it should be able to
   handle the prefixes which with lengths are different from the prefix-length hint.
   This document provides guidance on what a requesting router client should do in
   different situations to help it operate properly.  From the delegating router server
   perspective, the delegating router server is free to ignore the prefix-
   length prefix-length hints
   depending on server policy, but in cases where the
   delegating router server has a
   policy for considering the hint, this document provides guidance on
   how the prefix-length hint should be handled by the delegating router server in
   different situations.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Problem Description and Proposed Solutions

3.1.  Creation of Solicit Message

   Problem:

   The Solicit message allows a requesting router client to ask delegating
   routers servers for prefixes and
   other configuration parameters.  The
   requesting router client might want a different
   prefix length due to configuration changes or it might just want the
   same prefix again after reboot.  The delegating router 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 requesting router client
   with the preferred prefix depending on server policy, but the requesting router client
   should be able to signal to the
   delegating router server its real time need.

   The delegating routers servers usually has a record of the prefix it gave to the requesting router 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 requesting router client device to have persistant storage,
   since rebooting the device would cause the
   requesting router client to use the original
   IAID in the IA_PD.

   Solution:

   When the requesting router client prefers a prefix of specific length from the delegating router, server,
   the requesting router SHOULD client MUST send a Solicit message using the same IAID in the
   IAPD, include the preferred prefix-length value in the "prefix-length" "prefix-
   length" field of the
   OPTION_IAPREFIX IAPREFIX option, and set the "IPv6 prefix" field
   to zero.  This is an indiction to the delegating router server that the requesting
   router client prefers
   a prefix of the specified length, regardless of what it had gotten
   before.

   When the requesting router client wants the same prefix back from the
   delegating router, server, it SHOULD 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 OPTION_IAPREFIX
   IAPREFIX option, and the length of the prefix in the "prefix-length"
   field.  This is an indication to the delegating router server that the requesting router 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 requesting router client to include a prefix-length hint in the
   Solicit message, to signal its preference to the delegating
   router. server.  It is
   unclear about how the prefix-length hint should be handled by the delegating router.
   server.  The requesting router client might want a different prefix length due to
   configuration changes or it might just want the same prefix again
   after reboot.  The delegating router server should interpret these cases differently.

   Many delegating routers servers are configured to provide only prefixes of specific
   lengths to the requesting router. client.  E.g.  If the requesting
   router client requested for a /54, and
   the delegating router server could only provide /30, /48, and /56.  How should these delegating routers
   servers decide which prefix to give to the requesting router client based on the
   prefix-length hint?

   Solution:

   Upon the receipt of Solicit message, if the requesting router client included only a
   prefix-length hint in the message, the delegating
   router 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 requesting router. client.  If the
   delegating router server does not have a prefix with length
   matching the prefix-length hint value, then the delegating router server SHOULD provide
   the prefix with the shortest length possible which is closest to the
   prefix-length hint value.

   If the requesting router client included a specific prefix value and the
   corresponding prefix-length value in the Solicit
   message, the
   delegating router server SHOULD first try to check its prefix pool for a prefix
   matching the requested prefix value.  If the requested prefix is not
   available in the delegating router's server's prefix pool, and the client also included a
   prefix-length hint in the same IA_PD option, then the
   delegating router server SHOULD
   try to provide a prefix matching the prefix-
   length prefix-length value, or the
   prefix with the shortest length possible which is closest to the
   prefix-length hint value.

3.3.  Receipt of Advertise Message

   Problem:

   The delegating router 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 delegating router server in the Advertise message is different
   from what the requesting router client requested in the Solicit message, the question
   would be whether the
   requesting router client should use the provided prefix length or
   continue to ask for its preferred prefix length.  There are certain
   situations where the requesting router 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 requesting router client ignores the Advertise
   messages, and continues to solicit for the preferred prefix length,
   the requesting router client might be stuck in the DHCP process.  Another question is
   whether the requesting router client should ignore other configuration parameters such
   as available addresses.

   Solution:

   If the requesting router client could use the prefixes provided by included in the
   delegating routers Advertise
   messages despite being different from the prefix-length hint, the requesting router
   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 requesting router client Solicted for only IA_PDs and cannot use the prefixes provided by
   included in the
   delegating routers, 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 requesting router client MUST send
   Solicit messages at defined intervals, as specified in [RFC7083].

   If the requesting router client also Solicited for other stateful configuration options
   such as IA_NAs, IA_NAs and the requesting router 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:

   Delegating routers

   servers might not be able to provide a prefix with length equal or
   shorter than the prefix-length hint.  If the requesting
   router client decided to use
   the prefix provided by the delegating router 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
   for the requesting router client to express this preference during Renew/Rebind.  E.g.
   If the requesting
   router client requested for a /60 but got a /64, the requesting router client should be
   able to signal to the delegating router server during Renew/Rebind that it would still
   prefer a /60.  This is to see whether the
   delegating router server has the prefix
   preferred by the requesting router client available in its prefix pool during Renew/Rebind. Renew/
   Rebind.  [RFC3633] is not completely clear on whether the requesting router client is
   allowed to include a prefix-length hint in the Renew/Rebind message.

   Solution:

   During Renew/Rebind, if the requesting router client prefers a prefix length different
   from the prefix it is currently using, then the requesting
   router client SHOULD send
   the Renew/Rebind message with the same IA_PD, and include two OPTION_IAPREFIX
   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 requesting router client is currently using and also get the
   prefix the requesting router client prefers, and go through a graceful switch over.

   If the delegating router server is unable to provide the requesting router client with the newly
   requested prefix, but is able to extend lifetime of the old prefix,
   the requesting router client SHOULD continue using the old prefix.

3.5.  Receipt of Renew/Rebind Message

   Problem:

   The prefix preferred by the requesting router client might become available in the delegating router's
   server's prefix pool during Renew/Rebind, but was unavailable during
   Solicit.  This might be due to delegating router server configuration change or because
   some other requesting router client stopped using the prefix.

   The question is whether the delegating router server should remember the prefix-length
   hint the requesting router client originally included in the Solicit message and check
   during Renew/Rebind to see if it has the prefix length the requesting router client
   preferred.  This would require the delegating router server to keep extra information
   about the requesting
   router. client.  There is also the possibility that the requesting router's client's
   preference for the prefix length might have changed during this time
   interval, so the prefix-length hint remembered by the delegating
   router server might
   not be what the requesting router client prefers during Renew/
   Rebind. Renew/Rebind.

   Instead of having the delegating router server remember the prefix-length hint of the requesting router,
   client, another option is for the requesting
   router client to include the prefix-length
   hint in the Renew/Rebind message.  The current specification is
   unclear about what the delegating router server should do if the requesting router client also included
   in the Renew/Rebind message a prefix-length hint value, and whether
   the delegating router server could provide a different prefix to the requesting router client during
   Renew/Rebind.

   Solution:

   Upon the receipt of Renew/Rebind, if the requesting router client included in the IA_PD
   both OPTION_IAPREFIX an IAPREFIX option with the delegated prefix value and an OPTION_IAPREFIX
   IAPREFIX option with a prefix-length hint value, the delegating router 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 delegating router's server's limit.

   If the delegating router server assigned the prefix included in IA_PD to the
   requesting router, client,
   the delegating router 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 requesting router. 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 requesting router 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 requesting router. client.

   If the delegating router server does not know the requesting router's client's bindings(e.g. a different delegating router
   server receiving the message during Rebind), then the delegating router server SHOULD
   ignore the original delegated prefix, and try to assign a new prefix
   of requested length.

   It's unnecessary for the delegating router server to remember the prefix-
   length prefix-length hint
   the requesting router client requested during Solicit.  It is possible that the requesting router's
   client's preference for the prefix length might have changed during
   this time interval, so the prefix-
   length prefix-length hint in the Renew message is
   reflecting what the requesting
   router 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 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 requesting routers clients and delegating routers 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>.

   [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

   Yong Cui
   Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6260-3059
   Email: yong@csnet1.cs.tsinghua.edu.cn

   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