draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06.txt   rfc8168.txt 
DHC Working Group T. Li Internet Engineering Task Force (IETF) T. Li
Internet-Draft C. Liu Request for Comments: 8168 C. Liu
Intended status: Standards Track Y. Cui Category: Standards Track Y. Cui
Expires: October 2, 2017 Tsinghua University ISSN: 2070-1721 Tsinghua University
March 31, 2017 May 2017
DHCPv6 Prefix Length Hint Issues DHCPv6 Prefix-Length Hint Issues
draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06
Abstract Abstract
DHCPv6 Prefix Delegation (RFC3633) allows a client to include a DHCPv6 Prefix Delegation allows a client to include a prefix-length
prefix-length hint value in the IA_PD option to indicate a preference hint value in the IA_PD option to indicate a preference for the size
for the size of the prefix to be delegated, but is unclear about how of the prefix to be delegated, but it is unclear about how the client
the client and server should act in different situations involving and server should act in different situations involving the prefix-
the prefix-length hint. This document provides a summary of the length hint. This document provides a summary of the existing
existing problems with the prefix-length hint and guidance on what problems with the prefix-length hint and guidance on what the client
the client and server could do in different situations. and server could do in different situations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on October 2, 2017. 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 Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Problem Description and Proposed Solutions . . . . . . . . . 3 3. Problem Description and Proposed Solutions . . . . . . . . . 3
3.1. Creation of Solicit Message . . . . . . . . . . . . . . . 3 3.1. Creation of Solicit Message . . . . . . . . . . . . . . . 3
3.2. Receipt of Solicit message . . . . . . . . . . . . . . . 4 3.2. Receipt of Solicit Message . . . . . . . . . . . . . . . 4
3.3. Receipt of Advertise Message . . . . . . . . . . . . . . 5 3.3. Receipt of Advertise Message . . . . . . . . . . . . . . 5
3.4. Creation of Renew/Rebind Message . . . . . . . . . . . . 6 3.4. Creation of Renew/Rebind Message . . . . . . . . . . . . 6
3.5. Receipt of Renew/Rebind Message . . . . . . . . . . . . . 6 3.5. Receipt of Renew/Rebind Message . . . . . . . . . . . . . 6
3.6. General Recommendation . . . . . . . . . . . . . . . . . 8 3.6. General Recommendation . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Normative References . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
DHCPv6 Prefix Delegation [RFC3633] allows a client to include a DHCPv6 Prefix Delegation [RFC3633] allows a client to include a
prefix-length hint value in the message sent to the server, to 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 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 prefix-length hint is communicated by a client to the server by
including an IA_PD Prefix Option (IAPREFIX option), encapsulated in including an IA_PD Prefix Option (IAPREFIX option), encapsulated in
an IA_PD option, with the "IPv6 prefix" field set to zero and the 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 "prefix-length" field set to a non-zero value. The servers are free
to ignore the prefix-length hint values depending on server policy. to ignore the prefix-length hint values depending on server policy.
However, some clients may not be able to function (or only in a 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 degraded state) when they're provided with a prefix whose length is
different from what they requested. E.g. If the client is asking different from what they requested. For example, if the client is
for a /56 and the server returns a /64, the functionality of the asking for a /56 and the server returns a /64, the functionality of
client might be limited because it might not be able to split the 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 prefix for all its interfaces. For other hints, such as requesting
for an explicit address, this might be less critical as it just helps for an explicit address, this might be less critical, as it just
a client that wishes to continue using what it used last time. The helps a client that wishes to continue using what it used last time.
prefix-length hint directly impacts the operational capability of the The prefix-length hint directly impacts the operational capability of
client, thus should be given more consideration. the client; thus, it should be given more consideration.
[RFC3633] is unclear about how the client and server should act in [RFC3633] is unclear about how the client and server should act in
different situations involving the prefix-length hint. From the different situations involving the prefix-length hint. From the
client perspective, it should be able to use the prefix-length hint 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 to signal to the server its real-time need and should be able to
handle prefixes with lengths different from the prefix-length hint. handle prefixes with lengths different from the prefix-length hint.
This document provides guidance on what a client should do in This document provides guidance on what a client should do in
different situations to help it operate properly. From the server different situations to help it operate properly. From the server
perspective, the server is free to ignore the prefix-length hints perspective, the server is free to ignore the prefix-length hints
depending on server policy, but in cases where the server has a depending on server policy; however, in cases where the server has a
policy for considering the hint, this document provides guidance on policy for considering the hint, this document provides guidance on
how the prefix-length hint should be handled by the server in how the prefix-length hint should be handled by the server in
different situations. different situations.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "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. Problem Description and Proposed Solutions
3.1. Creation of Solicit Message 3.1. Creation of Solicit Message
Problem: Problem:
The Solicit message allows a client to ask servers for prefixes and The Solicit message allows a client to ask servers for prefixes and
other configuration parameters. The client might want a different other configuration parameters. The client might want a different
prefix length due to configuration changes or it might just want the prefix length due to configuration changes, or it might just want the
same prefix again after reboot. The client might also prefer a same prefix again after reboot. The client might also prefer a
prefix of specific length in case the requested prefix is not prefix of a specific length in case the requested prefix is not
available. The server could decide whether to provide the client available. The server could decide whether to provide the client
with the preferred prefix depending on server policy, but 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. 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 The server usually has a record of the prefix it gave to the client
during previous interactions. The best way to assure a completely during its most recent interaction. The best way to assure a
new delegated prefix is to send a new IAID (Identity Association completely new delegated prefix is to send a new IAID (Identity
IDentifier) in the IA_PD (Identity Association for Prefix Association IDentifier) in the IA_PD (Identity Association for Prefix
Delegation). However, this would require the client device to have Delegation). However, this would require the client device to have
persistent storage, since rebooting the device would cause the client persistent storage, because rebooting the device would cause the
to use the original IAID in the IA_PD. client to use the original IAID in the IA_PD.
Solution: Solution:
When the client prefers a prefix of specific length from the server, When the client prefers a prefix of a specific length from the
the client MUST send a Solicit message using the same IAID in the server, the client MUST send a Solicit message using the same IAID in
IAPD, include the preferred prefix-length value in the "prefix- the IA_PD, include the preferred prefix-length value in the "prefix-
length" field of the IAPREFIX option, and set the "IPv6 prefix" field 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 to zero. This is an indication to the server that the client prefers
a prefix of the specified length, regardless of what it had gotten a prefix of the specified length, regardless of what it received
before. before.
When the client wants the same prefix back from the server, it MUST When the client wants the same prefix back from the server, it MUST
send a Solicit message using the same IAID in the IAPD, include the 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 previously delegated prefix value in the "IPv6 prefix" field of the
IAPREFIX option, and the length of the prefix in the "prefix-length" IAPREFIX option, and include the length of the prefix in the "prefix-
field. This is an indication to the server that the client wants the length" field. This is an indication to the server that the client
same prefix back. wants the same prefix back.
When the client wants the same prefix back from the server and would 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 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 prefix is not available, the client MUST send a Solicit message using
the same IAID in the IAPD, include the previously delegated prefix in the same IAID in the IA_PD, include the previously delegated prefix
one IAPREFIX option, and include the prefix-length hint in another in one IAPREFIX option, and include the prefix-length hint in another
IAPREFIX option. There is no requirement to the order of the two IAPREFIX option. There is no requirement regarding the order of the
IAPREFIX options. two IAPREFIX options.
3.2. Receipt of Solicit message 3.2. Receipt of Solicit Message
Problem: Problem:
[RFC3633] allows a client to include a prefix-length hint in the [RFC3633] allows a client to include a prefix-length hint in the
Solicit message, to signal its preference to the server. It is Solicit message to signal its preference to the server. How the
unclear about how the prefix-length hint should be handled by the prefix-length hint should be handled by the server is unclear. The
server. The client might want a different prefix length due to client might want a different prefix length due to configuration
configuration changes or it might just want the same prefix again changes or it might just want the same prefix again after reboot.
after reboot. The server should interpret these cases differently. The server should interpret these cases differently.
Many servers are configured to provide only prefixes of specific Many servers are configured to provide only prefixes of specific
lengths to the client. E.g. If the client requested for a /54, and lengths to the client, for example, if the client requested for a /54
the server could only provide /30, /48, and /56. How should these but the server could only provide /30, /48, and /56. How should
servers decide which prefix to give to the client based on the these servers decide which prefix to give to the client based on the
prefix-length hint? prefix-length hint?
Solution: Solution:
Upon the receipt of Solicit message, if the client included only a 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-length hint in the message, the server SHOULD first check its
prefix pool for a prefix with length matching the prefix-length hint prefix pool for a prefix with a length matching the prefix-length
value, regardless of the prefix record from previous interactions hint value, regardless of the prefix record from previous
with the client. If the server does not have a prefix with length interactions with the client. If the server does not have a prefix
matching the prefix-length hint value, then the server SHOULD provide with a length matching the prefix-length hint value, then the server
the prefix whose length is shorter and closest to the prefix-length SHOULD provide the prefix whose length is shorter and closest to the
hint value. prefix-length hint value.
If the client included a specific prefix value in the Solicit If the client included a specific prefix value in the Solicit
message, the server SHOULD check its prefix pool for a prefix message, the server SHOULD check its prefix pool for a prefix
matching the requested prefix value. If the requested prefix is not matching the requested prefix value. If the requested prefix is not
available in the server's prefix pool, and the client also included a 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 prefix-length hint in the same IA_PD option, then the server SHOULD
check its prefix pool for a prefix with length matching the prefix- 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 length length hint value. If the server does not have a prefix with a
matching the prefix-length hint value, the server SHOULD provide the length matching the prefix-length hint value, the server SHOULD
prefix whose length is shorter and closest to the prefix-length hint provide the prefix whose length is shorter and closest to the prefix-
value. length hint value.
If the server will not assign any prefixes to any IA_PDs in a 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 subsequent Request from the client, the server MUST send an Advertise
message to the client as described in Section 11.2 of [RFC3633]. message to the client as described in Section 11.2 of [RFC3633].
3.3. Receipt of Advertise Message 3.3. Receipt of Advertise Message
Problem: Problem:
The server might not be able to honor the prefix-length hint due to 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 server policy or lack of resources in its prefix pool. If the prefix
length provided by the server in the Advertise message is different length provided by the server in the Advertise message is different
from what the client requested in the Solicit message, the question from what the client requested in the Solicit message, the question
would be whether the client should use the provided prefix length or would be whether the client should use the provided prefix length or
continue to ask for its preferred prefix length. There are certain continue to ask for its preferred prefix length. There are certain
situations where the client could not operate properly if it used a situations in which the client could not operate properly if it used
prefix whose length is different from what it requested in the a prefix whose length is different from what it requested in the
prefix-length hint. However, if the client ignores the Advertise prefix-length hint. However, if the client ignores the Advertise
messages, and continues to solicit for the preferred prefix length, messages and continues to solicit for the preferred prefix length,
the client might be stuck in the DHCP process. Another question is the client might be stuck in the DHCP process. Another question is
whether the client should ignore other configuration parameters such whether the client should ignore other configuration parameters such
as available addresses. as available addresses.
Solution: Solution:
If the client could use the prefixes included in the Advertise If the client could use the prefixes included in the Advertise
messages despite being different from the prefix-length hint, the messages despite being different from the prefix-length hint, the
client SHOULD choose the shortest prefix length which is closest to client SHOULD choose the shortest prefix length that is closest to
the prefix-length hint. The client SHOULD continue requesting for the prefix-length hint. The client SHOULD continue requesting the
the preferred prefix in the subsequent DHCPv6 messages as defined in preferred prefix in the subsequent DHCPv6 messages as defined in
section 3.4 of this document. Section 3.4 of this document.
If the client sent a Solicit with only IA_PDs and cannot use the If the client sent a Solicit with only IA_PDs and cannot use the
prefixes included in the Advertise messages, it MUST ignore the prefixes included in the Advertise messages, it MUST ignore the
Advertise messages and continue to send Solicit messages until it Advertise messages and continue to send Solicit messages until it
gets the preferred prefix. To avoid traffic congestion, the client gets the preferred prefix. To avoid traffic congestion, the client
MUST send Solicit messages at defined intervals, as specified in MUST send Solicit messages at defined intervals, as specified in
[RFC7083]. [RFC7083].
If the client also solicited for other stateful configuration options If the client also solicited for other stateful configuration options
such as IA_NAs and the client cannot use the prefixes included in the such as IA_NAs and the client cannot use the prefixes included in the
Advertise messages, the client SHOULD accept the other stateful Advertise messages, the client SHOULD accept the other stateful
configuration options and continue to request for the desired IA_PD configuration options and continue to request the desired IA_PD
prefix in subsequent DHCPv6 messages as specified in [RFC7550]. prefix in subsequent DHCPv6 messages as specified in [RFC7550].
3.4. Creation of Renew/Rebind Message 3.4. Creation of Renew/Rebind Message
Problem: Problem:
Servers might not be able to provide a prefix with length equal or Servers might not be able to provide a prefix with the length equal
shorter than the prefix-length hint. If the client decided to use to or shorter than the prefix-length hint. If the client decided to
the prefix provided by the server despite being longer than the use the prefix provided by the server despite it being longer than
prefix-length hint, but would still prefer the prefix-length hint it the prefix-length hint but would still prefer the prefix-length hint
originally requested in the Solicit message, there should be some way originally requested in the Solicit message, there should be some way
for the client to express this preference during Renew/Rebind. E.g. for the client to express this preference during Renew/Rebind. For
If the client requested for a /60 but got a /64, the client should be example, if the client requested for a /60 but got a /64, the client
able to signal to the server during Renew/Rebind that it would still should be able to signal to the server during Renew/Rebind that it
prefer a /60. This is to see whether the server has the prefix would still prefer a /60. This is to see whether the server has the
preferred by the client available in its prefix pool during Renew/ prefix preferred by the client available in its prefix pool during
Rebind. [RFC3633] is not completely clear on whether the client is Renew/Rebind. [RFC3633] is not completely clear on whether the
allowed to include a prefix-length hint in the Renew/Rebind message. client is allowed to include a prefix-length hint in the Renew/Rebind
message.
Solution: Solution:
During Renew/Rebind, if the client prefers a prefix length different During Renew/Rebind, if the client prefers a prefix length that is
from the prefix it is currently using, then the client SHOULD send different from the prefix it is currently using, then the client
the Renew/Rebind message with the same IA_PD, and include two SHOULD send the Renew/Rebind message with the same IA_PD, and include
IAPREFIX options, one containing the currently delegated prefix and two IAPREFIX options, one containing the currently delegated prefix
the other containing the prefix-length hint. This is to extend the and the other containing the prefix-length hint. This is to extend
lifetime of the prefix the client is currently using and also get the the lifetime of the prefix the client is currently using, get the
prefix the client prefers, and go through a graceful switch over. prefix the client prefers, and go through a graceful switch over.
If the server is unable to provide the client with the newly If the server is unable to provide the client with the newly
requested prefix, but is able to extend lifetime of the old prefix, requested prefix, but is able to extend lifetime of the old prefix,
the client SHOULD continue using the old prefix. the client SHOULD continue using the old prefix.
3.5. Receipt of Renew/Rebind Message 3.5. Receipt of Renew/Rebind Message
Problem: Problem:
The prefix preferred by the client might become available in the The prefix preferred by the client might become available in the
server's prefix pool during Renew/Rebind, but was unavailable during server's prefix pool during Renew/Rebind, even though it was
Solicit. This might be due to server configuration change or because unavailable during Solicit. This might be due to a server
some other client stopped using the prefix. configuration change or because some other client stopped using the
prefix.
The question is whether the server should remember the prefix-length The question is whether the server should remember the prefix-length
hint the client originally included in the Solicit message and check hint the client originally included in the Solicit message and check
during Renew/Rebind to see if it has the prefix length the client it during Renew/Rebind to see if it has the prefix length the client
preferred. This would require the server to keep extra information preferred. This would require the server to keep extra information
about the client. There is also the possibility that the client's about the client. There is also the possibility that the client's
preference for the prefix length might have changed during this time preference for the prefix length might have changed during this time
interval, so the prefix-length hint remembered by the server might interval, so the prefix-length hint remembered by the server might
not be what the client prefers during Renew/Rebind. not be what the client prefers during Renew/Rebind.
Instead of having the server remember the prefix-length hint of the Instead of having the server remember the prefix-length hint of the
client, another option is for the client to include the prefix-length client, another option is for the client to include the prefix-length
hint in the Renew/Rebind message. The current specification is hint in the Renew/Rebind message. [RFC3633] is unclear about what
unclear about what the server should do if the client also included the server should do if the client also included a prefix-length hint
in the Renew/Rebind message a prefix-length hint value, and whether value in the Renew/Rebind message and whether the server could
the server could provide a different prefix to the client during provide a different prefix to the client during Renew/Rebind.
Renew/Rebind.
Solution: Solution:
Upon the receipt of Renew/Rebind, if the client included in the IA_PD Upon the receipt of a Renew/Rebind message, if the client included in
both an IAPREFIX option with the delegated prefix value and an the IA_PD both an IAPREFIX option with the delegated prefix value and
IAPREFIX option with a prefix-length hint value, the server SHOULD an IAPREFIX option with a prefix-length hint value, the server SHOULD
check to see whether it could extend the lifetime of the original check whether it could extend the lifetime of the original delegated
delegated prefix and whether it has any available prefix matching the prefix and whether it has any available prefix matching the prefix-
prefix-length hint, or as close a possible to the prefix-length hint, length hint (or determine the closest possible to the prefix-length
within the server's limit. hint) within its limit.
If the server assigned the prefix included in IA_PD to the client, 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: the server SHOULD do one of the following, depending on its policy:
1. Extend lifetime of the original delegated prefix. 1. Extend the lifetime of the original delegated prefix.
2. Extend lifetime of the original delegated prefix and assign a new 2. Extend the lifetime of the original delegated prefix and assign a
prefix of the requested length. new prefix of the requested length.
3. Mark the original delegated prefix as invalid by giving it 0 3. Mark the original delegated prefix as invalid by giving it 0
lifetimes, and assign a new prefix of requested length. This avoids lifetimes, and assign a new prefix of the requested length. This
the complexity of handling multiple delegated prefixes, but may break avoids the complexity of handling multiple delegated prefixes but
all the existing connections of the client. may break all the existing connections of the client.
4. Assign the original delegated prefix with 0 preferred-lifetime, a 4. Assign the original delegated prefix with 0 preferred-lifetime, a
specific non-zero valid-lifetime depending on actual requirement, and specific non-zero valid-lifetime depending on actual requirement,
assign a new prefix of requested length. This allows the client to and assign a new prefix of the requested length. This allows the
finish up existing connections with the original prefix, and use the client to finish up existing connections with the original prefix
new prefix to establish new connections. and use the new prefix to establish new connections.
5. Do not include the original delegated prefix in the Reply 5. Do not include the original delegated prefix in the Reply message,
message, and assign a new prefix of requested length. The original and assign a new prefix of the requested length. The original
prefix would be valid until its lifetime expires. This avoids sudden prefix would be valid until its lifetime expires. This avoids
renumbering on the client. sudden renumbering on the client.
If the server does not know the client's bindings (e.g. a different If the server does not know the client's bindings (e.g., a different
server receiving the message during Rebind), then the server SHOULD server receiving the message during Rebind), then the server SHOULD
ignore the original delegated prefix, and try to assign a new prefix ignore the original delegated prefix and try to assign a new prefix
of requested length. of the requested length.
It's unnecessary for the server to remember the prefix-length hint It's unnecessary for the server to remember the prefix-length hint
the client requested during Solicit. It is possible that the the client requested during Solicit. It is possible that the
client's preference for the prefix length might have changed during client's preference for the prefix length might have changed during
this time interval, so the prefix-length hint in the Renew message is this time interval, so the prefix-length hint in the Renew message is
reflecting what the client prefers at the time. reflecting what the client prefers at the time.
3.6. General Recommendation 3.6. General Recommendation
The recommendation to address the issues discussed in this document, 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 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 specific prefix length to always include an IAPREFIX option with just
the prefix-length hint in addition to any IAPREFIX options it has the prefix-length hint in addition to any IAPREFIX options it has
included for each IA_PD in any Solicit, Request, Renew, and Rebind included for each IA_PD in any Solicit, Request, Renew, and Rebind
messages it sends. While a server is free to ignore the hint, messages it sends. While a server is free to ignore the hint,
servers that do not choose to ignore the hint should attempt to 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 assign a prefix of the hint length (or assign the next closest length
available. Whether a server favors the hint or avoiding a that does not exceed the hint) if one is available. Whether a server
renumbering event is a matter of server policy. favors the hint or avoiding a renumbering event is a matter of server
policy.
4. Security Considerations 4. Security Considerations
This document provides guidance on how the clients and servers This document provides guidance on how the clients and servers
interact with regard to the DHCPv6 prefix-length hint. Security interact with regard to the DHCPv6 prefix-length hint. Security
considerations in DHCP are described in Section 23 of [RFC3315]. considerations in DHCP are described in Section 23 of [RFC3315].
Security considerations regarding DHCPv6 prefix delegation are Security considerations regarding DHCPv6 prefix delegation are
described in Section 15 of [RFC3633]. described in Section 15 of [RFC3633].
5. IANA Considerations 5. IANA Considerations
This document does not include an IANA request. This document does not require any IANA actions.
6. 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, Hilarie Orman for their review and comments.
7. Normative References 6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <http://www.rfc-editor.org/info/rfc3315>.
skipping to change at page 9, line 19 skipping to change at page 9, line 14
[RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT
and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November
2013, <http://www.rfc-editor.org/info/rfc7083>. 2013, <http://www.rfc-editor.org/info/rfc7083>.
[RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and [RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and
Recommendations with Multiple Stateful DHCPv6 Options", Recommendations with Multiple Stateful DHCPv6 Options",
RFC 7550, DOI 10.17487/RFC7550, May 2015, RFC 7550, DOI 10.17487/RFC7550, May 2015,
<http://www.rfc-editor.org/info/rfc7550>. <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 Authors' Addresses
Tianxiang Li Tianxiang Li
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
P.R.China China
Phone: +86-18301185866 Phone: +86-18301185866
Email: peter416733@gmail.com Email: peter416733@gmail.com
Cong Liu Cong Liu
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
P.R.China China
Phone: +86-10-6278-5822 Phone: +86-10-6278-5822
Email: gnocuil@gmail.com Email: gnocuil@gmail.com
Yong Cui Yong Cui
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
P.R.China China
Phone: +86-10-6260-3059 Phone: +86-10-6260-3059
Email: yong@csnet1.cs.tsinghua.edu.cn Email: yong.cui.thu@gmail.com
 End of changes. 57 change blocks. 
158 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/