idnits 2.17.1 draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 333. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 349), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 4) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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 (October 25, 2004) is 7121 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) ** Obsolete normative reference: RFC 3736 (ref. '3') (Obsoleted by RFC 8415) == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-renumbering-procedure-01 == Outdated reference: A later version (-04) exists of draft-ietf-dna-goals-03 Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Dynamic Host Congiguration T. Chown 2 Internet-Draft University of Southampton 3 Expires: April 25, 2005 S. Venaas 4 UNINETT 5 A. Vijayabhaskar 6 Cisco Systems (India) Private 7 Limited 8 October 25, 2004 10 Renumbering Requirements for Stateless DHCPv6 11 draft-ietf-dhc-stateless-dhcpv6-renumbering-02 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 25, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 IPv6 hosts using Stateless Address Autoconfiguration are able to 45 automatically configure their IPv6 address and default router 46 settings. However, further settings are not available. If such 47 hosts wish to automatically configure their DNS, NTP or other 48 specific settings the stateless variant of the Dynamic Host 49 Configuration Protocol for IPv6 (DHCPv6) could be used. This 50 combination of Stateless Address Autoconfiguration and stateless 51 DHCPv6 could be used quite commonly in IPv6 networks. However, hosts 52 using such a combination currently have no means by which to be 53 informed of changes in stateless DHCPv6 option settings, e.g. the 54 addition of a new NTP server address, a change in DNS search paths, 55 or full site renumbering. This document is presented as a problem 56 statement from which a solution should be proposed in a subsequent 57 document. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Renumbering Scenarios . . . . . . . . . . . . . . . . . . . . 4 64 3.1 Site renumbering . . . . . . . . . . . . . . . . . . . . . 4 65 3.2 Changes to a DHCPv6-assigned setting . . . . . . . . . . . 4 66 4. Renumbering Requirements . . . . . . . . . . . . . . . . . . . 4 67 5. Considerations in choosing a solution . . . . . . . . . . . . 5 68 6. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 5 69 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 6 74 10.2 Informative References . . . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 76 Intellectual Property and Copyright Statements . . . . . . . . 8 78 1. Introduction 80 IPv6 hosts using Stateless Address Autoconfiguration [1] are able to 81 automatically configure their IPv6 address and default router 82 settings. While Stateless Address Autoconfiguration for IPv6 allows 83 automatic configuration of these settings, it does not provide a 84 mechanism for additional, non IP-address settings to be automatically 85 configured. 87 The full version of the Dynamic Host Configuration Protocol for IPv6 88 (DHCPv6) [2] is designed to provide both stateful address assignment 89 to IPv6 hosts, as well as additional (non IP-address) configuration 90 including DNS, NTP and other specific settings. A full stateful 91 DHCPv6 server allocates the addresses and maintains the clients 92 bindings to keep track of client leases. 94 If hosts using Stateless Address Autoconfiguration for IPv6 wish to 95 automatically configure their DNS, NTP or other specific settings the 96 stateless variant [3] of DHCPv6 could be used. The stateless variant 97 of DHCPv6 is more lightweight. It does not do address assignment, 98 instead it only provides additional configuration parameters like DNS 99 resolver addresses. It does not maintain state about the information 100 assigned to clients, hence there is no need to maintain per-client 101 state on the server. In other words, all clients can be given the 102 same information, in the same way that the information in Router 103 Advertisements is not client-specific. 105 This combination of Stateless Address Autoconfiguration and stateless 106 DHCPv6 could be used quite commonly in IPv6 networks. 108 2. Problem Statement 110 A problem however lies in the ability, or lack of ability, of clients 111 using this combination to be informed of (or to deduce) changes in 112 DHCPv6 assigned settings. 114 While a DHCPv6 server unicasts Reconfigure message to individual 115 clients to trigger the clients to intiate Information-request/reply 116 configuration exchanges to update their configuration settings, the 117 stateless variant of DHCPv6 cannot use the Reconfigure mechanism 118 because it does not maintain a list of IP addresses (leases) to send 119 the unicast messages to. Note that in DHCPv6, Reconfigure messages 120 must be unicast; multicast is not allowed. 122 Thus events including the following cannot be handled: 124 o Full site renumbering 125 o DNS server change of address 127 o NTP server change of address 129 o A change in DNS search paths 131 It would be highly desirable that a host using the combination of 132 Stateless Address Autoconfiguration and stateless DHCPv6 could handle 133 a renumbering or reconfiguration event, whether planned or unplanned 134 by the network administrator. 136 Note that the scope of the problem can also be seen to extend beyond 137 Stateless DHCPv6, since only IP address options have a lifetime, i.e. 138 there is no mechanism even in the full DHCPv6 to "expire" old 139 information or otherwise force a client to recheck that new/updated 140 information is available. However, with full DHCPv6, a node may 141 learn of updates to non-address options when renewing its address 142 lease. 144 3. Renumbering Scenarios 146 There are two main scenarios for changes to DHCPv6-assigned settings, 147 that would require the client to initiate an Information-request/ 148 reply exchange to update the configuration. 150 3.1 Site renumbering 152 One of the fundamental principles of IPv6 is that sites receive their 153 IPv6 address allocations from an ISP using provider assigned (PA) 154 address space. There is currently no provider independent (PI) 155 address space in IPv6. A site changing its ISP must thus renumber 156 its network. Any such site renumbering will require hosts to 157 reconfigure both their own address and default router settings as 158 well as their stateless DHCPv6-assigned settings. 160 3.2 Changes to a DHCPv6-assigned setting 162 An administrator may need to change one or more stateless 163 DHCPv6-assigned settings, e.g. an NTP server, DNS server, or the DNS 164 search path. This may be required if a new, additional DNS server is 165 brought online, is moved to a new network (prefix), or an existing 166 server is decommissioned or known to be unavailable. 168 4. Renumbering Requirements 170 Ideally, any of the above scenarios should be handled automatically 171 by the hosts on the network. For this to be realised, a method is 172 required for the hosts to be informed that they should request new 173 stateless DHCPv6-assigned setting information. 175 The solution to the problem may depend on whether the renumbering or 176 configuration change is a planned or unplanned one, from the 177 perspective of the network administrator. There is already work 178 underway in understanding the planned renumbering [4] scenario for 179 IPv6 networks. However, there is currently no mechanism in stateless 180 DHCPv6 to even handle planned renumbering events. 182 5. Considerations in choosing a solution 184 There are a number of considerations that could be listed for a 185 desirable solution: 187 o The solution should support planned renumbering; it is desirable 188 that it also supports unplanned renumbering. 190 o Security is important. No new security concerns should be 191 introduced to Stateless DHCPv6 by the solution. 193 o It must be possible to update options even if the network is not 194 renumbered. 196 o It is desirable to maintain the "stateless" property; i.e., no 197 per-client state should need to be kept in the server. 199 6. Solution Space 201 Solutions should be designed and presented in a separate document. 202 An initial, brief set of candidate solutions might include: 204 o Adding a Reconfigure message mechanism that would work in the 205 stateless DHCPv6 environment. This could enable planned or 206 unplanned events, but may require a multicast mechanism to be 207 realised. 209 o Conveying a valid lifetime timer to clients for stateless 210 DHCPv6-assigned settings. This could primarily enable planned 211 events, but with a small time-out it could to some extent handle 212 unplanned events at the expense of the additional request traffic. 213 The selection of recommended lifetime values/ranges would be the 214 subject of future work. 216 o Using some form of Router Advertisement as a hint to request new 217 stateless DHCPv6-assigned settings. Using only an observed new 218 Router Advertisement prefix as a hint to re-request settings would 219 not handle changes that are purely to NTP, DNS or other options. 221 Other possible means of detection of network (re)attachment could 222 also be used as cues (e.g. see IPv6 DNA Goals [5]). 224 o Changing semantics of the DHCPv6 'O' flag such that toggling its 225 value may trigger an Information-request message. 227 There will also be conditions under which a client should also send 228 an Information-request, such as reconnection to a link. Such 229 specific recommendations are outside the scope of this document but 230 we expect ongoing work in the Detecting Network Attachment (DNA) WG 231 (as scoped in IPv6 DNA Goals [5]) to yield recommendations. 233 7. Summary 235 This document presents a problem statement for how IPv6 hosts that 236 use the combination of Stateless Address Autoconfiguration and 237 stateless DHCPv6 may be informed of renumbering events or other 238 changes to the settings that they originally learnt through stateless 239 DHCPv6. A short list of candidate solutions is presented, which the 240 authors hope may be expanded upon in subsequent documents. 242 8. Security Considerations 244 There are no security considerations in this problem statemement per 245 se. However, whatever mechanism is designed or chosen to address 246 this problem should avoid the introduction of new security concerns 247 for (stateless) DHCPv6. 249 The issues of maintaining appropriate security through a renumbering 250 event are outside the scope of this document (in the case where 251 specific servers within the network are being added or removed, 252 firewall configurations and ACLs, for example, will need to reflect 253 this). However, this is an important area for further work. 255 9. Acknowledgements 257 The authors would like to thank Ralph Droms, Bermie Volz and other 258 individuals on the DHC mail list for their comments on this draft, as 259 well as colleagues on the 6NET project. We also thank the review 260 comments, particularly those from Thomas Narten. 262 10. References 264 10.1 Normative References 266 [1] Thomson, S. and T. Narten, "IPv6 Stateless Address 267 Autoconfiguration", RFC 2462, December 1998. 269 [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 270 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 271 RFC 3315, July 2003. 273 [3] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) 274 Service for IPv6", RFC 3736, April 2004. 276 10.2 Informative References 278 [4] Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering an 279 IPv6 Network without a Flag Day", 280 draft-ietf-v6ops-renumbering-procedure-01 (work in progress), 281 July 2004. 283 [5] Choi, J., "Detecting Network Attachment in IPv6 Goals", 284 draft-ietf-dna-goals-03 (work in progress), October 2004. 286 Authors' Addresses 288 Tim Chown 289 University of Southampton 290 School of Electronics and Computer Science 291 Southampton, Hampshire SO17 1BJ 292 United Kingdom 294 EMail: tjc@ecs.soton.ac.uk 296 Stig Venaas 297 UNINETT 298 Trondheim NO 7465 299 Norway 301 EMail: venaas@uninett.no 303 Vijayabhaskar A Kalusivalingam 304 Cisco Systems (India) Private Limited 305 9, Brunton Road 306 Bangalore 560025 307 India 309 EMail: vibhaska@cisco.com 311 Intellectual Property Statement 313 The IETF takes no position regarding the validity or scope of any 314 Intellectual Property Rights or other rights that might be claimed to 315 pertain to the implementation or use of the technology described in 316 this document or the extent to which any license under such rights 317 might or might not be available; nor does it represent that it has 318 made any independent effort to identify any such rights. Information 319 on the procedures with respect to rights in RFC documents can be 320 found in BCP 78 and BCP 79. 322 Copies of IPR disclosures made to the IETF Secretariat and any 323 assurances of licenses to be made available, or the result of an 324 attempt made to obtain a general license or permission for the use of 325 such proprietary rights by implementers or users of this 326 specification can be obtained from the IETF on-line IPR repository at 327 http://www.ietf.org/ipr. 329 The IETF invites any interested party to bring to its attention any 330 copyrights, patents or patent applications, or other proprietary 331 rights that may cover technology that may be required to implement 332 this standard. Please address the information to the IETF at 333 ietf-ipr@ietf.org. 335 Disclaimer of Validity 337 This document and the information contained herein are provided on an 338 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 339 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 340 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 341 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 342 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 343 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 345 Copyright Statement 347 Copyright (C) The Internet Society (2004). This document is subject 348 to the rights, licenses and restrictions contained in BCP 78, and 349 except as set forth therein, the authors retain all their rights. 351 Acknowledgment 353 Funding for the RFC Editor function is currently provided by the 354 Internet Society.