idnits 2.17.1 draft-ietf-6renum-static-problem-03.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 (December 24, 2012) is 4103 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-6renum-enterprise-05 == Outdated reference: A later version (-08) exists of draft-ietf-6renum-gap-analysis-05 == Outdated reference: A later version (-04) exists of draft-ietf-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 (~~), 4 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: June 27, 2013 Huawei Technologies Co., Ltd 6 December 24, 2012 8 Problem Statement for Renumbering IPv6 Hosts with Static Addresses in 9 Enterprise Networks 10 draft-ietf-6renum-static-problem-03 12 Abstract 14 This document analyses the problems of updating the IPv6 addresses of 15 hosts in enterprise networks that for operational reasons require 16 static addresses. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on June 27, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Static Addresses Imply Static Prefixes . . . . . . . . . . 4 55 2.2. Other Hosts Need Literal Address . . . . . . . . . . . . . 4 56 2.3. Static Server Addresses . . . . . . . . . . . . . . . . . 5 57 2.4. Static Virtual Machine Addresses . . . . . . . . . . . . . 6 58 2.5. Asset Management and Security Tracing . . . . . . . . . . 6 59 2.6. Primitive Software Licensing . . . . . . . . . . . . . . . 7 60 2.7. Network Elements . . . . . . . . . . . . . . . . . . . . . 7 61 2.8. Access Control Lists . . . . . . . . . . . . . . . . . . . 8 62 2.9. Management Aspects . . . . . . . . . . . . . . . . . . . . 8 63 3. Summary of Problem Statement . . . . . . . . . . . . . . . . . 8 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 67 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 10 68 8. Informative References . . . . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 71 1. Introduction 73 A problem that is frequently mentioned in discussions of renumbering 74 enterprise networks [RFC5887] [I-D.ietf-6renum-enterprise] 75 [I-D.ietf-6renum-gap-analysis] is that of statically assigned 76 addresses. The scope of the present document is to analyse the 77 problems caused to enterprise networks during renumbering by static 78 addresses and to identify related gaps in existing technology. Some 79 aspects also apply to small office and home networks, but these are 80 not the intended scope of the document. 82 A static address can be defined as an IP address that is intended by 83 the network manager to remain constant over a long period of time, 84 possibly many years, regardless of system restarts or any other 85 unpredictable events. Static addressing often implies manual address 86 assignment, including manual preparation of configuration scripts. 87 An implication of hosts having static addresses is that subnets must 88 have static prefixes, which also requires analysis. 90 In a sense, the issue of static addresses is a result of history. As 91 discussed in Section 3.2 of [RFC6250], various properties of IP 92 addresses that have long been assumed by programmers and operators 93 are no longer true today, although they were true when almost all 94 addresses were manually assigned. In some cases, the resulting 95 operational difficulties are avoided by static addressing. 97 Although static addressing is in general problematic for renumbering, 98 hosts inside an enterprise may have static addresses for a number of 99 operational reasons: 101 o For some reason, other hosts need to be configured with a literal 102 numeric address for the host in question, so its address must be 103 static. 104 o Even if a site has local DNS support and this is normally used to 105 locate servers, some operators wish their servers to have static 106 addresses so that issues of address lifetime and DNS TTL cannot 107 affect connectivity. 108 o Some approaches to virtual server farms require static addressing. 109 o On some sites, the network operations staff require hosts to have 110 static addresses for asset management purposes and for address- 111 based backtracking of security incidents. 112 o Certain software licensing mechanisms are based on IP addresses. 113 o Network elements such as routers are usually assigned static 114 addresses, which are also configured into network monitoring and 115 management systems. 116 o Access Control Lists and other security mechanisms are often 117 configured using IP addresses. 119 Static addressing is not the same thing as manual addressing. Static 120 addresses may be configured automatically, for example by stateful 121 DHCPv6. In that case, the database from which the static address is 122 derived may itself have been created automatically in some fashion, 123 or configured manually. If a host's address is configured manually 124 by the host's administrator, it is by definition static. 126 This document analyses these issues in more detail and presents a 127 problem statement. Where obvious alternatives to static addresses 128 exist, they are mentioned. 130 2. Analysis 132 2.1. Static Addresses Imply Static Prefixes 134 Host addresses can only be static if subnet prefixes are also static. 135 Static prefixes are such a long-established practice in enterprise 136 networks that it is hard to discern the reason for them. Originally, 137 before DHCP became available, there was simply no alternative. Thus 138 it became accepted practice to assign subnet prefixes manually and 139 build them into static router configurations. Today, the static 140 nature of subnet prefixes has become a diagnostic tool in itself, at 141 least in the case of IPv4 where prefixes can easily be memorised. If 142 several users sharing a subnet prefix report problems, the fault can 143 readily be localised. 145 This model is being challenged for the case of unmanaged home IPv6 146 networks, in which it is possible to assign subnet prefixes 147 automatically, at least in a cold start scenario 148 [I-D.baker-homenet-prefix-assignment]. For an enterprise network, 149 the question arises whether automatic subnet prefix assignment can be 150 made using the "without a flag day" approach to renumbering. 151 [RFC4192] specifies that "the new prefix is added to the network 152 infrastructure in parallel with (and without interfering with) the 153 old prefix." Any method for automatic prefix assignment needs to 154 support this. 156 2.2. Other Hosts Need Literal Address 158 This issue commonly arises in small networks without local DNS 159 support, for devices such as printers that all other hosts need to 160 reach. In this case, not only does the host in question have a 161 static address, but that address is also configured in the other 162 hosts. It is long established practice in small IPv4 enterprise 163 networks that printers in particular are manually assigned a fixed 164 address (typically an [RFC1918] address) and that users are told to 165 manually configure printer access using that fixed address. For a 166 small network the work involved in doing this is much less than the 167 work involved in doing it "properly" by setting up DNS service, 168 whether local or hosted by an ISP, to give the printer a name. Also, 169 although the Service Location Protocol (SLP) [RFC2608] is widely 170 available for tasks such as printer discovery, it is not widely used 171 in enterprise networks. In consequence, if the printer is renumbered 172 for any reason, the manual configuration of all users' hosts must be 173 updated in many enterprises. 175 In the case of IPv6, exactly the same situation would be created by 176 numbering the printer statically under the site's Unique Local 177 Address (ULA) prefix [RFC4193]. Although this address would not 178 change if the site's globally routable prefix is changed, internal 179 renumbering for any other reason would be troublesome. Additionally, 180 the disadvantage compared to IPv4 is that an IPv6 address is harder 181 to communicate reliably, compared to something as simple as 182 "10.1.1.10". The process will be significantly more error-prone for 183 IPv6. 185 If such a host is numbered out of a globally routable prefix that is 186 potentially subject to renumbering, then a renumbering event will 187 require a configuration change in all hosts using the device in 188 question, and such configuration data are by no means stored in the 189 network layer. 191 At least two simple alternatives exist to avoid static numbering of 192 simple devices such as printers by giving them local names. One is 193 the use of Multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] in 194 combination with DNS Service Discovery [I-D.cheshire-dnsext-dns-sd]. 195 The other is the Service Location Protocol [RFC2608]. Both of these 196 solutions are widely implemented, but seemingly not widely deployed 197 in enterprise networks. 199 2.3. Static Server Addresses 201 On larger sites, it is safe to assume that servers of all kinds, 202 including printers, are identified in user configurations and 203 applications by DNS names. However, it is very widespread 204 operational practice that servers have static IP addresses. If they 205 did not, whenever an address assigned by stateless address auto- 206 configuration [RFC4862] or DHCPv6 [RFC3315] expired, and if the 207 address actually changed for some extraneous reason, sessions in 208 progress might fail (depending on whether the address deprecation 209 period was long enough). 211 DNS aspects of renumbering are discussed in more detail in 212 [I-D.ietf-6renum-enterprise]. Here, we note that one reason for 213 widespread use of static server addresses is the lack of deployment 214 of Secure Dynamic DNS update [RFC3007], or some other method of 215 prompt DNS updates, in enterprise networks. A separate issue is that 216 even with such updates in place, remote users of a server would 217 attempt to use the wrong address until the DNS time-to-live expired, 218 as discussed in [RFC4192]. 220 Server addresses can be managed centrally even if they are static, by 221 using DHCPv6 in stateful mode to ensure that the same address is 222 always assigned to a given server. Consistency with DNS can be 223 ensured by generating both DHCPv6 data and DNS data from a common 224 configuration database using a suitable configuration tool. This 225 does normally carry the implication that the database also contains 226 the hardware (MAC) addresses of the relevant LAN interfaces on the 227 servers, so that the correct IPv6 address can be delivered whenever a 228 server requests an address. Not every operator wishes to maintain 229 such a costly database, however, and some sites are therefore likely 230 today to fall back on manual configuration of server addresses as a 231 result. 233 In the event of renumbering of the prefix covering such servers, the 234 situation should be manageable if there is a common configuration 235 database; the "without a flag day" procedure [RFC4192] could be 236 followed. However, if there is no such database, a manual procedure 237 would have to be adopted. 239 2.4. Static Virtual Machine Addresses 241 According to [I-D.ietf-nvo3-overlay-problem-statement], the placement 242 and live migration of virtual machines (VMs) in a physical network 243 requires that their IP addresses are fixed and static. Otherwise, 244 when a VM is migrated to a different physical server, its IP address 245 would change and transport sessions in progress would be lost. In 246 effect this is a special case of the previous one. 248 If VMs are numbered out of a prefix that is subject to renumbering, 249 there is a direct conflict with application session continuity, 250 unless a procedure similar to [RFC4192] is followed. 252 2.5. Asset Management and Security Tracing 254 There are some large (campus-sized) sites that not only capture the 255 MAC addresses of servers in a configuration system, but also do so 256 for desktop client machines with wired connections, that are then 257 given static IP addresses. Such hosts are not normally servers, so 258 the two preceding cases do not apply. One motivation for this 259 approach is straightforward asset management (who has which computer, 260 connected to which cable?). Another, more compelling, reason is 261 security incident handling. If, as occurs with reasonable frequency 262 on any large network, a particular host is found to be generating 263 some form of unwanted traffic, it is urgent to be able to track back 264 from its IP address to its physical location, so that an appropriate 265 intervention can be made. A static binding between the MAC address 266 and the IPv6 address might be preferred for this purpose. 268 Such users will not in most circumstances be significantly 269 inconvenienced by prefix renumbering, as long as it follows the 270 [RFC4192] procedure. The address deprecation mechanism would allow 271 for clean termination of current sessions, including those in which 272 their machine was actually operating as a server, e.g., for a peer- 273 to-peer application. The only users who would be seriously affected 274 would be those running extremely long transport sessions that might 275 outlive the address deprecation period. 277 Note that such large campus sites generally allocate addresses 278 dynamically to wireless hosts, since (in an IPv4 world) addresses are 279 scarce and allocating static addresses to intermittent users is not 280 acceptable. Also, a wireless user may appear on different subnets at 281 different times, so cannot be given a single static address. These 282 users will in most circumstances only be slightly inconvenienced, if 283 at all, by prefix renumbering. 285 2.6. Primitive Software Licensing 287 Although it has many disadvantages and cannot be recommended as a 288 solution, software licensing based on IP addresses or prefixes is 289 still quite widely used in various forms. It is to be expected that 290 this practice will continue for IPv6. If so, there is no alternative 291 to informing the licensing party of the new address(es) by whatever 292 administrative process is required. In an RFC 4192 renumbering 293 procedure, the licenses for the old and new addresses or prefixes 294 would have to overlap. 296 If acceptable to the licensing mechanism, using addresses under an 297 enterprise's ULA prefix for software licensing would avoid this 298 problem. 300 2.7. Network Elements 302 Each interface of a router needs an IP address, and so do other 303 network elements such as firewalls, proxies, and load balancers. 304 Since these are critical infrastructure, they must be monitored and 305 in some cases controlled by a network management system. A 306 conventional approach to this is to assign the necessary IP addresses 307 statically, and also to configure those addresses in the monitoring 308 and management systems. It is common practice that some such 309 addresses will have no corresponding DNS entry. If these addresses 310 need to be changed, there will be considerable ramifications. A 311 restart of the network element might be needed, interrupting all user 312 sessions in progress. Simultaneously, the monitoring and management 313 system configurations must be updated, and in the case of a default 314 router, its clients must be informed. To avoid such disruption, 315 network elements must be renumbered according to an [RFC4192] 316 procedure, like any other host. 318 There is a school of thought that to minimise renumbering problems 319 for network elements and to keep the simplicity of static addressing 320 for them, network elements should all have static ULA addresses for 321 management and monitoring purposes, regardless of what other global 322 addresses they may have. 324 2.8. Access Control Lists 326 Access Control Lists (ACLs) and other security mechanisms are often 327 configured using static IP addresses. This may occur in network 328 elements or hosts. If they are not updated promptly during a 329 renumbering event, the result may be the opening of security 330 loopholes, or the blocking of legitimate traffic, or both. Such 331 security loopholes may never be detected until they are successfully 332 exploited. 334 2.9. Management Aspects 336 As noted in the Introduction, static addressing and manual address 337 configuration are not the same thing. In terms of managing a 338 renumbering event, static addressing derived automatically from a 339 central database, e.g. by stateful DHCPv6, is clearly better than 340 manual configuration by an administrator. This remains true even if 341 the database itself requires manual changes, since otherwise an 342 administrator would have to log in to every host concerned, a time- 343 consuming and error-prone task. In cases where static addresses 344 cannot be avoided, they could be assigned automatically from a 345 central database using a suitable protocol such as stateful DHCPv6. 346 Clearly the database needs to be supported by a suitable 347 configuration tool, to minimise manual updates and to eliminate 348 manual configuration of individual hosts. 350 3. Summary of Problem Statement 352 If subnet prefixes are statically assigned, various network elements 353 and the network management system must be updated when they are 354 renumbered. To avoid loss of existing user sessions, the old 355 prefixes need to be removed only after a period of overlap. 357 If a printer or similar local server is statically addressed, and has 358 no DNS or mDNS name and no discovery protocol, renumbering will 359 require configuration changes in all hosts using that server. Most 360 likely, these changes will be manual; therefore this type of 361 configuration should be avoided except for very small networks. Even 362 if the server is under a ULA prefix, any subnet rearrangement that 363 causes it to be renumbered will have the same effect. 365 If a server with a DNS name is statically addressed via a common 366 configuration database that supports both DHCPv6 and DNS, then it can 367 be renumbered "without a flag day" by following RFC 4192. However, 368 if there is no common configuration database, then present technology 369 requires manual intervention. Similar considerations apply to 370 virtual servers with static addresses. 372 If client computers such as desktops are statically addressed via a 373 common configuration database and stateful DHCPv6, they can also be 374 renumbered "without a flag day." But other statically addressed 375 clients will need manual intervention, so DHCPv6 should be used if 376 possible. 378 If address-based software licensing is unavoidable, requiring static 379 addresses, and ULAs cannot be used for this case, an administrative 380 procedure during renumbering seems unavoidable. 382 If network elements have static addresses, the network management 383 system and affected client hosts must be informed when they are 384 renumbered. Even if a network element is under a ULA prefix, any 385 subnet rearrangement that causes it to be renumbered will have the 386 same effect. 388 ACLs configured with static addresses must be updated during 389 renumbering. 391 It appears that the majority of the above problems can be largely 392 mitigated if the following measures are taken: 394 1. The site uses a general configuration management database and an 395 associated tool that manage all prefixes, DHCPv6, DNS, router and 396 security configuration in a consistent and integrated way. Even 397 if static addresses are used, they are always configured with 398 this tool, and never manually. Specification of such a tool is 399 out of scope for the present document. 400 2. All printers and other local servers are always accessed via a 401 DNS or mDNS name, or via a discovery protocol. User computers 402 are configured only with names for such servers and never with 403 their addresses. 405 3. Internal traffic uses a ULA prefix, such that disturbance to such 406 traffic is avoided if the externally used prefix changes. 407 4. If prefix renumbering is required, the RFC 4192 procedure is 408 followed. 410 Remaining open questions are: 412 1. Is minor residual loss of extremely long-living transport 413 sessions during renumbering operationally acceptable? 414 2. Can automatic network element renumbering can be performed 415 without interrupting any user sessions? 416 3. Do any software licensing systems require manual intervention? 418 4. Security Considerations 420 This document defines no protocol, so does not introduce any new 421 security exposures. However, security configurations such as ACLs 422 are affected by the renumbering of static addresses. 424 5. IANA Considerations 426 This document requests no action by IANA. 428 6. Acknowledgements 430 Valuable comments and contributions were made by Ran Atkinson, Ralph 431 Droms, Adrian Farrel, Wes George, Brian Haberman, Bing Liu, Pete 432 Resnick, and other participants in the 6renum WG. 434 This document was produced using the xml2rfc tool [RFC2629]. 436 7. Change log [RFC Editor: Please remove] 438 draft-ietf-6renum-static-problem-03: IETF LC and IESG comments, 2012- 439 12-24. 441 draft-ietf-6renum-static-problem-02: WGLC comments, clarified 442 discussion of SLP and mDNS, expanded discussion of configuration 443 tool, 2012-09-30. 445 draft-ietf-6renum-static-problem-01: WG comments, 2012-08-31. 447 draft-ietf-6renum-static-problem-00: adopted by WG and as milestone, 448 2012-07-30. 450 draft-carpenter-6renum-static-problem-02: more feedback from WG, 451 2012-02-28. 453 draft-carpenter-6renum-static-problem-01: feedback from WG, new text 454 on software licensing, 2011-12-06. 456 draft-carpenter-6renum-static-problem-00: original version, 457 2011-10-18. 459 8. Informative References 461 [I-D.baker-homenet-prefix-assignment] 462 Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small 463 Networks", draft-baker-homenet-prefix-assignment-01 (work 464 in progress), March 2012. 466 [I-D.cheshire-dnsext-dns-sd] 467 Cheshire, S. and M. Krochmal, "DNS-Based Service 468 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 469 progress), December 2011. 471 [I-D.cheshire-dnsext-multicastdns] 472 Cheshire, S. and M. Krochmal, "Multicast DNS", 473 draft-cheshire-dnsext-multicastdns-15 (work in progress), 474 December 2011. 476 [I-D.ietf-6renum-enterprise] 477 Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 478 Network Renumbering Scenarios, Considerations and 479 Methods", draft-ietf-6renum-enterprise-05 (work in 480 progress), December 2012. 482 [I-D.ietf-6renum-gap-analysis] 483 Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. 484 George, "IPv6 Site Renumbering Gap Analysis", 485 draft-ietf-6renum-gap-analysis-05 (work in progress), 486 December 2012. 488 [I-D.ietf-nvo3-overlay-problem-statement] 489 Narten, T., Gray, E., Dutt, D., Fang, L., Kreeger, L., 490 Napierala, M., and M. Sridharan, "Problem Statement: 491 Overlays for Network Virtualization", 492 draft-ietf-nvo3-overlay-problem-statement-01 (work in 493 progress), October 2012. 495 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 496 E. Lear, "Address Allocation for Private Internets", 497 BCP 5, RFC 1918, February 1996. 499 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 500 "Service Location Protocol, Version 2", RFC 2608, 501 June 1999. 503 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 504 June 1999. 506 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 507 Update", RFC 3007, November 2000. 509 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 510 and M. Carney, "Dynamic Host Configuration Protocol for 511 IPv6 (DHCPv6)", RFC 3315, July 2003. 513 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 514 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 515 September 2005. 517 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 518 Addresses", RFC 4193, October 2005. 520 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 521 Address Autoconfiguration", RFC 4862, September 2007. 523 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 524 Still Needs Work", RFC 5887, May 2010. 526 [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, 527 May 2011. 529 Authors' Addresses 531 Brian Carpenter 532 Department of Computer Science 533 University of Auckland 534 PB 92019 535 Auckland, 1142 536 New Zealand 538 Email: brian.e.carpenter@gmail.com 539 Sheng Jiang 540 Huawei Technologies Co., Ltd 541 Q14, Huawei Campus 542 No.156 Beiqing Road 543 Hai-Dian District, Beijing 100095 544 P.R. China 546 Email: jiangsheng@huawei.com