wdiff draft-ietf-dhc-dhcpv6-stateful-issues-06.txt draft-ietf-dhc-dhcpv6-stateful-issues-07.txt

Network Working Group O. Troan
Internet-Draft B. Volz
Updates: 3315,3633 (if approved) Cisco Systems, Inc.
Intended status: Standards Track M. Siodelski
Expires: January 1, April 5, 2015 ISC
June 30,
October 2, 2014

Issues and Recommendations with multiple stateful Multiple Stateful DHCPv6 options
draft-ietf-dhc-dhcpv6-stateful-issues-06.txt Options
draft-ietf-dhc-dhcpv6-stateful-issues-07.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 RFC 7084 has shown multiple issues with the DHCPv6
protocol in supporting multiple stateful options. This document
updates RFC 3315 and RFC 3633.

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 January 1, April 5, 2015.

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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Handling of multiple Multiple IA options types Options Types . . . . . . . . . . . . 4
4.1. Placement of Status Codes . . . . . . . . . . . . . . . . 5
4.2. Advertise Message . . . . . . . . . . . . . . . . . . . . 6
4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Renew Message . . . and Rebind Messages . . . . . . . . . . . . . . . . 8
4.4.1. Renew Message . . . 7
4.4.1. Updates to RFC 3315 . . . . . . . . . . . . . . . . . 8
4.4.2. Updates to RFC 3633 . . . . . . . . . . . . . . Rebind Message . . . 9
4.4.3. Creation and Transmission of Renew Messages (unified
text) . . . . . . . . . . . . . . . . 8
4.4.3. Updates to section 18.1.3 of RFC 3315 . . . . . . . . 9
4.4.4. Receipt Updates to Section 18.1.4 of Renew Messages (unified text) . . . . . . 11
4.5. Rebind Message . . . . . . . . . . . . . RFC 3315 . . . . . . . . 11
4.5.1. 10
4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . . . . . . . . . . 12
4.5.2. 11
4.4.6. Updates to Section 18.2.3 of RFC 3633 . . . . . . . . . 3315 . . . . . . . . 14
4.5.3. Creation and Transmission
4.4.7. Updates to Section 18.2.4 of Rebind Messages (unified
text) . . . . . RFC 3315 . . . . . . . . 15
4.4.8. Updates to RFC 3633 . . . . . . . . . . . 15
4.5.4. Receipt of Rebind Messages (unified text) . . . . . . 16
4.6. 17
4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 17
4.7. 18
4.6. Decline Should Not Necessarily Trigger a Release . . . . 18
4.8. 19
4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 18 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 19 20
8.2. Informative References . . . . . . . . . . . . . . . . . 19 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20

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
[RFC7084] has shown multiple issues with the DHCPv6 protocol in supporting
multiple stateful option types, in particular IA_NA (non-temporary
addresses) and
IA_PD. IA_PD (delegated prefixes).

This document describes a number of problems encountered with
multiple IA
coexistence of the IA_NA and IA_PD option types and recommended changes to the
DHCPv6 protocol specifications. specifications to address these problems.

The intention of this work is to clarify and, where needed, 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 However, as it is not possible to know
what future IA option
type. This latter approach has a number of issues: additional types might be used for, this work is primarily
to clarify DHCP
protocol traffic, 'collisions' between stateless operation when IA_NA and IA_PD options also
included with the are being
requested as per [RFC7084]. And, to provide a framework to support
new IA options, divergence in option types, assuming they are similar enough. Future
documents that each define new IA option type
specification specifies 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
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
and IA_PD option types. IA_TA DHCPv6 assigned temporary addresses also has
have limited value when DHCPv6 is used for non-temporary address
assignment, as the privacy issues identified for IPv6 stateless
address assignment ([RFC4941]) do not apply to DHCPv6 assignments.

The changes described in this document will are intended to be
incorporated in a new revision of the DHCPv6 protocol specification [RFC3315].
([I-D.dhcwg-dhc-rfc3315bis]).

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 [RFC2119].

3. Terminology

In addition to the terminology defined in [RFC3315], [RFC3633], and
[RFC7227], the following terminology is used in this document:

