draft-ietf-dhc-dhcpv6-stateful-issues-12.txt   rfc7550.txt 
Network Working Group O. Troan Internet Engineering Task Force (IETF) O. Troan
Internet-Draft B. Volz Request for Comments: 7550 B. Volz
Updates: 3315,3633 (if approved) Cisco Systems, Inc. Updates: 3315, 3633 Cisco Systems, Inc.
Intended status: Standards Track M. Siodelski Category: Standards Track M. Siodelski
Expires: September 21, 2015 ISC ISSN: 2070-1721 ISC
March 20, 2015 May 2015
Issues and Recommendations with Multiple Stateful DHCPv6 Options Issues and Recommendations with Multiple Stateful DHCPv6 Options
draft-ietf-dhc-dhcpv6-stateful-issues-12.txt
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) The Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
specification defined two stateful options, IA_NA and IA_TA, but did specification defined two stateful options, IA_NA and IA_TA, but did
not anticipate the development of additional stateful options. not anticipate the development of additional stateful options.
DHCPv6 Prefix Delegation added the IA_PD option, which is stateful. DHCPv6 Prefix Delegation added the IA_PD option, which is stateful.
Applications that use IA_NA and IA_PD together have revealed issues Applications that use IA_NA and IA_PD together have revealed issues
that need to be addressed. This document updates RFC 3315 and RFC that need to be addressed. This document updates RFCs 3315 and 3633
3633 to address these issues. to address these issues.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on September 21, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7550.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 24 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Handling of Multiple IA Option Types . . . . . . . . . . . . 4 4. Handling of Multiple IA Option Types . . . . . . . . . . . . 4
4.1. Placement of Status Codes in an Advertise Message . . . . 5 4.1. Placement of Status Codes in an Advertise Message . . . . 6
4.2. Advertise Message Processing by a Client . . . . . . . . 7 4.2. Advertise Message Processing by a Client . . . . . . . . 8
4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 8 4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 9 4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 10
4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 9 4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 10
4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 10 4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 11
4.4.3. Updates to section 18.1.3 of RFC 3315 . . . . . . . . 10 4.4.3. Updates to Section 18.1.3 of RFC 3315 . . . . . . . . 11
4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 12 4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 13
4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 13 4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 14
4.4.6. Updates to Section 18.2.3 of RFC 3315 . . . . . . . . 15 4.4.6. Updates to Section 18.2.3 of RFC 3315 . . . . . . . . 16
4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 17 4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 18
4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 18 4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 20
4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 19 4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 21
4.6. Decline Should Not Necessarily Trigger a Release . . . . 20 4.6. Decline Should Not Necessarily Trigger a Release . . . . 22
4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 21 4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Normative References . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2. Informative References . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 21 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
DHCPv6 [RFC3315] was written without 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] since added a new stateful option for Prefix Delegation to [RFC3633] since added a new stateful option for Prefix Delegation to
DHCPv6. Implementation experience of the Customer Edge Router (CER) DHCPv6. Implementation experience of the Customer Edge (CE) router
model described in [RFC7084] has shown issues with the DHCPv6 model described in [RFC7084] has shown issues with the DHCPv6
protocol in supporting multiple stateful option types, in particular protocol in supporting multiple stateful option types, in particular
IA_NA (non-temporary addresses) and IA_PD (delegated prefixes). IA_NA (non-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 specifies changes coexistence of the IA_NA and IA_PD option types and specifies changes
to the DHCPv6 protocol 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 DHCPv6 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 DHCPv6 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. Therefore, the IA_TA option type is mostly and IA_PD option types. Therefore, the IA_TA option type is mostly
out of scope for this document. 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]). [DHCPv6].
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:
Identity association (IA): Throughout this document, "IA" is Identity Association (IA): Throughout this document, "IA" is used to
used to refer to the Identity refer to the Identity Association containing addresses or prefixes
Association containing addresses or assigned to a client and carried in the IA_NA or IA_PD options,
prefixes assigned to a client and respectively.
carried in the IA_NA or IA_PD options
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_NA and/or IA_PD option. IA_PD option.
Stateful options: Options that require dynamic binding Stateful options: Options that require a dynamic binding state per
state per client on the server. client on the server.
Top-level options: Top-level options are DHCPv6 options Top-level options: Top-level options are DHCPv6 options that are not
that are not encapsulated within encapsulated within other options, excluding the Relay Message
other options, excluding the Relay- option. Options encapsulated by Relay Message options, but not by
Message option. Options encapsulated any other option, are still top-level options, whether they appear
by Relay-message options, but not by in a relay agent message or a server message; see [RFC7227].
any other option, are still top-level
options, whether they appear in a
relay agent message or a server
message. See [RFC7227].
4. Handling of Multiple IA Option Types 4. Handling of Multiple IA Option Types
The DHCPv6 specification [RFC3315] was written with the assumption The DHCPv6 specification [RFC3315] was written with the assumption
that the only stateful options were for assigning addresses. DHCPv6 that the only stateful options were for assigning addresses. DHCPv6
Prefix Delegation [RFC3633] describes how to extend the DHCPv6 Prefix Delegation [RFC3633] describes how to extend the DHCPv6
protocol to handle prefix delegation, but does not clearly specify protocol to handle prefix delegation, but does not clearly specify
how the DHCP address assignment and prefix delegation co-exist. how the DHCP address assignment and prefix delegation coexist.
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: several ways:
1. Reset the state machine and continue 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 2. Create separate DHCP sessions for each IA option type and
continue to Solicit for the unfulfilled IA options, or continue to Solicit for the unfulfilled IA options, or
3. The client could continue with the single session, and include 3. The client could continue with the single session and include the
the unfulfilled IA options in subsequent messages to the server. unfulfilled IA options in subsequent messages to the server.
Resetting the state machine and continuing to send Solicit messages 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 packet 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 or there are many clients on the network. Client messages or if there are many clients on the network. Client
implementors that follow this approach, SHOULD implement the updates implementors that follow this approach SHOULD implement the updates
to RFC-3315 specified in [RFC7083]. to RFC 3315 specified in [RFC7083].
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, causes state machine) per IA option type, while conceptually simple, causes
a number of issues: additional host resources required to create and a number of issues: additional host resources required to create and
maintain multiple instances of the state machine in clients, maintain multiple instances of the state machine in clients,
additional DHCP protocol traffic, unnecessary duplication of other additional DHCP protocol traffic, unnecessary duplication of other
configuration options and the potential for conflict, divergence in configuration options and the potential for conflict, and divergence
that each IA option type specification specifies its 'own' version of in that each IA option type specification specifies its 'own' version
the DHCP protocol. of the DHCP protocol.
The single session and state machine allows the client to use the The single session and state machine allows the client to use the
best configuration it is able to obtain from a single DHCP server best configuration it is able to obtain from a single DHCP server
during the configuration exchange. Note, however, that the server during the configuration exchange. Note, however, that the server
may not be configured to deliver the entire configuration requested may not be configured to deliver the entire configuration requested
by the client. In that case the client could continue to operate by the client. In that case, the client could continue to operate
only using the configuration received, even if other servers can only using the configuration received, even if other servers can
provide the missing configuration. In practice, especially in the provide the missing configuration. In practice, especially in the
case of handling IA_NA and IA_PD, this situation should be rare or a case of handling IA_NA and IA_PD, this situation should be rare or a
temporary operational error. So, it is more likely for the client to temporary operational error. So, it is more likely for the client to
get all configuration if it continues, in each subsequent get all configuration if it continues, in each subsequent
configuration exchange, to request all the configuration information configuration exchange, to request all the configuration information
it is programmed to try to obtain, including any stateful it is programmed to try to obtain, including any stateful
configuration options for which no results were returned in previous configuration options for which no results were returned in previous
exchanges. exchanges.
One major issue of this last approach is that it is difficult to One major issue of this last approach is that it is difficult to
allow it with the current DHCPv6 specifications; in some cases they allow it with the current DHCPv6 specifications; in some cases they
are not clear enough, and in other cases existing restrictions can are not clear enough, and in other cases existing restrictions can
make it impossible. This document introduces some clarifications and make it impossible. This document introduces some clarifications and
small modifications to the current specifications to address these small modifications to the current specifications to address these
concerns. concerns.
While all approaches have their own pros and cons, approach 3 SHOULD While all approaches have their own pros and cons, approach number 3
be used and is the focus of this document because it is deemed to above SHOULD be used and is the focus of this document because it is
work best for common cases of the mixed use of IA_NA and IA_PD. But deemed to work best for common cases of the mixed use of IA_NA and
this document does not exclude other approaches. Also, in some IA_PD. But this document does not exclude other approaches. Also,
corner cases it may not be feasible to maintain a single DHCPv6 in some corner cases it may not be feasible to maintain a single
session for both IA_NA and IA_PD. These corner cases are beyond the DHCPv6 session for both IA_NA and IA_PD. These corner cases are
scope of this document and may depend on the network in which the beyond the scope of this document and may depend on the network in
client (CER) is designed to operate and on the functions the client which the client (CE router) is designed to operate and on the
is required to perform. functions the client is required to perform.
The sections which follow update RFC 3315 and RFC 3633 to accommodate The sections that follow update RFCs 3315 and 3633 to accommodate the
the recommendation, though many of the changes are also applicable recommendation, though many of the changes are also applicable even
even if other approaches are used. if other approaches are used.
4.1. Placement of Status Codes in an Advertise Message 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, and NoPrefixAvail) are encapsulated in the IA
option. In Advertise messages though, the NoAddrsAvail code is option. In Advertise messages though, the NoAddrsAvail code is
returned at in the top level. This makes sense if the client is only returned at the top level. This makes sense if the client is only
interested in the assignment of the addresses and the failure case is interested in the assignment of the addresses and the failure case is
fatal. However, if the client sends both IA_NA and IA_PD options in fatal. However, if the client sends both IA_NA and IA_PD options in
a Solicit message, it is possible that the server offers no addresses a Solicit message, it is possible that the server will offer some
but it offers some prefixes, and the client may choose to send a prefixes but no addresses, and the client may choose to send a
Request message to obtain the offered prefixes. In this case, it is Request message to obtain the offered prefixes. In this case, it is
better if the Status Code option for IA specific status codes is better if the Status Code option for IA-specific status codes is
encapsulated in the IA option to indicate that the failure occurred encapsulated in the IA option to indicate that the failure occurred
for the specific IA. This also makes the NoAddrsAvail and for the specific IA. This also makes the NoAddrsAvail and
NoPrefixAvail Status Code option placement for Advertise messages NoPrefixAvail Status Code option placement for 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).
We have chosen the following solution: We have chosen the following solution:
Clients MUST handle each of the following Advertise messages formats Clients MUST handle each of the following Advertise message formats
when there are no addresses available (even when no other IA option when there are no addresses available (even when no other IA option
types were in the Solicit): types were in the Solicit):
1. Advertise containing the IA_NAs and/or IA_TAs with encapsulated 1. Advertise containing the IA_NAs and/or IA_TAs with an
Status Code option of NoAddrsAvail and no top-level Status Code encapsulated Status Code option of NoAddrsAvail and no top-level
option. Status Code option.
2. Advertise containing just a top-level Status Code option of 2. Advertise containing just a top-level Status Code option of
NoAddrsAvail and no IA_NAs/IA_TAs. NoAddrsAvail and no IA_NAs/IA_TAs.
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.
Note: Clients MUST handle the last two formats listed above to Note: Clients MUST handle the last two formats listed above to
facilitate backward compatibility with the servers which have not facilitate backward compatibility with the servers that have not been
been updated to this specification. updated to this specification.
See Section 4.2 for updated text for Section 17.1.3 of RFC 3315 and See Section 4.2 for updated text for Section 17.1.3 of RFC 3315 and
Section 11.1 of RFC 3633. Section 11.1 of RFC 3633.
Servers MUST return the Status Code option of NoAddrsAvail Servers MUST return the Status Code option of NoAddrsAvail
encapsulated in IA_NA/IA_TA options and MUST NOT return a top-level encapsulated in IA_NA/IA_TA options and MUST NOT return a top-level
Status Code option of NoAddrsAvail when no addresses will be assigned Status Code option of NoAddrsAvail when no addresses will be assigned
(1 in the above list). This means that the Advertise response (number 1 in the above list). This means that the Advertise response
matches the Reply response with respect to the handling of the matches the Reply response with respect to the handling of the
NoAddrsAvail status. NoAddrsAvail 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 the following text (which addresses the existing erratum
[Err2472]):
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 Processing by a Client 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
skipping to change at page 7, line 45 skipping to change at page 8, line 30
Note 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 the following text (which addresses the existing erratum
[Err2471] and 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) and - MUST process an included SOL_MAX_RT option (RFC 7083) and
- MUST process an included INF_MAX_RT option (RFC 7083). - MUST process an included INF_MAX_RT option (RFC 7083).
A client can display any associated status message(s) to the user A client can display any associated status message(s) to the user
or activity log. or activity log.
The client ignoring this Advertise message MUST NOT restart the The client ignoring this Advertise message MUST NOT restart the
Solicit retransmission timer. 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
skipping to change at page 8, line 30 skipping to change at page 9, line 18
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 has - The client MAY choose a less-preferred server if that server has
a better set of advertised parameters, such as the available set a better set of advertised parameters, such as the available set
of IAs, as well as the set of other configuration options of IAs, as well as the set of other configuration options
advertised. advertised.
And, replace the last paragraph of Section 11.1 of RFC 3633 with: And, replace the last paragraph of Section 11.1 of RFC 3633 with the
following text (which addresses the existing erratum [Err2469]):
The requesting router MUST ignore any Advertise message that The requesting router MUST ignore any Advertise message that
contains no addresses (IAADDR options encapsulated in IA_NA or contains no addresses (IAADDR options encapsulated in IA_NA or
IA_TA options) and no delegated prefixes (IAPREFIX options IA_TA options) and no delegated prefixes (IAPREFIX options
encapsulated in IA_PD options, see RFC 3633) with the exception encapsulated in IA_PD options; see RFC 3633) with the exception
that the requesting router: that the requesting router:
- MUST process an included SOL_MAX_RT option (RFC 7083) and - MUST process an included SOL_MAX_RT option (RFC 7083) and
- MUST process an included INF_MAX_RT option (RFC 7083). - MUST process an included INF_MAX_RT option (RFC 7083).
A client can display any associated status message(s) to the user A client can display any associated status message(s) to the user
or activity log. or activity log.
The requesting router ignoring this Advertise message MUST NOT The requesting router ignoring this Advertise message MUST NOT
restart the Solicit retransmission timer. 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
skipping to change at page 9, line 4 skipping to change at page 9, line 42
The requesting router ignoring this Advertise message MUST NOT The requesting router ignoring this Advertise message MUST NOT
restart the Solicit retransmission timer. 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
be carried in a separate DHCP option. should be carried in a separate DHCP option.
Solution: The server MUST set the T1/T2 times in all IA options in a Solution: The server MUST set the T1/T2 times in all IA options in a
Reply or Advertise message to the same value. To deal with the case Reply or Advertise message to the same value. To deal with the case
where servers have not yet been updated to do that, the client MUST where servers have not yet been updated to do that, the client MUST
select a T1 and T2 time from all IA options which will guarantee that select a T1 and T2 time from all IA options, which will guarantee
the client will send Renew/Rebind messages not later than at the T1/ that the client will send Renew/Rebind messages not later than at the
T2 times associated with any of the client's bindings. T1/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:
The T1/T2 times set in each applicable IA option for a Reply MUST The T1/T2 times set in each applicable IA option for a Reply MUST
be the same values across all IAs. The server MUST determine the be the same values across all IAs. The server MUST determine the
T1/T2 times across all of the applicable client's bindings in the T1/T2 times across all of the applicable client's bindings in the
Reply. This facilitates the client being able to renew all of the Reply. This facilitates the client being able to renew all of the
bindings at the same time. bindings at the same time.
Note: This additional paragraph has also been included in the revised 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 in this document 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 Sections 4.4.3 and
Section 4.4.4. 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 introduces relevant updates to the [RFC3315] and messages. It also introduces relevant updates to [RFC3315] and
[RFC3633]. [RFC3633].
4.4.1. Renew Message 4.4.1. Renew Message
In multiple IA option type model, the client may include multiple IA In multiple IA option type models, the client may include multiple IA
options in the Request message, and the server may create bindings 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 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 IA options in the Request message for which the server does not
create the bindings, the server sends the IA options in the Reply create the bindings, the server sends the IA options in the Reply
message with the NoAddrsAvail or NoPrefixAvail status codes. message with the NoAddrsAvail or NoPrefixAvail status codes.
The client may accept the bindings created by the server, but may The client may accept the bindings created by the server, but may
desire the other bindings to be created once they become available, desire the other bindings to be created once they become available,
e.g. when the server configuration is changed. The client which e.g., when the server configuration is changed. The client that
accepted the bindings created by the server will periodically send a accepted the bindings created by the server will periodically send a
Renew message to extend their lifetimes. However, the Renew message, Renew message to extend their lifetimes. However, the Renew message,
as described in the [RFC3315], does not support the ability for the as described in [RFC3315], does not support the ability for the
client to extend the lifetimes of the bindings for some IAs, while client to extend the lifetimes of the bindings for some IAs, while
requesting bindings for other IAs. requesting bindings for other IAs.
Solution: The client, which sends a Renew message to extend the Solution: The client, which sends a Renew message to extend the
lifetimes of the bindings assigned to the client, SHOULD include IA lifetimes of the bindings assigned to the client, SHOULD include IA
options for these bindings as well as IA options for all other options for these bindings as well as IA options for all other
bindings that the client desires but has been unable to obtain. The bindings that the client desires but has been unable to obtain. The
client and server processing need to be modified. Note that this client and server processing need to be modified. Note that this
change makes the server's IA processing of Renew similar to the change makes the server's IA processing of Renew similar to the
Request processing. Request processing.
4.4.2. Rebind Message 4.4.2. Rebind Message
According to the Section 4.4.1, the client includes IA options in a According to Section 4.4.1, the client includes IA options in a Renew
Renew message for the bindings it desires but has been unable to message for the bindings it desires but has been unable to obtain by
obtain by sending a Request message, apart from the IA options for sending a Request message, apart from the IA options for the existing
the existing bindings. 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.
Solution: The client SHOULD continue to include the IA options Solution: The client SHOULD continue to include the IA options
received from the server and it MAY include additional IA options to received from the server, and it MAY include additional IA options to
request creation of the additional bindings. request creation of the 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
assigned to an IA, the client sends a Renew message to the server assigned to an IA, the client sends a Renew message to the server
from which the addresses were obtained, which includes an IA option from which the addresses were obtained, which includes an IA option
for the IA whose address lifetimes are to be extended. The client for the IA whose address lifetimes are to be extended. The client
includes IA Address options within the IA option for the addresses includes IA Address options within the IA option for the addresses
assigned to the IA. The server determines new lifetimes for these assigned to the IA. The server determines new lifetimes for these
addresses according to the administrative configuration of the addresses according to the administrative configuration of the
server. The server may also add new addresses to the IA. The server. The server may also add new addresses to the IA. The
server can remove addresses from the IA by returning IA Address server can remove addresses from the IA by returning IA Address
options for such addresses with preferred and valid lifetimes set options for such addresses with preferred and valid lifetimes set
to zero. to 0.
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.
At time T1, the client initiates a Renew/Reply message exchange to At time T1, the client initiates a Renew/Reply message exchange to
extend the lifetimes on any addresses in the IA. extend the lifetimes on any addresses in the IA.
If T1 or T2 had been set to 0 by the server (for an IA_NA) or there If T1 or T2 had been set to 0 by the server (for an IA_NA) or there
are no T1 or T2 times (for an IA_TA) in a previous Reply, the are no T1 or T2 times (for an IA_TA) in a previous Reply, the
client may send a Renew or Rebind message, respectively, at the client may send a Renew or Rebind message, respectively, at the
skipping to change at page 11, line 39 skipping to change at page 12, line 33
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.
For IAs to which addresses have been assigned, the client includes For IAs to which addresses have been assigned, the client includes
a corresponding IA option containing an IA Address option for each a corresponding IA option containing an IA Address option for each
address assigned to the IA. The client MUST NOT include addresses address assigned to the IA. The client MUST NOT include addresses
in any IA option that the client did not obtain from the server or in any IA option that the client did not obtain from the server or
that are no longer valid (that have a zero valid lifetime). that are no longer valid (that have a valid lifetime of 0).
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 the
address field set to 0 to indicate the client's preference for the "IPv6 address" field set to 0 to indicate the client's preference
preferred and valid lifetimes for any newly assigned addresses. for the 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
about parameter values the client would like to have returned. about parameter values the client would like to have returned.
The client transmits the message according to section 14, using the The client transmits the message according to section 14, using the
following parameters: following parameters:
IRT REN_TIMEOUT IRT REN_TIMEOUT
MRT REN_MAX_RT MRT REN_MAX_RT
MRC 0 MRC 0
MRD Remaining time until T2 MRD Remaining time until T2
The message exchange is terminated when time T2 is reached (see The message exchange is terminated when time T2 is reached (see
section 18.1.4), at which time the client begins a Rebind message section 18.1.4), at which time the client begins a Rebind message
exchange. exchange.
4.4.4. Updates to Section 18.1.4 of RFC 3315 4.4.4. Updates to Section 18.1.4 of RFC 3315
Replace Section 18.1.4 of RFC 3315 with the following text: Replace Section 18.1.4 of RFC 3315 with the following text:
At time T2 (which will only be reached if the server to which the At time T2 (which will only be reached if the server to which the
Renew message was sent at time T1 has not responded), the client Renew message was sent at time T1 has not responded), the client
initiates a Rebind/Reply message exchange with any available initiates a Rebind/Reply message exchange with any available
server. server.
The client constructs the Rebind message as described in 18.1.3 The client constructs the Rebind message as described in section
with the following differences: 18.1.3 with the following differences:
- The client sets the "msg-type" field to REBIND. - The client sets the "msg-type" field to REBIND.
- The client does not include the Server Identifier option in the - The client does not include the Server Identifier option in the
Rebind message. Rebind message.
The client transmits the message according to section 14, using the The client transmits the message according to section 14, using the
following parameters: following parameters:
IRT REB_TIMEOUT IRT REB_TIMEOUT
MRT REB_MAX_RT MRT REB_MAX_RT
MRC 0 MRC 0
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 addresses across all IAs have expired, at which time the client
uses Solicit message to locate a new DHCP server and sends a uses the 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
report any status code or message from the status code option in report any status code or message from the Status Code option in
the Reply message. the Reply message.
If the client receives a Reply message with a Status Code If the client receives a Reply message with a status code
containing UnspecFail, the server is indicating that it was unable containing UnspecFail, the server is indicating that it was unable
to process the message due to an unspecified failure condition. If to process the message due to an unspecified failure condition. If
the client retransmits the original message to the same server to the client retransmits the original message to the same server to
retry the desired operation, the client MUST limit the rate at retry the desired operation, the client MUST limit the rate at
which it retransmits the message and limit the duration of the time which it retransmits the message and limit the duration of the time
during which it retransmits the message. during which it retransmits the message.
When the client receives a Reply message with a Status Code option When the client receives a Reply message with a Status Code option
with the value UseMulticast, the client records the receipt of the with the value UseMulticast, the client records the receipt of the
message and sends subsequent messages to the server through the message and sends subsequent messages to the server through the
interface on which the message was received using multicast. The interface on which the message was received using multicast. The
client resends the original message using multicast. client resends the original message using multicast.
When the client receives a NotOnLink status from the server in When the client receives a NotOnLink status from the server in
response to a Confirm message, the client performs DHCP server response to a Confirm message, the client performs DHCP server
solicitation, as described in section 17, and client-initiated solicitation, as described in section 17, and client-initiated
configuration as described in section 18. If the client receives configuration, as described in section 18. If the client receives
any Reply messages that do not indicate a NotOnLink status, the any Reply messages that do not indicate a NotOnLink status, the
client can use the addresses in the IA and ignore any messages that client can use the addresses in the IA and ignore any messages that
indicate a NotOnLink status. indicate a NotOnLink status.
When the client receives a NotOnLink status from the server in When the client receives a NotOnLink status from the server in
response to a Request, the client can either re-issue the Request response to a Request, the client can either reissue the Request
without specifying any addresses or restart the DHCP server without specifying any addresses or restart the DHCP server
discovery process (see section 17). discovery process (see section 17).
The client SHOULD perform duplicate address detection [17] on each The client SHOULD perform duplicate address detection [17] on each
of the received addresses in any IAs, on which it has not performed of the received addresses in any IAs, on which it has not performed
duplicate address detection during processing of any of the duplicate address detection during processing of any of the
previous Reply messages from the server. The client performs the previous Reply messages from the server. The client performs the
duplicate address detection before using the received addresses for duplicate address detection before using the received addresses for
the traffic. If any of the addresses are found to be in use on the the traffic. If any of the addresses are found to be in use on the
link, the client sends a Decline message to the server for those link, the client sends a Decline message to the server for those
addresses as described in section 18.1.7. addresses as described in section 18.1.7.
If the Reply was received in response to a Solicit (with a Rapid If the Reply was received in response to a Solicit (with a Rapid
Commit option), Request, Renew or Rebind message, the client Commit option), Request, Renew, or Rebind message, the client
updates the information it has recorded about IAs from the IA updates the information it has recorded about IAs from the IA
options contained in the Reply message: options contained in the Reply message:
- Record T1 and T2 times. - Record T1 and T2 times.
- Add any new addresses in the IA option to the IA as recorded by - Add any new addresses in the IA option to the IA as recorded by
the client. the client.
- Update lifetimes for any addresses in the IA option that the - Update lifetimes for any addresses in the IA option that the
client already has recorded in the IA. client already has recorded in the IA.
skipping to change at page 14, line 36 skipping to change at page 15, line 36
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 status code, the client has the client receives a NoAddrsAvail status code, the client has
received no usable addresses in the IA. received no usable addresses in the IA.
If the client can operate with the addresses obtained from the If the client can operate with the addresses obtained from the
server the client uses addresses and other information from any IAs server, the client uses addresses and other information from any
that do not contain a Status Code option with the NoAddrsAvail IAs that do not contain a Status Code option with the NoAddrsAvail
status code. The client MAY include the IAs for which it received status code. The client MAY include the IAs for which it received
the NoAddrsAvail status code, with no addresses, in subsequent the NoAddrsAvail status code, with no addresses, in subsequent
Renew and Rebind messages sent to the server, to retry obtaining Renew and Rebind messages sent to the server, to retry obtaining
the addresses for these IAs. the addresses for these IAs.
If the client cannot operate without the addresses for the IAs for If the client cannot operate without the addresses for the IAs for
which it received the NoAddrsAvail status code, the client may try which it received the NoAddrsAvail status code, the client may try
another server (perhaps by restarting the DHCP server discovery another server (perhaps by restarting the DHCP server discovery
process). process).
skipping to change at page 15, line 13 skipping to change at page 16, line 13
other configuration information only. 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, the client: Rebind message, the client:
- sends a Request message if any of the IAs in the Reply message - sends a Request message if any of the IAs in the Reply message
contains the NoBinding status code. The client places IA contains the NoBinding status code. The client places IA
options in this message for only those IAs for which the server options in this message for only those IAs for which the server
returned the NoBinding status code in the Reply message. The returned the NoBinding status code in the Reply message. The
client continues to use other bindings for which the server did client continues to use other bindings for which the server did
not return an error not return an error.
- sends a Renew/Rebind if any of the IAs is not in the Reply - sends a Renew/Rebind if any of the IAs are not in the Reply
message, but in this case the client MUST limit the rate at message, but in this case the client MUST limit the rate at
which it sends these messages, to avoid the Renew/Rebind storm which it sends these messages, to avoid the Renew/Rebind storm.
- 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.
skipping to change at page 15, line 44 skipping to change at page 16, 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 client entry for the IA the server sends If the server finds the client entry for the IA, the server sends
back the IA to the client with new lifetimes and, if applicable, 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 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 in the IA, the server MAY choose not to 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
skipping to change at page 16, line 29 skipping to change at page 17, line 29
- If the server is configured to create new bindings as a result - If the server is configured to create new bindings as a result
of processing Renew messages, but the server will not assign any of processing Renew messages, but the server will not assign any
addresses to an IA, the server returns the IA option containing addresses to an IA, the server returns the IA option containing
a Status Code option with the NoAddrsAvail status code and a a Status Code option with the NoAddrsAvail status code and a
status message for a user. status message for a user.
- If the server does not support creation of new bindings for the - If the server does not support creation of new bindings for the
client sending a Renew message, or if this behavior is disabled client sending a Renew message, or if this behavior is disabled
according to the server's policy or configuration information, according to the server's policy or configuration information,
the server returns the IA option containing a Status code option the server returns the IA option containing a Status Code option
with the NoBinding status code and a status message for a user. 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 Renew 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 Renew 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.
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
skipping to change at page 17, line 23 skipping to change at page 18, line 23
If the server finds the client entry for the IA and the server If the server finds the client entry for the IA and the server
determines that the addresses in the IA are appropriate for the determines that the addresses in the IA are appropriate for the
link to which the client's interface is attached according to the link to which the client's interface is attached according to 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 that the client entry for the IA and any of
addresses are no longer appropriate for the link to which the 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 address 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
longer valid. In this situation, if the server does not send a longer valid. In this situation, if the server does not send a
Reply message it silently discards the Rebind message. Reply message, it silently discards the Rebind message.
Otherwise, for each IA for which the server cannot find a client Otherwise, for each IA for which the server cannot find a client
entry, the server has the following choices depending on the entry, the server has the following choices depending on the
server's policy and configuration information: server's policy and configuration information:
- If the server is configured to create new bindings as a result - If the server is configured to create new bindings as a result
of processing Rebind messages (also see the note about the of processing Rebind messages (also see the note about the
Rapid Commit option below), the server SHOULD create a binding Rapid Commit option below), the server SHOULD create a binding
and return the IA with allocated addresses with lifetimes and, and return the IA with allocated addresses with lifetimes and,
if applicable, T1/T2 times and other information requested by if applicable, T1/T2 times and other information requested by
skipping to change at page 18, line 18 skipping to change at page 19, line 18
containing a Status Code option with the NoAddrsAvail status containing a Status Code option with the NoAddrsAvail status
code and a status message for a user. code and a status message for a user.
- If the server does not support creation of new bindings for the - If the server does not support creation of new bindings for the
client sending a Rebind message, or if this behavior is client sending a Rebind message, or if this behavior is
disabled according to the server's policy or configuration disabled according to the server's policy or configuration
information, the server returns the IA option containing a information, the server returns the IA option containing a
Status Code option with the NoBinding status code and a status Status Code option with the NoBinding status code and a status
message for a user. message for a user.
When the server creates new bindings for the IA it is possible When the server creates new bindings for the IA, it is possible
that other servers also create bindings as a result of receiving that other servers also create bindings as a result of receiving
the same Rebind message. This is the same issue as in the the same Rebind message. This is the same issue as in the
Discussion under the Rapid Commit option, see section 22.14. Discussion under "Rapid Commit Option"; see section 22.14.
Therefore, the server SHOULD only create new bindings during Therefore, the server SHOULD only create new bindings during
processing of a Rebind message if the server is configured to processing of a Rebind message if the server is configured to
respond with a Reply message to a Solicit message containing the respond with a Reply message to a Solicit message containing the
Rapid Commit option. Rapid Commit option.
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 Rebind
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 Rebind
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.
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
skipping to change at page 19, line 13 skipping to change at page 20, line 22
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 an IA Prefix option or with the IPv6
of IA Prefix option set to 0, in a Renew or Rebind message to prefix field of the IA Prefix option set to 0, in a Renew or
obtain bindings it desires but has been unable to obtain. The Rebind message to obtain bindings it desires but has been unable
requesting router MAY set the prefix-length field of the IA Prefix to obtain. The requesting router MAY set the "prefix-length"
option as a hint to the server. As in [RFC3315], the requesting field of the IA Prefix option as a hint to the server. As in
router MAY also provide lifetime hints in the IA Prefix option. [RFC3315], the requesting router MAY also provide lifetime hints
in the IA Prefix option.
Replace the following text in Section 12.2 of RFC 3633: 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 IA Prefix option For the Renew or Rebind, if the IA_PD contains no IA Prefix option
or it contains an IA Prefix option with the IPv6 prefix field set or it contains an IA Prefix option with the IPv6 prefix field set
to 0, the delegating router SHOULD assign prefixes to the IA_PD to 0, the delegating router SHOULD assign prefixes to the IA_PD
according to the delegating router's explicit configuration according to the delegating router's explicit configuration
information. In this case, if the IA_PD contains an IA Prefix information. In this case, if the IA_PD contains an IA Prefix
option with the IPv6 prefix field set to 0, the delegating router option with the IPv6 prefix field set to 0, the delegating router
MAY use the value in the prefix-length field of the IA Prefix MAY use the value in the "prefix-length" field of the IA Prefix
option as a hint for the length of the prefixes to be 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 delegating router MAY also respect lifetime hints provided by
the requesting router in the IA Prefix option. 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
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.
Note: Confirm has a specific meaning and does not overload Renew/ Note: Confirm has a specific meaning and does not overload Renew/
Rebind. It also is lower processing cost as the server does NOT need Rebind. It also has a lower processing cost as the server does NOT
to extend lease times or otherwise send back other configuration need to extend lease times or otherwise send back other configuration
options. options.
The Confirm message is used by the client to verify that it has not The Confirm message is used by the client to verify that it has not
moved to a different link. For IAs with addresses, the mechanism moved to a different link. For IAs with addresses, the mechanism
used to verify if a client has moved or not, is by matching the used to verify if a client has moved or not is by matching the link's
link's on-link prefix(es) (typically a /64) against the prefix-length on-link prefix(es) (typically a /64) against the prefix-length first
first bits of the addresses provided by the client in the IA_NA or bits of the addresses provided by the client in the IA_NA or IA_TA
IA_TA IA-types. As a consequence Confirm can only be used when the IA-types. As a consequence, Confirm can only be used when the client
client has an IA with address(es) (IA_NA or IA_TA). has an IA with an 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 delegating router (server) has IA_PD requires verification that the delegating router (server) has
the binding for the IAs. In that case a requesting router (client) the binding for the IAs. In that case, a requesting router (client)
MUST use the Rebind message in place of the Confirm message and it MUST use the Rebind message in place of the Confirm message and it
MUST include all of its bindings, even 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).
A client SHOULD NOT send a Release message for other bindings it may A client SHOULD NOT send a Release message for other bindings it may
skipping to change at page 21, line 13 skipping to change at page 22, line 27
when sending Renew and Rebind messages. 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 (see [I-D.ietf-mif-mpvd-arch] and outside the scope of this document (see [MPVD-ARCH] and
[I-D.ietf-mif-mpvd-dhcp-support]). [DHCPv6-SUPPORT]).
5. IANA Considerations
This specification does not require any IANA actions.
6. Security Considerations 5. Security Considerations
There are no new security considerations pertaining to this document. There are no new security considerations pertaining to this document.
7. Acknowledgements 6. References
Thanks to many people that contributed to identify the stateful
issues addressed by this document and for reviewing drafts of the
document, including Ralph Droms, John Brzozowski, Ted Lemon, Hemant
Singh, Wes Beebee, Gaurau Halwasia, Bud Millword, Tim Winters, Rob
Shakir, Jinmei Tatuya, Andrew Yourtchenko, Fred Templin, Tomek
Mrugalski, Suresh Krishnan, and Ian Farrer.
8. References
8.1. Normative References 6.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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration Protocol
IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. DOI 10.17487/RFC3633, December 2003,
<http://www.rfc-editor.org/info/rfc3633>.
[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, DOI 10.17487/RFC7083, November
2013, <http://www.rfc-editor.org/info/rfc7083>.
8.2. Informative References 6.2. Informative References
[I-D.dhcwg-dhc-rfc3315bis] [DHCPv6] 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", Work in
dhcwg-dhc-rfc3315bis-04 (work in progress), February 2015. Progress, draft-ietf-dhc-rfc3315bis-00, March 2015.
[I-D.ietf-mif-mpvd-arch]
Anipko, D., "Multiple Provisioning Domain Architecture",
draft-ietf-mif-mpvd-arch-11 (work in progress), March
2015.
[I-D.ietf-mif-mpvd-dhcp-support] [DHCPv6-SUPPORT]
Krishnan, S., Korhonen, J., and S. Bhandari, "Support for Krishnan, S., Korhonen, J., and S. Bhandari, "Support for
multiple provisioning domains in DHCPv6", draft-ietf-mif- multiple provisioning domains in DHCPv6", Work in
mpvd-dhcp-support-01 (work in progress), March 2015. Progress, draft-ietf-mif-mpvd-dhcp-support-01, March 2015.
[Err2469] RFC Errata, Errata ID 2469, RFC 3633,
<http://www.rfc-editor.org>.
[Err2471] RFC Errata, Errata ID 2471, RFC 3315,
<http://www.rfc-editor.org>.
[Err2472] RFC Errata, Errata ID 2472, RFC 3315,
<http://www.rfc-editor.org>.
[MPVD-ARCH]
Anipko, D., "Multiple Provisioning Domain Architecture",
Work in Progress, draft-ietf-mif-mpvd-arch-11, March 2015.
[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,
2010. DOI 10.17487/RFC6059, November 2010,
<http://www.rfc-editor.org/info/rfc6059>.
[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. DOI 10.17487/RFC7084, November 2013,
<http://www.rfc-editor.org/info/rfc7084>.
[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, DOI 10.17487/RFC7227, May 2014,
<http://www.rfc-editor.org/info/rfc7227>.
Acknowledgements
Thanks to the many people that contributed to identify the stateful
issues addressed by this document and for reviewing drafts of this
document, including Ralph Droms, John Brzozowski, Ted Lemon, Hemant
Singh, Wes Beebee, Gaurau Halwasia, Bud Millword, Tim Winters, Rob
Shakir, Jinmei Tatuya, Andrew Yourtchenko, Fred Templin, Tomek
Mrugalski, Suresh Krishnan, and Ian Farrer.
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.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
USA United States
EMail: volz@cisco.com
Email: volz@cisco.com
Marcin Siodelski Marcin Siodelski
ISC ISC
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
USA United States
Email: msiodelski@gmail.com EMail: msiodelski@gmail.com
 End of changes. 112 change blocks. 
229 lines changed or deleted 241 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/