draft-ietf-dhc-dhcpv6-stateful-issues-09.txt   draft-ietf-dhc-dhcpv6-stateful-issues-10.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: May 30, 2015 ISC Expires: August 2, 2015 ISC
November 26, 2014 January 29, 2015
Issues and Recommendations with Multiple Stateful DHCPv6 Options Issues and Recommendations with Multiple Stateful DHCPv6 Options
draft-ietf-dhc-dhcpv6-stateful-issues-09.txt draft-ietf-dhc-dhcpv6-stateful-issues-10.txt
Abstract Abstract
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written The Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
with the expectation that additional stateful DHCPv6 options would be specification defined two stateful options, IA_NA and IA_TA, but did
developed. IPv6 Prefix Options for Dynamic Host Configuration not anticipate the development of additional stateful options.
Protocol (DHCP) version 6 has since shoe-horned a new option for DHCPv6 Prefix Delegation added the IA_PD option, which is stateful.
Prefix Delegation into DHCPv6. Implementation experience of the CPE Applications that use IA_NA and IA_PD together have revealed issues
model described in RFC 7084 has shown multiple issues with the DHCPv6 that need to be addressed. This document updates RFC 3315 and RFC
protocol in supporting multiple stateful options. This document 3633 to address these issues.
updates RFC 3315 and RFC 3633 to address the identified issues.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 30, 2015. This Internet-Draft will expire on August 2, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Handling of Multiple IA Options Types . . . . . . . . . . . . 3 4. Handling of Multiple IA Option Types . . . . . . . . . . . . 4
4.1. Placement of Status Codes . . . . . . . . . . . . . . . . 4 4.1. Placement of Status Codes in an Advertise Message . . . . 5
4.2. Advertise Message . . . . . . . . . . . . . . . . . . . . 6 4.2. Advertise Message Processing by a Client . . . . . . . . 6
4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 7 4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 8 4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 8
4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 8 4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 8
4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 8 4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 9
4.4.3. Updates to section 18.1.3 of RFC 3315 . . . . . . . . 9 4.4.3. Updates to section 18.1.3 of RFC 3315 . . . . . . . . 9
4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 10 4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 11
4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 11 4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 12
4.4.6. Updates to Section 18.2.3 of RFC 3315 . . . . . . . . 13 4.4.6. Updates to Section 18.2.3 of RFC 3315 . . . . . . . . 14
4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 15 4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 16
4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 17 4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 17
4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 18 4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 18
4.6. Decline Should Not Necessarily Trigger a Release . . . . 19 4.6. Decline Should Not Necessarily Trigger a Release . . . . 19
4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 19 4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
DHCPv6 [RFC3315] was not written with the expectation that additional DHCPv6 [RFC3315] was written without the expectation that additional
stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation
[RFC3633] has since shoe-horned a new option for Prefix Delegation [RFC3633] since added a new stateful option for Prefix Delegation to
into DHCPv6. Implementation experience of the CPE model described in DHCPv6. Implementation experience of the Customer Edge Router model
[RFC7084] has shown issues with the DHCPv6 protocol in supporting described in [RFC7084] has shown issues with the DHCPv6 protocol in
multiple stateful option types, in particular IA_NA (non-temporary supporting multiple stateful option types, in particular IA_NA (non-
addresses) and IA_PD (delegated prefixes). temporary addresses) and IA_PD (delegated prefixes).
This document describes a number of problems encountered with This document describes a number of problems encountered with
coexistence of the IA_NA and IA_PD option types and changes to the coexistence of the IA_NA and IA_PD option types and specifies changes
DHCPv6 protocol specifications to address these problems. to the DHCPv6 protocol to address these problems.
The intention of this work is to clarify and, where needed, modify The intention of this work is to clarify and, where needed, modify
the DHCP protocol specification to support IA_NA and IA_PD option the DHCPv6 protocol specification to support IA_NA and IA_PD option
types within a single DHCP session. types within a single DHCPv6 session.
Note that while IA_TA (temporary addresses) options may be included Note that while IA_TA (temporary addresses) options may be included
with other IA option type requests, these generally are not renewed with other IA option type requests, these generally are not renewed
(there are no T1/T2 times) and have a separate life cycle from IA_NA (there are no T1/T2 times) and have a separate life cycle from IA_NA
and IA_PD option types. DHCPv6 assigned temporary addresses also and IA_PD option types. Therefore, the IA_TA option type is mostly
have limited value when DHCPv6 is used for non-temporary address out of scope for this document.
assignment, as the privacy issues identified for IPv6 stateless
address assignment ([RFC4941]) do not apply to DHCPv6 assignments.
Therefore, the IA_TA option type is mostly out of scope for this
document.
The changes described in this document are intended to be The changes described in this document are intended to be
incorporated in a new revision of the DHCPv6 protocol specification incorporated in a new revision of the DHCPv6 protocol specification
([I-D.dhcwg-dhc-rfc3315bis]). ([I-D.dhcwg-dhc-rfc3315bis]).
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 3, line 47 skipping to change at page 3, line 43
prefixes assigned to a client and prefixes assigned to a client and
carried in the IA_NA or IA_PD options carried in the IA_NA or IA_PD options
respectively. respectively.
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 option. IA_NA and/or IA_PD option.
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 Top-level options: Top-level options are DHCPv6 options
that are not encapsulated within
other options, excluding the Relay-
Message option. Options encapsulated
by Relay-message options, but not by
any other option, are still top-level
options, whether they appear in a
relay agent message or a server
message. See [RFC7227].
DHCPv6 was written with the assumption that the only stateful options 4. Handling of Multiple IA Option Types
were for assigning addresses. DHCPv6 PD describes how to extend the
DHCPv6 protocol to handle prefix delegation, but [RFC3633] did not The DHCPv6 specification [RFC3315] was written with the assumption
consider how DHCP address assignment and prefix delegation could co- that the only stateful options were for assigning addresses. DHCPv6
exist. Prefix Delegation [RFC3633] describes how to extend the DHCPv6
protocol to handle prefix delegation, but does not clearly specify
how the DHCP address assignment and prefix delegation co-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:
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 in subsequent messages to the server.
Reseting the state machine and continuing to send Solicit messages 1. Reset the state machine and continue to send Solicit messages,
2. Create separate DHCP sessions for each IA option type and
continue to Solicit for the unfulfilled IA options, or
3. The client could continue with the single session, and include
the unfulfilled IA options in subsequent messages to the server.
Resetting the state machine and continuing to send Solicit messages
may result in the client never completing DHCP and is generally not may result in the client never completing DHCP and is generally not
considered a good solution. It can also result in a request storm if considered a good solution. It can also result in a packet storm if
the client does not appropriately rate limit its sending of Solicit the client does not appropriately rate limit its sending of Solicit
messages. messages.
Creating a separate DHCP session (separate instances of the client Creating a separate DHCP session (separate instances of the client
state machine) per IA option type, while conceptually simple, has a state machine) per IA option type, while conceptually simple, causes
number of issues: multiple instances of the state machine in clients, a number of issues: additional host resources required to create and
additional DHCP protocol traffic, 'collisions' between other maintain multiple instances of the state machine in clients,
configuration options, divergence in that each IA option type additional DHCP protocol traffic, unnecessary duplication of other
specification specifies its 'own' version of the DHCP protocol. configuration options and the potential for conflict, divergence in
that each IA option type specification specifies its 'own' version of
This leaves a single DHCP session and state machine which is the the DHCP protocol.
proposed solution. Here, the client can use what it is able to
obtain and can continue to request what it was previously unable to
obtain while maintaining a single session and state machine.
Proposed solution: the client should keep a single session with the We have chosen to recommend that clients use the remaining option: a
server and include the missing options in subsequent messages single DHCP session and state machine. The client maintains a single
(Request, Renew, and Rebind) to the server. session and state machine. It uses the best configuration it is able
to obtain during any configuration exchange. But it continues, in
each subsequent configuration exchange, to request all the
configuration information it is programmed to try to obtain,
including any stateful configuration options for which no results
were returned in previous exchanges.
4.1. Placement of Status Codes 4.1. Placement of Status Codes in an Advertise Message
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 though, the NoAddrsAvail code is
NoAddrsAvail code is in the top level. This makes sense if the returned at in the top level. This makes sense if the client is only
client is only interested in the assignment of the addresses and the interested in the assignment of the addresses and the failure case is
failure case is fatal. However, if the client sends both IA_NA and fatal. However, if the client sends both IA_NA and IA_PD options in
IA_PD options in a Solicit message, it is possible that the server a Solicit message, it is possible that the server offers no addresses
offers no addresses but it offers some prefixes, and the client may but it offers some prefixes, and the client may choose to send a
choose to send a Request message to obtain the offered prefixes. In Request message to obtain the offered prefixes. In this case, it is
this case, it is better if the Status Code option for IA specific better if the Status Code option for IA specific status codes is
status codes is encapsulated in the IA option to indicate that the encapsulated in the IA option to indicate that the failure occurred
failure occurred for the specific IA. This also makes the for the specific IA. This also makes the NoAddrsAvail and
NoAddrsAvail and NoPrefixAvail Status Code option placement for NoPrefixAvail Status Code option placement for Advertise messages
Advertise messages identical to Reply messages. identical to Reply messages.
In addition, how a server formats the Advertise message when In addition, how a server formats the Advertise message when
addresses are not available has been a point of some confusion and addresses are not available has been a point of some confusion and
implementations seem to vary (some strictly follow RFC 3315 while implementations seem to vary (some strictly follow RFC 3315 while
others assumed it was encapsulated in the IA option as for Reply others assumed it was encapsulated in the IA option as for Reply
messages). messages).
Therefore, the proposed solution is: We have chosen the following solution:
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
other IA option types were 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 the IA_NAs and/or IA_TAs with encapsulated
NoAddrsAvail) and no IA_NAs/IA_TAs. Status Code option of NoAddrsAvail and no top-level Status Code
2. Advertise containing the IA_NAs and/or IA_TAs with encapsulated
Status Code option (of NoAddrsAvail) and no top-level Status Code
option. option.
3. Advertise containing a top-level Status Code option (of 2. Advertise containing just a top-level Status Code option of
NoAddrsAvail) and IA_NAs and/or IA_TAs with a Status Code option NoAddrsAvail and no IA_NAs/IA_TAs.
(of NoAddrsAvail).
Servers MUST return the Status Code option (of NoAddrsAvail) 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.
Note: Clients MUST be prepared to handle the last two formats listed
above to facilitate backward compatibility with the servers which
have not been updated to this specification.
See Section 4.2 for updated text for Section 17.1.3 of RFC 3315 and
Section 11.1 of RFC 3633.
Servers MUST return the Status Code option of NoAddrsAvail
encapsulated in an IA_NA/IA_TA options and not as 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 (1 in
in the above list). This means that the Advertise response matches the above list). This means that the Advertise response matches the
the Reply response with respect to the handling of the NoAddrsAvail 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
Code option with code NoAddrsAvail and a status message for Code option with code NoAddrsAvail and a status message for
the user, a Server Identifier option with the server's DUID, the user, a Server Identifier option with the server's DUID,
and a Client Identifier option with the client's DUID. and a Client Identifier option with the client's DUID.
With: With:
If the server will not assign any addresses to an IA in a If the server will not assign any addresses to an IA in a
subsequent Request from the client, the server MUST include subsequent Request from the client, the server MUST include
the IA in the Advertise message with no addresses in the IA the IA in the Advertise message with no addresses in the IA
and a Status Code option encapsulated in the IA containing and a Status Code option encapsulated in the IA containing
status code NoAddrsAvail. status code NoAddrsAvail.
4.2. Advertise Message 4.2. Advertise Message Processing by a Client
[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, and [RFC3633]
requesting both IA_NA and IA_PD, with a server that only offers one specifies that a client must ignore an Advertise message if a server
of them, is not supported in the current protocol specification. returns the NoPrefixAvail status to a requesting router. Thus, a
client requesting both IA_NA and IA_PD, with a server that only
offers either addresses or delegated prefixes, is not supported by
the current protocol specifications.
Proposed solution: a client SHOULD accept Advertise messages, even Solution: a client SHOULD accept Advertise messages, even when not
when not all IA option types are being offered. And, in this case, all IA option types are being offered. And, in this case, the client
the client SHOULD include the not offered IA option types in its SHOULD include the not offered IA option types in its Request. A
Request. A client SHOULD only ignore an Advertise message when all client SHOULD only ignore an Advertise message when none of the
IA options include no offered addresses or delegated prefixes. Note requested IA options include offered addresses or delegated prefixes.
that ignored messages MUST still be processed for SOL_MAX_RT and Note that ignored messages MUST still be processed for SOL_MAX_RT and
INF_MAX_RT options as specified in [RFC7083]. INF_MAX_RT options as specified in [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]):
The client MUST ignore any Advertise message that contains no The client MUST ignore any Advertise message that contains no
addresses (IAADDR options encapsulated in IA_NA or IA_TA options) addresses (IAADDR options encapsulated in IA_NA or IA_TA options)
and no delegated prefixes (IAPREFIX options encapsulated in IA_PD and no delegated prefixes (IAPREFIX options encapsulated in IA_PD
options, see RFC 3633) with the exception that the client options, see RFC 3633) with the exception that the client:
MUST process an included SOL_MAX_RT option (RFC 7083), MUST - MUST process an included SOL_MAX_RT option (RFC 7083),
process an included INF_MAX_RT option (RFC 7083), and MAY - MUST process an included INF_MAX_RT option (RFC 7083), and
display any associated status message(s) to the user. - MAY display any associated status message(s) to the user.
The client ignoring this Advertise message MUST NOT restart the
Solicit retransmission timer.
And, replace: And, replace:
- The client MAY choose a less-preferred server if that server - The client MAY choose a less-preferred server if that server
has a better set of advertised parameters, such as the has a better set of advertised parameters, such as the
available addresses advertised in IAs. available addresses advertised in IAs.
With: With:
- The client MAY choose a less-preferred server if that server - The client MAY choose a less-preferred server if that server has
has a better set of advertised parameters, such as the a better set of advertised parameters, such as the available set
available options advertised in IAs. of IAs, as well as the set of other configuration options
advertised.
It is important to note that the receipt of an Advertise message And, replace the last paragraph of Section 11.1 of RFC 3633 with:
without any addresses and delegated prefixes does not imply that the
client should restart the Solicit retransmissions timers. Doing so The requesting router MUST ignore any Advertise message that
would lead to a Solicit/Advertise storm. 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 requesting router:
- 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.
The requesting router ignoring this Advertise message MUST NOT
restart the Solicit retransmission timer.
4.3. T1/T2 Timers 4.3. T1/T2 Timers
The T1 and T2 times determine when the client will contact the server The T1 and T2 times determine when the client will contact the server
to extend lifetimes of information received in an IA. How should a to extend lifetimes of information received in an IA. How should a
client handle the case where multiple IA options have different T1 client handle the case where multiple IA options have different T1
and T2 times? and T2 times?
In a multiple IA option type model, the T1/T2 times are protocol In a multiple IA option type model, the T1/T2 times are protocol
timers, that should be independent of the IA options themselves. If timers, that should be independent of the IA options themselves. If
we were to redo the DHCP protocol from scratch the T1/T2 times should we were to redo the DHCP protocol from scratch the T1/T2 times should
be carried in a separate DHCP option. be carried in a separate DHCP option.
Proposed solution: The server MUST set the T1/T2 times in all IA Solution: The server MUST set the T1/T2 times in all IA options in a
options in a Reply or Advertise message to the same value. To deal Reply or Advertise message to the same value. To deal with the case
with the case where servers have not yet been updated to do that, the where servers have not yet been updated to do that, the client MUST
client MUST select a T1 and T2 time from all IA options which will select a T1 and T2 time from all IA options which will guarantee that
guarantee that the client will send Renew/Rebind messages not later the client will send Renew/Rebind messages not later than at the T1/
than at the T1/T2 times associated with any of the client's bindings. T2 times associated with any of the client's bindings.
As an example, if the client receives a Reply with T1_NA of 3600 / As an example, if the client receives a Reply with T1_NA of 3600 /
T2_NA of 5760 and T1_PD of 0 / T2_PD of 1800, the client SHOULD use T2_NA of 5760 and T1_PD of 0 / T2_PD of 1800, the client SHOULD use
the T1_PD of 0 / T2_PD of 1800. The reason for this is that a T1 of the T1_PD of 0 / T2_PD of 1800. The reason for this is that a T1 of
0 means that the Renew time is at the client's discretion, but this 0 means that the Renew time is at the client's discretion, but this
value cannot be greater than the T2 value (1800). value cannot be greater than the T2 value (1800).
The following paragraph should be added to Sections 18.2.1, 18.2.3, The following paragraph should be added to Sections 18.2.1, 18.2.3,
and 18.2.4 of RFC 3315: and 18.2.4 of RFC 3315:
skipping to change at page 8, line 9 skipping to change at page 8, line 39
Note: This additional paragraph has also been included in the revised Note: This additional paragraph has also been included in the revised
text later for Sections 18.2.3 and 18.2.4 of RFC 3315. text later for Sections 18.2.3 and 18.2.4 of RFC 3315.
Changes for client T1/T2 handling are included in Section 4.4.3 and Changes for client T1/T2 handling are included in Section 4.4.3 and
Section 4.4.4. Section 4.4.4.
4.4. Renew and Rebind Messages 4.4. Renew and Rebind Messages
This section presents issues with handling multiple IA option types This section presents issues with handling multiple IA option types
in the context of creation and processing the Renew and Rebind in the context of creation and processing the Renew and Rebind
messages. It also proposes relevant updates to the [RFC3315] and messages. It also introduces relevant updates to the [RFC3315] and
[RFC3633]. [RFC3633].
4.4.1. Renew Message 4.4.1. Renew Message
The Renew message, as described in [RFC3315], allows a client to only In multiple IA option type model, the client may include multiple IA
renew bindings assigned via a Request message. options in the Request message, and the server may create bindings
only for a subset of the IA options included by the client. For the
IA options in the Request message for which the server does not
create the bindings, the server sends the IA options in the Reply
message with the NoAddrsAvail or NoPrefixAvail status codes.
In a multiple IA option type model, the Renew does not support the The client may accept the bindings created by the server, but may
ability for the client to renew one IA option type while requesting desire the other bindings to be created once they become available,
bindings for other IA option types that were not available when the e.g. when the server configuration is changed. The client which
client sent the Request. accepted the bindings created by the server will periodically send a
Renew message to extend their lifetimes. However, the Renew message,
as described in the [RFC3315], does not support the ability for the
client to extend the lifetimes of the bindings for some IAs, while
requesting bindings for other IAs.
Proposed solution: The client should continue with the IA options Solution: The client, which sends a Renew message to extend the
received, while continuing to include the other IA options in lifetimes of the bindings assigned to the client, should include IA
subsequent messages to the server. The client and server processing options for these bindings as well as IA options for all other
need to be modified. Note that this change makes the server's IA bindings that the client desires but has been unable to obtain. The
processing of Renew similar to the Request processing. 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.
4.4.2. Rebind Message 4.4.2. Rebind Message
In Section 4.4.1 it has been proposed that the client includes IA According to the Section 4.4.1, the client includes IA options in a
options in a Renew message for the bindings it desires but has been Renew message for the bindings it desires but has been unable to
unable to obtain by sending a Request message, apart from the IA obtain by sending a Request message, apart from the IA options for
options for the existing bindings. the existing bindings.
At time T2, the client stops sending Renew messages to the server and At time T2, the client stops sending Renew messages to the server and
initiates the Rebind/Reply message exchange with any available initiates the Rebind/Reply message exchange with any available
server. In this case, it should be possible to continue trying to server. In this case, it should be possible to continue trying to
obtain new bindings using the Rebind message if the client failed to obtain new bindings using the Rebind message if the client failed to
get the response from the server to the Renew message. get the response from the server to the Renew message.
The Rebind message, as described in [RFC3315] does not explicitly Solution: The client should continue to include the IA options
specify what a server should do when an IA option which contains no received from the server and it may include additional IA options to
addresses is present. request creation of the additional bindings.
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 4.4.3. Updates to section 18.1.3 of RFC 3315
Replace Section 18.1.3 of RFC 3315 with the following text: Replace Section 18.1.3 of RFC 3315 with the following text:
To extend the valid and preferred lifetimes for the addresses To extend the valid and preferred lifetimes for the addresses
associated with an IA, the client sends a Renew message to the assigned to an IA, the client sends a Renew message to the server
server from which the client obtained the addresses in the IA from which the addresses were obtained, which includes an IA option
containing an IA option for the IA. The client includes IA Address for the IA whose address lifetimes are to be extended. The client
options in the IA option for the addresses associated with the IA. includes IA Address options within the IA option for the addresses
The server determines new lifetimes for the addresses in the IA assigned to the IA. The server determines new lifetimes for these
according to the administrative configuration of the server. The addresses according to the administrative configuration of the
server may also add new addresses to the IA. The server may remove server. The server may also add new addresses to the IA. The
addresses from the IA by setting the preferred and valid lifetimes server can remove addresses from the IA by returning IA Address
of those addresses to zero. options for such addresses with preferred and valid lifetimes set
to zero.
The server controls the time at which the client contacts the The server controls the time at which the client contacts the
server to extend the lifetimes on assigned addresses through the T1 server to extend the lifetimes on assigned addresses through the T1
and T2 parameters assigned to an IA. However, as the client and T2 parameters assigned to an IA. However, as the client
Renews/Rebinds all IAs from the server at the same time, the client Renews/Rebinds all IAs from the server at the same time, the client
MUST select a T1 and T2 time from all IA options which will MUST select a T1 and T2 time from all IA options which will
guarantee that the client will send Renew/Rebind messages not later guarantee that the client will send Renew/Rebind messages not later
than at the T1/T2 times associated with any of the client's than at the T1/T2 times associated with any of the client's
bindings. bindings.
skipping to change at page 9, line 48 skipping to change at page 10, line 35
generates a transaction ID and inserts this value in the generates a transaction ID and inserts this value in the
"transaction-id" field. "transaction-id" field.
The client places the identifier of the destination server in a The client places the identifier of the destination server in a
Server Identifier option. Server Identifier option.
The client MUST include a Client Identifier option to identify The client MUST include a Client Identifier option to identify
itself to the server. The client adds any appropriate options, itself to the server. The client adds any appropriate options,
including one or more IA options. including one or more IA options.
The client includes an IA option with all addresses currently For IAs to which addresses have been assigned, the client includes
assigned to the IA in its Renew message. The client also includes a corresponding IA option containing an IA Address option for each
IA options for all other bindings for which the client desires to address assigned to the IA. The client MUST not include addresses
extend the lifetimes of addresses. The client MUST only include in any IA option that the client did not obtain from the server or
addresses in the IA that the client obtained from the server and that are no longer valid (that have a zero valid lifetime).
are still valid (have non-zero lifetime).
The client MAY include an IA option for each binding it desires but 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 has been unable to obtain. This IA option MUST NOT contain any
addresses. However, it MAY contain the IA Address option with IPv6 addresses. However, it MAY contain the IA Address option with IPv6
address field set to 0 to indicate the client's preference for the address field set to 0 to indicate the client's preference for the
preferred and valid lifetimes for any newly assigned addresses. preferred and valid lifetimes for any newly assigned addresses.
The client MUST include an Option Request option (see section 22.7) The client MUST include an Option Request option (see section 22.7)
to indicate the options the client is interested in receiving. The to indicate the options the client is interested in receiving. The
client MAY include options with data values as hints to the server client MAY include options with data values as hints to the server
skipping to change at page 11, line 20 skipping to change at page 12, line 6
MRD Remaining time until valid lifetimes of all addresses in MRD Remaining time until valid lifetimes of all addresses in
all IAs have expired all IAs have expired
If all addresses for an IA have expired the client may choose to If all addresses for an IA have expired the client may choose to
include this IA without any addresses (or with only a hint for include this IA without any addresses (or with only a hint for
lifetimes) in subsequent Rebind messages to indicate that the lifetimes) in subsequent Rebind messages to indicate that the
client is interested in assignment of the addresses to this IA. client is interested in assignment of the addresses to this IA.
The message exchange is terminated when the valid lifetimes of all The message exchange is terminated when the valid lifetimes of all
addresses across all IAs have expired, at which time the client may addresses across all IAs have expired, at which time the client
use a Solicit message to locate a new DHCP server and send a uses Solicit message to locate a new DHCP server and sends a
Request for the expired IAs to the new server. Request for the expired IAs to the new server.
4.4.5. Updates to Section 18.1.8 of RFC 3315 4.4.5. Updates to Section 18.1.8 of RFC 3315
Replace Section 18.1.8 of RFC 3315 with the following text: Replace Section 18.1.8 of RFC 3315 with the following text:
Upon the receipt of a valid Reply message in response to a Solicit Upon the receipt of a valid Reply message in response to a Solicit
(with a Rapid Commit option), Request, Confirm, Renew, Rebind or (with a Rapid Commit option), Request, Confirm, Renew, Rebind or
Information-request message, the client extracts the configuration Information-request message, the client extracts the configuration
information contained in the Reply. The client MAY choose to information contained in the Reply. The client MAY choose to
skipping to change at page 12, line 46 skipping to change at page 13, line 32
that have a valid lifetime of 0 in the IA Address option. that have a valid lifetime of 0 in the IA Address option.
- Leave unchanged any information about addresses the client has - Leave unchanged any information about addresses the client has
recorded in the IA but that were not included in the IA from the recorded in the IA but that were not included in the IA from the
server. server.
Management of the specific configuration information is detailed in Management of the specific configuration information is detailed in
the definition of each option in section 22. the definition of each option in section 22.
The client examines the status code in each IA individually. If The client examines the status code in each IA individually. If
the client receives a NoAddrsAvail, the client has received no the client receives a NoAddrsAvail status code, the client has
usable addresses in the IA. received no usable addresses in the IA.
If the client finds no usable addresses in any of the IAs, it may
either try another server (by restarting the DHCP server discovery
process) or use the Information-request message to obtain other
configuration information only.
The client uses addresses and other information from any IAs that If the client can operate with the addresses obtained from the
do not contain a Status Code option with the NoAddrsAvail code. server the client uses addresses and other information from any IAs
For each IA for which the client receives NoAddrsAvail status code that do not contain a Status Code option with the NoAddrsAvail
the client has the following choices: status code. The client MAY include the IAs for which it received
the NoAddrsAvail status code, with no addresses, in subsequent
Renew and Rebind messages sent to the server, to retry obtaining
the addresses for these IAs.
- The client includes the IA with no addresses in subsequent Renew If the client cannot operate without the addresses for the IAs for
and Rebind messages sent to the server, to request creation of which it received the NoAddrsAvail status code, the client may try
the binding for the IA. another server (perhaps by restarting the DHCP server discovery
process).
- Tries another server (by restarting the DHCP server discovery If the client finds no usable addresses in any of the IAs, it may
process). either try another server (perhaps restarting the DHCP server
discovery process) or use the Information-request message to obtain
other configuration information only.
When the client receives a Reply message in response to a Renew or When the client receives a Reply message in response to a Renew or
Rebind message, for each IA in the original Renew or Rebind Rebind message, the client:
message, the client:
- Sends a Request message if the server responded with the - sends a Request message if any of the IAs in the Reply message
NoBinding status code. The client places only these IA options contains the NoBinding status code. The client places IA
in the Request message for which the server returned NoBinding options in this message for only those IAs for which the server
status code in the Reply message. The client continues to use returned the NoBinding status code in the Reply message. The
other bindings for which the server did not return an error. client continues to use other bindings for which the server did
not return an error
- Sends a Renew/Rebind if the IA is not in the Reply message. - sends a Renew/Rebind if any of the IAs is not in the Reply
However, in this case, the client MUST limit the rate at which message, but in this case the client MUST limit the rate at
it sends subsequent Renew/Rebind messages and limit the duration which it sends these messages, to avoid the Renew/Rebind storm
of the time during which it sends the messages.
- Otherwise accepts the information in the IA. - otherwise accepts the information in the IA.
When the client receives a valid Reply message in response to a When the client receives a valid Reply message in response to a
Release message, the client considers the Release event completed, Release message, the client considers the Release event completed,
regardless of the Status Code option(s) returned by the server. regardless of the Status Code option(s) returned by the server.
When the client receives a valid Reply message in response to a When the client receives a valid Reply message in response to a
Decline message, the client considers the Decline event completed, Decline message, the client considers the Decline event completed,
regardless of the Status Code option(s) returned by the server. regardless of the Status Code option(s) returned by the server.
4.4.6. Updates to Section 18.2.3 of RFC 3315 4.4.6. Updates to Section 18.2.3 of RFC 3315
skipping to change at page 14, line 11 skipping to change at page 14, line 44
to which the server has not sent a unicast option, the server to which the server has not sent a unicast option, the server
discards the Renew message and responds with a Reply message discards the Renew message and responds with a Reply message
containing a Status Code option with the value UseMulticast, a containing a Status Code option with the value UseMulticast, a
Server Identifier option containing the server's DUID, the Client Server Identifier option containing the server's DUID, the Client
Identifier option from the client message, and no other options. Identifier option from the client message, and no other options.
For each IA in the Renew message from a client, the server locates 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 the client's binding and verifies that the information in the IA
from the client matches the information stored for that client. from the client matches the information stored for that client.
If the server finds the addresses in the IA for the client then the If the server finds the client entry for the IA the server sends
server sends back the IA to the client with new lifetimes and, if back the IA to the client with new lifetimes and, if applicable,
applicable, T1/T2 times. If the server is unable to extend the T1/T2 times. If the server is unable to extend the lifetimes of an
lifetimes of an address in the IA, the server MAY choose not to address in the IA, the server MAY choose not to include the IA
include the IA Address option for this address. Address option for this address.
The server may choose to change the list of addresses and the The server may choose to change the list of addresses and the
lifetimes of addresses in IAs that are returned to the client. 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 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 appropriate for the link to which the client is attached, the
server returns the address to the client with lifetimes of 0. server returns the address to the client with lifetimes of 0.
For each IA for which the server cannot find a client entry, the For each IA for which the server cannot find a client entry, the
server has the following choices depending on the server's policy server has the following choices depending on the server's policy
skipping to change at page 15, line 28 skipping to change at page 16, line 14
4.4.7. Updates to Section 18.2.4 of RFC 3315 4.4.7. Updates to Section 18.2.4 of RFC 3315
Replace Section 18.2.4 of RFC 3315 with the following text: Replace Section 18.2.4 of RFC 3315 with the following text:
When the server receives a Rebind message that contains an IA When the server receives a Rebind message that contains an IA
option from a client, it locates the client's binding and verifies option from a client, it locates the client's binding and verifies
that the information in the IA from the client matches the that the information in the IA from the client matches the
information stored for that client. information stored for that client.
If the server finds the addresses in the IA for the client and the If the server finds the client entry for the IA and the server
server determines that the addresses in the IA are appropriate for determines that the addresses in the IA are appropriate for the
the link to which the client's interface is attached according to link to which the client's interface is attached according to the
the server's explicit configuration information, the server SHOULD server's explicit configuration information, the server SHOULD
send back the IA to the client with new lifetimes and, if send back the IA to the client with new lifetimes and, if
applicable, T1/T2 times. If the server is unable to extend the 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 lifetimes of an address in the IA, the server MAY choose not to
include the IA Address option for this address. include the IA Address option for this address.
If the server finds the client entry for the IA and any of the If the server finds the client entry for the IA and any of the
addresses are no longer appropriate for the link to which the addresses are no longer appropriate for the link to which the
client's interface is attached according to the server's explicit client's interface is attached according to the server's explicit
configuration information, the server returns the addresses to the configuration information, the server returns the address to the
client with lifetimes of 0. client with lifetimes of 0.
If the server cannot find a client entry for the IA, the IA If the server cannot find a client entry for the IA, the IA
contains addresses and the server determines that the addresses in contains addresses and the server determines that the addresses in
the IA are not appropriate for the link to which the client's the IA are not appropriate for the link to which the client's
interface is attached according to the server's explicit interface is attached according to the server's explicit
configuration information, the server MAY send a Reply message to configuration information, the server MAY send a Reply message to
the client containing the client's IA, with the lifetimes for the the client containing the client's IA, with the lifetimes for the
addresses in the IA set to 0. This Reply constitutes an explicit addresses in the IA set to 0. This Reply constitutes an explicit
notification to the client that the addresses in the IA are no notification to the client that the addresses in the IA are no
skipping to change at page 17, line 10 skipping to change at page 17, line 47
18.2. 18.2.
The T1/T2 times set in each applicable IA option for a Reply MUST The T1/T2 times set in each applicable IA option for a Reply MUST
be the same values across all IAs. The server MUST determine the be the same values across all IAs. The server MUST determine the
T1/T2 times across all of the applicable client's bindings in the T1/T2 times across all of the applicable client's bindings in the
Reply. This facilitates the client being able to renew all of the Reply. This facilitates the client being able to renew all of the
bindings at the same time. bindings at the same time.
4.4.8. Updates to RFC 3633 4.4.8. Updates to RFC 3633
Replace Section 12.1: Replace the following text in Section 12.1 of RFC 3633:
Each prefix has valid and preferred lifetimes whose durations are Each prefix has valid and preferred lifetimes whose durations are
specified in the IA_PD Prefix option for that prefix. The specified in the IA_PD Prefix option for that prefix. The
requesting router uses Renew and Rebind messages to request the requesting router uses Renew and Rebind messages to request the
extension of the lifetimes of a delegated prefix. extension of the lifetimes of a delegated prefix.
With: With:
Each prefix has valid and preferred lifetimes whose durations are Each prefix has valid and preferred lifetimes whose durations are
specified in the IA_PD Prefix option for that prefix. The specified in the IA_PD Prefix option for that prefix. The
requesting router uses Renew and Rebind messages to request the requesting router uses Renew and Rebind messages to request the
extension of the lifetimes of a delegated prefix. extension of the lifetimes of a delegated prefix.
The requesting router MAY include IA_PD options without any The requesting router MAY include IA_PD options without any
prefixes, i.e. without IA Prefix option or with IPv6 prefix field prefixes, i.e. without IA Prefix option or with IPv6 prefix field
of IA Prefix option set to 0, in a Renew or Rebind message to of IA Prefix option set to 0, in a Renew or Rebind message to
obtain bindings it desires but has been unable to obtain. The obtain bindings it desires but has been unable to obtain. The
requesting router MAY set the prefix-length field of the IA Prefix requesting router MAY set the prefix-length field of the IA Prefix
option as a hint to the server. option as a hint to the server. As in [RFC3315], the requesting
router MAY also provide lifetime hints in the IA Prefix option.
Replace Section 12.2: Replace the following text in Section 12.2 of RFC 3633:
The delegating router behaves as follows when it cannot find a The delegating router behaves as follows when it cannot find a
binding for the requesting router's IA_PD: binding for the requesting router's IA_PD:
With: With:
For the Renew or Rebind, if the IA_PD contains no prefixes, i.e. For the Renew or Rebind, if the IA_PD contains no IA Prefix option
contains no IA Prefix option or the IPv6 prefix field in the IA or it contains an IA Prefix option with the IPv6 prefix field set
Prefix option is set to 0, the delegating router SHOULD assign to 0, the delegating router SHOULD assign prefixes to the IA_PD
prefixes to the IA_PD according to the delegating router's according to the delegating router's explicit configuration
explicit configuration information. In this case, when the server information. In this case, if the IA_PD contains an IA Prefix
assigns new prefixes to the IA_PD, the server MAY use the value in option with the IPv6 prefix field set to 0, the delegating router
the prefix-length field of the IA Prefix option as a hint for the MAY use the value in the prefix-length field of the IA Prefix
length of the prefixes being assigned. option as a hint for the length of the prefixes to be assigned.
The delegating router MAY also respect lifetime hints provided by
the requesting router in the IA Prefix option.
The delegating router behaves as follows when it cannot find a The delegating router behaves as follows when it cannot find a
binding for the requesting router's IA_PD containing prefixes: binding for the requesting router's IA_PD containing prefixes:
4.5. 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
skipping to change at page 18, line 37 skipping to change at page 19, line 25
IA_TA IA-types. As a consequence Confirm can only be used when the 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). 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 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 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 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 delegating router (server) has
IAs. In that case a client MUST use the Rebind message in place of the binding for the IAs. In that case a requesting router (client)
the Confirm message and it MUST include all of its bindings, even MUST use the Rebind message in place of the Confirm message and it
address IAs. MUST include all of its bindings, even address IAs.
Note that Section 18.1.2 of RFC 3315 states that a client MUST 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 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 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]. has not moved using other techniques, such as described in [RFC6059].
And, as stated above, a client with delegated prefixes, MUST send a And, as stated above, a client with delegated prefixes, MUST send a
Rebind instead of a Confirm. Rebind instead of a Confirm.
4.6. Decline Should Not Necessarily Trigger a Release 4.6. Decline Should Not Necessarily Trigger a Release
Some client implementations have been found to send a Release message Some client implementations have been found to send a Release message
for other bindings they may have received after they determine a for other bindings they may have received after they determine a
conflict and have correctly sent a Decline message for the conflict and have correctly sent a Decline message for the
conflicting address(es). 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. The
client SHOULD treat the failure to acquire a binding as a result of
the conflict, to be equivalent to not having received the binding,
insofar as it behaves when sending Renew and Rebind messages.
4.7. Multiple Provisioning Domains 4.7. Multiple Provisioning Domains
This document has assumed that all DHCP servers on a network are in a This document has assumed that all DHCP servers on a network are in a
single provisioning domain and thus should be "equal" in the service single provisioning domain and thus should be "equal" in the service
that they offer. 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
outside the scope of this document. outside the scope of this document (see [I-D.ietf-mif-mpvd-arch] and
[I-D.ietf-mif-mpvd-dhcp-support]).
5. IANA Considerations 5. IANA Considerations
This specification does not require any IANA actions. This specification does not require any IANA actions.
6. Security Considerations 6. Security Considerations
There are no new security considerations pertaining to this document. There are no new security considerations pertaining to this document.
7. Acknowledgements 7. Acknowledgements
Thanks to many people that contributed to identify the stateful Thanks to many people that contributed to identify the stateful
issues addressed by this document and for reviewing drafts of the issues addressed by this document and for reviewing drafts of the
document, including Ralph Droms, John Brzozowski, Ted Lemon, Hemant document, including Ralph Droms, John Brzozowski, Ted Lemon, Hemant
Singh, Wes Beebee, Gaurau Halwasia, Bud Millword, Tim Winters, Rob Singh, Wes Beebee, Gaurau Halwasia, Bud Millword, Tim Winters, Rob
Shakir, Jinmei Tatuya, Andrew Yourtchenko, and Fred Templin. Shakir, Jinmei Tatuya, Andrew Yourtchenko, Fred Templin, Tomek
Mrugalski, Suresh Krishnan, and Ian Farrer.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
skipping to change at page 20, line 24 skipping to change at page 21, line 13
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-03 (work in progress), October 2014. dhcwg-dhc-rfc3315bis-03 (work in progress), October 2014.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [I-D.ietf-mif-mpvd-arch]
Extensions for Stateless Address Autoconfiguration in Anipko, D., "Multiple Provisioning Domain Architecture",
IPv6", RFC 4941, September 2007. draft-ietf-mif-mpvd-arch-09 (work in progress), January
2015.
[I-D.ietf-mif-mpvd-dhcp-support]
Krishnan, S., Korhonen, J., and S. Bhandari, "Support for
multiple provisioning domains in DHCPv6", draft-ietf-mif-
mpvd-dhcp-support-00 (work in progress), August 2014.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059, November Detecting Network Attachment in IPv6", RFC 6059, November
2010. 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
 End of changes. 64 change blocks. 
223 lines changed or deleted 275 lines changed or added

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