Issues with multiple stateful DHCPv6 options
draft-ietf-dhc-dhcpv6-stateful-issues-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (dhc WG) | |
|---|---|---|---|
| Authors | Ole Trøan , Bernie Volz | ||
| Last updated | 2012-05-06 | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| Reviews |
SECDIR Last Call review
(of
-11)
Has Issues
GENART Last Call review
(of
-11)
Ready with Nits
|
||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-dhc-dhcpv6-stateful-issues-00
Network Working Group O. Troan
Internet-Draft B. Volz
Intended status: Standards Track Cisco Systems, Inc.
Expires: November 8, 2012 May 7, 2012
Issues with multiple stateful DHCPv6 options
draft-ietf-dhc-dhcpv6-stateful-issues-00.txt
Abstract
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written
with the expectation that additional stateful DHCPv6 options would be
developed. IPv6 Prefix Options for Dynamic Host Configuration
Protocol (DHCP) version 6 shoe-horned the new options for Prefix
Delegation into DHCPv6. Implementation experience of the CPE model
described in has shown multiple issues with the DHCPv6 protocol in
supporting multiple stateful options.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 8, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Troan & Volz Expires November 8, 2012 [Page 1]
Internet-Draft Multiple Stateful Option May 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Handling of multiple IA options types . . . . . . . . . . . . . 4
4.1. Advertisement message . . . . . . . . . . . . . . . . . . . 4
4.2. Placement of Status codes . . . . . . . . . . . . . . . . . 5
4.3. T1/T2 timers . . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Confirm message . . . . . . . . . . . . . . . . . . . . . . 6
4.5. Release messages . . . . . . . . . . . . . . . . . . . . . 6
4.6. Unanswered options . . . . . . . . . . . . . . . . . . . . 6
4.7. Multiple provisioning domains . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Troan & Volz Expires November 8, 2012 [Page 2]
Internet-Draft Multiple Stateful Option May 2012
1. Introduction
DHCPv6 [RFC3315] was not written with the expectation that additional
stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation
[RFC3633] shoe-horned the new options for Prefix Delegation into
DHCPv6. Implementation experience of the CPE model described in
[RFC6204] has shown multiple issues with the DHCPv6 protocol in
supporting multiple stateful options.
This document describes a number of problems encountered with
multiple IA option types into DHCP and recommended changes to the
DHCPv6 protocol specifications.
The intention of this work is to modify the DHCP protocol
specification to support multiple IA option types within a single
DHCP session. This problem can also be solved by implementing a
separate DHCP session (separate client state machine) per IA option
type. This latter approach has a number of issues: additional DHCP
protocol traffic, 'collisions' between stateless options also
included with the IA options, divergence in that each IA option type
specification specifies its 'own' version of the DHCP protocol.
The changes described in this document will be incorporated in a new
revision of the DHCPv6 protocol specification [RFC3315].
2. Conventions
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 RFC 2119 [RFC2119].
3. Terminology
Stateful options Options that require dynamic binding
state per client on the server.
Identity association (IA): A collection of stateful options assigned
to a client. Each IA has an associated
IAID. A client may have more than one IA
assigned to it; for example, one for each
of its interfaces. Each IA holds one
type of IA option; for example, an
identity association for temporary
addresses (IA_TA) holds temporary
addresses (see "identity association for
temporary addresses"). Throughout this
Troan & Volz Expires November 8, 2012 [Page 3]
Internet-Draft Multiple Stateful Option May 2012
document, "IA" is used to refer to an
identity association without identifying
the type of stateful option in the IA.
4. Handling of multiple IA options types
DHCPv6 was written with the assumption that the only stateful options
where for assigning addresses. DHCPv6 PD describes how to extend the
DHCPv6 protocol to handle prefix delegation, but RFC3633 did not
consider how DHCP address assignment and prefix delegation could co-
exist.
4.1. Advertisement message
RFC3315 specifies that a client must ignore an Advertise message if 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
of them, is not supported in the current protocol specification.
Proposed solution: a client should accept Advertise messages, even
when not all IA option types are being offered. A client should
ignore an Advertise message when no bindings at all are being
offered.
Replace Section 17.1.3: (existing errata)
The client MUST ignore any Advertise message that includes a Status
Code option containing the value NoAddrsAvail, with the exception
that the client MAY display the associated status message(s) to the
user.
With:
The client MUST ignore any Advertise message that contains no
bindings (if only IA_NA and/or IA_TA options were requested,
this is a message that includes a Status Code option containing the
value NoAddrsAvail), with the exception that the client MAY display
the associated status message(s) to the user.
And, replace:
- The client MAY choose a less-preferred server if that server
has a better set of advertised parameters, such as the
available addresses advertised in IAs.
With:
Troan & Volz Expires November 8, 2012 [Page 4]
Internet-Draft Multiple Stateful Option May 2012
- The client MAY choose a less-preferred server if that server
has a better set of advertised parameters, such as the
available options advertised in IAs.
It is important to note that the receipt of a Advertisement without
any bindings does not imply that the client should restart the
Solicit retransmissions timers. Doing so would lead to a Solicit/
Advertisement storm.
4.2. Placement of Status codes
In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink,
NoBinding) are encapsulated in the IA option. In Advertisement
messages the Status Code option with the NoAddrsAvail code is in the
"global" scope. That makes sense when the failure case is fatal.
With the introduction of multiple IA option types, there might be a
case where a server is not willing to offer addresses, but might be
willing to offer other stateful option types.
While a Status Code option is implicitly bound to a specific type of
IA, e.g. NoPrefixAvail is only applicable to IA_PD and NoAddrsAvail
is only applicable to IA_NA/IA_TA, it may be problematic to make this
assumption for all status codes. Ideally the Status Code option
should be encapsulated in the IA option for all DHCP messages. This
makes Advertisement messages equal to Reply messages.
Proposed solution: No change. For backwards compatibility, the
NoAddrsAvail Status Code option when no addresses are available will
be kept in the global scope for Advertise messages. Other IA option
types MUST encapsulate the Status Code option within the IA option.
4.3. T1/T2 timers
The T1 and T2 timers determine when the client will contact the
server to extend lifetimes of information received in an IA. How
should a client handle the case where multiple IA options have
different T1 and T2 timers?
In a multiple IA option types model, the T1/T2 timers are protocol
timers, that should be independent of the IA options themselves. If
we were to redo the DHCP protocol from scratch the T1/T2 timers
should be carried in a separate DHCP option.
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
with the case where servers have not yet been updated to do that,
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
Troan & Volz Expires November 8, 2012 [Page 5]
Internet-Draft Multiple Stateful Option May 2012
are ignored.
4.4. Confirm message
The Confirm message, as described in [RFC3315], is specific to
address assignment. It lets a server without a binding to reply to
the message, under the assumption that the server only needs
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 client has moved and needs to validate its addresses. Not all
bindings can be validated by servers and the Confirm message provides
for this by specifying that a server that is unable to determine the
on-link status MUST NOT send a Reply.
Note: Confirm has a specific meaning and does not overload Renew/
Rebind. It also is lower processing cost as the server does NOT need
to extend lease times or otherwise send back other configuration
options.
Proposed solution: Allow and specify the Confirm message for other IA
option types. A server SHOULD respond to a Confirm message only if
it has definitive knowledge, based on the network configuration and
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
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 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
server. The client should continue with the IA options received,
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
Troan & Volz Expires November 8, 2012 [Page 6]
Internet-Draft Multiple Stateful Option May 2012
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 it already has one or more bindings. A client MUST NOT use Renew
(or Rebind) if it has no valid bindings it is renewing.
Replace Section 18.2.3:
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 but has one or
more bindings for the client, the server SHOULD treat this like a
Request message for the IA. If the server has no other bindings for
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
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
that they offer.
One could envision a network where the DHCP servers are in multiple
provisioning domains, and it may be desireable to have the DHCP
client obtain different IA types from different provisioning domains.
How a client detects the multiple provisioning domains and how it
would interact with the multiple servers in these different domains
is outside the scope of this document and an area for future work.
5. IANA Considerations
This specification does not require any IANA actions.
6. Security Considerations
There are no new security considerations pertaining to this document.
Troan & Volz Expires November 8, 2012 [Page 7]
Internet-Draft Multiple Stateful Option May 2012
7. Acknowledgements
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011.
Authors' Addresses
Ole Troan
Cisco Systems, Inc.
Philip Pedersens vei 20
N-1324 Lysaker,
Norway
Email: ot@cisco.com
Bernie Volz
Cisco Systems, Inc.
1414 Massachusetts Ave
Boxborough, MA 01719,
USA
Email: volz@cisco.com
Troan & Volz Expires November 8, 2012 [Page 8]