draft-ietf-dhc-dhcpv6-stateful-issues-00.txt   draft-ietf-dhc-dhcpv6-stateful-issues-01.txt 
Network Working Group O. Troan Network Working Group O. Troan
Internet-Draft B. Volz Internet-Draft B. Volz
Intended status: Standards Track Cisco Systems, Inc. Updates: 3315,3633 (if approved) Cisco Systems, Inc.
Expires: November 8, 2012 May 7, 2012 Intended status: Standards Track October 6, 2012
Expires: April 9, 2013
Issues with multiple stateful DHCPv6 options Issues with multiple stateful DHCPv6 options
draft-ietf-dhc-dhcpv6-stateful-issues-00.txt draft-ietf-dhc-dhcpv6-stateful-issues-01.txt
Abstract Abstract
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written
with the expectation that additional stateful DHCPv6 options would be with the expectation that additional stateful DHCPv6 options would be
developed. IPv6 Prefix Options for Dynamic Host Configuration developed. IPv6 Prefix Options for Dynamic Host Configuration
Protocol (DHCP) version 6 shoe-horned the new options for Prefix Protocol (DHCP) version 6 shoe-horned the new options for Prefix
Delegation into DHCPv6. Implementation experience of the CPE model Delegation into DHCPv6. Implementation experience of the CPE model
described in has shown multiple issues with the DHCPv6 protocol in described in has shown multiple issues with the DHCPv6 protocol in
supporting multiple stateful options. supporting multiple stateful options.
skipping to change at page 1, line 36 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 November 8, 2012. This Internet-Draft will expire on April 9, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Handling of multiple IA options types . . . . . . . . . . . . . 4 4. Handling of multiple IA options types . . . . . . . . . . . . 4
4.1. Advertisement message . . . . . . . . . . . . . . . . . . . 4 4.1. Advertisement message . . . . . . . . . . . . . . . . . . 4
4.2. Placement of Status codes . . . . . . . . . . . . . . . . . 5 4.2. Placement of Status codes . . . . . . . . . . . . . . . . 5
4.3. T1/T2 timers . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. T1/T2 timers . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Confirm message . . . . . . . . . . . . . . . . . . . . . . 6 4.4. Renew and Rebind messages . . . . . . . . . . . . . . . . 6
4.5. Release messages . . . . . . . . . . . . . . . . . . . . . 6 4.5. Confirm message . . . . . . . . . . . . . . . . . . . . . 8
4.6. Unanswered options . . . . . . . . . . . . . . . . . . . . 6 4.6. Release messages . . . . . . . . . . . . . . . . . . . . . 9
4.7. Multiple provisioning domains . . . . . . . . . . . . . . . 7 4.7. Multiple provisioning domains . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
DHCPv6 [RFC3315] was not written with the expectation that additional DHCPv6 [RFC3315] was not written with the expectation that additional
stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation
[RFC3633] shoe-horned the new options for Prefix Delegation into [RFC3633] shoe-horned the new options for Prefix Delegation into
DHCPv6. Implementation experience of the CPE model described in DHCPv6. Implementation experience of the CPE model described in
[RFC6204] has shown multiple issues with the DHCPv6 protocol in [RFC6204] has shown multiple issues with the DHCPv6 protocol in
supporting multiple stateful options. supporting multiple stateful options.
skipping to change at page 4, line 11 skipping to change at page 4, line 11
addresses (IA_TA) holds temporary addresses (IA_TA) holds temporary
addresses (see "identity association for addresses (see "identity association for
temporary addresses"). Throughout this temporary addresses"). Throughout this
document, "IA" is used to refer to an document, "IA" is used to refer to an
identity association without identifying identity association without identifying
the type of stateful option in the IA. the type of stateful option in the IA.
4. Handling of multiple IA options types 4. Handling of multiple IA options types
DHCPv6 was written with the assumption that the only stateful options DHCPv6 was written with the assumption that the only stateful options
where for assigning addresses. DHCPv6 PD describes how to extend the were for assigning addresses. DHCPv6 PD describes how to extend the
DHCPv6 protocol to handle prefix delegation, but RFC3633 did not DHCPv6 protocol to handle prefix delegation, but [RFC3633] did not
consider how DHCP address assignment and prefix delegation could co- consider how DHCP address assignment and prefix delegation could co-
exist. exist.
If a client requests multiple IA option types, but the server is
configured to only offer a subset of them, the client could react in
several ways. Reset the state machine and continue to send Solicit
messages, create separate DHCP sessions for each IA option type and
continue to Solicit for the missing options, or it could continue
with the single session, and include the missing options on
subsequent messages to the server.
Proposed solution: the client should keep a single session with the
server and include the missing options on subsequent messages
(Request, Renew, and Rebind) to the server.
4.1. Advertisement message 4.1. Advertisement message
RFC3315 specifies that a client must ignore an Advertise message if a [RFC3315] specifies that a client must ignore an Advertise message if
server will not assign any addresses to a client. A client a server will not assign any addresses to a client. A client
requesting both IA_NA and IA_PD, with a server that only offers one requesting both IA_NA and IA_PD, with a server that only offers one
of them, is not supported in the current protocol specification. of them, is not supported in the current protocol specification.
Proposed solution: a client should accept Advertise messages, even Proposed solution: a client SHOULD accept Advertise messages, even
when not all IA option types are being offered. A client should when not all IA option types are being offered. A client SHOULD
ignore an Advertise message when no bindings at all are being ignore an Advertise message when no bindings at all are being
offered. offered. The client SHOULD include the not offered IA option types
in its Request.
Replace Section 17.1.3: (existing errata) Replace Section 17.1.3 of [RFC3315]: (existing errata)
The client MUST ignore any Advertise message that includes a Status The client MUST ignore any Advertise message that includes a Status
Code option containing the value NoAddrsAvail, with the exception Code option containing the value NoAddrsAvail, with the exception
that the client MAY display the associated status message(s) to the that the client MAY display the associated status message(s) to the
user. user.
With: With:
The client MUST ignore any Advertise message that contains no The client MUST ignore any Advertise message that contains no
bindings (if only IA_NA and/or IA_TA options were requested, bindings (if only IA_NA and/or IA_TA options were requested,
skipping to change at page 6, line 6 skipping to change at page 6, line 24
we were to redo the DHCP protocol from scratch the T1/T2 timers we were to redo the DHCP protocol from scratch the T1/T2 timers
should be carried in a separate DHCP option. should be carried in a separate DHCP option.
Proposed solution: The server SHOULD set the T1/T2 timers in all IA Proposed solution: The server SHOULD set the T1/T2 timers in all IA
options in Reply and Advertise messages to the same value. To deal options in Reply and Advertise messages to the same value. To deal
with the case where servers have not yet been updated to do that, with the case where servers have not yet been updated to do that,
clients MUST use the shortest (explicit or implicit) T1/T2 timer clients MUST use the shortest (explicit or implicit) T1/T2 timer
(larger than 0) in any IA options in the Reply. Longer T1/T2 timers (larger than 0) in any IA options in the Reply. Longer T1/T2 timers
are ignored. are ignored.
4.4. Confirm message 4.4. Renew and Rebind messages
The Renew message, as described in [RFC3315], allows a client to only
renew bindings assigned via a Request message. The Rebind message,
as described in [RFC3315] does not explicitly specify what a server
should do when an IA option which contains no addresses is present.
In a multiple IA option type model, the Renew does not support the
ability for the client to renew one IA option type while requesting
bindings for other IA option types that were not available when the
client sent the Request.
Proposed solution: The client should continue with the IA options
received, while continuing to include the other IA options in
subsequent messages to the server. The client and server processing
need to be modified. Note that this change makes the server's IA
processing of Renew and Rebind similar to the Request processing.
Replace Section 18.1.3 of [RFC3315]:
At time T1 for an IA, the client initiates a Renew/Reply message
exchange to extend the lifetimes on any addresses in the IA. The
client includes an IA option with all addresses currently assigned
to the IA in its Renew message.
With:
At time T1 for an IA, the client initiates a Renew/Reply message
exchange to extend the lifetimes on any addresses in the IA. The
client includes an IA option with all addresses currently assigned
to the IA in its Renew message. The client also includes an IA
option for each binding it desires but has been unable to obtain.
Replace Section 18.2.3 of [RFC3315]:
If the server cannot find a client entry for the IA the server
returns the IA containing no addresses with a Status Code option
set to NoBinding in the Reply message.
With:
If the server cannot find a client entry for the IA the server
creates the bindings for that client according to the server's
policy and configuration information and records the IAs and
other information requested by the client.
Note that clients that communicate with servers that do not support
this updated Renew processing will receive the NoBinding status for
the IA which had no bindings. The client MUST continue to process
the other IAs in the Reply. The client MAY attempt a Solicit/
Advertise/Request/Reply sequence periodically to obtain bindings for
these IAs. However, it MUST limit the frequency at which is does
this to no more often than the renewal frequency.
Replace Section 18.1.4 of [RFC3315]:
At time T2 for an IA (which will only be reached if the server to
which the Renew message was sent at time T1 has not responded), the
client initiates a Rebind/Reply message exchange with any available
server. The client includes an IA option with all addresses
currently assigned to the IA in its Rebind message.
With:
At time T2 for an IA (which will only be reached if the server to
which the Renew message was sent at time T1 has not responded), the
client initiates a Rebind/Reply message exchange with any available
server. The client includes an IA option with all addresses
currently assigned to the IA in its Rebind message. The client
also includes an IA option for each binding it desires but has been
unable to obtain.
4.5. Confirm message
The Confirm message, as described in [RFC3315], is specific to The Confirm message, as described in [RFC3315], is specific to
address assignment. It lets a server without a binding to reply to address assignment. It lets a server without a binding to reply to
the message, under the assumption that the server only needs the message, under the assumption that the server only needs
knowledge about the prefix(es) on the link, to inform the client that knowledge about the prefix(es) on the link, to inform the client that
the address is likely valid or not. This message is sent when e.g. the address is likely valid or not. This message is sent when e.g.
the client has moved and needs to validate its addresses. Not all the client has moved and needs to validate its addresses. Not all
bindings can be validated by servers and the Confirm message provides bindings can be validated by servers and the Confirm message provides
for this by specifying that a server that is unable to determine the for this by specifying that a server that is unable to determine the
on-link status MUST NOT send a Reply. on-link status MUST NOT send a Reply.
Note: Confirm has a specific meaning and does not overload Renew/ Note: Confirm has a specific meaning and does not overload Renew/
Rebind. It also is lower processing cost as the server does NOT need Rebind. It also is lower processing cost as the server does NOT need
to extend lease times or otherwise send back other configuration to extend lease times or otherwise send back other configuration
options. options.
Proposed solution: Allow and specify the Confirm message for other IA Proposed solution: Allow and specify the Confirm message for other IA
option types. A server SHOULD respond to a Confirm message only if option types. The server performs the same test as for addresses on
it has definitive knowledge, based on the network configuration and the delegated prefixes (see [RFC3315], section 18.2.2).
not the specific client's bindings, that the client is still on-link
or not on-link.
4.5. Release messages
A client can release any individual lease at any time. A client can Replace Section 12.1 of [RFC3633]:
get "back" a lease by using a Renew message. It MAY do this at any
time, though must avoid creating a Renew storm. E.g. wait until T1.
4.6. Unanswered options If such verification is needed the requesting router MUST initiate
a Rebind/Reply message exchange as described in section 18.1.4,
"Creation and Transmission of Rebind Messages" of RFC 3315, with
the exception that the retransmission parameters should be set as
for the Confirm message, described in section 18.1.2, "Creation
and Transmission of Confirm Messages" of RFC 3315. The requesting
router includes any IA_PDs, along with prefixes associated with
those IA_PDs in its Rebind message.
If a client requests multiple IA option types, but the server is ...
willing to only offer a subset of them, the client could react in
several ways. Reset the state machine and continue to send Solicit
messages, create separate DHCP sessions for each IA option type and
continue to Solicit for the missing options, or it could continue
with the single session, and include the missing options on
subsequent messages to the server.
Proposed solution: the client should keep a single session with the The Confirm and Decline message types are not used with Prefix
server. The client should continue with the IA options received, Delegation.
while continuing to request the other IA options in subsequent
messages to the server. That means to continue to include the empty
unanswered IAs in subsequent Renew and Rebind messages.
For the IAs that the server will not offer a binding, it must reply With:
using the same behaviour as for a Request message. That is not with
the currently specified NoBinding status). This behaviour will not
require the server to remember the IAs that it is not willing to
serve. I.e. the change is to allow the client to include IAs in
Renew/Rebind messages for which it has not received bindings (yet).
A client can only use the Renew (or Rebind) to request new IA options If such verification is needed the requesting router MUST initiate
if it already has one or more bindings. A client MUST NOT use Renew a Confirm message exchange as described in section 18.1.2,
(or Rebind) if it has no valid bindings it is renewing. "Creation and Transmission of Confirm Messages" of RFC 3315. The
requesting router includes any IA_PDs, along with prefixes
associated with those IA_PDs in its Confirm message.
Replace Section 18.2.3: ...
If the server cannot find a client entry for the IA the server The Decline message type is not used with Prefix Delegation.
returns the IA containing no addresses with a Status Code option set
to NoBinding in the Reply message.
With: 4.6. Release messages
If the server cannot find a client entry for the IA but has one or A client can release any individual lease at any time. A client can
more bindings for the client, the server SHOULD treat this like a get "back" a lease by using a Renew message. It MAY do this at any
Request message for the IA. If the server has no other bindings for time, though must avoid creating a Renew storm. E.g. wait until T1.
the client, the server SHOULD return the IA containing no bindings
with a Status Code option set to NoBinding in the Reply message.
4.7. Multiple provisioning domains 4.7. Multiple provisioning domains
This document has assumed that all DHCP servers on a network are in a This document has assumed that all DHCP servers on a network are in a
single provisioning domain and thus should be "equal" in the service single provisioning domain and thus should be "equal" in the service
that they offer. that they offer. This was also assumed by [RFC3315] and [RFC3633].
One could envision a network where the DHCP servers are in multiple One could envision a network where the DHCP servers are in multiple
provisioning domains, and it may be desireable to have the DHCP provisioning domains, and it may be desirable to have the DHCP client
client obtain different IA types from different provisioning domains. obtain different IA types from different provisioning domains. How a
How a client detects the multiple provisioning domains and how it client detects the multiple provisioning domains and how it would
would interact with the multiple servers in these different domains interact with the multiple servers in these different domains is
is outside the scope of this document and an area for future work. outside the scope of this document and an area for future work.
5. IANA Considerations 5. IANA Considerations
This specification does not require any IANA actions. This specification does not require any IANA actions.
6. Security Considerations 6. Security Considerations
There are no new security considerations pertaining to this document. There are no new security considerations pertaining to this document.
7. Acknowledgements 7. Acknowledgements
8. Normative References 8. References
8.1. 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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[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,
December 2003. December 2003.
8.2. Informative References
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011. Routers", RFC 6204, April 2011.
Authors' Addresses Authors' Addresses
Ole Troan Ole Troan
Cisco Systems, Inc. Cisco Systems, Inc.
Philip Pedersens vei 20 Philip Pedersens vei 20
N-1324 Lysaker, N-1324 Lysaker,
 End of changes. 26 change blocks. 
77 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/