idnits 2.17.1 draft-chown-dhc-stateless-dhcpv6-renumbering-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 18, 2003) is 7465 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2462 (ref. '1') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (ref. '2') (Obsoleted by RFC 8415) == Outdated reference: A later version (-04) exists of draft-ietf-dhc-dhcpv6-stateless-01 -- Possible downref: Normative reference to a draft: ref. '4' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Congiguration T. Chown 3 Internet-Draft University of Southampton 4 Expires: May 18, 2004 S. Venaas 5 UNINETT 6 A.K. Vijayabhaskar 7 Hewlett-Packard 8 November 18, 2003 10 Renumbering Requirements for Stateless DHCPv6 11 draft-chown-dhc-stateless-dhcpv6-renumbering-00 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 18, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 IPv6 hosts using Stateless Address Autoconfiguration are able to 42 automatically configure their IPv6 address and default router 43 settings. However, further settings are not available. If such 44 hosts wish to automatically configure their DNS, NTP or other 45 specific settings the stateless variant of the Dynamic Host 46 Configuration Protocol for IPv6 (DHCPv6) could be used. This 47 combination of Stateless Address Autoconfiguration and stateless 48 DHCPv6 could be used quite commonly in IPv6 networks. However, 49 hosts using such a combination currently have no means by which to be 50 informed of changes in stateless DHCPv6 option settings, e.g. the 51 addition of a new NTP server address, changes in DNS search paths, or 52 full site renumbering. This document is presented as a problem 53 statement from which a solution should be proposed in a subsequent 54 document. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Renumbering Scenarios . . . . . . . . . . . . . . . . . . . . 4 61 3.1 Site renumbering . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2 Changes to a DHCPv6-assigned setting . . . . . . . . . . . . . 4 63 4. Renumbering Requirements . . . . . . . . . . . . . . . . . . . 4 64 5. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 5 65 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 Normative References . . . . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 69 Intellectual Property and Copyright Statements . . . . . . . . 7 71 1. Introduction 73 IPv6 hosts using Stateless Address Autoconfiguration [1] are able to 74 automatically configure their IPv6 address and default router 75 settings. While Stateless Address Autoconfiguration for IPv6 allows 76 automatic configuration of these settings, it does not provide a 77 mechanism for additional, non IP-address settings to be automatically 78 configured. 80 The full version of the Dynamic Host Configuration Protocol for IPv6 81 (DHCPv6) [2] is designed to provide both stateful address assignment 82 to IPv6 hosts, as well as additional (non IP-address) configuration 83 including DNS, NTP and other specific settings. A full stateful 84 DHCPv6 server allocates the addresses and maintains the clients 85 bindings to keep track of client leases. 87 If hosts using Stateless Address Autoconfiguration for IPv6 wish to 88 automatically configure their DNS, NTP or other specific settings the 89 stateless variant [3] of DHCPv6 could be used. The stateless variant 90 of DHCPv6 is more lightweight. It does not do address assignment, 91 instead it only provides additional configuration parameters like DNS 92 resolver addresses. It does not maintain state about the information 93 assigned to clients; the additional parameters do not have an 94 explicit life-time associated with them in the same way that IP 95 addresses do, and hence the DHCPv6 server does not need to maintain 96 the state of the clients. 98 This combination of Stateless Address Autoconfiguration and stateless 99 DHCPv6 could be used quite commonly in IPv6 networks. In the 100 absence of an alternative method for DNS, NTP and other options to be 101 automatically configured, it may become the most common combination 102 for statelessly configuring hosts. 104 2. Problem Statement 106 A problem however lies in the ability, or lack of ability, of clients 107 using this combination to be informed of (or to deduce) changes in 108 DHCPv6 assigned settings. 110 While a DHCPv6 server unicasts Reconfigure message to individual 111 clients to trigger the clients to intiate Information-request/reply 112 configuration exchanges to update their configuration settings, the 113 stateless variant of DHCPv6 cannot use the Reconfigure mechanism 114 because it does not maintain a list of IP addresses (leases) to send 115 the unicast messages to. 117 Thus events including the following cannot be handled: 119 o Full site renumbering 121 o DNS server change of address 123 o NTP server change of address 125 o Changes in DNS search paths 127 It would be highly desirable that a host using the combination of 128 Stateless Address Autoconfiguration and stateless DHCPv6 could handle 129 a renumbering or reconfiguration event, whether planned or unplanned 130 by the network administrator. 132 3. Renumbering Scenarios 134 There are two main scenarios for changes to DHCPv6-assigned settings, 135 that would require the client to initiate an Information-request/ 136 reply exchange to update the configuration. 138 3.1 Site renumbering 140 One of the fundamental principles of IPv6 is that sites receive their 141 IPv6 address allocations from an ISP using provider assigned (PA) 142 address space. There is currently no provider independent (PI) 143 address space in IPv6. A site wishing to change ISP must thus 144 renumber its network. Any such site renumbering will require hosts 145 to reconfigure both their own address and default router settings as 146 well as their stateless DHCPv6-assigned settings. 148 3.2 Changes to a DHCPv6-assigned setting 150 An administrator may need to change one or more stateless 151 DHCPv6-assigned settings, e.g. an NTP server, DNS server, or the DNS 152 search path. This may be required if a new, additional DNS server 153 is brought online, is moved to a new network (prefix), or an existing 154 server is decommissioned or known to be unavailable. 156 4. Renumbering Requirements 158 Ideally, any of the above scenarios should be handled automatically 159 by the hosts on the network. For this to be realised, a method is 160 required for the hosts to be informed that they should request new 161 stateless DHCPv6-assigned setting information. 163 The solution to the problem may depend on whether the renumbering or 164 configuration change is a planned or unplanned one, from the 165 perspective of the network administrator. There is already work 166 underway in understanding the planned renumbering [4] scenario for 167 IPv6 networks. However, there is currently no mechanism in 168 stateless DHCPv6 to even handle planned renumbering events. 170 The unplanned renumbering event, which may be more common in smaller, 171 unmanaged networks, is more difficult to cater for. Ideally, any 172 solution for the problem should consider planned and unplanned 173 events. 175 The solution should also be secure, such that additional security 176 concerns are not added to the stateless DHCPv6 networking 177 environment. 179 5. Solution Space 181 Solutions should be designed and presented in a separate document. 182 An initial, brief set of candidate solutions might include: 184 o Adding a Reconfigure message mechanism that would work in the 185 stateless DHCPv6 environment. This could enable planned or 186 unplanned events, but may require a multicast mechanism to be 187 realised. 189 o Conveying a valid lifetime timer to clients for stateless 190 DHCPv6-assigned settings. This could primarily enable planned 191 events, but with a small time-out it could to some extent handle 192 unplanned events at the expense of the additional request traffic. 194 o Using some form of Router Advertisement as a hint to request new 195 stateless DHCPv6-assigned settings. Using only an observed new 196 Router Advertisement prefix as a hint to re-request settings would 197 not handle changes that are purely to NTP, DNS or other options. 199 6. Summary 201 This document presents a problem statement for how IPv6 hosts that 202 use the combination of Stateless Address Autoconfiguration and 203 stateless DHCPv6 may be informed of renumbering events or other 204 changes to the settings that they originally learnt through stateless 205 DHCPv6. A short list of candidate solutions is presented, which the 206 authors hope may be expanded upon in subsequent documents. 208 7. Security Considerations 210 There are no security considerations in this problem statemement per 211 se. However, whatever mechanism is designed or chosen to address this 212 problem should avoid the introduction of new security concerns for 213 (stateless) DHCPv6. 215 Normative References 217 [1] Thomson, S. and T. Narten, "IPv6 Stateless Address 218 Autoconfiguration", RFC 2462, December 1998. 220 [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 221 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 222 RFC 3315, July 2003. 224 [3] Droms, R., "A Guide to Implementing Stateless DHCPv6 Service", 225 draft-ietf-dhc-dhcpv6-stateless-01 (work in progress), October 226 2003. 228 [4] Baker, F., "Procedures for Renumbering an IPv6 Network without a 229 Flag Day", draft-baker-ipv6-renumber-procedure-01 (work in 230 progress), October 2003. 232 Authors' Addresses 234 Tim Chown 235 University of Southampton 236 School of Electronics and Computer Science 237 Southampton, Hampshire SO17 1BJ 238 United Kingdom 240 EMail: tjc@ecs.soton.ac.uk 242 Stig Venaas 243 UNINETT 244 Trondheim NO 7465 245 Norway 247 EMail: venaas@uninett.no 249 Vijayabhaskar A K 250 Hewlett-Packard STSD-I 251 29, Cunningham Road 252 Bangalore 560052 253 India 255 EMail: vijayak@india.hp.com 257 Intellectual Property Statement 259 The IETF takes no position regarding the validity or scope of any 260 intellectual property or other rights that might be claimed to 261 pertain to the implementation or use of the technology described in 262 this document or the extent to which any license under such rights 263 might or might not be available; neither does it represent that it 264 has made any effort to identify any such rights. Information on the 265 IETF's procedures with respect to rights in standards-track and 266 standards-related documentation can be found in BCP-11. Copies of 267 claims of rights made available for publication and any assurances of 268 licenses to be made available, or the result of an attempt made to 269 obtain a general license or permission for the use of such 270 proprietary rights by implementors or users of this specification can 271 be obtained from the IETF Secretariat. 273 The IETF invites any interested party to bring to its attention any 274 copyrights, patents or patent applications, or other proprietary 275 rights which may cover technology that may be required to practice 276 this standard. Please address the information to the IETF Executive 277 Director. 279 Full Copyright Statement 281 Copyright (C) The Internet Society (2003). All Rights Reserved. 283 This document and translations of it may be copied and furnished to 284 others, and derivative works that comment on or otherwise explain it 285 or assist in its implementation may be prepared, copied, published 286 and distributed, in whole or in part, without restriction of any 287 kind, provided that the above copyright notice and this paragraph are 288 included on all such copies and derivative works. However, this 289 document itself may not be modified in any way, such as by removing 290 the copyright notice or references to the Internet Society or other 291 Internet organizations, except as needed for the purpose of 292 developing Internet standards in which case the procedures for 293 copyrights defined in the Internet Standards process must be 294 followed, or as required to translate it into languages other than 295 English. 297 The limited permissions granted above are perpetual and will not be 298 revoked by the Internet Society or its successors or assignees. 300 This document and the information contained herein is provided on an 301 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 302 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 303 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 304 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 305 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 307 Acknowledgment 309 Funding for the RFC Editor function is currently provided by the 310 Internet Society.