Skip to main content

DHCPv6 Prefix Length Hint Issues
draft-cui-dhc-dhcpv6-prefix-length-hint-issue-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Yong Cui , Tianxiang Li , Cong Liu
Last updated 2015-07-06
Replaced by draft-ietf-dhc-dhcpv6-prefix-length-hint-issue, RFC 8168
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-cui-dhc-dhcpv6-prefix-length-hint-issue-00
DHC Working Group                                                 Y. Cui
Internet-Draft                                                     T. Li
Intended status: Standards Track                                  C. Liu
Expires: January 7, 2016                             Tsinghua University
                                                            July 6, 2015

                    DHCPv6 Prefix Length Hint Issues
            draft-cui-dhc-dhcpv6-prefix-length-hint-issue-00

Abstract

   DHCPv6 Prefix Delegation [RFC3633] allows a client to set a hint
   value in the prefix-length field of 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 the different situation
   involving the the prefix length hint.

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 January 7, 2016.

Copyright Notice

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

Cui, et al.              Expires January 7, 2016                [Page 1]
Internet-Draft      DHCPv6 Prefix Length Hint Issues           July 2015

   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 . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Creation of Solicit Message by the Client . . . . . . . .   3
     3.2.  Receipt of Solicit message by the Server  . . . . . . . .   3
     3.3.  Receipt of Advertise Message by the Client  . . . . . . .   4
     3.4.  Creation of Renew/Rebind Message by the Client  . . . . .   4
     3.5.  Receipt of Renew Message by the Server  . . . . . . . . .   5
     3.6.  Receipt of Rebind Message by the Server . . . . . . . . .   5
   4.  Proposed Solution . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Creation of Solicit Message by the Client . . . . . . . .   6
     4.2.  Receipt of Solicit message by the Server  . . . . . . . .   6
     4.3.  Receipt of Advertise Message by the Client  . . . . . . .   7
     4.4.  Creation of Renew Message by the Client . . . . . . . . .   7
     4.5.  Receipt of Renew Message by the Server  . . . . . . . . .   7
     4.6.  Creation of Rebind Message by the Client  . . . . . . . .   8
     4.7.  Receipt of Rebind Message by the Server . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Contributors List . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The DHCPv6 specification [RFC3315] allows a client to include data
   values in the requested options, as hints to the server about
   parameter values the client would like to have returned.  The servers
   are free to ignore the hint values depending on server policy.  This
   would not cause problems for some hint values such as T1 and T2
   lifetimes, but it would be an issue for the prefix length hint.  Some
   clients can't function normally when they're provided with a prefix
   which 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.  The clients usually
   have higher preference on the prefix length hint than the other
   option hints, and it should be treated differently.

   The current specification is unclear about how the client and server
   should act in different situations involving the prefix length hint.

Cui, et al.              Expires January 7, 2016                [Page 2]
Internet-Draft      DHCPv6 Prefix Length Hint Issues           July 2015

   From the client perspective, it should be able to use the prefix
   length hint to signal to the server its real time need and it should
   be able to handle the prefixes which lengths are different from the
   prefix length hint.  This document provides guidance on what a client
   should do in different situations, to prevent it from failing.  From
   the server perspective, the server is free to ignore the prefix
   length hints depending on server policy, but in cases where the
   server has a 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", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Problem Description

3.1.  Creation of Solicit Message by the Client

   The Solicit message allows a client to ask servers for addresses and
   configuration parameters.  When the client's configuration changes,
   it might require a prefix length different from what it is currently
   using.  Sometimes the client might want to switch to a new prefix
   right away.  The current specification is unclear about what the
   client should do if it wants to switch to a different prefix length.
   There is also the problem of what the client should do if the server
   is not able to provide the requested prefix length.

   Additionally, if the server is able to provide the new prefix length
   that the client wants, what the client should do with the prefix it
   is currently using.  The client could either deprecate the old prefix
   right away by sending a Release message or the client could use the
   two prefixes at the same time and deprecate the old prefix after some
   time interval.

3.2.  Receipt of Solicit message by the Server

   Some servers will keep a record about prefixes it gave to the client
   during previous interactions, and give the client with the same
   prefix if the same client requested a prefix from the server.  If the
   server has prefix record from previous interactions with the client,
   and the client is now requesting a different prefix length in the
   Solicit message, the server has to decide whether to honor the newly
   requested prefix length hint or give the client the recorded prefix.
   The current specification is unclear about what a server should do in
   this situation, and it is dependent on the server policy.  Normally

Cui, et al.              Expires January 7, 2016                [Page 3]
Internet-Draft      DHCPv6 Prefix Length Hint Issues           July 2015

   the server just gives the client the prefix the client had gotten
   before, during previous interactions with the server, but that might
   not be what the client prefers.  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, because giving the client a prefix different from
   what it needs might cause functional problems for the client.

   Many servers are configured to provide prefixes of specific lengths
   to the client.  E.g.  Some servers will only provide /48 and /56.
   The question is how should these servers decide which prefix to give
   to the client based on the client's prefix length hint.  If the
   client requested for a /54, and the server could only provide
   /30,/48, and /56, the server has to decide which prefix to give to
   the client.

3.3.  Receipt of Advertise Message by the Client

   The server might not be able to honor the prefix length hint due to
   server policy.  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 or continue to ask for its preferred prefix.
   There are certain situations where the client would fail 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 continue to solicit for the desired prefix length, the client
   might be stuck in the DHCP process.

3.4.  Creation of Renew/Rebind Message by the Client

   Servers might not be able to provide a prefix matching the prefix
   length hint requested by the client.  If the client decided to use
   the prefix provided by the server which doesn't match 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 client to express this preference during Renew/Rebind.  E.g.
   If the client requested for a /60 but got a /64, there should be some
   way for the client 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.

   [RFC3315] does not allow a client to include in the Renew/Rebind
   message hint values different from what it already has, so the client
   cannot directly include a different prefix length hint value in the
   Renew/Rebind message.  The current specification is also unclear
   about whether the client can include both the prefix it is currently

Cui, et al.              Expires January 7, 2016                [Page 4]
Internet-Draft      DHCPv6 Prefix Length Hint Issues           July 2015

   using as well as a different prefix length value as hint in the
   Renew/Rebind message.

   This would raise the same question as to what the client should do
   with the prefix it is currently using, if the server is able to
   provide the new prefix that the client wants.

3.5.  Receipt of Renew Message by the Server

   Upon the receipt of the Renew message, the question is whether the
   server should remember the prefix length hint the client originally
   included in the Solicit message and check to see if it now has the
   prefix length the client originally desired.  The prefix desired by
   the client might become available in the prefix pool during Renew but
   was unavailable during Solicit.  This might be due to server
   configuration change or because some other client stopped using the
   prefix.  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 remembered by the server might not be
   what the client wants during the Renew process.

   Another question is what the server should do if the client also
   included in the Renew message a prefix length value different from
   what the client is currently using.  The current specification does
   not specify how this should be handled and whether the server could
   also provide a different prefix to the client during the Renew
   process.

3.6.  Receipt of Rebind Message by the Server

   [RFC3315] specifies that when the server receives a Rebind message
   that contains an IA option from a client, it locates the client's
   binding and verifies that information in the IA from the client
   matches the information stored for that client.  So the current
   specification requires the client to include in the Rebind message
   the prefix it is currently using.  The question is what the server
   should do if the client also included in the Rebind message a prefix
   length value different from what the client is currently using.  The
   Rebind message is sent to any available servers the client can find,
   so the servers might have the prefix length the client wanted, but
   the current specification does not specify whether the server could
   also provide a different prefix to the client during the Rebind
   process.

Cui, et al.              Expires January 7, 2016                [Page 5]
Internet-Draft      DHCPv6 Prefix Length Hint Issues           July 2015

4.  Proposed Solution

4.1.  Creation of Solicit Message by the Client

   When the client's configuration changes and suddenly requires a
   prefix length different from what it already has, the client should
   send a Solicit message with a different IAID, including the desired
   prefix length in the prefix-length field of the IA_PD option as the
   hint.

   If the client is able to get the new prefix right away, it could do
   one of the following things depending on client's need:

   1.Deprecate the old prefix right away by sending a Release message to
   the server, and switch over to the new prefix.

   2.Use the two prefixes at the same time and deprecate the old prefix
   after some time interval.  The client could wait for the old prefix
   to expire or it could extend the lifetime of the old prefix with some
   specific value.

   If the client is unable to get the new prefix right away, it should
   continue using the old prefix, while soliciting for the new prefix.If
   the client is unable to use the old prefix anymore, it should
   deprecate the old prefix by sending a Release message to the server
   and keep sending Solicit messages asking for the new prefix.  The
   client should send the Solicit messages at defined time intervals to
   avoid traffic congestion.

