draft-ietf-dhc-dhcpv6-stateful-issues-07.txt   draft-ietf-dhc-dhcpv6-stateful-issues-08.txt 
Network Working Group O. Troan Network Working Group O. Troan
Internet-Draft B. Volz Internet-Draft B. Volz
Updates: 3315,3633 (if approved) Cisco Systems, Inc. Updates: 3315,3633 (if approved) Cisco Systems, Inc.
Intended status: Standards Track M. Siodelski Intended status: Standards Track M. Siodelski
Expires: April 5, 2015 ISC Expires: April 25, 2015 ISC
October 2, 2014 October 22, 2014
Issues and Recommendations with Multiple Stateful DHCPv6 Options Issues and Recommendations with Multiple Stateful DHCPv6 Options
draft-ietf-dhc-dhcpv6-stateful-issues-07.txt draft-ietf-dhc-dhcpv6-stateful-issues-08.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 RFC 7084 has shown multiple issues with the DHCPv6 described in RFC 7084 has shown multiple issues with the DHCPv6
protocol in supporting multiple stateful options. This document protocol in supporting multiple stateful options. This document
updates RFC 3315 and RFC 3633. updates RFC 3315 and RFC 3633 to address the identified issues.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 5, 2015. This Internet-Draft will expire on April 25, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 15 skipping to change at page 2, line 15
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. 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 . . . . . . . . . . . . 3
4.1. Placement of Status Codes . . . . . . . . . . . . . . . . 5 4.1. Placement of Status Codes . . . . . . . . . . . . . . . . 4
4.2. Advertise Message . . . . . . . . . . . . . . . . . . . . 6 4.2. Advertise Message . . . . . . . . . . . . . . . . . . . . 6
4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 7 4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 8 4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 8
4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 8 4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 8
4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 8 4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 8
4.4.3. Updates to section 18.1.3 of RFC 3315 . . . . . . . . 9 4.4.3. Updates to section 18.1.3 of RFC 3315 . . . . . . . . 9
4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 10 4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 10
4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 11 4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 11
4.4.6. Updates to Section 18.2.3 of RFC 3315 . . . . . . . . 14 4.4.6. Updates to Section 18.2.3 of RFC 3315 . . . . . . . . 13
4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 15 4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 15
4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 17 4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 17
4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 18 4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 18
4.6. Decline Should Not Necessarily Trigger a Release . . . . 19 4.6. Decline Should Not Necessarily Trigger a Release . . . . 19
4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 19 4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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
[RFC7084] has shown issues with the DHCPv6 protocol in supporting [RFC7084] has shown issues with the DHCPv6 protocol in supporting
multiple stateful option types, in particular IA_NA (non-temporary multiple stateful option types, in particular IA_NA (non-temporary
addresses) and IA_PD (delegated prefixes). addresses) and IA_PD (delegated prefixes).
This document describes a number of problems encountered with This document describes a number of problems encountered with
coexistence of the IA_NA and IA_PD option types and changes to the coexistence of the IA_NA and IA_PD option types and changes to the
DHCPv6 protocol specifications to address these problems. DHCPv6 protocol specifications to address these problems.
The intention of this work is to clarify and, where needed, modify The intention of this work is to clarify and, where needed, modify
the DHCP protocol specification to support multiple IA option types the DHCP protocol specification to support IA_NA and IA_PD option
within a single DHCP session. However, as it is not possible to know types within a single DHCP session.
what future IA option types might be used for, this work is primarily
to clarify DHCP operation when IA_NA and IA_PD options are being
requested as per [RFC7084]. And, to provide a framework to support
new IA option types, assuming they are similar enough. Future
documents that define new IA option types will need to specify
whether they fit into this framework or define the DHCP operation for
the new and existing IA option types, as appropriate.
There are two general solutions to the problem of supporting multiple
IA option types. One is by using a separate DHCP session (separate
instances of the client state machine) per IA option type. While
conceptually simple, this approach has a number of issues: multiple
instances of the state machine in clients, additional DHCP protocol
traffic, 'collisions' between other configuration options, divergence
in that each IA option type specification specifies its 'own' version
of the DHCP protocol. The other is by using a single DHCP session
and state machine, which is the approach taken by this document (see
Section 4).
Note that while IA_TA (temporary addresses) options may be included Note that while IA_TA (temporary addresses) options may be included
with other IA option type requests, these generally are not renewed with other IA option type requests, these generally are not renewed
(there are no T1/T2 times) and have a separate life cycle from IA_NA (there are no T1/T2 times) and have a separate life cycle from IA_NA
and IA_PD option types. DHCPv6 assigned temporary addresses also and IA_PD option types. DHCPv6 assigned temporary addresses also
have limited value when DHCPv6 is used for non-temporary address have limited value when DHCPv6 is used for non-temporary address
assignment, as the privacy issues identified for IPv6 stateless assignment, as the privacy issues identified for IPv6 stateless
address assignment ([RFC4941]) do not apply to DHCPv6 assignments. address assignment ([RFC4941]) do not apply to DHCPv6 assignments.
Therefore, the IA_TA option type is mostly out of scope for this
document.
The changes described in this document are intended to be The changes described in this document are intended to be
incorporated in a new revision of the DHCPv6 protocol specification incorporated in a new revision of the DHCPv6 protocol specification
([I-D.dhcwg-dhc-rfc3315bis]). ([I-D.dhcwg-dhc-rfc3315bis]).
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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. Terminology 3. Terminology
In addition to the terminology defined in [RFC3315], [RFC3633], and In addition to the terminology defined in [RFC3315], [RFC3633], and
[RFC7227], the following terminology is used in this document: [RFC7227], the following terminology is used in this document:
Resource (allocable resource): A value (or a collection of values) Identity association (IA): Throughout this document, "IA" is
dynamically assigned to the client by used to refer to the Identity
the server and being carried in the Association containing addresses or
stateful options. Examples of prefixes assigned to a client and
resources are an IPv6 address or an carried in the IA_NA or IA_PD options
IPv6 prefix. Information about the respectively.
resources is transported in stateful
options such as IA_NA, for addresses,
and IA_PD, for prefix delegations.
In the future, other types of
resources and stateful options may be
defined.
Identity association (IA): A collection of resources 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
non-temporary addresses (IA_NA) holds
non-temporary addresses. Throughout
this document, "IA" is used to refer
to an identity association without
identifying the type of resources in
the IA.
IA option types: This is used to generally mean an IA option types: This is used to generally mean an
IA_NA and/or IA_PD and may also IA_NA and/or IA_PD option.
include IA_TA, as well as future IA
options.
Stateful options: Options that require dynamic binding Stateful options: Options that require dynamic binding
state per client on the server. state per client on the server.
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
were 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 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 configured to only offer a subset of them, the client could react in
several ways. Reset the state machine and continue to send Solicit several ways. Reset the state machine and continue to send Solicit
messages, create separate DHCP sessions for each IA option type and messages, create separate DHCP sessions for each IA option type and
continue to Solicit for the unfulfilled IA options, or it could continue to Solicit for the unfulfilled IA options, or it could
continue with the single session, and include the unfulfilled IA continue with the single session, and include the unfulfilled IA
options in subsequent messages to the server. options in subsequent messages to the server.
Reseting the state machine and continuing to send Solicit messages
may result in the client never completing DHCP and is generally not
considered a good solution. It can also result in a request storm if
the client does not appropriately rate limit its sending of Solicit
messages.
Creating a separate DHCP session (separate instances of the client
state machine) per IA option type, while conceptually simple, has a
number of issues: multiple instances of the state machine in clients,
additional DHCP protocol traffic, 'collisions' between other
configuration options, divergence in that each IA option type
specification specifies its 'own' version of the DHCP protocol.
This leaves a single DHCP session and state machine which is the
proposed solution. Here, the client can use what it is able to
obtain and can continue to request what it was previously unable to
obtain while maintaining a single session and state machine.
Proposed solution: the client should keep a single session with the Proposed solution: the client should keep a single session with the
server and include the missing options in subsequent messages server and include the missing options in subsequent messages
(Request, Renew, and Rebind) to the server. (Request, Renew, and Rebind) to the server.
4.1. Placement of Status Codes 4.1. Placement of Status Codes
In Reply messages IA specific status codes (i.e., NoAddrsAvail, In Reply messages IA specific status codes (i.e., NoAddrsAvail,
NotOnlink, NoBinding, NoPrefixAvail) are encapsulated in the IA NotOnLink, NoBinding, NoPrefixAvail) are encapsulated in the IA
option. In Advertise messages the Status Code option with the option. In Advertise messages the Status Code option with the
NoAddrsAvail code is in the top-level. That makes sense when the NoAddrsAvail code is in the top level. This makes sense if the
failure case is fatal. However, with the introduction of other client is only interested in the assignment of the addresses and the
stateful option types, there may be cases where a server is not failure case is fatal. However, if the client sends both IA_NA and
willing to offer addresses, but is willing to offer other resources, IA_PD options in a Solicit message, it is possible that the server
e.g. delegated prefixes. offers no addresses but it offers some prefixes, and the client may
choose to send a Request message to obtain the offered prefixes. In
Ideally the Status Code option for IA specific status codes should be this case, it is better if the Status Code option for IA specific
encapsulated in the IA option for all DHCP messages. This also makes status codes is encapsulated in the IA option to indicate that the
the NoAddrsAvail and NoPrefixAvail Status Code option placement for failure occurred for the specific IA. This also makes the
NoAddrsAvail and NoPrefixAvail Status Code option placement for
Advertise messages identical to Reply messages. Advertise messages identical to Reply messages.
In addition, how a server formats the Advertise message when In addition, how a server formats the Advertise message when
addresses are not available has been a point of some confusion and addresses are not available has been a point of some confusion and
implementations seem to vary (some strictly follow RFC 3315 while implementations seem to vary (some strictly follow RFC 3315 while
others assumed it was encapsulated in the IA option as for Reply others assumed it was encapsulated in the IA option as for Reply
messages). messages).
Therefore, the proposed solution is: Therefore, the proposed solution is:
skipping to change at page 7, line 44 skipping to change at page 7, line 28
client handle the case where multiple IA options have different T1 client handle the case where multiple IA options have different T1
and T2 times? and T2 times?
In a multiple IA option type model, the T1/T2 times are protocol In a multiple IA option type model, the T1/T2 times are protocol
timers, that should be independent of the IA options themselves. If timers, that should be independent of the IA options themselves. If
we were to redo the DHCP protocol from scratch the T1/T2 times should we were to redo the DHCP protocol from scratch the T1/T2 times should
be carried in a separate DHCP option. be carried in a separate DHCP option.
Proposed solution: The server MUST set the T1/T2 times in all IA Proposed solution: The server MUST set the T1/T2 times in all IA
options in a Reply or Advertise message to the same value. To deal options in a Reply or Advertise message 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, the
clients MUST use the shortest (explicit or implicit) T1/T2 times client MUST select a T1 and T2 time from all IA options which will
(larger than 0), from the same IA option, in the Reply. T1/T2 times guarantee that the client will send Renew/Rebind messages not later
from other IAs are ignored. than at the T1/T2 times associated with any of the client's bindings.
The following paragraph should be added to Section 18.2.1, 18.2.3, As an example, if the client receives a Reply with T1_NA of 3600 /
T2_NA of 5760 and T1_PD of 0 / T2_PD of 1800, the client SHOULD use
the T1_PD of 0 / T2_PD of 1800. The reason for this is that a T1 of
0 means that the Renew time is at the client's discretion, but this
value cannot be greater than the T2 value (1800).
The following paragraph should be added to Sections 18.2.1, 18.2.3,
and 18.2.4 of RFC 3315: and 18.2.4 of RFC 3315:
The T1/T2 times set in each applicable IA option for a Reply MUST The T1/T2 times set in each applicable IA option for a Reply MUST
be the same values across all IAs. The server MUST determine the be the same values across all IAs. The server MUST determine the
T1/T2 times across all of the applicable client's bindings in the T1/T2 times across all of the applicable client's bindings in the
Reply. This facilitates the client being able to renew all of the Reply. This facilitates the client being able to renew all of the
bindings at the same time. bindings at the same time.
Note: This additional paragraph has also been included in the revised
text later for Sections 18.2.3 and 18.2.4 of RFC 3315.
Changes for client T1/T2 handling are included in Section 4.4.3 and
Section 4.4.4.
4.4. Renew and Rebind Messages 4.4. Renew and Rebind Messages
This section presents issues with handling multiple IA option types This section presents issues with handling multiple IA option types
in the context of creation and processing the Renew and Rebind in the context of creation and processing the Renew and Rebind
messages. It also proposes relevant updates to the [RFC3315] and messages. It also proposes relevant updates to the [RFC3315] and
[RFC3633]. [RFC3633].
4.4.1. Renew Message 4.4.1. Renew Message
The Renew message, as described in [RFC3315], allows a client to only The Renew message, as described in [RFC3315], allows a client to only
skipping to change at page 9, line 26 skipping to change at page 9, line 22
containing an IA option for the IA. The client includes IA Address containing an IA option for the IA. The client includes IA Address
options in the IA option for the addresses associated with the IA. options in the IA option for the addresses associated with the IA.
The server determines new lifetimes for the addresses in the IA The server determines new lifetimes for the addresses in the IA
according to the administrative configuration of the server. The according to the administrative configuration of the server. The
server may also add new addresses to the IA. The server may remove server may also add new addresses to the IA. The server may remove
addresses from the IA by setting the preferred and valid lifetimes addresses from the IA by setting the preferred and valid lifetimes
of those addresses to zero. of those addresses to zero.
The server controls the time at which the client contacts the The server controls the time at which the client contacts the
server to extend the lifetimes on assigned addresses through the T1 server to extend the lifetimes on assigned addresses through the T1
and T2 parameters assigned to an IA. and T2 parameters assigned to an IA. However, as the client
Renews/Rebinds all IAs from the server at the same time, the client
MUST select a T1 and T2 time from all IA options which will
guarantee that the client will send Renew/Rebind messages not later
than at the T1/T2 times associated with any of the client's
bindings.
At time T1 for an IA, the client initiates a Renew/Reply message At time T1, the client initiates a Renew/Reply message exchange to
exchange to extend the lifetimes on any addresses in the IA. extend the lifetimes on any addresses in the IA.
If T1 or T2 had been set to 0 by the server (for an IA_NA) or there If T1 or T2 had been set to 0 by the server (for an IA_NA) or there
are no T1 or T2 times (for an IA_TA) in a previous Reply, the are no T1 or T2 times (for an IA_TA) in a previous Reply, the
client may send a Renew or Rebind message, respectively, at the client may send a Renew or Rebind message, respectively, at the
client's discretion. client's discretion.
The client sets the "msg-type" field to RENEW. The client The client sets the "msg-type" field to RENEW. The client
generates a transaction ID and inserts this value in the generates a transaction ID and inserts this value in the
"transaction-id" field. "transaction-id" field.
skipping to change at page 10, line 35 skipping to change at page 10, line 37
MRD Remaining time until T2 MRD Remaining time until T2
The message exchange is terminated when time T2 is reached (see The message exchange is terminated when time T2 is reached (see
section 18.1.4), at which time the client begins a Rebind message section 18.1.4), at which time the client begins a Rebind message
exchange. exchange.
4.4.4. Updates to Section 18.1.4 of RFC 3315 4.4.4. Updates to Section 18.1.4 of RFC 3315
Replace Section 18.1.4 of RFC 3315 with the following text: Replace Section 18.1.4 of RFC 3315 with the following text:
At time T2 for an IA (which will only be reached if the server to At time T2 (which will only be reached if the server to which the
which the Renew message was sent at time T1 has not responded), the Renew message was sent at time T1 has not responded), the client
client initiates a Rebind/Reply message exchange with any available initiates a Rebind/Reply message exchange with any available
server. server.
The client constructs the Rebind message as described in 18.1.3 The client constructs the Rebind message as described in 18.1.3
with the following differences: with the following differences:
- The client sets the "msg-type" field to REBIND. - The client sets the "msg-type" field to REBIND.
- The client does not include the Server Identifier option in the - The client does not include the Server Identifier option in the
Rebind message. Rebind message.
skipping to change at page 12, line 26 skipping to change at page 12, line 27
duplicate address detection before using the received addresses for duplicate address detection before using the received addresses for
the traffic. If any of the addresses are found to be in use on the the traffic. If any of the addresses are found to be in use on the
link, the client sends a Decline message to the server for those link, the client sends a Decline message to the server for those
addresses as described in section 18.1.7. addresses as described in section 18.1.7.
If the Reply was received in response to a Solicit (with a Rapid If the Reply was received in response to a Solicit (with a Rapid
Commit option), Request, Renew or Rebind message, the client Commit option), Request, Renew or Rebind message, the client
updates the information it has recorded about IAs from the IA updates the information it has recorded about IAs from the IA
options contained in the Reply message: options contained in the Reply message:
- Record T1 and T2 times. The client MUST use the shortest - Record T1 and T2 times.
(explicit or implicit) T1 and T2 times (larger than 0) from the
same IA option across all of the IA options to facilitate
initiating the renewal process for all bindings simultaneously.
T1/T2 times from other IAs are ignored.
- Add any new addresses in the IA option to the IA as recorded by - Add any new addresses in the IA option to the IA as recorded by
the client. the client.
- Update lifetimes for any addresses in the IA option that the - Update lifetimes for any addresses in the IA option that the
client already has recorded in the IA. client already has recorded in the IA.
- Discard any addresses from the IA, as recorded by the client, - Discard any addresses from the IA, as recorded by the client,
that have a valid lifetime of 0 in the IA Address option. that have a valid lifetime of 0 in the IA Address option.
skipping to change at page 13, line 5 skipping to change at page 12, line 49
recorded in the IA but that were not included in the IA from the recorded in the IA but that were not included in the IA from the
server. server.
Management of the specific configuration information is detailed in Management of the specific configuration information is detailed in
the definition of each option in section 22. the definition of each option in section 22.
The client examines the status code in each IA individually. If The client examines the status code in each IA individually. If
the client receives a NoAddrsAvail, the client has received no the client receives a NoAddrsAvail, the client has received no
usable addresses in the IA. usable addresses in the IA.
If the client finds no usable addresses in any IA, the client MAY If the client finds no usable addresses in any of the IAs, it may
use the Information-request message to obtain other configuration either try another server (by restarting the DHCP server discovery
information only. process) or use the Information-request message to obtain other
configuration information only.
The client uses addresses and other information from any IAs that The client uses addresses and other information from any IAs that
do not contain a Status Code option with the NoAddrsAvail code. do not contain a Status Code option with the NoAddrsAvail code.
For each IA for which the client receives NoAddrsAvail status code For each IA for which the client receives NoAddrsAvail status code
the client has the following choices: the client has the following choices:
- The client includes the IA with no addresses in subsequent Renew - The client includes the IA with no addresses in subsequent Renew
and Rebind messages sent to the server, to request creation of and Rebind messages sent to the server, to request creation of
the binding for the IA. the binding for the IA.
- Tries another server (perhaps restarting the DHCP server - Tries another server (by restarting the DHCP server discovery
discovery process). process).
When the client receives a Reply message in response to a Renew or When the client receives a Reply message in response to a Renew or
Rebind message, for each IA in the original Renew or Rebind Rebind message, for each IA in the original Renew or Rebind
message, the client: message, the client:
- Sends a Request message if the IA sent in the Renew or Rebind - Sends a Request message if the server responded with the
contained addresses that the client is currently using and the NoBinding status code. The client places only these IA options
server responded with a NoBinding status code. in the Request message for which the server returned NoBinding
status code in the Reply message. The client continues to use
- Tries to obtain the IA from another server (by restarting the other bindings for which the server did not return an error.
DHCP discovery process) if the client attempted to obtain a new
binding in the Renew or Rebind message by sending an IA without
any addresses and the server responded with NoBinding status
code.
- Follows the retransmission procedure for Renew/Rebind messages - Follows the retransmission procedure for Renew/Rebind messages
as described in section 14 if the IA is not in the Reply as described in section 14 if the IA is not in the Reply
message. message.
- Otherwise accepts the information in the IA. - Otherwise accepts the information in the IA.
When the client receives a valid Reply message in response to a When the client receives a valid Reply message in response to a
Release message, the client considers the Release event completed, Release message, the client considers the Release event completed,
regardless of the Status Code option(s) returned by the server. regardless of the Status Code option(s) returned by the server.
skipping to change at page 19, line 42 skipping to change at page 19, line 39
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
Thanks to many people that contributed to identify the issues in this Thanks to many people that contributed to identify the stateful
document, including Ralph Droms, John, Brzozowski, Ted Lemon, Hemant issues addressed by this document and for reviewing drafts of the
Singh, Wes Beebee, Gaurau Halwasia, Bud Millword, Tim Winters, and document, including Ralph Droms, John Brzozowski, Ted Lemon, Hemant
Rob Shakir. Singh, Wes Beebee, Gaurau Halwasia, Bud Millword, Tim Winters, Rob
Shakir, Jinmei Tatuya, Andrew Yourtchenko, and Fred Templin.
8. References 8. References
8.1. Normative 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
 End of changes. 26 change blocks. 
102 lines changed or deleted 95 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/