draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-02.txt   draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-03.txt 
DHC Working Group Y. Cui DHC Working Group T. Li
Internet-Draft T. Li Internet-Draft C. Liu
Intended status: Standards Track C. Liu Intended status: Standards Track Y. Cui
Expires: December 21, 2016 Tsinghua University Expires: January 27, 2017 Tsinghua University
June 19, 2016 July 26, 2016
DHCPv6 Prefix Length Hint Issues DHCPv6 Prefix Length Hint Issues
draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-02 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-03
Abstract Abstract
DHCPv6 Prefix Delegation [RFC3633] allows a requesting router to DHCPv6 Prefix Delegation [RFC3633] allows a client to include a
include a prefix-length hint value in the IA_PD option to indicate a prefix-length hint value in the IA_PD option to indicate a preference
preference for the size of the prefix to be delegated, but is unclear for the size of the prefix to be delegated, but is unclear about how
about how the requesting router and delegating router should act in the client and server should act in different situations involving
different situations involving the prefix-length hint. This document the prefix-length hint. This document provides a summary of the
provides a summary of the existing problems with the prefix-length existing problems with the prefix-length hint and guidance on what
hint and guidance on what the requesting router and delegating router the client and server could do in different situations.
could do in different situations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 21, 2016. This Internet-Draft will expire on January 27, 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 19 skipping to change at page 2, line 18
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 . . . . . . . . . . . . 5 3.4. Creation of Renew/Rebind Message . . . . . . . . . . . . 5
3.5. Receipt of Renew/Rebind Message . . . . . . . . . . . . . 6 3.5. Receipt of Renew/Rebind Message . . . . . . . . . . . . . 6
3.6. General Recommendation . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
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 requesting router to DHCPv6 Prefix Delegation [RFC3633] allows a client to include a
include a prefix-length hint value in the message sent to the prefix-length hint value in the message sent to the server, to
delegating router, to indicate a preference for the size of the indicate a preference for the size of the prefix to be delegated. A
prefix to be delegated. A prefix-length hint is communicated by a prefix-length hint is communicated by a client to the server by
requesting router to the delegating router by including an IA_PD including an IA_PD Prefix Option(IAPREFIX option), encapsulated in an
Prefix Option(OPTION_IAPREFIX), encapsulated in an IA_PD option, with IA_PD option, with the "IPv6 prefix" field set to zero and the
the "IPv6 prefix" field set to zero and the "prefix-length" field set "prefix-length" field set to a non-zero value. The servers are free
to a non-zero value. The delegating routers are free to ignore the to ignore the prefix-length hint values depending on server policy.
prefix-length hint values depending on server policy. However, some However, some clients may not be able to function (or only in a
requesting routers may not be able to function (or only in a degraded degraded state) when they're provided with a prefix which length is
state) when they're provided with a prefix which length is different different from what they requested. E.g. If the client is asking
from what they requested. E.g. If the requesting router is asking for a /56 and the server returns a /64, the functionality of the
for a /56 and the delegating router returns a /64, the functionality client might be limited because it might not be able to split the
of the requesting router might be limited because it might not be prefix for all its interfaces. For other hints, such as requesting
able to split the prefix for all its interfaces. For other hints, for a explicit address, this might be less critical as it just helps
such as requesting for a explicit address or lifetime, this might be a client that wishes to continue using what it used last time. The
less critical as it just help a client that wishes to continue using prefix-length hint directly impacts the operational capability of the
what it used last time, or a client that wants to Renew its lease for client, thus should be given more consideration.
a certain period of time. The prefix-length hint directly impacts
the operational capability of the requesting router, thus should be
given more consideration.
[RFC3633] is unclear about how the requesting router and delegating [RFC3633] is unclear about how the client and server should act in
router should act in different situations involving the prefix-length different situations involving the prefix-length hint. From the
hint. From the requesting router perspective, it should be able to client perspective, it should be able to use the prefix-length hint
use the prefix-length hint to signal to the delegating router its to signal to the server its real time need and it should be able to
real time need and it should be able to handle the prefixes which handle prefixes with lengths different from the prefix-length hint.
lengths are different from the prefix-length hint. This document This document provides guidance on what a client should do in
provides guidance on what a requesting router should do in different different situations to help it operate properly. From the server
situations to help it operate properly. From the delegating router perspective, the server is free to ignore the prefix-length hints
perspective, the delegating router is free to ignore the prefix- depending on server policy, but in cases where the server has a
length hints depending on server policy, but in cases where the policy for considering the hint, this document provides guidance on
delegating router has a policy for considering the hint, this how the prefix-length hint should be handled by the server in
document provides guidance on how the prefix-length hint should be different situations.
handled by the delegating router in 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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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 requesting router to ask delegating The Solicit message allows a client to ask servers for prefixes and
routers for prefixes and other configuration parameters. The other configuration parameters. The client might want a different
requesting router might want a different prefix length due to prefix length due to configuration changes or it might just want the
configuration changes or it might just want the same prefix again same prefix again after reboot. The client might also prefer a
after reboot. The delegating router could decide whether to provide prefix of specific length in case the requested prefix is not
the requesting router with the preferred prefix depending on server available. The server could decide whether to provide the client
policy, but the requesting router should be able to signal to the with the preferred prefix depending on server policy, but the client
delegating router its real time need. should be able to signal to the server its real time need.
The delegating routers usually has a record of the prefix it gave to The servers usually has a record of the prefix it gave to the client
the requesting router during previous interactions. The best way to during previous interactions. The best way to assure a completely
assure a completely new delegated prefix is to send a new IAID in the new delegated prefix is to send a new IAID in the IA_PD. However,
IA_PD. However, this would require the requesting router device to this would require the client device to have persistant storage,
have persistant storage, since rebooting the device would cause the since rebooting the device would cause the client to use the original
requesting router to use the original IAID in the IA_PD. IAID in the IA_PD.
Solution: Solution:
When the requesting router prefers a prefix of specific length from When the client prefers a prefix of specific length from the server,
the delegating router, the requesting router SHOULD send a Solicit the client MUST send a Solicit message using the same IAID in the
message using the same IAID in the IAPD, include the preferred IAPD, include the preferred prefix-length value in the "prefix-
prefix-length value in the "prefix-length" field of the length" field of the IAPREFIX option, and set the "IPv6 prefix" field
OPTION_IAPREFIX option, and set the "IPv6 prefix" field to zero. to zero. This is an indiction to the server that the client prefers
This is an indiction to the delegating router that the requesting a prefix of the specified length, regardless of what it had gotten
router prefers a prefix of the specified length, regardless of what before.
it had gotten before.
When the requesting router wants the same prefix back from the When the client wants the same prefix back from the server, it MUST
delegating router, it SHOULD send a Solicit message using the same send a Solicit message using the same IAID in the IAPD, include the
IAID in the IAPD, include the previously delegated prefix value in previously delegated prefix value in the "IPv6 prefix" field of the
the "IPv6 prefix" field of the OPTION_IAPREFIX option, and the length IAPREFIX option, and the length of the prefix in the "prefix-length"
of the prefix in the "prefix-length" field. This is an indication to field. This is an indication to the server that the client wants the
the delegating router that the requesting router wants the same same prefix back.
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 3.2. Receipt of Solicit message
Problem: Problem:
[RFC3633] allows a requesting router to include a prefix-length hint [RFC3633] allows a client to include a prefix-length hint in the
in the Solicit message, to signal its preference to the delegating Solicit message, to signal its preference to the server. It is
router. It is unclear about how the prefix-length hint should be unclear about how the prefix-length hint should be handled by the
handled by the delegating router. The requesting router might want a server. The client might want a different prefix length due to
different prefix length due to configuration changes or it might just configuration changes or it might just want the same prefix again
want the same prefix again after reboot. The delegating router after reboot. The server should interpret these cases differently.
should interpret these cases differently.
Many delegating routers are configured to provide only prefixes of Many servers are configured to provide only prefixes of specific
specific lengths to the requesting router. E.g. If the requesting lengths to the client. E.g. If the client requested for a /54, and
router requested for a /54, and the delegating router could only the server could only provide /30, /48, and /56. How should these
provide /30, /48, and /56. How should these delegating routers servers decide which prefix to give to the client based on the
decide which prefix to give to the requesting router based on the
prefix-length hint? prefix-length hint?
Solution: Solution:
Upon the receipt of Solicit message, if the requesting router Upon the receipt of Solicit message, if the client included only a
included only a prefix-length hint in the message, the delegating prefix-length hint in the message, the server SHOULD first check its
router SHOULD first check its prefix pool for a prefix with length prefix pool for a prefix with length matching the prefix-length hint
matching the prefix-length hint value, regardless of the prefix value, regardless of the prefix record from previous interactions
record from previous interactions with the requesting router. If the with the client. If the server does not have a prefix with length
delegating router does not have a prefix with length matching the matching the prefix-length hint value, then the server SHOULD provide
prefix-length hint value, then the delegating router SHOULD provide
the prefix with the shortest length possible which is closest to the the prefix with the shortest length possible which is closest to the
prefix-length hint value. prefix-length hint value.
If the requesting router included a specific prefix value and the If the client included a specific prefix value in the Solicit
corresponding prefix-length value in the Solicit message, the message, the server SHOULD check its prefix pool for a prefix
delegating router SHOULD first try to check its prefix pool for a matching the requested prefix value. If the requested prefix is not
prefix matching the requested prefix value. If the requested prefix available in the server's prefix pool, and the client also included a
is not available in the delegating router's prefix pool, then the prefix-length hint in the same IA_PD option, then the server SHOULD
delegating router SHOULD try to provide a prefix matching the prefix- try to provide a prefix matching the prefix-length value, or the
length value, or the prefix with the shortest length possible which prefix with the shortest length possible which is closest to the
is closest to the prefix-length value. prefix-length hint value.
3.3. Receipt of Advertise Message 3.3. Receipt of Advertise Message
Problem: Problem:
The delegating router might not be able to honor the prefix-length The server might not be able to honor the prefix-length hint due to
hint due to server policy or lack of resources in its prefix pool. server policy or lack of resources in its prefix pool. If the prefix
If the prefix length provided by the delegating router in the length provided by the server in the Advertise message is different
Advertise message is different from what the requesting router from what the client requested in the Solicit message, the question
requested in the Solicit message, the question would be whether the would be whether the client should use the provided prefix length or
requesting router should use the provided prefix length or continue continue to ask for its preferred prefix length. There are certain
to ask for its preferred prefix length. There are certain situations situations where the client could not operate properly if it used a
where the requesting router could not operate properly if it used a
prefix which length is different from what it requested in the prefix which length is different from what it requested in the
prefix-length hint. However, if the requesting router ignores the prefix-length hint. However, if the client ignores the Advertise
Advertise messages, and continues to solicit for the preferred prefix messages, and continues to solicit for the preferred prefix length,
length, the requesting router might be stuck in the DHCP process. the client might be stuck in the DHCP process. Another question is
Another question is whether the requesting router should ignore other whether the client should ignore other configuration parameters such
configuration parameters such as available addresses. as available addresses.
Solution: Solution:
If the requesting router could use the prefixes provided by the If the client could use the prefixes included in the Advertise
delegating routers despite being different from the prefix-length messages despite being different from the prefix-length hint, the
hint, the requesting router SHOULD choose the shortest prefix length client SHOULD choose the shortest prefix length which is closest to
which is closest to the prefix-length hint. 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 cannot use the prefixes provided by the If the client Solicted for only IA_PDs and cannot use the prefixes
delegating routers, it MUST ignore the Advertise messages and included in the Advertise messages, it MUST ignore the Advertise
continue to send Solicit messages until it gets the preferred prefix. messages and continue to send Solicit messages until it gets the
To avoid traffic congestion, the requesting router MUST send Solicit preferred prefix. To avoid traffic congestion, the client MUST send
messages at defined intervals, as specified in [RFC7083]. Solicit messages at defined intervals, as specified in [RFC7083].
If the requesting router also Solicited for other stateful If the client also Solicited for other stateful configuration options
configuration options such as IA_NAs, the requesting router SHOULD such as IA_NAs and the client cannot use the prefixes included in the
accept the stateful configuration options and continue to request for Advertise messages, the client SHOULD accept the other stateful
the desired IA_PD prefix in subsequent DHCPv6 messages as specified configuration options and continue to request for the desired IA_PD
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:
Delegating routers might not be able to provide a prefix with length servers might not be able to provide a prefix with length equal or
equal or shorter than the prefix-length hint. If the requesting shorter than the prefix-length hint. If the client decided to use
router decided to use the prefix provided by the delegating router the prefix provided by the server despite being longer than the
despite being longer than the prefix-length hint, but would still prefix-length hint, but would still prefer the prefix-length hint it
prefer the prefix-length hint it originally requested in the Solicit originally requested in the Solicit message, there should be some way
message, there should be some way for the requesting router to for the client to express this preference during Renew/Rebind. E.g.
express this preference during Renew/Rebind. E.g. If the requesting If the client requested for a /60 but got a /64, the client should be
router requested for a /60 but got a /64, the requesting router able to signal to the server during Renew/Rebind that it would still
should be able to signal to the delegating router during Renew/Rebind prefer a /60. This is to see whether the server has the prefix
that it would still prefer a /60. This is to see whether the preferred by the client available in its prefix pool during Renew/
delegating router has the prefix preferred by the requesting router Rebind. [RFC3633] is not completely clear on whether the client is
available in its prefix pool during Renew/Rebind. [RFC3633] is not allowed to include a prefix-length hint in the Renew/Rebind message.
completely clear on whether the requesting router is allowed to
include a prefix-length hint in the Renew/Rebind message.
Solution: Solution:
During Renew/Rebind, if the requesting router prefers a prefix length During Renew/Rebind, if the client prefers a prefix length different
different from the prefix it is currently using, then the requesting from the prefix it is currently using, then the client SHOULD send
router SHOULD send the Renew/Rebind message with the same IA_PD, and the Renew/Rebind message with the same IA_PD, and include two
include two OPTION_IAPREFIX options, one containing the currently IAPREFIX options, one containing the currently delegated prefix and
delegated prefix and the other containing the prefix-length hint. the other containing the prefix-length hint. This is to extend the
This is to extend the lifetime of the prefix the requesting router is lifetime of the prefix the client is currently using and also get the
currently using and also get the prefix the requesting router prefix the client prefers, and go through a graceful switch over.
prefers, and go through a graceful switch over.
If the delegating router is unable to provide the requesting router If the server is unable to provide the client with the newly
with the newly requested prefix, but is able to extend lifetime of requested prefix, but is able to extend lifetime of the old prefix,
the old prefix, the requesting router SHOULD continue using the old the client SHOULD continue using the old prefix.
prefix.
3.5. Receipt of Renew/Rebind Message 3.5. Receipt of Renew/Rebind Message
Problem: Problem:
The prefix preferred by the requesting router might become available The prefix preferred by the client might become available in the
in the delegating router's prefix pool during Renew/Rebind, but was server's prefix pool during Renew/Rebind, but was unavailable during
unavailable during Solicit. This might be due to delegating router Solicit. This might be due to server configuration change or because
configuration change or because some other requesting router stopped some other client stopped using the prefix.
using the prefix.
The question is whether the delegating router should remember the The question is whether the server should remember the prefix-length
prefix-length hint the requesting router originally included in the hint the client originally included in the Solicit message and check
Solicit message and check during Renew/Rebind to see if it has the during Renew/Rebind to see if it has the prefix length the client
prefix length the requesting router preferred. This would require preferred. This would require the server to keep extra information
the delegating router to keep extra information about the requesting about the client. There is also the possibility that the client's
router. There is also the possibility that the requesting router'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 delegating interval, so the prefix-length hint remembered by the server might
router might not be what the requesting router prefers during Renew/ not be what the client prefers during Renew/Rebind.
Rebind.
Instead of having the delegating router remember the prefix-length Instead of having the server remember the prefix-length hint of the
hint of the requesting router, another option is for the requesting client, another option is for the client to include the prefix-length
router to include the prefix-length hint in the Renew/Rebind message. hint in the Renew/Rebind message. The current specification is
The current specification is unclear about what the delegating router unclear about what the server should do if the client also included
should do if the requesting router also included in the Renew/Rebind in the Renew/Rebind message a prefix-length hint value, and whether
message a prefix-length hint value, and whether the delegating router the server could provide a different prefix to the client during
could provide a different prefix to the requesting router during
Renew/Rebind. Renew/Rebind.
Solution: Solution:
Upon the receipt of Renew/Rebind, if the requesting router included Upon the receipt of Renew/Rebind, if the client included in the IA_PD
in the IA_PD both OPTION_IAPREFIX option with the delegated prefix both an IAPREFIX option with the delegated prefix value and an
value and an OPTION_IAPREFIX option with a prefix-length hint value, IAPREFIX option with a prefix-length hint value, the server SHOULD
the delegating router SHOULD check to see whether it could extend the check to see whether it could extend the lifetime of the original
lifetime of the original delegated prefix and whether it has any delegated prefix and whether it has any available prefix matching the
available prefix matching the prefix-length hint, or as close a prefix-length hint, or as close a possible to the prefix-length hint,
possible to the prefix-length hint, within the delegating router's within the server's limit.
limit.
If the delegating router assigned the prefix included in IA_PD to the If the server assigned the prefix included in IA_PD to the client,
requesting router, the delegating router SHOULD do one of the the server SHOULD do one of the following, depending on its policy:
following, depending on its policy:
1. Extend lifetime of the original delegated prefix. 1. Extend lifetime of the original delegated prefix.
2. Extend lifetime of the original delegated prefix and assign a new 2. Extend lifetime of the original delegated prefix and assign a new
prefix of the requested length. 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 requested length. This avoids
the complexity of handling multiple delegated prefixes, but may break the complexity of handling multiple delegated prefixes, but may break
all the existing connections of the requesting router. 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 requesting router to finish up existing length. This allows the client to finish up existing connections
connections with the original prefix, and use the new prefix to with the original prefix, and use the new prefix to establish new
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 it's lifetime expires. This avoids
sudden renumbering on the requesting router. sudden renumbering on the client.
If the delegating router does not know the requesting router's If the server does not know the client's bindings(e.g. a different
bindings(e.g. a different delegating router receiving the message server receiving the message during Rebind), then the server SHOULD
during Rebind), then the delegating router SHOULD ignore the original ignore the original delegated prefix, and try to assign a new prefix
delegated prefix, and try to assign a new prefix of requested length. of requested length.
It's unnecessary for the delegating router to remember the prefix- It's unnecessary for the server to remember the prefix-length hint
length hint the requesting router requested during Solicit. It is the client requested during Solicit. It is possible that the
possible that the requesting router's preference for the prefix client's preference for the prefix length might have changed during
length might have changed during this time interval, so the prefix- this time interval, so the prefix-length hint in the Renew message is
length hint in the Renew message is reflecting what the requesting reflecting what the client prefers at the time.
router 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 4. Security Considerations
This document introduces no new security considerations over those This document introduces no new security considerations over those
already discussed in section 15 of RFC3633, as this document provides already discussed in section 15 of RFC3633, as this document provides
guidance on how the requesting routers and delegating routers guidance on how the clients and servers interact with regard to the
interact with regard to the prefix-length hint mechanism introduced prefix-length hint mechanism introduced in RFC3633.
in RFC3633.
5. IANA Considerations 5. IANA Considerations
This document does not include an IANA request. This document does not include an IANA request.
6. Contributors List 6. Contributors List
Many thanks to Qi Sun, Bernie Volz, Ole Troan, Sunil Gandhewar, Many thanks to Qi Sun, Bernie Volz, Ole Troan, Sunil Gandhewar,
Marcin Siodelski. Marcin Siodelski.
skipping to change at page 9, line 7 skipping to change at page 9, line 12
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>.
Authors' Addresses 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 Tianxiang Li
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
P.R.China P.R.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 P.R.China
Phone: +86-10-6278-5822 Phone: +86-10-6278-5822
Email: gnocuil@gmail.com 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
 End of changes. 37 change blocks. 
216 lines changed or deleted 208 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/