Resource (allocable resource): A value (or a collection of values)
dynamically assigned to the client by
the server and being carried in the
stateful options. An example Examples of the
resources are: are an IPv6 address or an
IPv6 prefix. Information about the
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 stateful options 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 temporary
non-temporary addresses (IA_TA) (IA_NA) holds temporary
addresses (see "identity association
for temporary addresses").
non-temporary addresses. Throughout
this document, "IA" is used to refer
to an identity association without
identifying the type of stateful option resources in
the IA.

IA option types: This is used to generally mean an
IA_NA and/or IA_PD and may also
include IA_TA, as well as any future IA
options.

Stateful options: Options that require dynamic binding
state per client on the server.

4. Handling of multiple Multiple IA options types Options Types

DHCPv6 was written with the assumption that the only stateful options
were 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.

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 unfulfilled IA options, or it could
continue with the single session, and include the unfulfilled IA
options on in subsequent messages to the server.

Proposed solution: the client should keep a single session with the
server and include the missing options on in subsequent messages
(Request, Renew, and Rebind) to the server.

4.1. Placement of Status Codes

In Reply messages IA specific status codes (i.e., NoAddrsAvail,
NotOnlink, NoBinding, NoPrefixAvail) are encapsulated in the IA
option. In Advertise messages the Status Code option with the
NoAddrsAvail code is in the top-level. That makes sense when the
failure case is fatal. With However, with the introduction of multiple IA other
stateful option types, there might may be a case cases where a server is not
willing to offer addresses, but might be is willing to offer other stateful option types.

While a Status Code option is implicitly bound to a specific type of
IA, resources,
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. delegated prefixes.

Ideally the Status Code option for IA specific status codes should be
encapsulated in the IA option for all DHCP messages. This also makes
the NoAddrsAvail and NoPrefixAvail Status Code option placement for
Advertise messages identical to Reply messages.

However,

In addition, how a server formats the Advertise message when
addresses are not available has been a point of some confusion and
implementations seem to vary. vary (some strictly follow RFC 3315 while
others assumed it was encapsulated in the IA option as for Reply
messages).

Therefore, the Proposed proposed solution is:

Clients MUST be prepared to handle each of the following Advertise
messages formats when there are no addresses available (even when no
IA_PD was
other IA option types were in the Solicit):

1. Advertise containing just a top-level Status Code option (of
NoAddrsAvail) and no IA_NAs/IA_TAs.

2. Advertise containing the IA_NAs and/or IA_TAs with encapsulated
Status Code option (of NoAddrsAvail) and no top-level Status Code
option.

3. Advertise containing a top-level Status Code option (of
NoAddrsAvail) and IA_NAs and/or IA_TAs with a Status Code option
(of NoAddrsAvail).

Servers MUST use return the Status Code option (of NoAddrsAvail)
encapsulated in an IA_NA/IA_TA options and not as a top-level Status
Code option (of NoAddrsAvail) when no addresses will be assigned (2
in the above list). This means that the Advertise response matches
the Reply response with respect to the handling of the NoAddrsAvail
status.

Replace the following paragraph in RFC 3315, section 17.2.2:

If the server will not assign any addresses to any IAs in a
subsequent Request from the client, the server MUST send an
Advertise message to the client that includes only a Status
Code option with code NoAddrsAvail and a status message for
the user, a Server Identifier option with the server's DUID,
and a Client Identifier option with the client's DUID.

With:

If the server will not assign any addresses to an IA in a
subsequent Request from the client, the server MUST include
the IA in the Advertise message with no addresses in the IA
and a Status Code option encapsulated in the IA containing
status code NoAddrsAvail.

4.2. Advertise 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. And, in this case,
the client SHOULD include the not offered IA option types in its
Request. A client SHOULD only ignore an Advertise message when no all
IA
option includes any options include no offered addresses or delegated prefixes (or any
future allocable resource). prefixes. Note
that ignored messages MUST still be processed for SOL_MAX_RT and
INF_MAX_RT options as specified in [RFC7083].

Replace Section 17.1.3 of RFC 3315: (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 (this includes the changes made by [RFC7083]):

The client MUST ignore any Advertise message that contains no
addresses (IAADDR options encapsulated in IA_NA or IA_TA options)
and no delegated prefixes (IAPREFIX options encapsulated in IA_PD
options, see RFC 3633) with the exception that the client
MUST process an included SOL_MAX_RT option (RFC 7083), MUST
process an included INF_MAX_RT option (RFC 7083), and MAY
display any 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:

- 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 an Advertise message
without any addresses and delegated prefixes does not imply that the
client should restart the Solicit retransmissions timers. Doing so
would lead to a Solicit/Advertise storm.

4.3. T1/T2 Timers

The T1 and T2 timers times 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? times?

In a multiple IA option type model, the T1/T2 timers times 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 times should
be carried in a separate DHCP option.

Proposed solution: The server SHOULD MUST set the T1/T2 timers times in all IA
options in a Reply and or Advertise messages message 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 times
(larger than 0) in any 0), from the same IA options option, in the Reply. Longer T1/T2 timers times
from other IAs are ignored.

The following paragraph should be added to Section 18.2.1, 18.2.3,
and 18.2.4 of RFC 3315:

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
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
bindings at the same time.

4.4. Renew and Rebind Messages

This section presents issues with handling multiple IA option types
in the context of creation and processing the Renew and Rebind
messages. It also proposes relevant updates to the [RFC3315] and
[RFC3633].

4.4.1. Renew Message

The Renew message, as described in [RFC3315], allows a client to only
renew bindings assigned via a Request message.

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 similar to the Request processing.

The first two subsections contain the required updates to [RFC3315]
and [RFC3633] to accommodate this behavior on

4.4.2. Rebind Message

In Section 4.4.1 it has been proposed that the client and the
server. The remaining two subsections propose a "unified" text to be
included includes IA
options in a Renew message for the [I-D.dhcwg-dhc-rfc3315bis], describing bindings it desires but has been
unable to obtain by sending a Request message, apart from the client's
and server's behavior IA
options for renewing both addresses and prefixes.

4.4.1. Updates to RFC 3315

Replace Section 18.1.3 of RFC 3315: the existing bindings.

At time T1 for an IA, T2, the client stops sending Renew messages to the server and
initiates a Renew/Reply the Rebind/Reply message exchange with any available
server. In this case, it should be possible to extend continue trying to
obtain new bindings using the lifetimes on any addresses in Rebind message if the IA. The client includes an IA option with all addresses currently assigned failed to
get the response from the server to the IA in its Renew message.

With:

At time T1

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.

Proposed solution: The client should continue with the IA options
received and it MAY include additional IA options to request creation
of additional bindings.

4.4.3. Updates to section 18.1.3 of RFC 3315

Replace Section 18.1.3 of RFC 3315 with the following text:

To extend the valid and preferred lifetimes for the addresses
associated with an IA, the client initiates sends a Renew/Reply Renew message
exchange to extend the lifetimes on any
server from which the client obtained the addresses in the IA. The
client includes IA
containing an IA option with all addresses currently assigned
to for the IA in its Renew message. IA. The client also includes an IA Address
options in the IA option for each binding it desires but has been unable to obtain.

Replace Section 18.2.3 of RFC 3315:

If the addresses associated with the IA.
The server cannot find a client entry determines new lifetimes for the addresses in the IA
according to the server
returns administrative configuration of the IA containing no server. The
server may also add new addresses with a Status Code option
set to NoBinding in the Reply message.

With:

If the IA. The server cannot find a client entry for may remove
addresses from the IA by setting the preferred and valid lifetimes
of those addresses to zero.

The server
creates controls the time at which the bindings for that client according contacts the
server to extend the server's
policy and configuration information and returns lifetimes on assigned addresses through the IAs T1
and other
information requested by T2 parameters assigned to an IA.

At time T1 for an IA, 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 it does this to no more often than the renewal frequency.

4.4.2. Updates to RFC 3633

Replace Section 12.2 of RFC 3633:

Renew message: If the delegating router cannot find a binding
for the requesting router's IA_PD the delegating
router returns the IA_PD containing no prefixes
with a Status Code option set to NoBinding in the
Reply message.

With:

Renew message: If the delegating router cannot find a binding
for the requesting router's IA_PD, the delegating
router creates the bindings for that client
according to the server's policy and
configuration information and returns the IAs and
other information requested by the client.

4.4.3. Creation and Transmission of Renew Messages (unified text)

To extend the valid and preferred lifetimes for the resources
associated with IAs, the client sends a Renew message to the server
from which the client obtained the resources.

The server controls the time at which the client contacts the server
to extend the lifetimes on client's bindings through the T1 and T2
parameters assigned to IAs. The server SHOULD assign the same T1 and
T2 value to each binding assigned to the client. In this case the
client uses the common T1 or T2 value returned in the IAs to
determine the time when it should send Renew or Rebind message to the
server. If the server sends different T1/T2 values for different
IAs, the client uses the shortest T1/T2 value (larger than 0). T1/T2
values in other IA options are ignored.

If T1 or T2 is set to 0 by the server for all IA_NA and IA_PD
options, or there are no T1 or T2 times (for an IA_TA), the client
may send Renew or Rebind message, respectively, at the client's
discretion.

At time T1, the client that initiates a Renew/Reply message exchange,
includes IA options for all bindings for which it desires to extend
lifetimes in its Renew message. For each IA being included, the
client includes all resources currently associated with the IA.

The client also includes IA option for each binding it desires but
has been unable to obtain. For example: a client which has non-
temporary addresses assigned but hasn't been delegated a prefix, may
include an IA_PD option (in addition to the IA_NA option) in the
Renew message to request prefix delegation.

The client constructing initiates a Renew Renew/Reply message SHOULD NOT include resources
in IA options that the client does not have. If the client included
a resource it does not have and the server does not allocate this
resource for the client, the server will return the resource
exchange to extend the
client lifetimes on any addresses in the IA with the lifetimes IA.

If T1 or T2 had been set to 0. This is a signal to 0 by the client to not use this resource. The server MAY allocate (for an IA_NA) or there
are no T1 or T2 times (for an IA_TA) in a
different resource to previous Reply, the
client and may send it in a Renew or Rebind message, respectively, at the same IA.
client's discretion.

The client sets the "msg-type" field to RENEW. The client
generates a transaction ID and inserts this value in the
"transaction-id" field.

The client places the identifier of the destination server in a
Server Identifier option.

The client MUST include a Client Identifier option to identify itself identify
itself to the server. The client adds any appropriate options,
including one or more IA options.

The client includes an IA option with all addresses currently
assigned to the IA in its Renew message. The client also includes
IA options for all other bindings for which the client desires to
extend the lifetimes of addresses. The client MUST only include
addresses in the IA that the client obtained from the server and
are still valid (have non-zero lifetime).

The client MAY include an IA option for each binding it desires but
has been unable to obtain. This IA option MUST NOT contain any
addresses. However, it MAY contain the IA Address option with IPv6
address field set to 0 to indicate the server. The client adds client's preference for the
preferred and valid lifetimes for any appropriate options, including
one or more IA options. newly assigned addresses.

The client MUST include an Option Request option (see section 22.7)
to indicate the options the client is interested in receiving. The
client MAY include options with data values as hints to the server
about parameter values the client would like to have returned.

The client transmits the message according to section 14, using the
following parameters:

IRT REN_TIMEOUT

MRT REN_MAX_RT

MRC 0

MRD Remaining time until T2

If the server finds that any resource sent by the client is not
appropriate, according to the server's configuration information, the
server sends back the IA with the corresponding IA Address (for
inappropriate address), IA Prefix option (for inappropriate prefix)
or other option appropriate for the type of the resource, with
lifetimes set to 0. The client which receives the option with
lifetimes set to 0 MUST NOT use the corresponding resource.

The message exchange is terminated when time T2 is reached, reached (see
section 18.1.4), at which time the client begins a Rebind message
exchange.

4.4.4. Receipt of Renew Messages (unified text)

When the server receives a Renew message via unicast from a client Updates to
which the server has not sent a unicast option, the server discards
the Renew message and responds with a Reply message containing a
Status Code option Section 18.1.4 of RFC 3315

Replace Section 18.1.4 of RFC 3315 with the value UseMulticast, a Server Identifier
option containing the server's DUID, the Client Identifier option
from the client message, and no other options.

When the server receives a Renew message that contains an IA option
from a client, it locates the client's binding and verifies that the
information in the IA from the client matches the information stored
for the client.

If the server cannot find a client entry for the IA, the server
creates the bindings following text:

At time T2 for that client according to the server's policy
and configuration information and returns the IAs and other
information requested by the client. For each an IA for which the
server (which will not create a binding only be reached if the server returns an IA option
containing a Status Code option set to NoBinding in the Reply
message.

If
which the server finds that any resource Renew message was sent by the client is at time T1 has not
appropriate, according to the server's configuration information, the
server sends back responded), the IA
client initiates a Rebind/Reply message exchange with the corresponding IA Address (for
invalid address), IA Prefix option (for invalid prefix) or any other
option appropriate for the type of the resource, with lifetimes set
to 0. available
server.

The server client constructs a Reply the Rebind message by setting as described in 18.1.3
with the following differences:

- The client sets the "msg-type" field to REPLY, and copying the transaction ID from the Renew message into
the transaction-id field. REBIND.

- The server MUST client does not include a Server Identifier option containing the
server's DUID and the Client Server Identifier option from the Renew message in the Reply
Rebind message.

The server includes other options containing configuration
information to be returned client transmits the message according to section 14, using the
following parameters:

IRT REB_TIMEOUT
MRT REB_MAX_RT

MRC 0

MRD Remaining time until valid lifetimes of all addresses in
all IAs have expired

If all addresses for an IA have expired the client as described may choose to
include this IA without any addresses (or with only a hint for
lifetimes) in [RFC3315].

4.5. subsequent Rebind Message

In the Section 4.4 it has been proposed messages to indicate that the
client includes IA
options is interested in a Renew message for assignment of the bindings it desires but has been
unable addresses to obtain by sending a Request message, apart from the IA
options for this IA.

The message exchange is terminated when the existing bindings.

At time T2 (being a shortest, greater than 0, time valid lifetimes of all
addresses across all
client's IAs), IAs have expired, at which time the client stops sending Renew messages may
use a Solicit message to the locate a new DHCP server and initiates send a
Request for the Rebind/Reply message exchange with any available
server. In this case, it should be possible to continue trying expired IAs to
obtain new bindings using the Rebind message if the client failed new server.

4.4.5. Updates to
get Section 18.1.8 of RFC 3315

Replace Section 18.1.8 of RFC 3315 with the response from following text:

Upon the server receipt of a valid Reply message in response to the Renew message.

The a Solicit
(with a Rapid Commit option), Request, Confirm, Renew, Rebind or
Information-request message, as described the client extracts the configuration
information contained in [RFC3315] does not explicitly
specify what a server should do when an IA option which contains no
addresses is present.

Proposed solution: the Reply. The client should continue with the IA options
received and it MAY include additional IA options to request creation
of additional bindings.

The first two subsections contain the required updates to [RFC3315]
and [RFC3633] choose to accommodate this behavior on the client and
report any status code or message from the
server. The remaining two subsections propose a "unified" text to be
included status code option in
the [I-D.dhcwg-dhc-rfc3315bis], describing Reply message.

If the client's
and server's behavior client receives a Reply message with respect to processing different IA option
types in a single Rebind message.

4.5.1. Updates to RFC 3315

Replace Section 18.1.4 of RFC 3315:

At time T2 for an IA (which will only be reached if Status Code
containing UnspecFail, the server is indicating that it was unable
to
which process the Renew message was sent at time T1 has not responded), due to an unspecified failure condition. If
the client initiates a Rebind/Reply retransmits the original 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 same server to
retry the desired operation, the client MUST limit the rate at
which it retransmits the Renew message was sent at and limit the duration of the time T1 has not responded),
during which it retransmits the message.

When the client initiates receives a Rebind/Reply Reply message exchange with any
available server. The client includes an IA a Status Code option
with all
addresses currently assigned to the IA in its Rebind message. The
client also includes an IA option (without value UseMulticast, the IA Address option)
for each binding it desires but has been unable to obtain.

The client constructing a Rebind message SHOULD NOT include
addresses in IA options that records the client does not have. If receipt of the
client included an address it does not have
message and sends subsequent messages to the server does
not allocate this address for the client, the server will return through the IA Address option containing address included by
interface on which the message was received using multicast. The
client in resends the IA with lifetimes set to 0. This is an indication to original message using multicast.

When the client to not use this address. The server MAY allocate receives a
different address NotOnLink status from the server in
response to a Confirm message, the client performs DHCP server
solicitation, as described in section 17, and send it client-initiated
configuration as described in section 18. If the same IA.

Replace Section 18.2.4 of RFC 3315 with client receives
any Reply messages that do not indicate a NotOnLink status, the following text to clarify
how
client can use the server should handle all of addresses in the possible conditions: IA and ignore any messages that
indicate a NotOnLink status.

When the server client receives a Rebind message that contains an IA
option NotOnLink status from the server in
response to a client, it locates Request, the client's binding and verifies
that client can either re-issue the information Request
without specifying any addresses or restart the DHCP server
discovery process (see section 17).

The client SHOULD perform duplicate address detection [17] on each
of the received addresses in any IAs, on which it has not performed
duplicate address detection during processing of any of the IA
previous Reply messages from the server. The client matches performs the
information stored
duplicate address detection before using the received addresses for that client.

If
the server finds traffic. If any of the addresses are found to be in use on the IA for
link, the client and sends a Decline message to the server determines that the for those
addresses as described in section 18.1.7.

If the IA are appropriate for
the link to which the client's interface is attached according Reply was received in response to a Solicit (with a Rapid
Commit option), Request, Renew or Rebind message, the server's explicit configuration information, client
updates the server SHOULD
send back information it has recorded about IAs from the IA to
options contained in the Reply message:

