draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05.txt   draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06.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: July 29, 2017 Tsinghua University Expires: October 2, 2017 Tsinghua University
January 25, 2017 March 31, 2017
DHCPv6 Prefix Length Hint Issues DHCPv6 Prefix Length Hint Issues
draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06
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 July 29, 2017. This Internet-Draft will expire on October 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . 5 3.4. Creation of Renew/Rebind Message . . . . . . . . . . . . 6
3.5. Receipt of Renew/Rebind Message . . . . . . . . . . . . . 6 3.5. Receipt of Renew/Rebind Message . . . . . . . . . . . . . 6
3.6. General Recommendation . . . . . . . . . . . . . . . . . 8 3.6. General Recommendation . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Contributors List . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 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 including an IA_PD Prefix Option (IAPREFIX option), encapsulated in
an IA_PD option, with the "IPv6 prefix" field set to zero and the an IA_PD option, with the "IPv6 prefix" field set to zero and the
"prefix-length" field set to a non-zero value. The servers are free "prefix-length" field set to a non-zero value. The servers are free
to ignore the prefix-length hint values depending on server policy. to ignore the prefix-length hint values depending on server policy.
However, some clients may not be able to function (or only in a However, some clients may not be able to function (or only in a
degraded state) when they're provided with a prefix which length is degraded state) when they're provided with a prefix whose length is
different from what they requested. E.g. If the client is asking different from what they requested. 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 an 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
skipping to change at page 3, line 32 skipping to change at page 3, line 32
The Solicit message allows a client to ask servers for prefixes and The Solicit message allows a client to ask servers for prefixes and
other configuration parameters. The client might want a different other configuration parameters. The client might want a different
prefix length due to configuration changes or it might just want the prefix length due to configuration changes or it might just want the
same prefix again after reboot. The client might also prefer a same prefix again after reboot. The client might also prefer a
prefix of specific length in case the requested prefix is not prefix of 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 server 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 (Identity Association
this would require the client device to have persistent storage, IDentifier) in the IA_PD (Identity Association for Prefix
since rebooting the device would cause the client to use the original Delegation). However, this would require the client device to have
IAID in the IA_PD. persistent storage, since rebooting the device would cause the client
to use the original IAID in the IA_PD.
Solution: Solution:
When the client prefers a prefix of specific length from the server, When the client prefers a prefix of 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 indication to the server that the client prefers to zero. This is an indication to the server that the client prefers
a prefix of the specified length, regardless of what it had gotten a prefix of the specified length, regardless of what it 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 available, the client MUST send a Solicit message using prefix is not available, the client MUST send a Solicit message using
the same IAID in the IAPD, include the previously delegated prefix in the same IAID in the 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. There is no requirement to the order of the two
IAPREFIX options.
3.2. Receipt of Solicit message 3.2. Receipt of Solicit message
Problem: Problem:
[RFC3633] allows a client to include a prefix-length hint in the [RFC3633] allows a client to include a prefix-length hint in the
Solicit message, to signal its preference to the server. It is Solicit message, to signal its preference to the server. It is
unclear about how the prefix-length hint should be handled by the unclear about how the prefix-length hint should be handled by the
server. The client might want a different prefix length due to server. The client might want a different prefix length due to
configuration changes or it might just want the same prefix again configuration changes or it might just want the same prefix again
skipping to change at page 4, line 40 skipping to change at page 4, line 42
prefix-length hint? prefix-length hint?
Solution: Solution:
Upon the receipt of Solicit message, if the client included only a Upon the receipt of Solicit message, if the client included only a
prefix-length hint in the message, the server SHOULD first check its prefix-length hint in the message, the server SHOULD first check its
prefix pool for a prefix with length matching the prefix-length hint prefix pool for a prefix with length matching the prefix-length hint
value, regardless of the prefix record from previous interactions value, regardless of the prefix record from previous interactions
with the client. If the server does not have a prefix with length with the client. If the server does not have a prefix with length
matching the prefix-length hint value, then the server SHOULD provide matching the prefix-length hint value, then the server SHOULD provide
the prefix with the shortest length possible which is closest to the the prefix whose length is shorter and closest to the prefix-length
prefix-length hint value. hint value.
If the client included a specific prefix value in the Solicit If the client included a specific prefix value in the Solicit
message, the server SHOULD check its prefix pool for a prefix message, the server SHOULD check its prefix pool for a prefix
matching the requested prefix value. If the requested prefix is not matching the requested prefix value. If the requested prefix is not
available in the server's prefix pool, and the client also included a available in the server's prefix pool, and the client also included a
prefix-length hint in the same IA_PD option, then the server SHOULD prefix-length hint in the same IA_PD option, then the server SHOULD
try to provide a prefix matching the prefix-length value, or the check its prefix pool for a prefix with length matching the prefix-
prefix with the shortest length possible which is closest to the length hint value. If the server does not have a prefix with length
prefix-length hint value. matching the prefix-length hint value, the server SHOULD provide the
prefix whose length is shorter and closest to the prefix-length hint
value.
If the server will not assign any prefixes to any IA_PDs in a
subsequent Request from the client, the server MUST send an Advertise
message to the client as described in Section 11.2 of [RFC3633].
3.3. Receipt of Advertise Message 3.3. Receipt of Advertise Message
Problem: Problem:
The server might not be able to honor the prefix-length hint due to The server might not be able to honor the prefix-length hint due to
server policy or lack of resources in its prefix pool. If the prefix server policy or lack of resources in its prefix pool. If the prefix
length provided by the server in the Advertise message is different length provided by the server in the Advertise message is different
from what the client requested in the Solicit message, the question from what the client requested in the Solicit message, the question
would be whether the client should use the provided prefix length or would be whether the client should use the provided prefix length or
continue to ask for its preferred prefix length. There are certain continue to ask for its preferred prefix length. There are certain
situations where the client could not operate properly if it used a situations where the client could not operate properly if it used a
prefix which length is different from what it requested in the prefix whose length is different from what it requested in the
prefix-length hint. However, if the client ignores the Advertise prefix-length hint. However, if the client ignores the Advertise
messages, and continues to solicit for the preferred prefix length, messages, and continues to solicit for the preferred prefix length,
the client might be stuck in the DHCP process. Another question is the client might be stuck in the DHCP process. Another question is
whether the client should ignore other configuration parameters such whether the client should ignore other configuration parameters such
as available addresses. as available addresses.
Solution: Solution:
If the client could use the prefixes included in the Advertise If the client could use the prefixes included in the Advertise
messages despite being different from the prefix-length hint, the messages despite being different from the prefix-length hint, the
skipping to change at page 7, line 29 skipping to change at page 7, line 37
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 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 specific non-zero valid-lifetime depending on actual requirement, and
length. This allows the client to finish up existing connections assign a new prefix of requested length. This allows the client to
with the original prefix, and use the new prefix to establish new finish up existing connections with the original prefix, and use the
connections. new prefix to establish new connections.
5. Do not include the original delegated prefix in the Reply 5. Do not include the original delegated prefix in the Reply
message, 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 its lifetime expires. This avoids sudden prefix would be valid until its lifetime expires. This avoids 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.
skipping to change at page 8, line 20 skipping to change at page 8, line 24
the prefix-length hint in addition to any IAPREFIX options it has the prefix-length hint in addition to any IAPREFIX options it has
included for each IA_PD in any Solicit, Request, Renew, and Rebind included for each IA_PD in any Solicit, Request, Renew, and Rebind
messages it sends. While a server is free to ignore the hint, messages it sends. While a server is free to ignore the hint,
servers that do not choose to ignore the hint should attempt to servers that do not choose to ignore the hint should attempt to
assign a prefix of at least the hint length (or shorter) if one is assign a prefix of at least the hint length (or shorter) if one is
available. Whether a server favors the hint or avoiding a available. Whether a server favors the hint or avoiding a
renumbering event is a matter of server policy. 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 provides guidance on how the clients and servers
already discussed in section 15 of RFC3633, as this document provides interact with regard to the DHCPv6 prefix-length hint. Security
guidance on how the clients and servers interact with regard to the considerations in DHCP are described in Section 23 of [RFC3315].
prefix-length hint mechanism introduced in RFC3633. Security considerations regarding DHCPv6 prefix delegation are
described in Section 15 of [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. Acknowledgements
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, Ted Lemon, Roni Even, Benoit Claise, Mirja
Kuehlewind, Kathleen Moriarty, Eric Rescorla, Alvaro Retana, Susan
Hares, Hilarie Orman for their review and comments.
7. Normative References 7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[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>.
[RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and [RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and
 End of changes. 18 change blocks. 
30 lines changed or deleted 46 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/