draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-03.txt   draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-04.txt 
DHC Working Group T. Li DHC Working Group T. Li
Internet-Draft C. Liu Internet-Draft C. Liu
Intended status: Standards Track Y. Cui Intended status: Standards Track Y. Cui
Expires: January 27, 2017 Tsinghua University Expires: April 20, 2017 Tsinghua University
July 26, 2016 October 17, 2016
DHCPv6 Prefix Length Hint Issues DHCPv6 Prefix Length Hint Issues
draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-03 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-04
Abstract Abstract
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 IA_PD option to indicate a preference 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 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 client and server should act in different situations involving
the prefix-length hint. This document provides a summary of the the prefix-length hint. This document provides a summary of the
existing problems with the prefix-length hint and guidance on what existing problems with the prefix-length hint and guidance on what
the client and server could do in different situations. the client and server could do in different situations.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 27, 2017. This Internet-Draft will expire on April 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 31 skipping to change at page 2, line 31
6. Contributors List . . . . . . . . . . . . . . . . . . . . . . 8 6. Contributors List . . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . 8
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 an including an IA_PD Prefix Option (IAPREFIX option), encapsulated in
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 which length is degraded state) when they're provided with a prefix which length is
different from what they requested. E.g. If the client is asking 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 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 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 a explicit address, this might be less critical as it just helps 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 a client that wishes to continue using what it used last time. The
prefix-length hint directly impacts the operational capability of the prefix-length hint directly impacts the operational capability of the
client, thus should be given more consideration. client, thus 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 it 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
skipping to change at page 3, line 35 skipping to change at page 3, line 35
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 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 servers usually has a record of the prefix it gave to the client The servers usually has a record of the prefix it gave to the client
during previous interactions. The best way to assure a completely during previous interactions. The best way to assure a completely
new delegated prefix is to send a new IAID in the IA_PD. However, new delegated prefix is to send a new IAID in the IA_PD. However,
this would require the client device to have persistant storage, this would require the client device to have persistent storage,
since rebooting the device would cause the client to use the original since rebooting the device would cause the client to use the original
IAID in the IA_PD. 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 specific length from the server,
the client MUST send a Solicit message using the same IAID in the the client MUST send a Solicit message using the same IAID in the
IAPD, include the preferred prefix-length value in the "prefix- IAPD, 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 indiction 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 had gotten
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 IAPD, 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 the length of the prefix in the "prefix-length"
field. This is an indication to the server that the client wants the field. This is an indication to the server that the client wants the
same prefix back. 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 specified length in case the requested
prefix is not avaiable, 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 IAPD, include the previously delegated prefix in
one IAPREFIX option, and include the prefix-length hint in another one IAPREFIX option, and include the prefix-length hint in another
IAPREFIX option. IAPREFIX option.
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. It is
skipping to change at page 5, line 32 skipping to change at page 5, line 32
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 which is closest to
the prefix-length hint. The client SHOULD continue requesting for the prefix-length hint. The client SHOULD continue requesting for
the preferred prefix in the subsequent DHCPv6 messages as defined in the 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 Solicted for only IA_PDs and cannot use the prefixes If the client sent a Solicit with only IA_PDs and cannot use the
included in the Advertise messages, it MUST ignore the Advertise prefixes included in the Advertise messages, it MUST ignore the
messages and continue to send Solicit messages until it gets the Advertise messages and continue to send Solicit messages until it
preferred prefix. To avoid traffic congestion, the client MUST send gets the preferred prefix. To avoid traffic congestion, the client
Solicit messages at defined intervals, as specified in [RFC7083]. MUST send Solicit messages at defined intervals, as specified in
[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 for 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 length equal or
shorter than the prefix-length hint. If the client decided to use shorter than the prefix-length hint. If the client decided to use
the prefix provided by the server despite being longer than the the prefix provided by the server despite being longer than the
prefix-length hint, but would still prefer the prefix-length hint it prefix-length hint, but would still prefer the prefix-length hint it
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. E.g.
If the client requested for a /60 but got a /64, the client should be 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 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 prefer a /60. This is to see whether the server has the prefix
preferred by the client available in its prefix pool during Renew/ preferred by the client available in its prefix pool during Renew/
Rebind. [RFC3633] is not completely clear on whether the client is Rebind. [RFC3633] is not completely clear on whether the client is
skipping to change at page 7, line 36 skipping to change at page 7, line 36
all the existing connections of the client. 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
short non-zero valid-lifetime, and assign a new prefix of requested short non-zero valid-lifetime, and assign a new prefix of requested
length. This allows the client to finish up existing connections length. This allows the client to finish up existing connections
with the original prefix, and use the new prefix to establish new with the original prefix, and use the new prefix to establish new
connections. connections.
5. Do not include the original delegated prefix in the Reply 5. Do not include the original delegated prefix in the Reply
message, and assign a new prefix of requested length. The original message, and assign a new prefix of requested length. The original
prefix would be valid until it's lifetime expires. This avoids prefix would be valid until its lifetime expires. This avoids sudden
sudden renumbering on the client. 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 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.
 End of changes. 13 change blocks. 
20 lines changed or deleted 21 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/