4.2.  Receipt of Solicit message by the Server

   When the prefix length hint in the Solicit message sent by the client
   is different from the prefix record the server has from previous
   interactions with the client, the server should try to honor the
   prefix length hint the client included in the Solicit message.
   Because it is what the client prefers to have at the time being.  If
   the client wanted the same prefix back it would just include the old
   prefix as the hint in the Solicit message.  If the server has a
   policy for considering the client's hint it should regard the prefix
   length hint in the Solicit message as the prefix length most
   preferred by the client at the time being.

   Many servers are configured to provide prefixes of specific lengths
   to the client.  In this situation, the server should provide a prefix
   which length is shorter than the prefix length hint and which length
   is closest to the prefix length hint.  E.g.  If the server could only
   provide prefixes with lengths /30,/48, and /56, and the client is
   requesting for a /50 in the prefix length hint, then the server

Cui, et al.              Expires January 7, 2016                [Page 6]
Internet-Draft      DHCPv6 Prefix Length Hint Issues           July 2015

   should provide the /48 to the client.

4.3.  Receipt of Advertise Message by the Client

   If none of the prefixes provided by the server in the Advertise
   messages match the prefix length hint the client included in the
   Solicit message, the client could choose to either accept or ignore
   the prefixes provided by the servers depending on functional need.

   If the client could use the prefixes provided by the servers despite
   being different from the prefix length hint, the client should choose
   a prefix length closest to the prefix length hint.

   There are certain situations where the client will fail if it used a
   prefix which length does not meet its requirement.  If the client
   cannot use the prefixes provided by the servers, it should ignore the
   Advertise messages and continue to send Solicit messages until it
   gets the desired prefix.  To prevent the client from not functioning,
   the client should not ignore other configuration parameters provided
   by the server such as available IA_NA addresses.

4.4.  Creation of Renew Message by the Client

   During the Renew process, if the client prefers a prefix length
   different from the prefix it is currently using, then the client
   should two IA_PD options in the Renew message, one with the currently
   delegated prefix as the hint and the other with the preferred prefix
   length as the 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 unable to provide the client with the
   newly requested prefix, the client should continue using the prefix
   it currently has.

4.5.  Receipt of Renew Message by the Server

   Upon the receipt of Renew message, if the client included an IA_PD
   option with a prefix length hint different from the prefix that has
   been delegated to the client, the server should check to9 see whether
   it has a prefix matching the prefix length hint.

   If the server is able to provide a prefix matching the prefix length
   hint, then it should provide the new prefix to the client, while
   giving the old prefix a shorter lifetime.  This way, the client
   wouldn't have to deprecate the old prefix right away.

   If the server is unable to provide a prefix matching the newly

Cui, et al.              Expires January 7, 2016                [Page 7]
Internet-Draft      DHCPv6 Prefix Length Hint Issues           July 2015

   requested prefix length hint during Renew then it should just extend
   the lifetime of the old prefix.

   It's unnecessary for the server to remember what the client requested
   before.  The prefix length hint is reflecting what the client prefers
   at the time being.  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 in the Renew message might not be
   the same as the prefix length hint the client originally sent in the
   Solicit message.

4.6.  Creation of Rebind Message by the Client

   During the Rebind process, if the client prefers a prefix length
   different from the prefix it is currently using, then the client
   should check to see if any of the available servers have the prefix
   length preferred by the client.  The client should include two IA_PD
   options in the Rebind message, one with the currently delegated
   prefix as the hint, and the other with the preferred prefix length as
   the hint.  This is to extend lifetime of the prefix the client is
   currently using and also get the prefix the client prefers, and go
   through a graceful switch over.

4.7.  Receipt of Rebind Message by the Server

   Upon the receipt of Rebind message, if the client included an IA_PD
   option with a prefix length hint different from the prefix that has
   been delegated to the client, the server should check to see whether
   it has a prefix in its prefix pool that match the prefix length in
   the hint.

   If the server is able to provide a prefix matching the prefix length
   hint, then it should provide the new prefix to the client, while
   giving the old prefix a shorter lifetime.  This way, the client
   wouldn't have to deprecate the old prefix right away.

   If the server is unable to provide the client with the newly
   requested prefix during Rebind then it should just extend the
   lifetime of the old prefix.

5.  Security Considerations

   TBD.

Cui, et al.              Expires January 7, 2016                [Page 8]
Internet-Draft      DHCPv6 Prefix Length Hint Issues           July 2015

6.  IANA Considerations

   This document does not include an IANA request.

7.  Contributors List

   Many thanks to Qi Sun, Bernie Volz, Ole Troan.

8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

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

Cui, et al.              Expires January 7, 2016                [Page 9]