- Record T1 and T2 times. The client with new lifetimes MUST use the shortest
(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.

If times from other IAs are ignored.

- Add any new addresses in the server cannot find a client entry IA option to the IA as recorded by
the client.

- Update lifetimes for any addresses in the IA and option that the server
determines
client already has recorded in the IA.

- Discard any addresses from the IA, as recorded by the client,
that have a valid lifetime of 0 in the IA Address option.

- Leave unchanged any information about addresses the client has
recorded in the IA are but that were not appropriate for included in the
link to which IA from the client's interface is attached according to
server.

Management of the
server's explicit specific configuration information, the server MAY send a
Reply message to information is detailed in
the definition of each option in section 22.

The client containing examines the client's IA, with status code in each IA individually. If
the
lifetimes for client receives a NoAddrsAvail, the client has received no
usable addresses in the IA set to zero. This Reply
constitutes an explicit notification to IA.

If the client that the finds no usable addresses in any IA, the IA are no longer valid. In this situation, if client MAY
use the
server does Information-request message to obtain other configuration
information only.

The client uses addresses and other information from any IAs that
do not send contain a Reply message it silently discards Status Code option with the
Rebind message.

If NoAddrsAvail code.
For each IA for which the server cannot find a client entry for receives NoAddrsAvail status code
the IA and client has the following choices:

- The client includes the IA is
empty (i.e. contains with no addresses), the server MAY assign the addresses to this IA in subsequent Renew
and send a Reply message Rebind messages sent to the client with
this IA containing allocated addresses with lifetimes and T1/T2
times. In server, to request creation of
the case when binding for the IA.

- Tries another server (perhaps restarting the DHCP server
discovery process).

When the client included addresses receives a Reply message in the IA,
included addresses are appropriate response to a Renew or
Rebind message, for each IA in the link to which original Renew or Rebind
message, the
client's interface is attached according to client:

- Sends a Request message if the server's explicit
configuration information and they are not IA sent in use, the server MAY
allocate these Renew or Rebind
contained addresses to that the client. If client is currently using and the
server does not
allocate addresses responded with a NoBinding status code.

- Tries to obtain the client, the IA from another server returns (by restarting the IA
containing only Status Code option set
DHCP discovery process) if the client attempted to NoBinding obtain a new
binding in the Reply
message.

When Renew or Rebind message by sending an IA without
any addresses and the server creates new bindings responded with NoBinding status
code.

- Follows the retransmission procedure for Renew/Rebind messages
as described in section 14 if the IA it is possible that
other servers also create bindings as a result of receiving not in the
same Rebind Reply
message. This is

- Otherwise accepts the same issue as information in the Discussion
under the Rapid Commit option, see section 22.14. Therefore, the
server SHOULD only create new bindings during processing of a
Rebind message if IA.

When the server is configured to respond with client receives a valid Reply message in response to a Solicit message containing
Release message, the Rapid Commit option.

The server constructs client considers the Release event completed,
regardless of the Status Code option(s) returned by the server.

When the client receives a valid Reply message in response to a
Decline message, the client considers the Decline event completed,
regardless of the Status Code option(s) returned by setting the "msg-type"
field server.

4.4.6. Updates to REPLY, and copying Section 18.2.3 of RFC 3315

Replace Section 18.2.3 of RFC 3315 with the transaction ID from following text:

When the Rebind server receives a Renew message into via unicast from a client
to which the transaction-id field.

The server MUST include has not sent a unicast option, the server
discards the Renew message and responds with a Reply message
containing a Status Code option with the value UseMulticast, a
Server Identifier option containing the server's DUID and DUID, the Client
Identifier option from the Rebind
message client message, and no other options.

For each IA in the Reply message.

The Renew message from a client, the server includes other options containing configuration
information to be returned to locates
the client as described client's binding and verifies that the information in section
18.2.

4.5.2. Updates to RFC 3633

Replace Section 12.2 of RFC 3633:

Rebind message: If the delegating router cannot find a binding
for IA
from the requesting router's IA_PD and client matches the
delegating router determines information stored for that client.

If the prefixes server finds the addresses in the IA_PD are not appropriate IA for the link to
which the requesting router's interface is
attached according to client then the delegating routers
explicit configuration,
server sends back the delegating router MAY
send a Reply message IA to the requesting router
containing the IA_PD client with new lifetimes and, if
applicable, T1/T2 times. If the server is unable to extend the
lifetimes of the
prefixes an address in the IA_PD set IA, the server MAY choose not to zero. This Reply
constitutes an explicit notification
include the IA Address option for this address.

The server may choose to change the
requesting router that list of addresses and the prefixes
lifetimes of addresses in the IA_PD IAs that are no longer valid. If the delegating router is
unable returned to determine if the prefix is not
appropriate for the link, the Rebind message is
discarded.

with:

Rebind message: client.

If the delegating router cannot find a binding
for the requesting router's IA_PD and the
delegating router determines server finds that any of the prefixes addresses in the IA_PD IA are not
appropriate for the link to which the requesting router's interface client is
attached according to the delegating routers
explicit configuration, the delegating router MAY
send a Reply message to attached, the requesting router
containing
server returns the IA_PD with address to the client with lifetimes of 0.

For each IA for which the
prefixes in server cannot find a client entry, the IA_PD set to zero. This Reply
constitutes an explicit notification
server has the following choices depending on the server's policy
and configuration information:

- If the server is configured to create new bindings as a result
of processing Renew messages, the
requesting router that server SHOULD create a binding
and return the prefixes IA with allocated addresses with lifetimes and,
if applicable, T1/T2 times and other information requested by
the client. The server MAY use values in the IA_PD
are no longer valid. IA Address option
(if included) as a hint.

- If the delegating router server is
unable configured to determine if create new bindings as a result
of processing Renew messages, but the prefix is server will not
appropriate for assign any
addresses to an IA, the link, server returns the Rebind IA option containing
a Status Code option with the NoAddrsAvail status code and a
status message is
discarded. for a user.

- If the IA_PD contains no prefixes or
the prefixes are appropriate server does not support creation of new bindings for the link to
which the requesting router's interface
client sending a Renew message, or if this behavior is
attached disabled
according to the delegating router's
explicit server's policy or configuration information and if
prefixes are not in use, information,
the server returns the delegating router
MAY assign prefixes to this IA_PD.

4.5.3. Creation and Transmission of Rebind Messages (unified text)

At time T2 for an IA (which will only be reached if option containing a Status code option
with the NoBinding status code and a status message for a user.

The server constructs a Reply message by setting the "msg-type"
field to
which REPLY, and copying the transaction ID from the Renew
message was sent at time T1 has not responded), into the
client initiates transaction-id field.

The server MUST include a Rebind/Reply message exchange with any available
server. For each IA being included, Server Identifier option containing the client stores all resources
currently associated with
server's DUID and the IA. Client Identifier option from the Renew
message in the Reply message.

The client also server includes other options containing configuration
information to be returned to the client as described in section
18.2.

The T1/T2 times set in each applicable IA option for each binding it desires but
has been unable to obtain. For example: a Reply MUST
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
Reply. This facilitates the client which has non-
temporary addresses assigned but has not been delegated a prefix, may
include an IA_PD option (in addition being able to renew all of the IA_NA option) in
bindings at the
Rebind message same time.

4.4.7. Updates to request Section 18.2.4 of RFC 3315

Replace Section 18.2.4 of RFC 3315 with the prefix delegation.

The client constructing following text:

When the server receives a Rebind message SHOULD NOT include resources
in that contains an IA options
option from a client, it locates the client's binding and verifies
that the information in the IA from the client does not have. matches the
information stored for that client.

If the server finds the addresses in the IA for the client included
a resource it does not have and the
server does not allocate this
resource determines that the addresses in the IA are appropriate for
the client, link to which the client's interface is attached according to
the server's explicit configuration information, the server will return the appropriate
option containing SHOULD
send back the resource (e.g. IA Address, IA Prefix) with to the client with new lifetimes set to 0. This and, if
applicable, T1/T2 times. If the server is an indication unable to extend the
lifetimes of an address in the IA, the client to not use
this resource. The server MAY allocate a different resource choose not to
include the IA Address option for this address.

If the server finds the client entry for the IA and send it in any of the same IA.

The client sets
addresses are no longer appropriate for the "msg-type" field link to REBIND. The client generates
a transaction ID and inserts this value in which the "transaction-id"
field.

The client MUST include a Client Identifier option
client's interface is attached according to identify itself the server's explicit
configuration information, the server returns the addresses to the server. The client adds any appropriate options, including
one or more IA options. The
client MUST include the list with lifetimes of
resources 0.

If the server cannot find a client currently has associated with entry for the IAs IA, the IA
contains addresses and the server determines that the addresses in
the
Rebind message.

The client MUST include an Option Request option IA are not appropriate for the link to indicate which the
options that client client's
interface is interested in receiving. The client MAY
include options with data values as hints attached according to the server about
parameter values server's explicit
configuration information, the client would like server MAY send a Reply message to have returned.

The
the client transmits containing the message according to Section 14, using client's IA, with the
following parameters:

IRT REB_TIMEOUT

MRT REB_MAX_RT

MRC 0

MRD Remaining time until valid lifetimes of all for the
addresses or
prefixes in the IA have expired

The message exchange is terminated when set to 0. This Reply constitutes an explicit
notification to the valid lifetimes of all client that the resources assigned to addresses in the IA expire, at which time are no
longer valid. In this situation, if the client has
several alternative actions to choose from; for example:

- The client may choose to use a Solicit message to locate a new
DHCP server and does not send a Request for
Reply message it silently discards the expired Rebind message.

Otherwise, for each IA to for which the new
server.

- The server cannot find a client may have other resources in other IAs, so
entry, the client
may choose to discard server has the expired IA and use following choices depending on the other IAs.

4.5.4. Receipt of Rebind Messages (unified text)

When
server's policy and configuration information:

- If the server receives is configured to create new bindings as a result
of processing Rebind message that contains an IA messages (also see the note about the
Rapid Commit option
from a client, it locates below), the client's server SHOULD create a binding
and verifies that return the IA with allocated addresses with lifetimes and,
if applicable, T1/T2 times and other information requested by
the client. The server MAY use values in the IA from the client matches the information stored
for that client. Address option
(if included) as a hint.

- If the server finds is configured to create new bindings as a result
of processing Rebind messages, but the resource in server will not assign
any addresses to an IA, the server returns the IA for option
containing a Status Code option with the client NoAddrsAvail status
code and a status message for a user.

- If the server determines that the resources in the IA are appropriate does not support creation of new bindings for the link to which the client's interface
client sending a Rebind message, or if this behavior is attached
disabled according to the server's explicit policy or configuration
information, the server SHOULD send
back returns the IA to the client option containing a
Status Code option with new lifetimes the NoBinding status code and T1/T2 times.

If a status
message for a user.

When the server cannot find a client entry creates new bindings for the IA and the server
determines it is possible
that other servers also create bindings as a result of receiving
the resources in the IA are not appropriate for same Rebind message. This is the
link to which same issue as in the client's interface is attached according to
Discussion under the
server's explicit configuration information, Rapid Commit option, see section 22.14.
Therefore, the server MAY send SHOULD only create new bindings during
processing of a
Reply Rebind message to the client containing the client's IA, with the
lifetimes for the resources in if the IA set server is configured to zero. This
respond with a Reply
constitutes an explicit notification message to a Solicit message containing the client that the resources
in the IA are no longer valid. In this situation, if the
Rapid Commit option.

The server does
not send constructs a Reply message it silently discards by setting the "msg-type"
field to REPLY, and copying the transaction ID from the Rebind message.

If
message into the transaction-id field.

The server cannot find MUST include a client entry for Server Identifier option containing the IA
server's DUID and the IA is
empty (i.e. contains no resources), Client Identifier option from the server MAY assign Rebind
message in the
resources Reply message.

The server includes other options containing configuration
information to this be returned to the client as described in section
18.2.

The T1/T2 times set in each applicable IA and send option for a Reply message to MUST
be the client with this
IA containing allocated resources with lifetimes and T1/T2 times. In same values across all IAs. The server MUST determine the case when
T1/T2 times across all of the client included resources applicable client's bindings in the IA, included
resources are appropriate for
Reply. This facilitates the link client being able to which renew all of the client's
interface is attached according to
bindings at the server's explicit
configuration information same time.

4.4.8. Updates to RFC 3633

Replace Section 12.1:

Each prefix has valid and they preferred lifetimes whose durations are not
specified in use, the server MAY
allocate these resources IA_PD Prefix option for that prefix. The
requesting router uses Renew and Rebind messages to request the client. If
extension of the server does not
allocate resources to lifetimes of a delegated prefix.

With:

Each prefix has valid and preferred lifetimes whose durations are
specified in the client, IA_PD Prefix option for that prefix. The
requesting router uses Renew and Rebind messages to request the server returns
extension of the lifetimes of a delegated prefix.

The requesting router MAY include IA_PD options without any
prefixes, i.e. without IA
containing only Status Code Prefix option or with IPv6 prefix field
of IA Prefix option set to NoBinding 0, in the Reply
message.

When the server creates new bindings for the IA it is possible that
other servers also create bindings as a result of receiving the same Renew or Rebind message. This is the same issue as in the Discussion under
the Rapid Commit option, see section 22.14 of [RFC3315]. Therefore,
the server SHOULD only create new message to
obtain bindings during processing it desires but has been unable to obtain. The
requesting router MAY set the prefix-length field of a
Rebind message if the server is configured to respond with IA Prefix
option as a Reply
message hint to a Solicit message containing the Rapid Commit option. server.

Replace Section 12.2:

The server constructs delegating router behaves as follows when it cannot find a Reply message by setting
binding for the "msg-type" requesting router's IA_PD:

With:

For the Renew or Rebind, if the IA_PD contains no prefixes, i.e.
contains no IA Prefix option or the IPv6 prefix field in the IA
Prefix option is set to REPLY, and copying 0, the transaction ID from delegating router MAY assign
prefixes to the Rebind message into IA_PD according to the delegating router's
explicit configuration information. In this case, when the transaction-id field.

The server MUST include a Server Identifier option containing
assigns new prefixes to the
server's DUID and IA_PD, the Client Identifier option from server MAY use the Rebind
message value in
the Reply message.

The server includes other options containing configuration
information to be returned to prefix-length field of the client IA Prefix option as described in section
18.2.

4.6. a hint for the
length of the prefixes being assigned.

The delegating router behaves as follows when it cannot find a
binding for the requesting router's IA_PD containing prefixes:

4.5. Confirm Message

The Confirm message, as described in [RFC3315], is specific to
address assignment. It allows 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.

The Confirm message is used by the client to verify that it has not
moved to a different link. For IAs with addresses, the mechanism
used to verify if a client has moved or not, is by matching the
link's on-link prefix(es) (typically a /64) against the prefix-length
first bits of the addresses provided by the client in the IA_NA or
IA_TA IA-types. As a consequence Confirm can only be used when the
client has an IA with address(es) (IA_NA or IA_TA).

A client MUST have a binding including an IA with addresses to use
the Confirm message. A client with IAs with addresses as well as
other IA-types MAY, depending on the IA-type, use the Confirm message
to detect if the client has moved to a different link. A client that
does not have a binding with an IA with addresses MUST use the Rebind
message instead.

IA_PD requires verification that the server has the binding for the
IAs. In that case a client MUST use the Rebind message in place of
the Confirm message and it MUST include all of its bindings, even
address IAs.

4.7.

Note that Section 18.1.2 of RFC 3315 states that a client MUST
initiate a Confirm when it may have moved to a new link. This is
relaxed to a SHOULD as a client may have determined whether it has or
has not moved using other techniques, such as described in [RFC6059].
And, as stated above, a client with delegated prefixes, MUST send a
Rebind instead of a Confirm.

4.6. Decline Should Not Necessarily Trigger a Release

Some clients will client implementations have been found to send a Release message
for other bindings they may have received after they determine a
conflict and have correctly sent a Decline message for the
conflicting address(es).

It is recommended that a client SHOULD NOT send a Release message for
other bindings it may have received just because it sent a Decline
message. The client should retain the non-conflicting bindings.

4.8.

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. This was also assumed by [RFC3315] and [RFC3633].

One could envision a network where the DHCP servers are in multiple
provisioning domains, and it may be desirable 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.

5. IANA Considerations

This specification does not require any IANA actions.

6. Security Considerations

There are no new security considerations pertaining to this document.

7. Acknowledgements

Thanks to many people that contributed to identify the issues in this
document, including Ralph Droms, John, Brzozowski, Ted Lemon, Hemant
Singh, Wes Beebee, Gaurau Halwasia, Bud Millword, Tim Winters, and
Rob Shakir.

8. References
8.1. 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.

[RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT
and INF_MAX_RT", RFC 7083, November 2013.

8.2. Informative References

[I-D.dhcwg-dhc-rfc3315bis]
Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) bis", draft-
dhcwg-dhc-rfc3315bis-01
dhcwg-dhc-rfc3315bis-02 (work in progress), May July 2014.

[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.

[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059, November
2010.

[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
November 2013.

[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, May 2014.

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

Marcin Siodelski
ISC
950 Charter Street
Redwood City, CA 94063
USA

Email: msiodelski@gmail.com