draft-ietf-dhc-dhcpv6-stateful-issues-11.txt   draft-ietf-dhc-dhcpv6-stateful-issues-12.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: August 16, 2015 ISC Expires: September 21, 2015 ISC
February 12, 2015 March 20, 2015
Issues and Recommendations with Multiple Stateful DHCPv6 Options Issues and Recommendations with Multiple Stateful DHCPv6 Options
draft-ietf-dhc-dhcpv6-stateful-issues-11.txt 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 RFC 3315 and RFC
3633 to address these issues. 3633 to address these issues.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 August 16, 2015. This Internet-Draft will expire on September 21, 2015.
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 37 skipping to change at page 2, line 37
4.1. Placement of Status Codes in an Advertise Message . . . . 5 4.1. Placement of Status Codes in an Advertise Message . . . . 5
4.2. Advertise Message Processing by a Client . . . . . . . . 7 4.2. Advertise Message Processing by a Client . . . . . . . . 7
4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 8 4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 9 4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 9
4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 9 4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 9
4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 10 4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . 10
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 . . . . . . . . 12
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 . . . . . . . . 13
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 . . . . . . . . 15
4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 16 4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 17
4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 18 4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 18
4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 19 4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 19
4.6. Decline Should Not Necessarily Trigger a Release . . . . 20 4.6. Decline Should Not Necessarily Trigger a Release . . . . 20
4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 20 4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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 Router (CER)
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
skipping to change at page 4, line 43 skipping to change at page 4, line 43
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 unfulfilled IA options in subsequent messages to the server. the 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 there are many clients on the network. Client
implementors that follow this approach, are strongly advised to implementors that follow this approach, SHOULD implement the updates
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, divergence in
that each IA option type specification specifies its 'own' version of that each IA option type specification specifies its 'own' version of
the DHCP protocol. the DHCP protocol.
skipping to change at page 5, line 29 skipping to change at page 5, line 29
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, we recommend and While all approaches have their own pros and cons, approach 3 SHOULD
focus on approach 3 for this document because it is deemed to work be used and is the focus of this document because it is deemed to
best for common cases of the mixed use of IA_NA and IA_PD. But this work best for common cases of the mixed use of IA_NA and IA_PD. But
document does not exclude other approaches. Also, in some corner this document does not exclude other approaches. Also, in some
cases it may not be feasible to maintain a single DHCPv6 session for corner cases it may not be feasible to maintain a single DHCPv6
both IA_NA and IA_PD. These corner cases are beyond the scope of session for both IA_NA and IA_PD. These corner cases are beyond the
this document and may depend on the network in which the client (CER) scope of this document and may depend on the network in which the
is designed to operate and on the functions the client is required to client (CER) is designed to operate and on the functions the client
perform. is required to perform.
The sections which follow update RFC 3315 and RFC 3633 to accommodate The sections which follow update RFC 3315 and RFC 3633 to accommodate
the recommendation, though many of the changes are also applicable the recommendation, though many of the changes are also applicable
even if other approaches are used. even 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, NoPrefixAvail) are encapsulated in the IA
option. In Advertise messages though, the NoAddrsAvail code is option. In Advertise messages though, the NoAddrsAvail code is
skipping to change at page 6, line 20 skipping to change at page 6, line 20
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 be prepared to handle each of the following Advertise Clients MUST handle each of the following Advertise messages formats
messages formats when there are no addresses available (even when no when there are no addresses available (even when no other IA option
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 encapsulated
Status Code option of NoAddrsAvail and no top-level Status Code Status Code option of NoAddrsAvail and no top-level Status Code
option. option.
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 be prepared to handle the last two formats listed Note: Clients MUST handle the last two formats listed above to
above to facilitate backward compatibility with the servers which facilitate backward compatibility with the servers which have not
have not been updated to this specification. been 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 an IA_NA/IA_TA options and not as a top-level Status encapsulated in IA_NA/IA_TA options and MUST NOT return a top-level
Code option of NoAddrsAvail when no addresses will be assigned (1 in Status Code option of NoAddrsAvail when no addresses will be assigned
the above list). This means that the Advertise response matches the (1 in the above list). This means that the Advertise response
Reply response with respect to the handling of the NoAddrsAvail matches the Reply response with respect to the handling of the
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.
skipping to change at page 8, line 9 skipping to change at page 8, line 9
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 process an included SOL_MAX_RT option (RFC 7083) and
- MUST process an included INF_MAX_RT option (RFC 7083), and - MUST process an included INF_MAX_RT option (RFC 7083).
- MAY display any associated status message(s) to the user. A client can display any associated status message(s) to the user
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
available addresses advertised in IAs. available addresses advertised in IAs.
With: With:
skipping to change at page 8, line 35 skipping to change at page 8, line 37
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 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), - MUST process an included SOL_MAX_RT option (RFC 7083) and
- MUST process an included INF_MAX_RT option (RFC 7083), and - MUST process an included INF_MAX_RT option (RFC 7083).
- MAY display any associated status message(s) to the user. A client can display any associated status message(s) to the user
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
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.
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 that
the client will send Renew/Rebind messages not later than at the T1/ the client will send Renew/Rebind messages not later than at the T1/
skipping to change at page 10, line 10 skipping to change at page 10, line 15
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 which
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 the [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 the Section 4.4.1, the client includes IA options in a
Renew message for the bindings it desires but has been unable to Renew message for the bindings it desires but has been unable to
obtain by sending a Request message, apart from the IA options for obtain by sending a Request message, apart from the IA 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.
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
skipping to change at page 20, line 39 skipping to change at page 20, line 44
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 A client SHOULD NOT send a Release message for other bindings it may
other bindings it may have received just because it sent a Decline have received just because it sent a Decline message. The client
message. The client SHOULD retain the non-conflicting bindings. The SHOULD retain the non-conflicting bindings. The client SHOULD treat
client SHOULD treat the failure to acquire a binding as a result of the failure to acquire a binding as a result of the conflict, to be
the conflict, to be equivalent to not having received the binding, equivalent to not having received the binding, insofar as it behaves
insofar as it behaves 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
skipping to change at page 22, line 9 skipping to change at page 22, line 11
[RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT [RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT
and INF_MAX_RT", RFC 7083, November 2013. and INF_MAX_RT", RFC 7083, November 2013.
8.2. Informative References 8.2. Informative References
[I-D.dhcwg-dhc-rfc3315bis] [I-D.dhcwg-dhc-rfc3315bis]
Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) bis", draft- Configuration Protocol for IPv6 (DHCPv6) bis", draft-
dhcwg-dhc-rfc3315bis-03 (work in progress), October 2014. dhcwg-dhc-rfc3315bis-04 (work in progress), February 2015.
[I-D.ietf-mif-mpvd-arch] [I-D.ietf-mif-mpvd-arch]
Anipko, D., "Multiple Provisioning Domain Architecture", Anipko, D., "Multiple Provisioning Domain Architecture",
draft-ietf-mif-mpvd-arch-10 (work in progress), February draft-ietf-mif-mpvd-arch-11 (work in progress), March
2015. 2015.
[I-D.ietf-mif-mpvd-dhcp-support] [I-D.ietf-mif-mpvd-dhcp-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", draft-ietf-mif-
mpvd-dhcp-support-00 (work in progress), August 2014. mpvd-dhcp-support-01 (work in progress), 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, 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. 20 change blocks. 
48 lines changed or deleted 51 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/