idnits 2.17.1 draft-carpenter-6renum-static-problem-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 28, 2012) is 4439 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-baker-homenet-prefix-assignment-00 == Outdated reference: A later version (-04) exists of draft-narten-nvo3-overlay-problem-statement-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6RENUM B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational S. Jiang 5 Expires: August 31, 2012 Huawei Technologies Co., Ltd 6 February 28, 2012 8 Problem Statement for Renumbering IPv6 Hosts with Static Addresses 9 draft-carpenter-6renum-static-problem-02 11 Abstract 13 This document analyses the problems of updating the IPv6 addresses of 14 hosts in enterprise networks that for operational reasons require 15 static addresses. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 31, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Static Addresses Imply Static Prefixes . . . . . . . . . . 4 54 2.2. Other Hosts Need Literal Address . . . . . . . . . . . . . 4 55 2.3. Static Server Addresses . . . . . . . . . . . . . . . . . 5 56 2.4. Static Virtual Machine Addresses . . . . . . . . . . . . . 5 57 2.5. Asset Management and Security Tracing . . . . . . . . . . 6 58 2.6. Primitive Software Licensing . . . . . . . . . . . . . . . 6 59 2.7. Network Elements . . . . . . . . . . . . . . . . . . . . . 7 60 2.8. Management Aspects . . . . . . . . . . . . . . . . . . . . 7 61 3. Summary of Problem Statement . . . . . . . . . . . . . . . . . 8 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 65 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 9 66 8. Informative References . . . . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 A problem that is frequently mentioned in discussions of renumbering 72 enterprise networks [RFC5887] [I-D.jiang-6renum-enterprise] 73 [I-D.liu-6renum-gap-analysis] is that of statically assigned 74 addresses. A static address can be defined as an IP address that is 75 intended by the network manager to remain constant over a long period 76 of time, possibly many years, regardless of system restarts or any 77 other unpredictable events. Static addressing often implies manual 78 address assignment, including manual preparation of configuration 79 scripts. An implication of hosts having static addresses is that 80 subnets must have static prefixes, which also requires analysis. 82 Although static addressing is in general problematic for renumbering, 83 hosts inside an enterprise may have static addresses for a number of 84 operational reasons: 86 o For some reason, other hosts need to be configured with a literal 87 numeric address for the host in question, so its address must be 88 static. 89 o Even if a site has local DNS support and this is normally used to 90 locate servers, some operators wish their servers to have static 91 addresses so that issues of address lifetime and DNS TTL cannot 92 affect connectivity. 93 o Some approaches to virtual server farms require static addressing. 94 o On some sites, the network operations staff require hosts to have 95 static addresses for asset management purposes and for address- 96 based backtracking of security incidents. 97 o Certain software licensing mechanisms are based on IP addresses. 98 o Network elements such as routers are usually assigned static 99 addresses, which are also configured into network monitoring and 100 management systems. 102 Static addressing is not the same thing as manual addressing. Static 103 addresses may be configured automatically, for example by stateful 104 DHCPv6. In that case, the database from which the static address is 105 derived may itself have been created automatically in some fashion, 106 or configured manually. If a host's address is configured manually 107 by the host's administrator, it is by definition static. 109 This document analyses these issues in more detail and presents a 110 problem statement. Where obvious alternatives to static addresses 111 exist, they are mentioned. 113 2. Analysis 114 2.1. Static Addresses Imply Static Prefixes 116 Host addresses can only be static if subnet prefixes are also static. 117 Static prefixes are such a long-established practice in enterprise 118 networks that it is hard to discern the reason for them. Originally, 119 before DHCP became available, there was simply no alternative. Thus 120 it became accepted practice to assign subnet prefixes manually and 121 build them into static router configurations. Today, the static 122 nature of subnet prefixes has become a diagnostic tool in itself, at 123 least in the case of IPv4 where prefixes can easily be memorised. If 124 several users sharing a subnet prefix report problems, the fault can 125 readily be localised. 127 This model is being challenged for the case of unmanaged home IPv6 128 networks, in which it is possible to assign subnet prefixes 129 automatically, at least in a cold start scenario 130 [I-D.baker-homenet-prefix-assignment]. For an enterprise network, 131 the question arises whether automatic subnet prefix assignment can be 132 made using the "without a flag day" approach to renumbering. 133 [RFC4192] specifies that "the new prefix is added to the network 134 infrastructure in parallel with (and without interfering with) the 135 old prefix." Any method for automatic prefix assignment needs to 136 support this. 138 2.2. Other Hosts Need Literal Address 140 This issue commonly arises in small networks without local DNS 141 support, for devices such as printers that all other hosts need to 142 reach. In this case, not only does the host in question have a 143 static address, but that address is also configured in the other 144 hosts. It is long established practice in small IPv4 networks that 145 printers in particular are manually assigned a fixed address 146 (typically an [RFC1918] address) and that users are told to manually 147 configure printer access using that fixed address. For a small 148 network the work involved in doing this is much less than the work 149 involved in doing it "properly" by setting up DNS service, whether 150 local or hosted by an ISP, to give the printer a name. It is also 151 unusual to enable the Service Location Protocol [RFC2608] for the 152 same purpose. In consequence, if the printer is renumbered for any 153 reason, the manual configuration of all users' hosts must be updated. 155 In the case of IPv6, exactly the same situation would be created by 156 numbering the printer statically under the site's ULA prefix 157 [RFC4193]. The disadvantage compared to IPv4 is that an IPv6 address 158 is harder to communicate reliably, compared to something as simple as 159 "10.1.1.10". The process will be significantly more error-prone for 160 IPv6. 162 If such a host is numbered out of a prefix that is potentially 163 subject to renumbering, then a renumbering event will require a 164 configuration change in all hosts using the device in question, and 165 the configuration data are by no means stored in the network layer. 167 At least two simple alternatives exist to avoid static numbering of 168 simple devices such as printers by giving them local names. One is 169 the use of Multicast DNS [I-D.cheshire-dnsext-multicastdns] and the 170 other is the Service Location Protocol [RFC2608]. 172 2.3. Static Server Addresses 174 On larger sites, it is safe to assume that servers of all kinds, 175 including printers, are identified in user configurations and 176 applications by DNS names. However, it is very widespread 177 operational practice that servers have static IP addresses. If they 178 did not, whenever an address assigned by stateless address auto- 179 configuration [RFC4862] or DHCPv6 [RFC3315] expired, and if the 180 address actually changed for some extraneous reason, sessions in 181 progress might fail (depending on whether the address deprecation 182 period was long enough). Also, since a dynamic DNS update [RFC3007] 183 would be required, remote users would attempt to use the wrong 184 address until the DNS time-to-live expired. 186 Such server addresses can be managed centrally even if they are 187 static, by using DHCPv6 in stateful mode, and by generating both 188 DHCPv6 data and DNS data from a common configuration database. This 189 does normally carry the implication that the database also contains 190 the hardware (MAC) addresses of the relevant LAN interfaces on the 191 servers, so that the correct IPv6 address can be delivered whenever a 192 server requests an address. Not every operator wishes to maintain 193 such a costly database, however, and some sites are very likely today 194 to fall back on manual configuration of server addresses as a result. 196 In the event of renumbering of the prefix covering such servers, the 197 situation should be manageable if there is a common configuration 198 database; the "without a flag day" procedure [RFC4192] could be 199 followed. However, if there is no such database, a manual procedure 200 would have to be adopted. 202 2.4. Static Virtual Machine Addresses 204 According to [I-D.narten-nvo3-overlay-problem-statement], "Placement 205 and movement of VMs in a network effectively requires that VM IP 206 addresses be fixed and static." Otherwise, when a VM is migrated to 207 a different physical server, its IP address would change and 208 transport sessions in progress would be lost. In effect this is a 209 special case of the previous one. 211 If VMs are numbered out of a prefix that is subject to renumbering, 212 there is a direct conflict with transport session continuity, unless 213 a procedure similar to [RFC4192] is followed. 215 2.5. Asset Management and Security Tracing 217 There are some large (campus-sized) sites that not only capture the 218 MAC addresses of servers in a configuration system, but also do so 219 for desktop client machines with wired connections, that are then 220 given static IP addresses. Such hosts are not normally servers, so 221 the two preceding cases do not apply. One motivation for this 222 approach is straightforward asset management (who has which computer, 223 connected to which cable?). Another, more compelling, reason is 224 security incident handling. If, as occurs with reasonable frequency 225 on any large network, a particular host is found to be generating 226 some form of unwanted traffic, it is urgent to be able to track back 227 from its IP address to its physical location, so that an appropriate 228 intervention can be made. 230 Such users will not in most circumstances be significantly 231 inconvenienced by prefix renumbering, as long as it follows the 232 [RFC4192] procedure. The address deprecation mechanism would allow 233 for clean termination of current sessions, including those in which 234 their machine was actually operating as a server, e.g., for a peer- 235 to-peer application. The only users who would be seriously affected 236 would be those running extremely long transport sessions that might 237 outlive the address deprecation period. 239 Note that such large campus sites generally allocate addresses 240 dynamically to wireless hosts, since (in an IPv4 world) addresses are 241 scarce and allocating static addresses to intermittent users is not 242 acceptable. Also, a wireless user may appear on different subnets at 243 different times, so cannot be given a single static address. These 244 users will in most circumstances only be slightly inconvenienced, if 245 at all, by prefix renumbering. 247 2.6. Primitive Software Licensing 249 Although it has many disadvantages and cannot be recommended as a 250 solution, software licensing based on IP addresses or prefixes is 251 still quite widely used in various forms. It is to be expected that 252 this practice will continue for IPv6. If so, there is no alternative 253 to informing the licensing party of the new address(es) by whatever 254 administrative process is required. In an RFC 4192 renumbering 255 procedure, the licenses for the old and new addresses or prefixes 256 would have to overlap. 258 If acceptable to the licensing mechanism, using addresses under an 259 enterprise's ULA prefix for software licensing would avoid this 260 problem. 262 2.7. Network Elements 264 Each interface of a router needs an IP address, and so do other 265 network elements such as firewalls, proxies, and load balancers. 266 Since these are critical infrastructure, they must be monitored and 267 in some cases controlled by a network management system. A 268 conventional approach to this is to assign the necessary IP addresses 269 statically, and also to configure those addresses in the monitoring 270 and management systems. It is quite common practice that some such 271 addresses will have no corresponding DNS entry. If these addresses 272 need to be changed, there will be considerable ramifications. A 273 restart of the network element might be needed, interrupting all user 274 sessions in progress. Simultaneously, the monitoring and management 275 system configurations must be updated, and in the case of a default 276 router, its clients must be informed. To avoid such disruption, 277 network elements must be renumbered according to an [RFC4192] 278 procedure, like any other host. 280 There is a school of thought that to minimise renumbering problems 281 for network elements and to keep the simplicity of static addressing 282 for them, network elements should all have static ULA addresses for 283 management and monitoring purposes, regardless of what other global 284 addresses they may have. 286 In any case, when network elements are renumbered, existing user 287 sessions may not survive, because of temporary "destination 288 unreachable" conditions being treated as fatal errors. This aspect 289 needs further investigation. 291 2.8. Management Aspects 293 As noted in the Introduction, static addressing and manual address 294 configuration are not the same thing. In terms of managing a 295 renumbering event, static addressing derived automatically from a 296 central database, e.g. by stateful DHCPv6, is clearly better than 297 manual configuration by an administrator. This remains true even if 298 the database itself requires manual changes, since otherwise an 299 administrator would have to log in to every host concerned, a time- 300 consuming and error-prone task. Thus, in cases where static 301 addresses cannot be avoided, they should in any case be assigned 302 automatically from a central database using a suitable protocol, 303 probably stateful DHCPv6. If possible, even static addresses kept in 304 the central database should be assigned automatically. Manual 305 updates of the central database should be kept to a minimum, and 306 manual configuration of individual hosts should be avoided if at all 307 possible. 309 3. Summary of Problem Statement 311 If subnet prefixes are statically assigned, various network elements 312 and the network management system must be informed when they are 313 renumbered. Alternatively, can automatic subnet prefix assignment be 314 performed without interruption to user sessions? 316 If a printer or similar local server is statically addressed out of a 317 non-ULA prefix, and has no DNS, mDNS or SLP name, prefix renumbering 318 will require configuration changes in all hosts using that server. 319 Most likely, these changes will be manual; therefore this situation 320 should be avoided except for very small networks. Even if the server 321 is under a ULA prefix, any subnet rearrangement that causes it to be 322 renumbered will have the same effect. 324 If a server with a DNS name is statically addressed via a common 325 configuration database that supports both DHCPv6 and DNS, then it can 326 be renumbered "without a flag day" by following RFC 4192. However, 327 if there is no common configuration database, then present technology 328 requires manual intervention. Similar considerations apply to 329 virtual servers with static addresses. 331 If client computers such as desktops are statically addressed via a 332 common configuration database and stateful DHCPv6, they can also be 333 renumbered "without a flag day." But other statically addressed 334 clients will need manual intervention, so DHCPv6 should be used if 335 possible. 337 If address-based software licensing is unavoidable, requiring static 338 addresses, and ULAs cannot be used for this case, an administrative 339 procedure during renumbering seems unavoidable. 341 If network elements have static addresses, the network management 342 system and affected client hosts must be informed when they are 343 renumbered. Even if a network element is under a ULA prefix, any 344 subnet rearrangement that causes it to be renumbered will have the 345 same effect. 347 It should be clarified whether automatic network element renumbering 348 can be performed without interrupting user sessions. 350 4. Security Considerations 352 This document defines no protocol, so does not introduce any new 353 security exposures. 355 5. IANA Considerations 357 This document requests no action by IANA. 359 6. Acknowledgements 361 Valuable comments and contributions were made by Brian Haberman, Bing 362 Liu, and other participants in the 6renum WG. 364 This document was produced using the xml2rfc tool [RFC2629]. 366 7. Change log [RFC Editor: Please remove] 368 draft-carpenter-6renum-static-problem-02: more feedback from WG, 369 2012-02-28. 371 draft-carpenter-6renum-static-problem-01: feedback from WG, new text 372 on software licensing, 2011-12-06. 374 draft-carpenter-6renum-static-problem-00: original version, 375 2011-10-18. 377 8. Informative References 379 [I-D.baker-homenet-prefix-assignment] 380 Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small 381 Networks", draft-baker-homenet-prefix-assignment-00 (work 382 in progress), October 2011. 384 [I-D.cheshire-dnsext-multicastdns] 385 Cheshire, S. and M. Krochmal, "Multicast DNS", 386 draft-cheshire-dnsext-multicastdns-15 (work in progress), 387 December 2011. 389 [I-D.jiang-6renum-enterprise] 390 Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 391 Network Renumbering Scenarios and Guidelines", 392 draft-jiang-6renum-enterprise-02 (work in progress), 393 December 2011. 395 [I-D.liu-6renum-gap-analysis] 396 Liu, B., Jiang, S., and B. Carpenter, "IPv6 Site 397 Renumbering Gap Analysis", 398 draft-liu-6renum-gap-analysis-03 (work in progress), 399 December 2011. 401 [I-D.narten-nvo3-overlay-problem-statement] 402 Narten, T., Sridhavan, M., Dutt, D., Black, D., and L. 403 Kreeger, "Problem Statement: Overlays for Network 404 Virtualization", 405 draft-narten-nvo3-overlay-problem-statement-01 (work in 406 progress), October 2011. 408 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 409 E. Lear, "Address Allocation for Private Internets", 410 BCP 5, RFC 1918, February 1996. 412 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 413 "Service Location Protocol, Version 2", RFC 2608, 414 June 1999. 416 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 417 June 1999. 419 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 420 Update", RFC 3007, November 2000. 422 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 423 and M. Carney, "Dynamic Host Configuration Protocol for 424 IPv6 (DHCPv6)", RFC 3315, July 2003. 426 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 427 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 428 September 2005. 430 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 431 Addresses", RFC 4193, October 2005. 433 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 434 Address Autoconfiguration", RFC 4862, September 2007. 436 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 437 Still Needs Work", RFC 5887, May 2010. 439 Authors' Addresses 441 Brian Carpenter 442 Department of Computer Science 443 University of Auckland 444 PB 92019 445 Auckland, 1142 446 New Zealand 448 Email: brian.e.carpenter@gmail.com 450 Sheng Jiang 451 Huawei Technologies Co., Ltd 452 Q14, Huawei Campus 453 No.156 Beiqing Road 454 Hai-Dian District, Beijing 100095 455 P.R. China 457 Email: jiangsheng@huawei.com