idnits 2.17.1 draft-ietf-6renum-static-problem-01.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 (August 31, 2012) is 4255 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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 (~~), 1 warning (==), 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: March 4, 2013 Huawei Technologies Co., Ltd 6 August 31, 2012 8 Problem Statement for Renumbering IPv6 Hosts with Static Addresses 9 draft-ietf-6renum-static-problem-01 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 March 4, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . 6 57 2.5. Asset Management and Security Tracing . . . . . . . . . . 6 58 2.6. Primitive Software Licensing . . . . . . . . . . . . . . . 7 59 2.7. Network Elements . . . . . . . . . . . . . . . . . . . . . 7 60 2.8. Management Aspects . . . . . . . . . . . . . . . . . . . . 7 61 3. Summary of Problem Statement . . . . . . . . . . . . . . . . . 8 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 65 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 10 66 8. Informative References . . . . . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 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 In a sense, the issue of static addresses is a result of history. As 83 discussed in Section 3.2 of [RFC6250], various properties of IP 84 addresses that have long been assumed by programmers and operators 85 are no longer true today, although they were true when almost all 86 addresses were manually assigned. In some cases, the resulting 87 operational difficulties are avoided by static addressing. 89 Although static addressing is in general problematic for renumbering, 90 hosts inside an enterprise may have static addresses for a number of 91 operational reasons: 93 o For some reason, other hosts need to be configured with a literal 94 numeric address for the host in question, so its address must be 95 static. 96 o Even if a site has local DNS support and this is normally used to 97 locate servers, some operators wish their servers to have static 98 addresses so that issues of address lifetime and DNS TTL cannot 99 affect connectivity. 100 o Some approaches to virtual server farms require static addressing. 101 o On some sites, the network operations staff require hosts to have 102 static addresses for asset management purposes and for address- 103 based backtracking of security incidents. 104 o Certain software licensing mechanisms are based on IP addresses. 105 o Network elements such as routers are usually assigned static 106 addresses, which are also configured into network monitoring and 107 management systems. 109 Static addressing is not the same thing as manual addressing. Static 110 addresses may be configured automatically, for example by stateful 111 DHCPv6. In that case, the database from which the static address is 112 derived may itself have been created automatically in some fashion, 113 or configured manually. If a host's address is configured manually 114 by the host's administrator, it is by definition static. 116 This document analyses these issues in more detail and presents a 117 problem statement. Where obvious alternatives to static addresses 118 exist, they are mentioned. 120 2. Analysis 122 2.1. Static Addresses Imply Static Prefixes 124 Host addresses can only be static if subnet prefixes are also static. 125 Static prefixes are such a long-established practice in enterprise 126 networks that it is hard to discern the reason for them. Originally, 127 before DHCP became available, there was simply no alternative. Thus 128 it became accepted practice to assign subnet prefixes manually and 129 build them into static router configurations. Today, the static 130 nature of subnet prefixes has become a diagnostic tool in itself, at 131 least in the case of IPv4 where prefixes can easily be memorised. If 132 several users sharing a subnet prefix report problems, the fault can 133 readily be localised. 135 This model is being challenged for the case of unmanaged home IPv6 136 networks, in which it is possible to assign subnet prefixes 137 automatically, at least in a cold start scenario 138 [I-D.baker-homenet-prefix-assignment]. For an enterprise network, 139 the question arises whether automatic subnet prefix assignment can be 140 made using the "without a flag day" approach to renumbering. 141 [RFC4192] specifies that "the new prefix is added to the network 142 infrastructure in parallel with (and without interfering with) the 143 old prefix." Any method for automatic prefix assignment needs to 144 support this. 146 2.2. Other Hosts Need Literal Address 148 This issue commonly arises in small networks without local DNS 149 support, for devices such as printers that all other hosts need to 150 reach. In this case, not only does the host in question have a 151 static address, but that address is also configured in the other 152 hosts. It is long established practice in small IPv4 networks that 153 printers in particular are manually assigned a fixed address 154 (typically an [RFC1918] address) and that users are told to manually 155 configure printer access using that fixed address. For a small 156 network the work involved in doing this is much less than the work 157 involved in doing it "properly" by setting up DNS service, whether 158 local or hosted by an ISP, to give the printer a name. It is also 159 unusual to enable the Service Location Protocol [RFC2608] for the 160 same purpose. In consequence, if the printer is renumbered for any 161 reason, the manual configuration of all users' hosts must be updated. 163 In the case of IPv6, exactly the same situation would be created by 164 numbering the printer statically under the site's ULA prefix 165 [RFC4193]. The disadvantage compared to IPv4 is that an IPv6 address 166 is harder to communicate reliably, compared to something as simple as 167 "10.1.1.10". The process will be significantly more error-prone for 168 IPv6. 170 If such a host is numbered out of a prefix that is potentially 171 subject to renumbering, then a renumbering event will require a 172 configuration change in all hosts using the device in question, and 173 the configuration data are by no means stored in the network layer. 175 At least two simple alternatives exist to avoid static numbering of 176 simple devices such as printers by giving them local names. One is 177 the use of Multicast DNS [I-D.cheshire-dnsext-multicastdns] and the 178 other is the Service Location Protocol [RFC2608]. 180 2.3. Static Server Addresses 182 On larger sites, it is safe to assume that servers of all kinds, 183 including printers, are identified in user configurations and 184 applications by DNS names. However, it is very widespread 185 operational practice that servers have static IP addresses. If they 186 did not, whenever an address assigned by stateless address auto- 187 configuration [RFC4862] or DHCPv6 [RFC3315] expired, and if the 188 address actually changed for some extraneous reason, sessions in 189 progress might fail (depending on whether the address deprecation 190 period was long enough). Also, since a dynamic DNS update [RFC3007] 191 would be required, remote users would attempt to use the wrong 192 address until the DNS time-to-live expired. 194 Such server addresses can be managed centrally even if they are 195 static, by using DHCPv6 in stateful mode, and by generating both 196 DHCPv6 data and DNS data from a common configuration database. This 197 does normally carry the implication that the database also contains 198 the hardware (MAC) addresses of the relevant LAN interfaces on the 199 servers, so that the correct IPv6 address can be delivered whenever a 200 server requests an address. Not every operator wishes to maintain 201 such a costly database, however, and some sites are very likely today 202 to fall back on manual configuration of server addresses as a result. 204 In the event of renumbering of the prefix covering such servers, the 205 situation should be manageable if there is a common configuration 206 database; the "without a flag day" procedure [RFC4192] could be 207 followed. However, if there is no such database, a manual procedure 208 would have to be adopted. 210 2.4. Static Virtual Machine Addresses 212 According to [I-D.narten-nvo3-overlay-problem-statement], the 213 placement and movement of virtual machines (VMs) in a physical 214 network effectively requires that their IP addresses are fixed and 215 static. Otherwise, when a VM is migrated to a different physical 216 server, its IP address would change and transport sessions in 217 progress would be lost. In effect this is a special case of the 218 previous one. 220 If VMs are numbered out of a prefix that is subject to renumbering, 221 there is a direct conflict with transport session continuity, unless 222 a procedure similar to [RFC4192] is followed. 224 2.5. Asset Management and Security Tracing 226 There are some large (campus-sized) sites that not only capture the 227 MAC addresses of servers in a configuration system, but also do so 228 for desktop client machines with wired connections, that are then 229 given static IP addresses. Such hosts are not normally servers, so 230 the two preceding cases do not apply. One motivation for this 231 approach is straightforward asset management (who has which computer, 232 connected to which cable?). Another, more compelling, reason is 233 security incident handling. If, as occurs with reasonable frequency 234 on any large network, a particular host is found to be generating 235 some form of unwanted traffic, it is urgent to be able to track back 236 from its IP address to its physical location, so that an appropriate 237 intervention can be made. 239 Such users will not in most circumstances be significantly 240 inconvenienced by prefix renumbering, as long as it follows the 241 [RFC4192] procedure. The address deprecation mechanism would allow 242 for clean termination of current sessions, including those in which 243 their machine was actually operating as a server, e.g., for a peer- 244 to-peer application. The only users who would be seriously affected 245 would be those running extremely long transport sessions that might 246 outlive the address deprecation period. 248 Note that such large campus sites generally allocate addresses 249 dynamically to wireless hosts, since (in an IPv4 world) addresses are 250 scarce and allocating static addresses to intermittent users is not 251 acceptable. Also, a wireless user may appear on different subnets at 252 different times, so cannot be given a single static address. These 253 users will in most circumstances only be slightly inconvenienced, if 254 at all, by prefix renumbering. 256 2.6. Primitive Software Licensing 258 Although it has many disadvantages and cannot be recommended as a 259 solution, software licensing based on IP addresses or prefixes is 260 still quite widely used in various forms. It is to be expected that 261 this practice will continue for IPv6. If so, there is no alternative 262 to informing the licensing party of the new address(es) by whatever 263 administrative process is required. In an RFC 4192 renumbering 264 procedure, the licenses for the old and new addresses or prefixes 265 would have to overlap. 267 If acceptable to the licensing mechanism, using addresses under an 268 enterprise's ULA prefix for software licensing would avoid this 269 problem. 271 2.7. Network Elements 273 Each interface of a router needs an IP address, and so do other 274 network elements such as firewalls, proxies, and load balancers. 275 Since these are critical infrastructure, they must be monitored and 276 in some cases controlled by a network management system. A 277 conventional approach to this is to assign the necessary IP addresses 278 statically, and also to configure those addresses in the monitoring 279 and management systems. It is quite common practice that some such 280 addresses will have no corresponding DNS entry. If these addresses 281 need to be changed, there will be considerable ramifications. A 282 restart of the network element might be needed, interrupting all user 283 sessions in progress. Simultaneously, the monitoring and management 284 system configurations must be updated, and in the case of a default 285 router, its clients must be informed. To avoid such disruption, 286 network elements must be renumbered according to an [RFC4192] 287 procedure, like any other host. 289 There is a school of thought that to minimise renumbering problems 290 for network elements and to keep the simplicity of static addressing 291 for them, network elements should all have static ULA addresses for 292 management and monitoring purposes, regardless of what other global 293 addresses they may have. 295 In any case, when network elements are renumbered, existing user 296 sessions may not survive, because of temporary "destination 297 unreachable" conditions being treated as fatal errors. This aspect 298 needs further investigation. 300 2.8. Management Aspects 302 As noted in the Introduction, static addressing and manual address 303 configuration are not the same thing. In terms of managing a 304 renumbering event, static addressing derived automatically from a 305 central database, e.g. by stateful DHCPv6, is clearly better than 306 manual configuration by an administrator. This remains true even if 307 the database itself requires manual changes, since otherwise an 308 administrator would have to log in to every host concerned, a time- 309 consuming and error-prone task. Thus, in cases where static 310 addresses cannot be avoided, they should in any case be assigned 311 automatically from a central database using a suitable protocol, 312 probably stateful DHCPv6. If possible, even static addresses kept in 313 the central database should be assigned automatically. Manual 314 updates of the central database should be kept to a minimum, and 315 manual configuration of individual hosts should be avoided if at all 316 possible. 318 3. Summary of Problem Statement 320 If subnet prefixes are statically assigned, various network elements 321 and the network management system must be informed when they are 322 renumbered. Alternatively, can automatic subnet prefix assignment be 323 performed without interruption to user sessions? 325 If a printer or similar local server is statically addressed out of a 326 non-ULA prefix, and has no DNS, mDNS or SLP name, prefix renumbering 327 will require configuration changes in all hosts using that server. 328 Most likely, these changes will be manual; therefore this situation 329 should be avoided except for very small networks. Even if the server 330 is under a ULA prefix, any subnet rearrangement that causes it to be 331 renumbered will have the same effect. 333 If a server with a DNS name is statically addressed via a common 334 configuration database that supports both DHCPv6 and DNS, then it can 335 be renumbered "without a flag day" by following RFC 4192. However, 336 if there is no common configuration database, then present technology 337 requires manual intervention. Similar considerations apply to 338 virtual servers with static addresses. 340 If client computers such as desktops are statically addressed via a 341 common configuration database and stateful DHCPv6, they can also be 342 renumbered "without a flag day." But other statically addressed 343 clients will need manual intervention, so DHCPv6 should be used if 344 possible. 346 If address-based software licensing is unavoidable, requiring static 347 addresses, and ULAs cannot be used for this case, an administrative 348 procedure during renumbering seems unavoidable. 350 If network elements have static addresses, the network management 351 system and affected client hosts must be informed when they are 352 renumbered. Even if a network element is under a ULA prefix, any 353 subnet rearrangement that causes it to be renumbered will have the 354 same effect. 356 It appears that the majority of the above problems can be largely 357 mitigated if the following measures are taken: 359 1. The site uses a general configuration management tool that 360 manages all prefixes, DHCPv6, DNS and router configurations in a 361 consistent and integrated way. Even if static addresses are 362 used, they are always configured with this tool, and never 363 manually. 364 2. All printers and other local servers are always accessed via a 365 DNS, mDNS or SLP name. User computers are configured only with 366 names for such servers and never with their addresses. 367 3. Internal traffic uses a ULA prefix, such that disturbance to such 368 traffic is avoided if the externally used prefix changes. 369 4. If external prefix renumbering is required, the RFC 4192 370 procedure is followed. 372 Remaining potential gaps are: 374 1. Is minor residual loss of ongoing transport sessions during 375 renumbering operationally acceptable? 376 2. Can automatic network element renumbering can be performed 377 without interrupting user sessions? 378 3. Do any software licensing systems require manual intervention? 380 4. Security Considerations 382 This document defines no protocol, so does not introduce any new 383 security exposures. 385 5. IANA Considerations 387 This document requests no action by IANA. 389 6. Acknowledgements 391 Valuable comments and contributions were made by Wes George, Brian 392 Haberman, Bing Liu, and other participants in the 6renum WG. 394 This document was produced using the xml2rfc tool [RFC2629]. 396 7. Change log [RFC Editor: Please remove] 398 draft-ietf-6renum-static-problem-01: WG comments, 2012-08-31. 400 draft-ietf-6renum-static-problem-00: adopted by WG and as milestone, 401 2012-07-30. 403 draft-carpenter-6renum-static-problem-02: more feedback from WG, 404 2012-02-28. 406 draft-carpenter-6renum-static-problem-01: feedback from WG, new text 407 on software licensing, 2011-12-06. 409 draft-carpenter-6renum-static-problem-00: original version, 410 2011-10-18. 412 8. Informative References 414 [I-D.baker-homenet-prefix-assignment] 415 Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small 416 Networks", draft-baker-homenet-prefix-assignment-01 (work 417 in progress), March 2012. 419 [I-D.cheshire-dnsext-multicastdns] 420 Cheshire, S. and M. Krochmal, "Multicast DNS", 421 draft-cheshire-dnsext-multicastdns-15 (work in progress), 422 December 2011. 424 [I-D.jiang-6renum-enterprise] 425 Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 426 Network Renumbering Scenarios and Guidelines", 427 draft-jiang-6renum-enterprise-02 (work in progress), 428 December 2011. 430 [I-D.liu-6renum-gap-analysis] 431 Liu, B., Jiang, S., and B. Carpenter, "IPv6 Site 432 Renumbering Gap Analysis", 433 draft-liu-6renum-gap-analysis-03 (work in progress), 434 December 2011. 436 [I-D.narten-nvo3-overlay-problem-statement] 437 Narten, T., Black, D., Dutt, D., Fang, L., Gray, E., 438 Kreeger, L., Napierala, M., and M. Sridhavan, "Problem 439 Statement: Overlays for Network Virtualization", 440 draft-narten-nvo3-overlay-problem-statement-04 (work in 441 progress), August 2012. 443 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 444 E. Lear, "Address Allocation for Private Internets", 445 BCP 5, RFC 1918, February 1996. 447 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 448 "Service Location Protocol, Version 2", RFC 2608, 449 June 1999. 451 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 452 June 1999. 454 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 455 Update", RFC 3007, November 2000. 457 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 458 and M. Carney, "Dynamic Host Configuration Protocol for 459 IPv6 (DHCPv6)", RFC 3315, July 2003. 461 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 462 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 463 September 2005. 465 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 466 Addresses", RFC 4193, October 2005. 468 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 469 Address Autoconfiguration", RFC 4862, September 2007. 471 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 472 Still Needs Work", RFC 5887, May 2010. 474 [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, 475 May 2011. 477 Authors' Addresses 479 Brian Carpenter 480 Department of Computer Science 481 University of Auckland 482 PB 92019 483 Auckland, 1142 484 New Zealand 486 Email: brian.e.carpenter@gmail.com 487 Sheng Jiang 488 Huawei Technologies Co., Ltd 489 Q14, Huawei Campus 490 No.156 Beiqing Road 491 Hai-Dian District, Beijing 100095 492 P.R. China 494 Email: jiangsheng@huawei.com