draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-00.txt   draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01.txt 
DHC Working Group Y. Cui DHC Working Group Y. Cui
Internet-Draft T. Li Internet-Draft T. Li
Intended status: Informational C. Liu Intended status: Informational C. Liu
Expires: July 16, 2016 Tsinghua University Expires: October 30, 2016 Tsinghua University
January 13, 2016 April 28, 2016
DHCPv6 Prefix Length Hint Issues DHCPv6 Prefix Length Hint Issues
draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-00 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01
Abstract Abstract
DHCPv6 Prefix Delegation [RFC3633] allows a requesting router to DHCPv6 Prefix Delegation [RFC3633] allows a requesting router to
include a prefix-length hint value in the IA_PD option to indicate a include a prefix-length hint value in the IA_PD option to indicate a
preference for the size of the prefix to be delegated, but is unclear preference for the size of the prefix to be delegated, but is unclear
about how the requesting router and delegating router should act in about how the requesting router and delegating router should act in
different situations involving the prefix-length hint. This document different situations involving the prefix-length hint. This document
provides a summary of the existing problems with the prefix-length provides a summary of the existing problems with the prefix-length
hint and guidance on what the requesting router and delegating router hint and guidance on what the requesting router and delegating router
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 July 16, 2016. This Internet-Draft will expire on October 30, 2016.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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. Problem Description and Proposed Solutions . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
2.1. Creation of Solicit Message . . . . . . . . . . . . . . . 3 3. Problem Description and Proposed Solutions . . . . . . . . . 3
2.2. Receipt of Solicit message . . . . . . . . . . . . . . . 4 3.1. Creation of Solicit Message . . . . . . . . . . . . . . . 3
2.3. Receipt of Advertise Message . . . . . . . . . . . . . . 5 3.2. Receipt of Solicit message . . . . . . . . . . . . . . . 4
2.4. Creation of Renew/Rebind Message . . . . . . . . . . . . 5 3.3. Receipt of Advertise Message . . . . . . . . . . . . . . 5
2.5. Receipt of Renew/Rebind Message . . . . . . . . . . . . . 6 3.4. Creation of Renew/Rebind Message . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 3.5. Receipt of Renew/Rebind Message . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Contributors List . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Normative References . . . . . . . . . . . . . . . . . . . . 8 6. Contributors List . . . . . . . . . . . . . . . . . . . . . . 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 requesting router to
include a prefix-length hint value in the message sent to the include a prefix-length hint value in the message sent to the
delegating router, to indicate a preference for the size of the delegating router, to indicate a preference for the size of the
prefix to be delegated. A prefix-length hint is communicated by a prefix to be delegated. A prefix-length hint is communicated by a
requesting router to the delegating router by including an IA_PD requesting router to the delegating router by including an IA_PD
Prefix Option(OPTION_IAPREFIX), encapsulated in an IA_PD option, with Prefix Option(OPTION_IAPREFIX), encapsulated in an IA_PD option, with
skipping to change at page 3, line 8 skipping to change at page 3, line 9
real time need and it should be able to handle the prefixes which real time need and it should be able to handle the prefixes which
lengths are different from the prefix-length hint. This document lengths are different from the prefix-length hint. This document
provides guidance on what a requesting router should do in different provides guidance on what a requesting router should do in different
situations to help it operate properly. From the delegating router situations to help it operate properly. From the delegating router
perspective, the delegating router is free to ignore the prefix- perspective, the delegating router is free to ignore the prefix-
length hints depending on server policy, but in cases where the length hints depending on server policy, but in cases where the
delegating router has a policy for considering the hint, this delegating router has a policy for considering the hint, this
document provides guidance on how the prefix-length hint should be document provides guidance on how the prefix-length hint should be
handled by the delegating router in different situations. handled by the delegating router in different situations.
2. Problem Description and Proposed Solutions 2. Requirements Language
2.1. Creation of Solicit Message The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Problem Description and Proposed Solutions
3.1. Creation of Solicit Message
Problem: Problem:
The Solicit message allows a requesting router to ask delegating The Solicit message allows a requesting router to ask delegating
routers for prefixes and other configuration parameters. When the routers for prefixes and other configuration parameters. When the
requesting router's configuration changes, it might require a prefix requesting router's configuration changes, it might require a prefix
length different from what it had previously gotten. The delegating length different from what it had previously gotten. The delegating
router usually has a record of the prefix it delegated to the router usually has a record of the prefix it delegated to the
requesting router during previous interactions. How should the requesting router during previous interactions. How should the
requesting router avoid getting the same prefix back from the requesting router avoid getting the same prefix back from the
skipping to change at page 3, line 35 skipping to change at page 3, line 42
requesting router should be able to signal to the delegating router requesting router should be able to signal to the delegating router
whether it wants a different prefix or the same prefix. The best way whether it wants a different prefix or the same prefix. The best way
to assure a completely new delegated prefix is to send a new IAID in to assure a completely new delegated prefix is to send a new IAID in
the IA_PD. However, this would require the requesting router device the IA_PD. However, this would require the requesting router device
to have persistant storage, since rebooting the device would cause to have persistant storage, since rebooting the device would cause
the requesting router to use the original IAID in the IA_PD. the requesting router to use the original IAID in the IA_PD.
Solution: Solution:
When the requesting router prefers a prefix of specific length from When the requesting router prefers a prefix of specific length from
the delegating router, the requesting router should send a Solicit the delegating router, the requesting router SHOULD send a Solicit
message including the preferred prefix-length value in the "prefix- message including the preferred prefix-length value in the "prefix-
length" field of the OPTION_IAPREFIX option, and set the "IPv6 length" field of the OPTION_IAPREFIX option, and set the "IPv6
prefix" field to zero. This is an indiction to the delegating router prefix" field to zero. This is an indiction to the delegating router
that the requesting router prefers a prefix of specific length, that the requesting router prefers a prefix of specific length,
regardless of what it had gotten before. regardless of what it had gotten before.
When the requesting router wants the same prefix back from the When the requesting router wants the same prefix back from the
delegating router, it should include the prefix value in the "IPv6 delegating router, it SHOULD include the prefix value in the "IPv6
prefix" field of the OPTION_IAPREFIX option, and the length of the prefix" field of the OPTION_IAPREFIX option, and the length of the
prefix in the "prefix-length" field. This is an indication to the prefix in the "prefix-length" field. This is an indication to the
delegating router that the requesting router wants the same prefix delegating router that the requesting router wants the same prefix
back. back.
2.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 requesting router to include a prefix-length hint
in the Solicit message, to signal its preference to the delegating in the Solicit message, to signal its preference to the delegating
router. It is unclear about how this prefix-length hint should be router. It is unclear about how this prefix-length hint should be
handled by the delegating router, whether to honor the prefix-length handled by the delegating router, whether to honor the prefix-length
hint or provide the prefix from previous interactions with the hint or provide the prefix from previous interactions with the
requesting router. The requesting router might want a different requesting router. The requesting router 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
skipping to change at page 4, line 30 skipping to change at page 4, line 33
specific lengths to the requesting router. E.g. If the requesting specific lengths to the requesting router. E.g. If the requesting
router requested for a /54, and the delegating router could only router requested for a /54, and the delegating router could only
provide /30, /48, and /56. How should these delegating routers provide /30, /48, and /56. How should these delegating routers
decide which prefix to give to the requesting router 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 requesting router
included only a prefix-length hint in the message, the delegating included only a prefix-length hint in the message, the delegating
router should try to honor the prefix-length hint within bounds of router SHOULD try to honor the prefix-length hint within bounds of
what the delegating router is configured to return, regardless of the what the delegating router is configured to return, regardless of the
prefix record from previous interactions with the requesting router. prefix record from previous interactions with the requesting router.
The delegating router should regard the prefix-length hint in the The delegating router SHOULD regard the prefix-length hint in the
Solicit message as the prefix length most preferred by the requesting Solicit message as the prefix length most preferred by the requesting
router at the time. router at the time.
If the requesting router included a specific prefix value and the If the requesting router included a specific prefix value and the
corresponding prefix-length value in the Solicit message, the corresponding prefix-length value in the Solicit message, the
delegating router should first try to provide the requested prefix to delegating router SHOULD first try to provide the requested prefix to
the requesting router. If the requested prefix is not available in the requesting router. If the requested prefix is not available in
the delegating router's prefix pool, then the delegating router the delegating router's prefix pool, then the delegating router
should try to provide a prefix matching the prefix-length value. SHOULD try to provide a prefix matching the prefix-length value.
The delegating router might not have prefixes exactly matching the The delegating router might not have prefixes exactly matching the
prefix-length hint. In this situation, the delegating router should prefix-length hint. In this situation, the delegating router SHOULD
provide the shortest prefix length possible which is closest to the provide the shortest prefix length possible which is closest to the
prefix-length hint. E.g. If the delegating router could only prefix-length hint. E.g. If the delegating router could only
provide prefixes of lengths /30, /48, and /56, and the requesting provide prefixes of lengths /30, /48, and /56, and the requesting
router is requesting for a /50 in the prefix-length hint, then the router is requesting for a /50 in the prefix-length hint, then the
delegating router should provide the /48 to the requesting router. delegating router should provide the /48 to the requesting router.
2.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 delegating router might not be able to honor the prefix-length
hint due to server policy. If the prefix length provided by the hint due to server policy. If the prefix length provided by the
delegating router in the Advertise message is different from what the delegating router in the Advertise message is different from what the
requesting router requested in the Solicit message, the question requesting router requested in the Solicit message, the question
would be whether the requesting router should use the provided prefix would be whether the requesting router should use the provided prefix
length or continue to ask for its preferred prefix length. There are length or continue to ask for its preferred prefix length. There are
certain situations where the requesting router could not operate certain situations where the requesting router could not operate
skipping to change at page 5, line 32 skipping to change at page 5, line 34
Solution: Solution:
If none of the prefixes provided by the delegating router in the If none of the prefixes provided by the delegating router in the
Advertise messages are equal or shorter than the prefix-length hint Advertise messages are equal or shorter than the prefix-length hint
the requesting router included in the Solicit message, the requesting the requesting router included in the Solicit message, the requesting
router could choose to either accept or ignore the prefixes provided router could choose to either accept or ignore the prefixes provided
by the delegating routers depending on functional need. by the delegating routers depending on functional need.
If the requesting router could use the prefixes provided by the If the requesting router could use the prefixes provided by the
delegating routers despite being different from the prefix-length delegating routers despite being different from the prefix-length
hint, the requesting router should choose the shortest prefix length hint, the requesting router SHOULD choose the shortest prefix length
which is closest to the prefix-length hint. which is closest to the prefix-length hint.
There are certain situations where the requesting router could not There are certain situations where the requesting router could not
operate if it used a prefix which length does not meet its operate if it used a prefix which length does not meet its
requirement. If the requesting router cannot use the prefixes requirement. If the requesting router cannot use the prefixes
provided by the delegating routers, it should ignore the Advertise provided by the delegating routers, it SHOULD ignore the Advertise
messages and continue to send Solicit messages until it gets the messages and continue to send Solicit messages until it gets the
preferred prefix. To avoid traffic congestion, the requesting router preferred prefix. To avoid traffic congestion, the requesting router
should send Solicit messages at defined intervals, as specified in SHOULD send Solicit messages at defined intervals, as specified in
[RFC7083]. If the requesting router also Solicited for IA_NAs, the [RFC7083]. If the requesting router also Solicited for IA_NAs, the
requesting router should accept the IA_NA addresses and continue to requesting router SHOULD accept the IA_NA addresses and continue to
request for the desired IA_PD prefix in subsequent DHCPv6 messages as request for the desired IA_PD prefix in subsequent DHCPv6 messages as
specified in [RFC7550].. specified in [RFC7550]..
2.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 Delegating routers might not be able to provide a prefix with length
equal or shorter than the prefix-length hint. If the requesting equal or shorter than the prefix-length hint. If the requesting
router decided to use the prefix provided by the delegating router router decided to use the prefix provided by the delegating router
despite being longer than the prefix-length hint, but would still despite being longer than the prefix-length hint, but would still
prefer the prefix-length hint it originally requested in the Solicit prefer the prefix-length hint it originally requested in the Solicit
message, there should be some way for the requesting router to message, there should be some way for the requesting router to
express this preference during Renew/Rebind. E.g. If the requesting express this preference during Renew/Rebind. E.g. If the requesting
skipping to change at page 6, line 21 skipping to change at page 6, line 28
that it would still prefer a /60. This is to see whether the that it would still prefer a /60. This is to see whether the
delegating router has the prefix preferred by the requesting router delegating router has the prefix preferred by the requesting router
available in its prefix pool during Renew/Rebind. [RFC3633] is not available in its prefix pool during Renew/Rebind. [RFC3633] is not
completely clear on whether the requesting router is allowed to completely clear on whether the requesting router is allowed to
include a prefix-length hint in the Renew/Rebind message. 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 requesting router prefers a prefix length
different from the prefix it is currently using, then the requesting different from the prefix it is currently using, then the requesting
router should send the Renew/Rebind message with the same IA_PD, and router SHOULD send the Renew/Rebind message with the same IA_PD, and
include two OPTION_IAPREFIX options, one containing the currently include two OPTION_IAPREFIX options, one containing the currently
delegated prefix and the other containing the prefix-length hint. delegated prefix and the other containing the prefix-length hint.
This is to extend the lifetime of the prefix the requesting router is This is to extend the lifetime of the prefix the requesting router is
currently using and also get the prefix the requesting router currently using and also get the prefix the requesting router
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 delegating router is unable to provide the requesting router
with the newly requested prefix, but is able to extend lifetime of with the newly requested prefix, but is able to extend lifetime of
the old prefix, the requesting router should continue using the old the old prefix, the requesting router SHOULD continue using the old
prefix. prefix.
2.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 requesting router might become available
in the delegating router's prefix pool during Renew/Rebind, but was in the delegating router's prefix pool during Renew/Rebind, but was
unavailable during Solicit. This might be due to delegating router unavailable during Solicit. This might be due to delegating router
configuration change or because some other requesting router stopped configuration change or because some other requesting router stopped
using the prefix. using the prefix.
The question is whether the delegating router should remember the The question is whether the delegating router should remember the
skipping to change at page 7, line 20 skipping to change at page 7, line 26
should do if the requesting router also included in the Renew/Rebind should do if the requesting router also included in the Renew/Rebind
message a prefix-length hint value, and whether the delegating router message a prefix-length hint value, and whether the delegating router
could provide a different prefix to the requesting router 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 requesting router included
in the IA_PD both OPTION_IAPREFIX option with the delegated prefix in the IA_PD both OPTION_IAPREFIX option with the delegated prefix
value and an OPTION_IAPREFIX option with a prefix-length hint value, value and an OPTION_IAPREFIX option with a prefix-length hint value,
the delegating router should check to see whether it could extend the the delegating router SHOULD check to see whether it could extend the
lifetime of the original delegated prefix and whether it has any lifetime of the original delegated prefix and whether it has any
available prefix matching the prefix-length hint, or as close a available prefix matching the prefix-length hint, or as close a
possible to the prefix-length hint, within the delegating router's possible to the prefix-length hint, within the delegating router's
limit. limit.
If the delegating router assigned the prefix included in IA_PD to the If the delegating router assigned the prefix included in IA_PD to the
requesting router, the delegating router can do one of the following, requesting router, the delegating router SHOULD do one of the
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 requesting router.
skipping to change at page 8, line 5 skipping to change at page 8, line 12
connections with the original prefix, and use the new prefix to connections with the original prefix, and use the new prefix to
establish new connections. 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, 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 requesting router.
If the delegating router does not know the requesting router's If the delegating router does not know the requesting router's
bindings(e.g. a different delegating router receiving the message bindings(e.g. a different delegating router receiving the message
during Rebind), then the delegating router should ignore the original during Rebind), then the delegating router SHOULD ignore the original
delegated prefix, and try to assign a new prefix of requested length. delegated prefix, and try to assign a new prefix of requested length.
It's unnecessary for the delegating router to remember the prefix- It's unnecessary for the delegating router to remember the prefix-
length hint the requesting router requested during Solicit. It is length hint the requesting router requested during Solicit. It is
possible that the requesting router's preference for the prefix possible that the requesting router's preference for the prefix
length might have changed during this time interval, so the prefix- length might have changed during this time interval, so the prefix-
length hint in the Renew message is reflecting what the requesting length hint in the Renew message is reflecting what the requesting
router prefers at the time. router prefers at the time.
3. 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 requesting routers and delegating routers
interact with regard to the prefix-length hint mechanism introduced interact with regard to the prefix-length hint mechanism introduced
in RFC3633. in RFC3633.
4. IANA Considerations 5. IANA Considerations
This document does not include an IANA request. This document does not include an IANA request.
5. 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.
6. Normative References 7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
DOI 10.17487/RFC3633, December 2003, DOI 10.17487/RFC3633, December 2003,
<http://www.rfc-editor.org/info/rfc3633>. <http://www.rfc-editor.org/info/rfc3633>.
[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>.
 End of changes. 30 change blocks. 
41 lines changed or deleted 53 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/