draft-ietf-dhc-dhcpv6-stateful-issues-03.txt | draft-ietf-dhc-dhcpv6-stateful-issues-04.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 November 5, 2012 | Intended status: Standards Track May 13, 2013 | |||
Expires: May 9, 2013 | Expires: November 14, 2013 | |||
Issues with multiple stateful DHCPv6 options | Issues with multiple stateful DHCPv6 options | |||
draft-ietf-dhc-dhcpv6-stateful-issues-03.txt | draft-ietf-dhc-dhcpv6-stateful-issues-04.txt | |||
Abstract | Abstract | |||
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written | |||
with the expectation that additional stateful DHCPv6 options would be | with the expectation that additional stateful DHCPv6 options would be | |||
developed. IPv6 Prefix Options for Dynamic Host Configuration | developed. IPv6 Prefix Options for Dynamic Host Configuration | |||
Protocol (DHCP) version 6 shoe-horned the new options for Prefix | Protocol (DHCP) version 6 shoe-horned the new options for Prefix | |||
Delegation into DHCPv6. Implementation experience of the CPE model | Delegation into DHCPv6. Implementation experience of the CPE model | |||
described in has shown multiple issues with the DHCPv6 protocol in | described in [RFC6204] has shown multiple issues with the DHCPv6 | |||
supporting multiple stateful options. | protocol in supporting multiple stateful options. | |||
Status of this Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on May 9, 2013. | This Internet-Draft will expire on November 14, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2013 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
4. Handling of multiple IA options types . . . . . . . . . . . . 4 | 4. Handling of multiple IA options types . . . . . . . . . . . . 3 | |||
4.1. Advertisement message . . . . . . . . . . . . . . . . . . 4 | 4.1. Advertisement message . . . . . . . . . . . . . . . . . . 4 | |||
4.2. Placement of Status codes . . . . . . . . . . . . . . . . 5 | 4.2. Placement of Status codes . . . . . . . . . . . . . . . . 5 | |||
4.3. T1/T2 timers . . . . . . . . . . . . . . . . . . . . . . . 6 | 4.3. T1/T2 timers . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4.4. Renew and Rebind messages . . . . . . . . . . . . . . . . 6 | 4.4. Renew and Rebind messages . . . . . . . . . . . . . . . . 6 | |||
4.5. Confirm message . . . . . . . . . . . . . . . . . . . . . 8 | 4.5. Confirm message . . . . . . . . . . . . . . . . . . . . . 7 | |||
4.6. Release messages . . . . . . . . . . . . . . . . . . . . . 9 | 4.6. Release messages . . . . . . . . . . . . . . . . . . . . 8 | |||
4.7. Multiple provisioning domains . . . . . . . . . . . . . . 9 | 4.7. Multiple provisioning domains . . . . . . . . . . . . . . 9 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 | 8.2. Informative References . . . . . . . . . . . . . . . . . 9 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
1. Introduction | 1. Introduction | |||
DHCPv6 [RFC3315] was not written with the expectation that additional | DHCPv6 [RFC3315] was not written with the expectation that additional | |||
stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation | stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation | |||
[RFC3633] shoe-horned the new options for Prefix Delegation into | [RFC3633] shoe-horned the new options for Prefix Delegation into | |||
DHCPv6. Implementation experience of the CPE model described in | DHCPv6. Implementation experience of the CPE model described in | |||
[RFC6204] has shown multiple issues with the DHCPv6 protocol in | [RFC6204] has shown multiple issues with the DHCPv6 protocol in | |||
supporting multiple stateful options. | supporting multiple stateful options. | |||
skipping to change at page 4, line 43 | skipping to change at page 4, line 20 | |||
of them, is not supported in the current protocol specification. | of them, is not supported in the current protocol specification. | |||
Proposed solution: a client SHOULD accept Advertise messages, even | Proposed solution: a client SHOULD accept Advertise messages, even | |||
when not all IA option types are being offered. A client SHOULD | when not all IA option types are being offered. A client SHOULD | |||
ignore an Advertise message when no bindings at all are being | ignore an Advertise message when no bindings at all are being | |||
offered. The client SHOULD include the not offered IA option types | offered. The client SHOULD include the not offered IA option types | |||
in its Request. | in its Request. | |||
Replace Section 17.1.3 of [RFC3315]: (existing errata) | Replace Section 17.1.3 of [RFC3315]: (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: | With: | |||
The client MUST ignore any Advertise message that contains no | The client MUST ignore any Advertise message that contains no | |||
bindings (if only IA_NA and/or IA_TA options were requested, | bindings (if only IA_NA and/or IA_TA options were requested, | |||
this is a message that includes a Status Code option containing the | this is a message that includes a Status Code option containing the | |||
value NoAddrsAvail), with the exception that the client MAY display | value NoAddrsAvail), with the exception that the client MAY display | |||
the associated status message(s) to the user. | the associated status message(s) to the user. | |||
And, replace: | And, replace: | |||
- The client MAY choose a less-preferred server if that server | - The client MAY choose a less-preferred server if that server | |||
has a better set of advertised parameters, such as the | has a better set of advertised parameters, such as the | |||
available addresses advertised in IAs. | available addresses advertised in IAs. | |||
With: | With: | |||
- The client MAY choose a less-preferred server if that server | - The client MAY choose a less-preferred server if that server | |||
has a better set of advertised parameters, such as the | has a better set of advertised parameters, such as the | |||
available options advertised in IAs. | available options advertised in IAs. | |||
It is important to note that the receipt of a Advertisement without | It is important to note that the receipt of a Advertisement without | |||
any bindings does not imply that the client should restart the | any bindings does not imply that the client should restart the | |||
Solicit retransmissions timers. Doing so would lead to a Solicit/ | Solicit retransmissions timers. Doing so would lead to a Solicit/ | |||
Advertisement storm. | Advertisement storm. | |||
4.2. Placement of Status codes | 4.2. Placement of Status codes | |||
In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, | In Reply messages IA specific status codes (i.e., NoAddrsAvail, | |||
NoBinding) are encapsulated in the IA option. In Advertisement | NotOnlink, NoBinding, NoPrefixAvail) are encapsulated in the IA | |||
messages the Status Code option with the NoAddrsAvail code is in the | option. In Advertisement messages the Status Code option with the | |||
"global" scope. That makes sense when the failure case is fatal. | NoAddrsAvail code is in the "global" scope. That makes sense when | |||
With the introduction of multiple IA option types, there might be a | the failure case is fatal. With the introduction of multiple IA | |||
case where a server is not willing to offer addresses, but might be | option types, there might be a case where a server is not willing to | |||
willing to offer other stateful option types. | offer addresses, but might be willing to offer other stateful option | |||
types. | ||||
While a Status Code option is implicitly bound to a specific type of | While a Status Code option is implicitly bound to a specific type of | |||
IA, e.g. NoPrefixAvail is only applicable to IA_PD and NoAddrsAvail | IA, e.g. NoPrefixAvail is only applicable to IA_PD and NoAddrsAvail | |||
is only applicable to IA_NA/IA_TA, it may be problematic to make this | is only applicable to IA_NA/IA_TA, it may be problematic to make this | |||
assumption for all status codes. Ideally the Status Code option | assumption for all status codes. Ideally the Status Code option | |||
should be encapsulated in the IA option for all DHCP messages. This | should be encapsulated in the IA option for all DHCP messages. This | |||
makes Advertisement messages equal to Reply messages. | makes Advertisement messages equal to Reply messages. | |||
Proposed solution: No change. For backwards compatibility, the | Proposed solution: No change. For backwards compatibility, the | |||
NoAddrsAvail Status Code option when no addresses are available will | NoAddrsAvail Status Code option when no addresses are available will | |||
skipping to change at page 6, line 46 | skipping to change at page 6, line 25 | |||
client sent the Request. | client sent the Request. | |||
Proposed solution: The client should continue with the IA options | Proposed solution: The client should continue with the IA options | |||
received, while continuing to include the other IA options in | received, while continuing to include the other IA options in | |||
subsequent messages to the server. The client and server processing | subsequent messages to the server. The client and server processing | |||
need to be modified. Note that this change makes the server's IA | need to be modified. Note that this change makes the server's IA | |||
processing of Renew and Rebind similar to the Request processing. | processing of Renew and Rebind similar to the Request processing. | |||
Replace Section 18.1.3 of [RFC3315]: | Replace Section 18.1.3 of [RFC3315]: | |||
At time T1 for an IA, the client initiates a Renew/Reply message | At time T1 for an IA, the client initiates a Renew/Reply message | |||
exchange to extend the lifetimes on any addresses in the IA. The | exchange to extend the lifetimes on any addresses in the IA. The | |||
client includes an IA option with all addresses currently assigned | client includes an IA option with all addresses currently assigned | |||
to the IA in its Renew message. | to the IA in its Renew message. | |||
With: | With: | |||
At time T1 for an IA, the client initiates a Renew/Reply message | At time T1 for an IA, the client initiates a Renew/Reply message | |||
exchange to extend the lifetimes on any addresses in the IA. The | exchange to extend the lifetimes on any addresses in the IA. The | |||
client includes an IA option with all addresses currently assigned | client includes an IA option with all addresses currently assigned | |||
to the IA in its Renew message. The client also includes an IA | to the IA in its Renew message. The client also includes an IA | |||
option for each binding it desires but has been unable to obtain. | option for each binding it desires but has been unable to obtain. | |||
Replace Section 18.2.3 of [RFC3315]: | Replace Section 18.2.3 of [RFC3315]: | |||
If the server cannot find a client entry for the IA the server | If the server cannot find a client entry for the IA the server | |||
returns the IA containing no addresses with a Status Code option | returns the IA containing no addresses with a Status Code option | |||
set to NoBinding in the Reply message. | set to NoBinding in the Reply message. | |||
With: | With: | |||
If the server cannot find a client entry for the IA the server | If the server cannot find a client entry for the IA the server | |||
creates the bindings for that client according to the server's | creates the bindings for that client according to the server's | |||
policy and configuration information and records the IAs and | policy and configuration information and records the IAs and | |||
other information requested by the client. | other information requested by the client. | |||
Note that clients that communicate with servers that do not support | Note that clients that communicate with servers that do not support | |||
this updated Renew processing will receive the NoBinding status for | this updated Renew processing will receive the NoBinding status for | |||
the IA which had no bindings. The client MUST continue to process | the IA which had no bindings. The client MUST continue to process | |||
the other IAs in the Reply. The client MAY attempt a Solicit/ | the other IAs in the Reply. The client MAY attempt a Solicit/ | |||
Advertise/Request/Reply sequence periodically to obtain bindings for | Advertise/Request/Reply sequence periodically to obtain bindings for | |||
these IAs. However, it MUST limit the frequency at which is does | these IAs. However, it MUST limit the frequency at which is does | |||
this to no more often than the renewal frequency. | this to no more often than the renewal frequency. | |||
Replace Section 18.1.4 of [RFC3315]: | Replace Section 18.1.4 of [RFC3315]: | |||
At time T2 for an IA (which will only be reached if the server to | At time T2 for an IA (which will only be reached if the server to | |||
which the Renew message was sent at time T1 has not responded), the | which the Renew message was sent at time T1 has not responded), the | |||
client initiates a Rebind/Reply message exchange with any available | client initiates a Rebind/Reply message exchange with any available | |||
server. The client includes an IA option with all addresses | server. The client includes an IA option with all addresses | |||
currently assigned to the IA in its Rebind message. | currently assigned to the IA in its Rebind message. | |||
With: | With: | |||
At time T2 for an IA (which will only be reached if the server to | At time T2 for an IA (which will only be reached if the server to | |||
which the Renew message was sent at time T1 has not responded), the | which the Renew message was sent at time T1 has not responded), the | |||
client initiates a Rebind/Reply message exchange with any available | client initiates a Rebind/Reply message exchange with any available | |||
server. The client includes an IA option with all addresses | server. The client includes an IA option with all addresses | |||
currently assigned to the IA in its Rebind message. The client | currently assigned to the IA in its Rebind message. The client | |||
also includes an IA option for each binding it desires but has been | also includes an IA option for each binding it desires but has been | |||
unable to obtain. | unable to obtain. | |||
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 lets a server without a binding to reply to | address assignment. It allows a server without a binding 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 is lower processing cost as the server does NOT need | |||
skipping to change at page 9, line 9 | skipping to change at page 8, line 43 | |||
associated with those IA_PDs in its Confirm message. | associated with those IA_PDs in its Confirm message. | |||
... | ... | |||
The Decline message type is not used with Prefix Delegation. | The Decline message type is not used with Prefix Delegation. | |||
4.6. Release messages | 4.6. Release messages | |||
A client can release any individual lease at any time. A client can | A client can release any individual lease at any time. A client can | |||
get "back" a lease by using a Renew message. It MAY do this at any | get "back" a lease by using a Renew message. It MAY do this at any | |||
time, though must avoid creating a Renew storm. E.g. wait until T1. | time, though must avoid creating a Renew storm. E.g. wait until T1. | |||
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 10, line 12 | skipping to change at page 10, line 4 | |||
Host Configuration Protocol (DHCP) version 6", RFC 3633, | Host Configuration Protocol (DHCP) version 6", RFC 3633, | |||
December 2003. | December 2003. | |||
8.2. Informative References | 8.2. Informative References | |||
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. | [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. | |||
Troan, "Basic Requirements for IPv6 Customer Edge | Troan, "Basic Requirements for IPv6 Customer Edge | |||
Routers", RFC 6204, April 2011. | Routers", RFC 6204, April 2011. | |||
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 | USA | |||
Email: volz@cisco.com | Email: volz@cisco.com | |||
End of changes. 23 change blocks. | ||||
81 lines changed or deleted | 81 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |