draft-ietf-dhc-dhcpv6-stateful-issues-06.txt   draft-ietf-dhc-dhcpv6-stateful-issues-07.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: January 1, 2015 ISC Expires: April 5, 2015 ISC
June 30, 2014 October 2, 2014
Issues with multiple stateful DHCPv6 options Issues and Recommendations with Multiple Stateful DHCPv6 Options
draft-ietf-dhc-dhcpv6-stateful-issues-06.txt draft-ietf-dhc-dhcpv6-stateful-issues-07.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
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 January 1, 2015. This Internet-Draft will expire on April 5, 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 . . . . . . . . . . . . 4
4.1. Placement of Status Codes . . . . . . . . . . . . . . . . 5 4.1. Placement of Status Codes . . . . . . . . . . . . . . . . 5
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 Message . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 8
4.4.1. Updates to RFC 3315 . . . . . . . . . . . . . . . . . 8 4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 8
4.4.2. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 9 4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 8
4.4.3. Creation and Transmission of Renew Messages (unified 4.4.3. Updates to section 18.1.3 of RFC 3315 . . . . . . . . 9
text) . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 10
4.4.4. Receipt of Renew Messages (unified text) . . . . . . 11 4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 11
4.5. Rebind Message . . . . . . . . . . . . . . . . . . . . . 11 4.4.6. Updates to Section 18.2.3 of RFC 3315 . . . . . . . . 14
4.5.1. Updates to RFC 3315 . . . . . . . . . . . . . . . . . 12 4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 15
4.5.2. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 14 4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 17
4.5.3. Creation and Transmission of Rebind Messages (unified 4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 18
text) . . . . . . . . . . . . . . . . . . . . . . . . 15 4.6. Decline Should Not Necessarily Trigger a Release . . . . 19
4.5.4. Receipt of Rebind Messages (unified text) . . . . . . 16 4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 19
4.6. Confirm Message . . . . . . . . . . . . . . . . . . . . . 17
4.7. Decline Should Not Necessarily Trigger a Release . . . . 18
4.8. Multiple Provisioning Domains . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 19 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 multiple issues with the DHCPv6 protocol in [RFC7084] has shown issues with the DHCPv6 protocol in supporting
supporting multiple stateful option types, in particular IA_NA and multiple stateful option types, in particular IA_NA (non-temporary
IA_PD. addresses) and IA_PD (delegated prefixes).
This document describes a number of problems encountered with This document describes a number of problems encountered with
multiple IA option types and recommended changes to the DHCPv6 coexistence of the IA_NA and IA_PD option types and changes to the
protocol specifications. DHCPv6 protocol specifications to address these problems.
The intention of this work is to modify the DHCP protocol The intention of this work is to clarify and, where needed, modify
specification to support multiple IA option types within a single the DHCP protocol specification to support multiple IA option types
DHCP session. This problem can also be solved by implementing a within a single DHCP session. However, as it is not possible to know
separate DHCP session (separate client state machine) per IA option what future IA option types might be used for, this work is primarily
type. This latter approach has a number of issues: additional DHCP to clarify DHCP operation when IA_NA and IA_PD options are being
protocol traffic, 'collisions' between stateless options also requested as per [RFC7084]. And, to provide a framework to support
included with the IA options, divergence in that each IA option type new IA option types, assuming they are similar enough. Future
specification specifies its 'own' version of the DHCP protocol. 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.
Note that while IA_TA options may be included with other IA option There are two general solutions to the problem of supporting multiple
type requests, these generally are not renewed (there are no T1/T2 IA option types. One is by using a separate DHCP session (separate
times) and have a separate life cycle from IA_NA and IA_PD option instances of the client state machine) per IA option type. While
types. IA_TA also has limited value when DHCPv6 is used for address 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. DHCPv6 assigned temporary addresses also
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.
The changes described in this document will be incorporated in a new The changes described in this document are intended to be
revision of the DHCPv6 protocol specification [RFC3315]. incorporated in a new revision of the DHCPv6 protocol specification
([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) Resource (allocable resource): A value (or a collection of values)
dynamically assigned to the client by dynamically assigned to the client by
the server and being carried in the the server and being carried in the
stateful options. An example of the stateful options. Examples of
resources are: IPv6 address or an resources are an IPv6 address or an
IPv6 prefix. Information about the IPv6 prefix. Information about the
resources is transported in stateful resources is transported in stateful
options such as IA_NA, for addresses, options such as IA_NA, for addresses,
and IA_PD, for prefix delegations. and IA_PD, for prefix delegations.
In the future, other types of In the future, other types of
resources and stateful options may be resources and stateful options may be
defined. defined.
Identity association (IA): A collection of stateful options Identity association (IA): A collection of resources assigned to
assigned to a client. Each IA has an a client. Each IA has an associated
associated IAID. A client may have IAID. A client may have more than
more than one IA assigned to it; for one IA assigned to it; for example,
example, one for each of its one for each of its interfaces. Each
interfaces. Each IA holds one type IA holds one type of IA option; for
of IA option; for example, an example, an identity association for
identity association for temporary non-temporary addresses (IA_NA) holds
addresses (IA_TA) holds temporary non-temporary addresses. Throughout
addresses (see "identity association this document, "IA" is used to refer
for temporary addresses"). to an identity association without
Throughout this document, "IA" is identifying the type of resources in
used to refer to an identity the IA.
association without identifying the
type of stateful option 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 and may also
include IA_TA, as well as any future include IA_TA, as well as future IA
IA options. 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 on subsequent messages to the server. options in subsequent messages to the server.
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 on 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. That makes sense when the
failure case is fatal. With the introduction of multiple IA option failure case is fatal. However, with the introduction of other
types, there might be a case where a server is not willing to offer stateful option types, there may be cases where a server is not
addresses, but might be willing to offer other stateful option types. willing to offer addresses, but is willing to offer other resources,
e.g. delegated prefixes.
While a Status Code option is implicitly bound to a specific type of Ideally the Status Code option for IA specific status codes should be
IA, e.g. NoPrefixAvail is only applicable to IA_PD and NoAddrsAvail encapsulated in the IA option for all DHCP messages. This also makes
is only applicable to IA_NA/IA_TA, it may be problematic to make this the NoAddrsAvail and NoPrefixAvail Status Code option placement for
assumption for all status codes. Ideally the Status Code option Advertise messages identical to Reply messages.
should be encapsulated in the IA option for all DHCP messages. This
makes Status Code option placement for Advertise messages identical
to Reply messages.
However, how a server formats the Advertise message when addresses In addition, how a server formats the Advertise message when
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. implementations seem to vary (some strictly follow RFC 3315 while
others assumed it was encapsulated in the IA option as for Reply
messages).
Therefore, the Proposed solution is: Therefore, the proposed solution is:
Clients MUST be prepared to handle each of the following Advertise Clients MUST be prepared to handle each of the following Advertise
messages formats when there are no addresses available (even when no messages formats when there are no addresses available (even when no
IA_PD was in the Solicit): other IA option types were in the Solicit):
1. Advertise containing just a top-level Status Code option (of 1. Advertise containing just a top-level Status Code option (of
NoAddrsAvail) and no IA_NAs/IA_TAs. NoAddrsAvail) and no IA_NAs/IA_TAs.
2. Advertise containing the IA_NAs and/or IA_TAs with encapsulated 2. Advertise containing the IA_NAs and/or IA_TAs with encapsulated
Status Code option (of NoAddrsAvail) and no top-level Status Code Status Code option (of NoAddrsAvail) and no top-level Status Code
option. option.
3. Advertise containing a top-level Status Code option (of 3. Advertise containing a top-level Status Code option (of
NoAddrsAvail) and IA_NAs and/or IA_TAs with a Status Code option NoAddrsAvail) and IA_NAs and/or IA_TAs with a Status Code option
(of NoAddrsAvail). (of NoAddrsAvail).
Servers MUST use the Status Code option (of NoAddrsAvail) Servers MUST return the Status Code option (of NoAddrsAvail)
encapsulated in an IA_NA/IA_TA options and not a top-level Status 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 Code option (of NoAddrsAvail) when no addresses will be assigned (2
in the above list). This means that the Advertise response matches in the above list). This means that the Advertise response matches
the Reply response with respect to the handling of the NoAddrsAvail the Reply response with respect to the handling of the NoAddrsAvail
status. status.
Replace the following paragraph in RFC 3315, section 17.2.2: Replace the following paragraph in RFC 3315, section 17.2.2:
If the server will not assign any addresses to any IAs in a If the server will not assign any addresses to any IAs in a
subsequent Request from the client, the server MUST send an subsequent Request from the client, the server MUST send an
Advertise message to the client that includes only a Status Advertise message to the client that includes only a Status
skipping to change at page 6, line 30 skipping to change at page 6, line 34
4.2. Advertise Message 4.2. Advertise Message
[RFC3315] specifies that a client must ignore an Advertise message if [RFC3315] specifies that a client must ignore an Advertise message if
a server will not assign any addresses to a client. A client a server will not assign any addresses to a client. A client
requesting both IA_NA and IA_PD, with a server that only offers one requesting both IA_NA and IA_PD, with a server that only offers one
of them, is not supported in the current protocol specification. of them, is not supported in the current protocol specification.
Proposed solution: a client SHOULD accept Advertise messages, even Proposed solution: a client SHOULD accept Advertise messages, even
when not all IA option types are being offered. And, in this case, 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 the client SHOULD include the not offered IA option types in its
Request. A client SHOULD only ignore an Advertise message when no IA Request. A client SHOULD only ignore an Advertise message when all
option includes any offered addresses or delegated prefixes (or any IA options include no offered addresses or delegated prefixes. Note
future allocable resource). Note that ignored messages MUST still be that ignored messages MUST still be processed for SOL_MAX_RT and
processed for SOL_MAX_RT and INF_MAX_RT options as specified in INF_MAX_RT options as specified in [RFC7083].
[RFC7083].
Replace Section 17.1.3 of RFC 3315: (existing errata) Replace Section 17.1.3 of RFC 3315: (existing errata)
The client MUST ignore any Advertise message that includes a Status The client MUST ignore any Advertise message that includes a Status
Code option containing the value NoAddrsAvail, with the exception Code option containing the value NoAddrsAvail, with the exception
that the client MAY display the associated status message(s) to the that the client MAY display the associated status message(s) to the
user. user.
With (this includes the changes made by [RFC7083]): With (this includes the changes made by [RFC7083]):
skipping to change at page 7, line 24 skipping to change at page 7, line 32
has a better set of advertised parameters, such as the has a better set of advertised parameters, such as the
available options advertised in IAs. available options advertised in IAs.
It is important to note that the receipt of an Advertise message It is important to note that the receipt of an Advertise message
without any addresses and delegated prefixes does not imply that the without any addresses and delegated prefixes does not imply that the
client should restart the Solicit retransmissions timers. Doing so client should restart the Solicit retransmissions timers. Doing so
would lead to a Solicit/Advertise storm. would lead to a Solicit/Advertise storm.
4.3. T1/T2 Timers 4.3. T1/T2 Timers
The T1 and T2 timers determine when the client will contact the The T1 and T2 times determine when the client will contact the server
server to extend lifetimes of information received in an IA. How to extend lifetimes of information received in an IA. How should a
should a client handle the case where multiple IA options have client handle the case where multiple IA options have different T1
different T1 and T2 timers? and T2 times?
In a multiple IA option type model, the T1/T2 timers 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 timers we were to redo the DHCP protocol from scratch the T1/T2 times should
should be carried in a separate DHCP option. be carried in a separate DHCP option.
Proposed solution: The server SHOULD set the T1/T2 timers in all IA Proposed solution: The server MUST set the T1/T2 times in all IA
options in Reply and Advertise messages 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,
clients MUST use the shortest (explicit or implicit) T1/T2 timer clients MUST use the shortest (explicit or implicit) T1/T2 times
(larger than 0) in any IA options in the Reply. Longer T1/T2 timers (larger than 0), from the same IA option, in the Reply. T1/T2 times
are ignored. from other IAs are ignored.
4.4. Renew Message 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 The Renew message, as described in [RFC3315], allows a client to only
renew bindings assigned via a Request message. renew bindings assigned via a Request message.
In a multiple IA option type model, the Renew does not support the 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 ability for the client to renew one IA option type while requesting
bindings for other IA option types that were not available when the bindings for other IA option types that were not available when the
client sent the Request. client sent the Request.
Proposed solution: The client should continue with the IA options Proposed solution: The client should continue with the IA options
received, while continuing to include the other IA options in received, while continuing to include the other IA options in
subsequent messages to the server. The client and server processing subsequent messages to the server. The client and server processing
need to be modified. Note that this change makes the server's IA need to be modified. Note that this change makes the server's IA
processing of Renew similar to the Request processing. processing of Renew similar to the Request processing.
The first two subsections contain the required updates to [RFC3315] 4.4.2. Rebind Message
and [RFC3633] to accommodate this behavior on the client and the
server. The remaining two subsections propose a "unified" text to be
included in the [I-D.dhcwg-dhc-rfc3315bis], describing the client's
and server's behavior for renewing both addresses and prefixes.
4.4.1. Updates to RFC 3315 In Section 4.4.1 it has been proposed that the client includes IA
options in a Renew message for the bindings it desires but has been
unable to obtain by sending a Request message, apart from the IA
options for the existing bindings.
Replace Section 18.1.3 of RFC 3315: At time T2, the client stops sending Renew messages to the server and
initiates the Rebind/Reply message exchange with any available
server. In this case, it should be possible to continue trying to
obtain new bindings using the Rebind message if the client failed to
get the response from the server to the Renew message.
At time T1 for an IA, the client initiates a Renew/Reply message The Rebind message, as described in [RFC3315] does not explicitly
exchange to extend the lifetimes on any addresses in the IA. The specify what a server should do when an IA option which contains no
client includes an IA option with all addresses currently assigned addresses is present.
to the IA in its Renew message.
With: Proposed solution: The client should continue with the IA options
received and it MAY include additional IA options to request creation
of additional bindings.
At time T1 for an IA, the client initiates a Renew/Reply message 4.4.3. Updates to section 18.1.3 of RFC 3315
exchange to extend the lifetimes on any addresses in the IA. The
client includes an IA option with all addresses currently assigned
to the IA in its Renew message. The client also includes an IA
option for each binding it desires but has been unable to obtain.
Replace Section 18.2.3 of RFC 3315: Replace Section 18.1.3 of RFC 3315 with the following text:
If the server cannot find a client entry for the IA the server To extend the valid and preferred lifetimes for the addresses
returns the IA containing no addresses with a Status Code option associated with an IA, the client sends a Renew message to the
set to NoBinding in the Reply message. server from which the client obtained the addresses in the IA
containing an IA option for the IA. The client includes IA Address
options in the IA option for the addresses associated with the IA.
The server determines new lifetimes for the addresses in the IA
according to the administrative configuration of the server. The
server may also add new addresses to the IA. The server may remove
addresses from the IA by setting the preferred and valid lifetimes
of those addresses to zero.
With: The server controls the time at which the client contacts the
server to extend the lifetimes on assigned addresses through the T1
and T2 parameters assigned to an IA.
If the server cannot find a client entry for the IA the server At time T1 for an IA, the client initiates a Renew/Reply message
creates the bindings for that client according to the server's exchange to extend the lifetimes on any addresses in the IA.
policy and configuration information and returns the IAs and other
information requested by the client.
Note that clients that communicate with servers that do not support If T1 or T2 had been set to 0 by the server (for an IA_NA) or there
this updated Renew processing will receive the NoBinding status for are no T1 or T2 times (for an IA_TA) in a previous Reply, the
the IA which had no bindings. The client MUST continue to process client may send a Renew or Rebind message, respectively, at the
the other IAs in the Reply. The client MAY attempt a client's discretion.
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 The client sets the "msg-type" field to RENEW. The client
generates a transaction ID and inserts this value in the
"transaction-id" field.
Replace Section 12.2 of RFC 3633: The client places the identifier of the destination server in a
Server Identifier option.
Renew message: If the delegating router cannot find a binding The client MUST include a Client Identifier option to identify
for the requesting router's IA_PD the delegating itself to the server. The client adds any appropriate options,
router returns the IA_PD containing no prefixes including one or more IA options.
with a Status Code option set to NoBinding in the
Reply message.
With: 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).
Renew message: If the delegating router cannot find a binding The client MAY include an IA option for each binding it desires but
for the requesting router's IA_PD, the delegating has been unable to obtain. This IA option MUST NOT contain any
router creates the bindings for that client addresses. However, it MAY contain the IA Address option with IPv6
according to the server's policy and address field set to 0 to indicate the client's preference for the
configuration information and returns the IAs and preferred and valid lifetimes for any newly assigned addresses.
other information requested by the client.
4.4.3. Creation and Transmission of Renew Messages (unified text) 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.
To extend the valid and preferred lifetimes for the resources The client transmits the message according to section 14, using the
associated with IAs, the client sends a Renew message to the server following parameters:
from which the client obtained the resources.
The server controls the time at which the client contacts the server IRT REN_TIMEOUT
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 MRT REN_MAX_RT
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, MRC 0
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 MRD Remaining time until T2
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 a Renew message SHOULD NOT include resources The message exchange is terminated when time T2 is reached (see
in IA options that the client does not have. If the client included section 18.1.4), at which time the client begins a Rebind message
a resource it does not have and the server does not allocate this exchange.
resource for the client, the server will return the resource to the
client in the IA with the lifetimes set to 0. This is a signal to
the client to not use this resource. The server MAY allocate a
different resource to the client and send it in the same IA.
The client sets "msg-type" field to RENEW. The client generates a 4.4.4. Updates to Section 18.1.4 of RFC 3315
transaction ID and inserts this value in the "transaction-id" field.
The client places the identifier of the destination server in a Replace Section 18.1.4 of RFC 3315 with the following text:
Server Identifier option.
The client MUST include a Client Identifier option to identify itself At time T2 for an IA (which will only be reached if the server to
to the server. The client adds any appropriate options, including which the Renew message was sent at time T1 has not responded), the
one or more IA options. client initiates a Rebind/Reply message exchange with any available
server.
The client MUST include an Option Request option to indicate the The client constructs the Rebind message as described in 18.1.3
options the client is interested in receiving. The client MAY with the following differences:
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 - The client sets the "msg-type" field to REBIND.
following parameters:
IRT REN_TIMEOUT - The client does not include the Server Identifier option in the
Rebind message.
MRT REN_MAX_RT The client transmits the message according to section 14, using the
following parameters:
MRC 0 IRT REB_TIMEOUT
MRT REB_MAX_RT
MRD Remaining time until T2 MRC 0
If the server finds that any resource sent by the client is not MRD Remaining time until valid lifetimes of all addresses in
appropriate, according to the server's configuration information, the all IAs have expired
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, at which If all addresses for an IA have expired the client may choose to
time the client begins a Rebind message exchange. include this IA without any addresses (or with only a hint for
lifetimes) in subsequent Rebind messages to indicate that the
client is interested in assignment of the addresses to this IA.
4.4.4. Receipt of Renew Messages (unified text) The message exchange is terminated when the valid lifetimes of all
addresses across all IAs have expired, at which time the client may
use a Solicit message to locate a new DHCP server and send a
Request for the expired IAs to the new server.
When the server receives a Renew message via unicast from a client to 4.4.5. Updates to Section 18.1.8 of RFC 3315
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 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 Replace Section 18.1.8 of RFC 3315 with the following text:
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 Upon the receipt of a valid Reply message in response to a Solicit
creates the bindings for that client according to the server's policy (with a Rapid Commit option), Request, Confirm, Renew, Rebind or
and configuration information and returns the IAs and other Information-request message, the client extracts the configuration
information requested by the client. For each IA for which the information contained in the Reply. The client MAY choose to
server will not create a binding the server returns an IA option report any status code or message from the status code option in
containing a Status Code option set to NoBinding in the Reply the Reply message.
message.
If the server finds that any resource sent by the client is not If the client receives a Reply message with a Status Code
appropriate, according to the server's configuration information, the containing UnspecFail, the server is indicating that it was unable
server sends back the IA with the corresponding IA Address (for to process the message due to an unspecified failure condition. If
invalid address), IA Prefix option (for invalid prefix) or any other the client retransmits the original message to the same server to
option appropriate for the type of the resource, with lifetimes set retry the desired operation, the client MUST limit the rate at
to 0. which it retransmits the message and limit the duration of the time
during which it retransmits the message.
The server constructs a Reply message by setting the "msg-type" field When the client receives a Reply message with a Status Code option
to REPLY, and copying the transaction ID from the Renew message into with the value UseMulticast, the client records the receipt of the
the transaction-id field. message and sends subsequent messages to the server through the
interface on which the message was received using multicast. The
client resends the original message using multicast.
The server MUST include a Server Identifier option containing the When the client receives a NotOnLink status from the server in
server's DUID and the Client Identifier option from the Renew message response to a Confirm message, the client performs DHCP server
in the Reply message. solicitation, as described in section 17, and client-initiated
configuration as described in section 18. If the client receives
any Reply messages that do not indicate a NotOnLink status, the
client can use the addresses in the IA and ignore any messages that
indicate a NotOnLink status.
The server includes other options containing configuration When the client receives a NotOnLink status from the server in
information to be returned to the client as described in [RFC3315]. response to a Request, the client can either re-issue the Request
without specifying any addresses or restart the DHCP server
discovery process (see section 17).
4.5. Rebind Message 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
previous Reply messages from the server. The client performs the
duplicate address detection before using the received addresses for
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
addresses as described in section 18.1.7.
In the Section 4.4 it has been proposed that the client includes IA If the Reply was received in response to a Solicit (with a Rapid
options in a Renew message for the bindings it desires but has been Commit option), Request, Renew or Rebind message, the client
unable to obtain by sending a Request message, apart from the IA updates the information it has recorded about IAs from the IA
options for the existing bindings. options contained in the Reply message:
At time T2 (being a shortest, greater than 0, time across all - Record T1 and T2 times. The client MUST use the shortest
client's IAs), the client stops sending Renew messages to the server (explicit or implicit) T1 and T2 times (larger than 0) from the
and initiates the Rebind/Reply message exchange with any available same IA option across all of the IA options to facilitate
server. In this case, it should be possible to continue trying to initiating the renewal process for all bindings simultaneously.
obtain new bindings using the Rebind message if the client failed to T1/T2 times from other IAs are ignored.
get the response from the server to the Renew message.
The Rebind message, as described in [RFC3315] does not explicitly - Add any new addresses in the IA option to the IA as recorded by
specify what a server should do when an IA option which contains no the client.
addresses is present.
Proposed solution: The client should continue with the IA options - Update lifetimes for any addresses in the IA option that the
received and it MAY include additional IA options to request creation client already has recorded in the IA.
of additional bindings.
The first two subsections contain the required updates to [RFC3315] - Discard any addresses from the IA, as recorded by the client,
and [RFC3633] to accommodate this behavior on the client and the that have a valid lifetime of 0 in the IA Address option.
server. The remaining two subsections propose a "unified" text to be
included in the [I-D.dhcwg-dhc-rfc3315bis], describing the client's
and server's behavior with respect to processing different IA option
types in a single Rebind message.
4.5.1. Updates to RFC 3315 - Leave unchanged any information about addresses the client has
recorded in the IA but that were not included in the IA from the
server.
Replace Section 18.1.4 of RFC 3315: Management of the specific configuration information is detailed in
the definition of each option in section 22.
At time T2 for an IA (which will only be reached if the server to The client examines the status code in each IA individually. If
which the Renew message was sent at time T1 has not responded), the client receives a NoAddrsAvail, the client has received no
the client initiates a Rebind/Reply message exchange with any usable addresses in the IA.
available server. The client includes an IA option with all
addresses currently assigned to the IA in its Rebind message.
With: If the client finds no usable addresses in any IA, the client MAY
use the Information-request message to obtain other configuration
information only.
At time T2 for an IA (which will only be reached if the server to The client uses addresses and other information from any IAs that
which the Renew message was sent at time T1 has not responded), do not contain a Status Code option with the NoAddrsAvail code.
the client initiates a Rebind/Reply message exchange with any For each IA for which the client receives NoAddrsAvail status code
available server. The client includes an IA option with all the client has the following choices:
addresses currently assigned to the IA in its Rebind message. The
client also includes an IA option (without the IA Address option)
for each binding it desires but has been unable to obtain.
The client constructing a Rebind message SHOULD NOT include - The client includes the IA with no addresses in subsequent Renew
addresses in IA options that the client does not have. If the and Rebind messages sent to the server, to request creation of
client included an address it does not have and the server does the binding for the IA.
not allocate this address for the client, the server will return
the IA Address option containing address included by the client in
the IA with lifetimes set to 0. This is an indication to the
client to not use this address. The server MAY allocate a
different address to the client and send it in the same IA.
Replace Section 18.2.4 of RFC 3315 with the following text to clarify - Tries another server (perhaps restarting the DHCP server
how the server should handle all of the possible conditions: discovery process).
When the server receives a Rebind message that contains an IA When the client receives a Reply message in response to a Renew or
option from a client, it locates the client's binding and verifies Rebind message, for each IA in the original Renew or Rebind
that the information in the IA from the client matches the message, the client:
information stored for that client.
If the server finds the addresses in the IA for the client and the - Sends a Request message if the IA sent in the Renew or Rebind
server determines that the addresses in the IA are appropriate for contained addresses that the client is currently using and the
the link to which the client's interface is attached according to server responded with a NoBinding status code.
the server's explicit configuration information, the server SHOULD
send back the IA to the client with new lifetimes and T1/T2 times.
If the server cannot find a client entry for the IA and the server - Tries to obtain the IA from another server (by restarting the
determines that the addresses in the IA are not appropriate for the DHCP discovery process) if the client attempted to obtain a new
link to which the client's interface is attached according to the binding in the Renew or Rebind message by sending an IA without
server's explicit configuration information, the server MAY send a any addresses and the server responded with NoBinding status
Reply message to the client containing the client's IA, with the code.
lifetimes for the addresses in the IA set to zero. This Reply
constitutes an explicit notification to the client that the
addresses in the IA are no longer valid. In this situation, if the
server does not send a Reply message it silently discards the
Rebind message.
If the server cannot find a client entry for the IA and the IA is - Follows the retransmission procedure for Renew/Rebind messages
empty (i.e. contains no addresses), the server MAY assign the as described in section 14 if the IA is not in the Reply
addresses to this IA and send a Reply message to the client with message.
this IA containing allocated addresses with lifetimes and T1/T2
times. In the case when the client included addresses in the IA,
included addresses are appropriate for the link to which the
client's interface is attached according to the server's explicit
configuration information and they are not in use, the server MAY
allocate these addresses to the client. If the server does not
allocate addresses to the client, the server returns the IA
containing only Status Code option set to NoBinding in the Reply
message.
When the server creates new bindings for the IA it is possible that - Otherwise accepts the information in the IA.
other servers also create bindings as a result of receiving the
same Rebind message. This is the same issue as in the Discussion When the client receives a valid Reply message in response to a
under the Rapid Commit option, see section 22.14. Therefore, the Release message, the client considers the Release event completed,
server SHOULD only create new bindings during processing of a regardless of the Status Code option(s) returned by the server.
Rebind message if the server is configured to respond with a Reply
message to a Solicit message containing the Rapid Commit option. 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 the server.
4.4.6. Updates to Section 18.2.3 of RFC 3315
Replace Section 18.2.3 of RFC 3315 with the following text:
When the server receives a Renew message via unicast from a client
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 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.
For each IA in the Renew message from a client, the server locates
the client's binding and verifies that the information in the IA
from the client matches the information stored for that client.
If the server finds the addresses in the IA for the client then the
server sends back the IA to the client with new lifetimes and, if
applicable, T1/T2 times. If the server is unable to extend the
lifetimes of an address in the IA, the server MAY choose not to
include the IA Address option for this address.
The server may choose to change the list of addresses and the
lifetimes of addresses in IAs that are returned to the client.
If the server finds that any of the addresses in the IA are not
appropriate for the link to which the client is attached, the
server returns the address to the client with lifetimes of 0.
For each IA for which the server cannot find a client entry, the
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 server SHOULD create a binding
and 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 Address option
(if included) as a hint.
- If the server is configured to create new bindings as a result
of processing Renew messages, but the server will not assign any
addresses to an IA, the server returns the IA option containing
a Status Code option with the NoAddrsAvail status code and a
status message for a user.
- If the server does not support creation of new bindings for the
client sending a Renew message, or if this behavior is disabled
according to the server's policy or configuration information,
the server returns the IA 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" The server constructs a Reply message by setting the "msg-type"
field to REPLY, and copying the transaction ID from the Rebind field to REPLY, and copying the transaction ID from the Renew
message into the transaction-id field. message into the transaction-id field.
The server MUST include a Server Identifier option containing the The server MUST include a Server Identifier option containing the
server's DUID and the Client Identifier option from the Rebind server's DUID and the Client Identifier option from the Renew
message in the Reply message. message in the Reply message.
The server includes other options containing configuration The server includes other options containing configuration
information to be returned to the client as described in section information to be returned to the client as described in section
18.2. 18.2.
4.5.2. Updates to RFC 3633 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
Replace Section 12.2 of RFC 3633: 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
Rebind message: If the delegating router cannot find a binding bindings at the same time.
for the requesting router's IA_PD and the
delegating router determines that the prefixes in
the IA_PD are not appropriate for the link to
which the requesting router's interface is
attached according to the delegating routers
explicit configuration, the delegating router MAY
send a Reply message to the requesting router
containing the IA_PD with the lifetimes of the
prefixes in the IA_PD set to zero. This Reply
constitutes an explicit notification to the
requesting router that the prefixes in the IA_PD
are no longer valid. If the delegating router is
unable to determine if the prefix is not
appropriate for the link, the Rebind message is
discarded.
with: 4.4.7. Updates to Section 18.2.4 of RFC 3315
Rebind message: If the delegating router cannot find a binding Replace Section 18.2.4 of RFC 3315 with the following text:
for the requesting router's IA_PD and the
delegating router determines that the prefixes in
the IA_PD are not appropriate for the link to
which the requesting router's interface is
attached according to the delegating routers
explicit configuration, the delegating router MAY
send a Reply message to the requesting router
containing the IA_PD with the lifetimes of the
prefixes in the IA_PD set to zero. This Reply
constitutes an explicit notification to the
requesting router that the prefixes in the IA_PD
are no longer valid. If the delegating router is
unable to determine if the prefix is not
appropriate for the link, the Rebind message is
discarded. If the IA_PD contains no prefixes or
the prefixes are appropriate for the link to
which the requesting router's interface is
attached according to the delegating router's
explicit configuration information and if
prefixes are not in use, the delegating router
MAY assign prefixes to this IA_PD.
4.5.3. Creation and Transmission of Rebind Messages (unified text) When the server receives a Rebind 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 that client.
At time T2 for an IA (which will only be reached if the server to If the server finds the addresses in the IA for the client and the
which the Renew message was sent at time T1 has not responded), the server determines that the addresses in the IA are appropriate for
client initiates a Rebind/Reply message exchange with any available the link to which the client's interface is attached according to
server. For each IA being included, the client stores all resources the server's explicit configuration information, the server SHOULD
currently associated with the IA. send back the IA to the client with new lifetimes and, if
applicable, T1/T2 times. If the server is unable to extend the
lifetimes of an address in the IA, the server MAY choose not to
include the IA Address option for this address.
The client also includes IA option for each binding it desires but If the server finds the client entry for the IA and any of the
has been unable to obtain. For example: a client which has non- addresses are no longer appropriate for the link to which the
temporary addresses assigned but has not been delegated a prefix, may client's interface is attached according to the server's explicit
include an IA_PD option (in addition to the IA_NA option) in the configuration information, the server returns the addresses to the
Rebind message to request the prefix delegation. client with lifetimes of 0.
The client constructing a Rebind message SHOULD NOT include resources If the server cannot find a client entry for the IA, the IA
in IA options that the client does not have. If the client included contains addresses and the server determines that the addresses in
a resource it does not have and the server does not allocate this the IA are not appropriate for the link to which the client's
resource for the client, the server will return the appropriate interface is attached according to the server's explicit
option containing the resource (e.g. IA Address, IA Prefix) with the configuration information, the server MAY send a Reply message to
lifetimes set to 0. This is an indication to the client to not use the client containing the client's IA, with the lifetimes for the
this resource. The server MAY allocate a different resource to the addresses in the IA set to 0. This Reply constitutes an explicit
client and send it in the same IA. notification to the client that the addresses in the IA are no
longer valid. In this situation, if the server does not send a
Reply message it silently discards the Rebind message.
The client sets the "msg-type" field to REBIND. The client generates Otherwise, for each IA for which the server cannot find a client
a transaction ID and inserts this value in the "transaction-id" entry, the server has the following choices depending on the
field. server's policy and configuration information:
The client MUST include a Client Identifier option to identify itself - If the server is configured to create new bindings as a result
to the server. The client adds any appropriate options, including of processing Rebind messages (also see the note about the
one or more IA options. The client MUST include the list of Rapid Commit option below), the server SHOULD create a binding
resources the client currently has associated with the IAs in the and return the IA with allocated addresses with lifetimes and,
Rebind message. if applicable, T1/T2 times and other information requested by
the client. The server MAY use values in the IA Address option
(if included) as a hint.
The client MUST include an Option Request option to indicate the - If the server is configured to create new bindings as a result
options that client is interested in receiving. The client MAY of processing Rebind messages, but the server will not assign
include options with data values as hints to the server about any addresses to an IA, the server returns the IA option
parameter values the client would like to have returned. containing a Status Code option with the NoAddrsAvail status
code and a status message for a user.
The client transmits the message according to Section 14, using the - If the server does not support creation of new bindings for the
following parameters: client sending a Rebind message, or if this behavior is
disabled according to the server's policy or configuration
information, the server returns the IA option containing a
Status Code option with the NoBinding status code and a status
message for a user.
IRT REB_TIMEOUT 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 Rebind message. This is the same issue as 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 the server is configured to
respond with a Reply message to a Solicit message containing the
Rapid Commit option.
MRT REB_MAX_RT The server constructs a Reply message by setting the "msg-type"
field to REPLY, and copying the transaction ID from the Rebind
message into the transaction-id field.
MRC 0 The server MUST include a Server Identifier option containing the
server's DUID and the Client Identifier option from the Rebind
message in the Reply message.
MRD Remaining time until valid lifetimes of all addresses or The server includes other options containing configuration
prefixes in the IA have expired information to be returned to the client as described in section
18.2.
The message exchange is terminated when the valid lifetimes of all The T1/T2 times set in each applicable IA option for a Reply MUST
the resources assigned to the IA expire, at which time the client has be the same values across all IAs. The server MUST determine the
several alternative actions to choose from; for example: 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.
- The client may choose to use a Solicit message to locate a new 4.4.8. Updates to RFC 3633
DHCP server and send a Request for the expired IA to the new
server.
- The client may have other resources in other IAs, so the client Replace Section 12.1:
may choose to discard the expired IA and use the other IAs.
4.5.4. Receipt of Rebind Messages (unified text) Each prefix has valid and preferred lifetimes whose durations are
specified in the IA_PD Prefix option for that prefix. The
requesting router uses Renew and Rebind messages to request the
extension of the lifetimes of a delegated prefix.
When the server receives a Rebind message that contains an IA option With:
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 that client.
If the server finds the resource in the IA for the client and the Each prefix has valid and preferred lifetimes whose durations are
server determines that the resources in the IA are appropriate for specified in the IA_PD Prefix option for that prefix. The
the link to which the client's interface is attached according to the requesting router uses Renew and Rebind messages to request the
server's explicit configuration information, the server SHOULD send extension of the lifetimes of a delegated prefix.
back the IA to the client with new lifetimes and T1/T2 times.
If the server cannot find a client entry for the IA and the server The requesting router MAY include IA_PD options without any
determines that the resources in the IA are not appropriate for the prefixes, i.e. without IA Prefix option or with IPv6 prefix field
link to which the client's interface is attached according to the of IA Prefix option set to 0, in a Renew or Rebind message to
server's explicit configuration information, the server MAY send a obtain bindings it desires but has been unable to obtain. The
Reply message to the client containing the client's IA, with the requesting router MAY set the prefix-length field of the IA Prefix
lifetimes for the resources in the IA set to zero. This Reply option as a hint to the server.
constitutes an explicit notification to the client that the resources
in the IA are no longer valid. In this situation, if the server does
not send a Reply message it silently discards the Rebind message.
If the server cannot find a client entry for the IA and the IA is Replace Section 12.2:
empty (i.e. contains no resources), the server MAY assign the
resources to this IA and send a Reply message to the client with this
IA containing allocated resources with lifetimes and T1/T2 times. In
the case when the client included resources in the IA, included
resources are appropriate for the link to which the client's
interface is attached according to the server's explicit
configuration information and they are not in use, the server MAY
allocate these resources to the client. If the server does not
allocate resources to the client, the server returns the IA
containing only Status Code option set to NoBinding in the Reply
message.
When the server creates new bindings for the IA it is possible that The delegating router behaves as follows when it cannot find a
other servers also create bindings as a result of receiving the same binding for the requesting router's IA_PD:
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 bindings during processing of a
Rebind message if the server is configured to respond with a Reply
message to a Solicit message containing the Rapid Commit option.
The server constructs a Reply message by setting the "msg-type" field With:
to REPLY, and copying the transaction ID from the Rebind message into
the transaction-id field.
The server MUST include a Server Identifier option containing the For the Renew or Rebind, if the IA_PD contains no prefixes, i.e.
server's DUID and the Client Identifier option from the Rebind contains no IA Prefix option or the IPv6 prefix field in the IA
message in the Reply message. Prefix option is set to 0, the delegating router MAY assign
prefixes to the IA_PD according to the delegating router's
explicit configuration information. In this case, when the server
assigns new prefixes to the IA_PD, the server MAY use the value in
the prefix-length field of the IA Prefix option as a hint for the
length of the prefixes being assigned.
The server includes other options containing configuration The delegating router behaves as follows when it cannot find a
information to be returned to the client as described in section binding for the requesting router's IA_PD containing prefixes:
18.2.
4.6. Confirm Message 4.5. Confirm Message
The Confirm message, as described in [RFC3315], is specific to The Confirm message, as described in [RFC3315], is specific to
address assignment. It allows a server without a binding to reply to address assignment. It allows a server without a binding to reply to
the message, under the assumption that the server only needs the message, under the assumption that the server only needs
knowledge about the prefix(es) on the link, to inform the client that knowledge about the prefix(es) on the link, to inform the client that
the address is likely valid or not. This message is sent when e.g. the address is likely valid or not. This message is sent when e.g.
the client has moved and needs to validate its addresses. Not all the client has moved and needs to validate its addresses. Not all
bindings can be validated by servers and the Confirm message provides bindings can be validated by servers and the Confirm message provides
for this by specifying that a server that is unable to determine the for this by specifying that a server that is unable to determine the
on-link status MUST NOT send a Reply. on-link status MUST NOT send a Reply.
skipping to change at page 18, line 32 skipping to change at page 18, line 49
other IA-types MAY, depending on the IA-type, use the Confirm message 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 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 does not have a binding with an IA with addresses MUST use the Rebind
message instead. message instead.
IA_PD requires verification that the server has the binding for the 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 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 the Confirm message and it MUST include all of its bindings, even
address IAs. address IAs.
4.7. Decline Should Not Necessarily Trigger a Release 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.
Some clients will send a Release message for other bindings they may 4.6. Decline Should Not Necessarily Trigger a Release
have received after they determine a conflict and have correctly sent
a Decline message for the conflicting address(es). Some 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 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 other bindings it may have received just because it sent a Decline
message. The client should retain the non-conflicting bindings. message. The client should retain the non-conflicting bindings.
4.8. Multiple Provisioning Domains 4.7. Multiple Provisioning Domains
This document has assumed that all DHCP servers on a network are in a This document has assumed that all DHCP servers on a network are in a
single provisioning domain and thus should be "equal" in the service single provisioning domain and thus should be "equal" in the service
that they offer. This was also assumed by [RFC3315] and [RFC3633]. that they offer. This was also assumed by [RFC3315] and [RFC3633].
One could envision a network where the DHCP servers are in multiple One could envision a network where the DHCP servers are in multiple
provisioning domains, and it may be desirable to have the DHCP client provisioning domains, and it may be desirable to have the DHCP client
obtain different IA types from different provisioning domains. How a obtain different IA types from different provisioning domains. How a
client detects the multiple provisioning domains and how it would client detects the multiple provisioning domains and how it would
interact with the multiple servers in these different domains is interact with the multiple servers in these different domains is
skipping to change at page 19, line 46 skipping to change at page 20, line 26
[RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT
and INF_MAX_RT", RFC 7083, November 2013. and INF_MAX_RT", RFC 7083, November 2013.
8.2. Informative References 8.2. Informative References
[I-D.dhcwg-dhc-rfc3315bis] [I-D.dhcwg-dhc-rfc3315bis]
Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) bis", draft- Configuration Protocol for IPv6 (DHCPv6) bis", draft-
dhcwg-dhc-rfc3315bis-01 (work in progress), May 2014. dhcwg-dhc-rfc3315bis-02 (work in progress), July 2014.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. 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 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084, Requirements for IPv6 Customer Edge Routers", RFC 7084,
November 2013. November 2013.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options", S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, May 2014. BCP 187, RFC 7227, May 2014.
Authors' Addresses Authors' Addresses
Ole Troan Ole Troan
Cisco Systems, Inc. Cisco Systems, Inc.
Philip Pedersens vei 20 Philip Pedersens vei 20
N-1324 Lysaker N-1324 Lysaker
Norway Norway
Email: ot@cisco.com Email: ot@cisco.com
Bernie Volz Bernie Volz
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 126 change blocks. 
469 lines changed or deleted 496 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/