draft-ietf-dhc-stateless-dhcpv6-renumbering-00.txt | draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt | |||
---|---|---|---|---|
Dynamic Host Congiguration T. Chown | Dynamic Host Congiguration T. Chown | |||
Internet-Draft University of Southampton | Internet-Draft University of Southampton | |||
Expires: September 6, 2004 S. Venaas | Expires: August 30, 2004 S. Venaas | |||
UNINETT | UNINETT | |||
A. Vijayabhaskar | A. Vijayabhaskar | |||
Hewlett-Packard STSD-I | Hewlett-Packard STSD-I | |||
March 8, 2004 | March 2004 | |||
Renumbering Requirements for Stateless DHCPv6 | Renumbering Requirements for Stateless DHCPv6 | |||
draft-ietf-dhc-stateless-dhcpv6-renumbering-00 | draft-ietf-dhc-stateless-dhcpv6-renumbering-01 | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | By submitting this Internet-Draft, I certify that any applicable | |||
all provisions of Section 10 of RFC2026. | patent or other IPR claims of which I am aware have been disclosed, | |||
and any of which I become aware will be disclosed, in accordance with | ||||
RFC 3668. | ||||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that other | Task Force (IETF), its areas, and its working groups. Note that | |||
groups may also distribute working documents as Internet-Drafts. | other groups may also distribute working documents as | |||
Internet-Drafts. | ||||
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." | |||
The list of current Internet-Drafts can be accessed at http:// | The list of current Internet-Drafts can be accessed at | |||
www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on September 6, 2004. | This Internet-Draft will expire on August 30, 2004. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2004). All Rights Reserved. | Copyright (C) The Internet Society (2004). All Rights Reserved. | |||
Abstract | Abstract | |||
IPv6 hosts using Stateless Address Autoconfiguration are able to | IPv6 hosts using Stateless Address Autoconfiguration are able to | |||
automatically configure their IPv6 address and default router | automatically configure their IPv6 address and default router | |||
settings. However, further settings are not available. If such | settings. However, further settings are not available. If such | |||
hosts wish to automatically configure their DNS, NTP or other | hosts wish to automatically configure their DNS, NTP or other | |||
specific settings the stateless variant of the Dynamic Host | specific settings the stateless variant of the Dynamic Host | |||
Configuration Protocol for IPv6 (DHCPv6) could be used. This | Configuration Protocol for IPv6 (DHCPv6) could be used. This | |||
combination of Stateless Address Autoconfiguration and stateless | combination of Stateless Address Autoconfiguration and stateless | |||
DHCPv6 could be used quite commonly in IPv6 networks. However, | DHCPv6 could be used quite commonly in IPv6 networks. However, hosts | |||
hosts using such a combination currently have no means by which to be | using such a combination currently have no means by which to be | |||
informed of changes in stateless DHCPv6 option settings, e.g. the | informed of changes in stateless DHCPv6 option settings, e.g. the | |||
addition of a new NTP server address, changes in DNS search paths, or | addition of a new NTP server address, changes in DNS search paths, or | |||
full site renumbering. This document is presented as a problem | full site renumbering. This document is presented as a problem | |||
statement from which a solution should be proposed in a subsequent | statement from which a solution should be proposed in a subsequent | |||
document. | document. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Renumbering Scenarios . . . . . . . . . . . . . . . . . . . . 4 | 3. Renumbering Scenarios . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1 Site renumbering . . . . . . . . . . . . . . . . . . . . . . . 4 | 3.1 Site renumbering . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.2 Changes to a DHCPv6-assigned setting . . . . . . . . . . . . . 4 | 3.2 Changes to a DHCPv6-assigned setting . . . . . . . . . . . 4 | |||
4. Renumbering Requirements . . . . . . . . . . . . . . . . . . . 4 | 4. Renumbering Requirements . . . . . . . . . . . . . . . . . . . 4 | |||
5. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 5 | 5. Considerations in choosing a solution . . . . . . . . . . . . 5 | |||
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 6. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
Normative References . . . . . . . . . . . . . . . . . . . . . 6 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
Intellectual Property and Copyright Statements . . . . . . . . 7 | 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 | ||||
Intellectual Property and Copyright Statements . . . . . . . . 8 | ||||
1. Introduction | 1. Introduction | |||
IPv6 hosts using Stateless Address Autoconfiguration [1] are able to | IPv6 hosts using Stateless Address Autoconfiguration [1] are able to | |||
automatically configure their IPv6 address and default router | automatically configure their IPv6 address and default router | |||
settings. While Stateless Address Autoconfiguration for IPv6 allows | settings. While Stateless Address Autoconfiguration for IPv6 allows | |||
automatic configuration of these settings, it does not provide a | automatic configuration of these settings, it does not provide a | |||
mechanism for additional, non IP-address settings to be automatically | mechanism for additional, non IP-address settings to be automatically | |||
configured. | configured. | |||
skipping to change at page 3, line 33 | skipping to change at page 3, line 33 | |||
stateless variant [3] of DHCPv6 could be used. The stateless variant | stateless variant [3] of DHCPv6 could be used. The stateless variant | |||
of DHCPv6 is more lightweight. It does not do address assignment, | of DHCPv6 is more lightweight. It does not do address assignment, | |||
instead it only provides additional configuration parameters like DNS | instead it only provides additional configuration parameters like DNS | |||
resolver addresses. It does not maintain state about the information | resolver addresses. It does not maintain state about the information | |||
assigned to clients; the additional parameters do not have an | assigned to clients; the additional parameters do not have an | |||
explicit life-time associated with them in the same way that IP | explicit life-time associated with them in the same way that IP | |||
addresses do, and hence the DHCPv6 server does not need to maintain | addresses do, and hence the DHCPv6 server does not need to maintain | |||
the state of the clients. | the state of the clients. | |||
This combination of Stateless Address Autoconfiguration and stateless | This combination of Stateless Address Autoconfiguration and stateless | |||
DHCPv6 could be used quite commonly in IPv6 networks. In the | DHCPv6 could be used quite commonly in IPv6 networks. In the absence | |||
absence of an alternative method for DNS, NTP and other options to be | of an alternative method for DNS, NTP and other options to be | |||
automatically configured, it may become the most common combination | automatically configured, it may become the most common combination | |||
for statelessly configuring hosts. | for statelessly configuring hosts. | |||
2. Problem Statement | 2. Problem Statement | |||
A problem however lies in the ability, or lack of ability, of clients | A problem however lies in the ability, or lack of ability, of clients | |||
using this combination to be informed of (or to deduce) changes in | using this combination to be informed of (or to deduce) changes in | |||
DHCPv6 assigned settings. | DHCPv6 assigned settings. | |||
While a DHCPv6 server unicasts Reconfigure message to individual | While a DHCPv6 server unicasts Reconfigure message to individual | |||
skipping to change at page 4, line 38 | skipping to change at page 4, line 38 | |||
address space. There is currently no provider independent (PI) | address space. There is currently no provider independent (PI) | |||
address space in IPv6. A site wishing to change ISP must thus | address space in IPv6. A site wishing to change ISP must thus | |||
renumber its network. Any such site renumbering will require hosts | renumber its network. Any such site renumbering will require hosts | |||
to reconfigure both their own address and default router settings as | to reconfigure both their own address and default router settings as | |||
well as their stateless DHCPv6-assigned settings. | well as their stateless DHCPv6-assigned settings. | |||
3.2 Changes to a DHCPv6-assigned setting | 3.2 Changes to a DHCPv6-assigned setting | |||
An administrator may need to change one or more stateless | An administrator may need to change one or more stateless | |||
DHCPv6-assigned settings, e.g. an NTP server, DNS server, or the DNS | DHCPv6-assigned settings, e.g. an NTP server, DNS server, or the DNS | |||
search path. This may be required if a new, additional DNS server | search path. This may be required if a new, additional DNS server is | |||
is brought online, is moved to a new network (prefix), or an existing | brought online, is moved to a new network (prefix), or an existing | |||
server is decommissioned or known to be unavailable. | server is decommissioned or known to be unavailable. | |||
4. Renumbering Requirements | 4. Renumbering Requirements | |||
Ideally, any of the above scenarios should be handled automatically | Ideally, any of the above scenarios should be handled automatically | |||
by the hosts on the network. For this to be realised, a method is | by the hosts on the network. For this to be realised, a method is | |||
required for the hosts to be informed that they should request new | required for the hosts to be informed that they should request new | |||
stateless DHCPv6-assigned setting information. | stateless DHCPv6-assigned setting information. | |||
The solution to the problem may depend on whether the renumbering or | The solution to the problem may depend on whether the renumbering or | |||
configuration change is a planned or unplanned one, from the | configuration change is a planned or unplanned one, from the | |||
perspective of the network administrator. There is already work | perspective of the network administrator. There is already work | |||
underway in understanding the planned renumbering [4] scenario for | underway in understanding the planned renumbering [4] scenario for | |||
IPv6 networks. However, there is currently no mechanism in | IPv6 networks. However, there is currently no mechanism in stateless | |||
stateless DHCPv6 to even handle planned renumbering events. | DHCPv6 to even handle planned renumbering events. | |||
The unplanned renumbering event, which may be more common in smaller, | The unplanned renumbering event, which may be more common in smaller, | |||
unmanaged networks, is more difficult to cater for. Ideally, any | unmanaged networks, is more difficult to cater for. Ideally, any | |||
solution for the problem should consider planned and unplanned | solution for the problem should consider planned and unplanned | |||
events. | events. | |||
The solution should also be secure, such that additional security | The solution should also be secure, such that additional security | |||
concerns are not added to the stateless DHCPv6 networking | concerns are not added to the stateless DHCPv6 networking | |||
environment. | environment. | |||
5. Solution Space | 5. Considerations in choosing a solution | |||
There are a number of considerations that could be listed for a | ||||
desirable solution: | ||||
o It should support planned renumbering; it is desirable to support | ||||
unplanned renumbering. | ||||
o Security is important; e.g., avoiding denialof service attacks | ||||
mounted through Reconfigure messages sent from an attacker. | ||||
o It must be possible to update options even if the network is not | ||||
renumbered. | ||||
o It is desirable to maintain the "stateless" property; i.e., no | ||||
per-client state should need to be kept in the server. | ||||
6. Solution Space | ||||
Solutions should be designed and presented in a separate document. | Solutions should be designed and presented in a separate document. | |||
An initial, brief set of candidate solutions might include: | An initial, brief set of candidate solutions might include: | |||
o Adding a Reconfigure message mechanism that would work in the | o Adding a Reconfigure message mechanism that would work in the | |||
stateless DHCPv6 environment. This could enable planned or | stateless DHCPv6 environment. This could enable planned or | |||
unplanned events, but may require a multicast mechanism to be | unplanned events, but may require a multicast mechanism to be | |||
realised. | realised. | |||
o Conveying a valid lifetime timer to clients for stateless | o Conveying a valid lifetime timer to clients for stateless | |||
DHCPv6-assigned settings. This could primarily enable planned | DHCPv6-assigned settings. This could primarily enable planned | |||
events, but with a small time-out it could to some extent handle | events, but with a small time-out it could to some extent handle | |||
unplanned events at the expense of the additional request traffic. | unplanned events at the expense of the additional request traffic. | |||
o Using some form of Router Advertisement as a hint to request new | o Using some form of Router Advertisement as a hint to request new | |||
stateless DHCPv6-assigned settings. Using only an observed new | stateless DHCPv6-assigned settings. Using only an observed new | |||
Router Advertisement prefix as a hint to re-request settings would | Router Advertisement prefix as a hint to re-request settings would | |||
not handle changes that are purely to NTP, DNS or other options. | not handle changes that are purely to NTP, DNS or other options. | |||
Other possible means of detection of network (re)attachment could | ||||
also be used as cues (e.g. see IPv6 DNA Goals [5]). | ||||
6. Summary | o Changing semantics of the DHCPv6 'O' flag such that toggling its | |||
value may trigger an Information-request message. | ||||
7. Summary | ||||
This document presents a problem statement for how IPv6 hosts that | This document presents a problem statement for how IPv6 hosts that | |||
use the combination of Stateless Address Autoconfiguration and | use the combination of Stateless Address Autoconfiguration and | |||
stateless DHCPv6 may be informed of renumbering events or other | stateless DHCPv6 may be informed of renumbering events or other | |||
changes to the settings that they originally learnt through stateless | changes to the settings that they originally learnt through stateless | |||
DHCPv6. A short list of candidate solutions is presented, which the | DHCPv6. A short list of candidate solutions is presented, which the | |||
authors hope may be expanded upon in subsequent documents. | authors hope may be expanded upon in subsequent documents. | |||
7. Security Considerations | 8. Security Considerations | |||
There are no security considerations in this problem statemement per | There are no security considerations in this problem statemement per | |||
se. However, whatever mechanism is designed or chosen to address this | se. However, whatever mechanism is designed or chosen to address | |||
problem should avoid the introduction of new security concerns for | this problem should avoid the introduction of new security concerns | |||
(stateless) DHCPv6. | for (stateless) DHCPv6. | |||
Normative References | 9. Acknowledgements | |||
The authors would like to thank Ralph Droms and Bermie Volz for their | ||||
comments on this draft. | ||||
10 Normative References | ||||
[1] Thomson, S. and T. Narten, "IPv6 Stateless Address | [1] Thomson, S. and T. Narten, "IPv6 Stateless Address | |||
Autoconfiguration", RFC 2462, December 1998. | Autoconfiguration", RFC 2462, December 1998. | |||
[2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. | [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. | |||
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", | Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", | |||
RFC 3315, July 2003. | RFC 3315, July 2003. | |||
[3] Droms, R., "A Guide to Implementing Stateless DHCPv6 Service", | [3] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) | |||
draft-ietf-dhc-dhcpv6-stateless-01 (work in progress), October | Service for IPv6", RFC 3736, April 2004. | |||
2003. | ||||
[4] Baker, F., "Procedures for Renumbering an IPv6 Network without a | [4] Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering an | |||
Flag Day", draft-baker-ipv6-renumber-procedure-01 (work in | IPv6 Network without a Flag Day", | |||
progress), October 2003. | draft-baker-ipv6-renumber-procedure-01 (work in progress), | |||
October 2003. | ||||
[5] Choi, J., "Detecting Network Attachment in IPv6 Goals", | ||||
draft-ietf-dna-goals-00 (work in progress), June 2004. | ||||
Authors' Addresses | Authors' Addresses | |||
Tim Chown | Tim Chown | |||
University of Southampton | University of Southampton | |||
School of Electronics and Computer Science | School of Electronics and Computer Science | |||
Southampton, Hampshire SO17 1BJ | Southampton, Hampshire SO17 1BJ | |||
United Kingdom | United Kingdom | |||
EMail: tjc@ecs.soton.ac.uk | EMail: tjc@ecs.soton.ac.uk | |||
skipping to change at page 7, line 8 | skipping to change at page 8, line 8 | |||
Hewlett-Packard STSD-I | Hewlett-Packard STSD-I | |||
29, Cunningham Road | 29, Cunningham Road | |||
Bangalore 560052 | Bangalore 560052 | |||
India | India | |||
EMail: vijayak@india.hp.com | EMail: vijayak@india.hp.com | |||
Intellectual Property Statement | Intellectual Property Statement | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
intellectual property or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; neither does it represent that it | might or might not be available; nor does it represent that it has | |||
has made any effort to identify any such rights. Information on the | made any independent effort to identify any such rights. Information | |||
IETF's procedures with respect to rights in standards-track and | on the procedures with respect to rights in RFC documents can be | |||
standards-related documentation can be found in BCP-11. Copies of | found in BCP 78 and BCP 79. | |||
claims of rights made available for publication and any assurances of | ||||
licenses to be made available, or the result of an attempt made to | Copies of IPR disclosures made to the IETF Secretariat and any | |||
obtain a general license or permission for the use of such | assurances of licenses to be made available, or the result of an | |||
proprietary rights by implementors or users of this specification can | attempt made to obtain a general license or permission for the use of | |||
be obtained from the IETF Secretariat. | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | ||||
http://www.ietf.org/ipr. | ||||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights which may cover technology that may be required to practice | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF Executive | this standard. Please address the information to the IETF at | |||
Director. | ietf-ipr@ietf.org. | |||
Full Copyright Statement | ||||
Copyright (C) The Internet Society (2004). All Rights Reserved. | Disclaimer of Validity | |||
This document and translations of it may be copied and furnished to | This document and the information contained herein are provided on an | |||
others, and derivative works that comment on or otherwise explain it | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
or assist in its implementation may be prepared, copied, published | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |||
and distributed, in whole or in part, without restriction of any | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |||
kind, provided that the above copyright notice and this paragraph are | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |||
included on all such copies and derivative works. However, this | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |||
document itself may not be modified in any way, such as by removing | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
the copyright notice or references to the Internet Society or other | ||||
Internet organizations, except as needed for the purpose of | ||||
developing Internet standards in which case the procedures for | ||||
copyrights defined in the Internet Standards process must be | ||||
followed, or as required to translate it into languages other than | ||||
English. | ||||
The limited permissions granted above are perpetual and will not be | Copyright Statement | |||
revoked by the Internet Society or its successors or assignees. | ||||
This document and the information contained herein is provided on an | Copyright (C) The Internet Society (2004). This document is subject | |||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | to the rights, licenses and restrictions contained in BCP 78, and | |||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | except as set forth therein, the authors retain all their rights. | |||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | ||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | ||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Acknowledgment | Acknowledgment | |||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
Internet Society. | Internet Society. | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |