draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01.txt   draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-02.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: Standards Track C. Liu
Expires: October 30, 2016 Tsinghua University Expires: December 21, 2016 Tsinghua University
April 28, 2016 June 19, 2016
DHCPv6 Prefix Length Hint Issues DHCPv6 Prefix Length Hint Issues
draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-02
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 October 30, 2016. This Internet-Draft will expire on December 21, 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . 5
3.5. Receipt of Renew/Rebind Message . . . . . . . . . . . . . 6 3.5. Receipt of Renew/Rebind Message . . . . . . . . . . . . . 6
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 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
the "IPv6 prefix" field set to zero and the "prefix-length" field set the "IPv6 prefix" field set to zero and the "prefix-length" field set
to a non-zero value. The delegating routers are free to ignore the to a non-zero value. The delegating routers are free to ignore the
prefix-length hint values depending on server policy. However, some prefix-length hint values depending on server policy. However, some
requesting routers can't function normally when they're provided with requesting routers may not be able to function (or only in a degraded
a prefix which length is different from what they requested. E.g. state) when they're provided with a prefix which length is different
If the requesting router is asking for a /56 and the delegating from what they requested. E.g. If the requesting router is asking
router returns a /64, the functionality of the requesting router for a /56 and the delegating router returns a /64, the functionality
might be limited because it might not be able to split the prefix for of the requesting router might be limited because it might not be
all its interfaces. able to split the prefix for all its interfaces. For other hints,
such as requesting for a explicit address or lifetime, this might be
less critical as it just help a client that wishes to continue using
what it used last time, or a client that wants to Renew its lease for
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 requesting router and delegating
router should act in different situations involving the prefix-length router should act in different situations involving the prefix-length
hint. From the requesting router perspective, it should be able to hint. From the requesting router perspective, it should be able to
use the prefix-length hint to signal to the delegating router its use the prefix-length hint to signal to the delegating router its
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-
skipping to change at page 3, line 22 skipping to change at page 3, line 28
"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 requesting router to ask delegating
routers for prefixes and other configuration parameters. When the routers for prefixes and other configuration parameters. The
requesting router's configuration changes, it might require a prefix requesting router might want a different prefix length due to
length different from what it had previously gotten. The delegating configuration changes or it might just want the same prefix again
router usually has a record of the prefix it delegated to the after reboot. The delegating router could decide whether to provide
requesting router during previous interactions. How should the the requesting router with the preferred prefix depending on server
requesting router avoid getting the same prefix back from the policy, but the requesting router should be able to signal to the
delegating router? delegating router its real time need.
The delegating router could decide whether to provide the requesting The delegating routers usually has a record of the prefix it gave to
router with the preferred prefix depending on server policy, but the the requesting router during previous interactions. The best way to
requesting router should be able to signal to the delegating router assure a completely new delegated prefix is to send a new IAID in the
whether it wants a different prefix or the same prefix. The best way IA_PD. However, this would require the requesting router device to
to assure a completely new delegated prefix is to send a new IAID in have persistant storage, since rebooting the device would cause the
the IA_PD. However, this would require the requesting router device requesting router to use the original IAID in the IA_PD.
to have persistant storage, since rebooting the device would cause
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 using the same IAID in the IAPD, include the preferred
length" field of the OPTION_IAPREFIX option, and set the "IPv6 prefix-length value in the "prefix-length" field of the
prefix" field to zero. This is an indiction to the delegating router OPTION_IAPREFIX option, and set the "IPv6 prefix" field to zero.
that the requesting router prefers a prefix of specific length, This is an indiction to the delegating router that the requesting
regardless of what it had gotten before. router prefers a prefix of the specified length, 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 send a Solicit message using the same
prefix" field of the OPTION_IAPREFIX option, and the length of the IAID in the IAPD, include the previously delegated prefix value in
prefix in the "prefix-length" field. This is an indication to the the "IPv6 prefix" field of the OPTION_IAPREFIX option, and the length
delegating router that the requesting router wants the same prefix of the prefix in the "prefix-length" field. This is an indication to
back. the delegating router that the requesting router wants the same
prefix back.
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 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 the prefix-length hint should be
handled by the delegating router, whether to honor the prefix-length handled by the delegating router. The requesting router might want a
hint or provide the prefix from previous interactions with the different prefix length due to configuration changes or it might just
requesting router. The requesting router might want a different want the same prefix again after reboot. The delegating router
prefix length due to configuration changes or it might just want the should interpret these cases differently.
same prefix again after reboot. The delegating router should
interpret these cases differently.
Many delegating routers are configured to provide only prefixes of Many delegating routers are configured to provide only prefixes of
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 first check its prefix pool for a prefix with length
what the delegating router is configured to return, regardless of the matching the prefix-length hint value, regardless of the prefix
prefix record from previous interactions with the requesting router. record from previous interactions with the requesting router. If the
The delegating router SHOULD regard the prefix-length hint in the delegating router does not have a prefix with length matching the
Solicit message as the prefix length most preferred by the requesting prefix-length hint value, then the delegating router SHOULD provide
router at the time. the prefix with the shortest length possible which is closest to the
prefix-length hint value.
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 check its prefix pool for a
the requesting router. If the requested prefix is not available in prefix matching the requested prefix value. If the requested prefix
the delegating router's prefix pool, then the delegating router is not available in the delegating router's prefix pool, then the
SHOULD try to provide a prefix matching the prefix-length value. delegating router SHOULD try to provide a prefix matching the prefix-
length value, or the prefix with the shortest length possible which
The delegating router might not have prefixes exactly matching the is closest to the prefix-length value.
prefix-length hint. In this situation, the delegating router SHOULD
provide the shortest prefix length possible which is closest to the
prefix-length hint. E.g. If the delegating router could only
provide prefixes of lengths /30, /48, and /56, and the requesting
router is requesting for a /50 in the prefix-length hint, then the
delegating router should provide the /48 to the requesting router.
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 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 or lack of resources in its prefix pool.
delegating router in the Advertise message is different from what the If the prefix length provided by the delegating router in the
requesting router requested in the Solicit message, the question Advertise message is different from what the requesting router
would be whether the requesting router should use the provided prefix requested in the Solicit message, the question would be whether the
length or continue to ask for its preferred prefix length. There are requesting router should use the provided prefix length or continue
certain situations where the requesting router could not operate to ask for its preferred prefix length. There are certain situations
properly if it used a prefix which length is different from what it where the requesting router could not operate properly if it used a
requested in the prefix-length hint. However, if the requesting prefix which length is different from what it requested in the
router ignores the Advertise messages, and continues to solicit for prefix-length hint. However, if the requesting router ignores the
the preferred prefix length, the requesting router might be stuck in Advertise messages, and continues to solicit for the preferred prefix
the DHCP process. length, the requesting router might be stuck in the DHCP process.
Another question is whether the requesting router should ignore other
configuration parameters such as available addresses.
Solution: Solution:
If none of the prefixes provided by the delegating router in the
Advertise messages are equal or shorter than the prefix-length hint
the requesting router included in the Solicit message, the requesting
router could choose to either accept or ignore the prefixes provided
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 If the requesting router cannot use the prefixes provided by the
operate if it used a prefix which length does not meet its delegating routers, it MUST ignore the Advertise messages and
requirement. If the requesting router cannot use the prefixes continue to send Solicit messages until it gets the preferred prefix.
provided by the delegating routers, it SHOULD ignore the Advertise To avoid traffic congestion, the requesting router MUST send Solicit
messages and continue to send Solicit messages until it gets the messages at defined intervals, as specified in [RFC7083].
preferred prefix. To avoid traffic congestion, the requesting router
SHOULD send Solicit messages at defined intervals, as specified in If the requesting router also Solicited for other stateful
[RFC7083]. If the requesting router also Solicited for IA_NAs, the configuration options such as IA_NAs, the requesting router SHOULD
requesting router SHOULD accept the IA_NA addresses and continue to accept the stateful configuration options and continue to request for
request for the desired IA_PD prefix in subsequent DHCPv6 messages as the desired IA_PD prefix in subsequent DHCPv6 messages as specified
specified in [RFC7550].. 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 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
 End of changes. 15 change blocks. 
90 lines changed or deleted 85 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/