idnits 2.17.1 draft-carpenter-6renum-static-problem-00.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 (October 18, 2011) is 4574 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 (-02) exists of draft-jiang-6renum-enterprise-01 == Outdated reference: A later version (-03) exists of draft-liu-6renum-gap-analysis-01 == Outdated reference: A later version (-04) exists of draft-narten-nvo3-overlay-problem-statement-00 -- 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 (~~), 5 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: April 20, 2012 Huawei Technologies Co., Ltd 6 October 18, 2011 8 Problem Statement for Renumbering IPv6 Hosts with Static Addresses 9 draft-carpenter-6renum-static-problem-00 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 April 20, 2012. 34 Copyright Notice 36 Copyright (c) 2011 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 . . . . . . . . . . 3 54 2.2. Other Hosts Need Literal Address . . . . . . . . . . . . . 4 55 2.3. Static Server Addresses . . . . . . . . . . . . . . . . . . 4 56 2.4. Static Virtual Machine Addresses . . . . . . . . . . . . . 5 57 2.5. Asset Management and Security Tracing . . . . . . . . . . . 5 58 2.6. Primitive Software Licensing . . . . . . . . . . . . . . . 6 59 2.7. Network Elements . . . . . . . . . . . . . . . . . . . . . 6 60 3. Summary of Problem Statement . . . . . . . . . . . . . . . . . 6 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 8 65 8. Informative References . . . . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 A problem that is frequently mentioned in discussions of renumbering 71 enterprise networks [RFC5887] [I-D.jiang-6renum-enterprise] 72 [I-D.liu-6renum-gap-analysis] is that of statically assigned 73 addresses. Static addressing often implies manual address 74 assignment, including manual preparation of configuration scripts. 75 An implication of hosts having static addresses is that subnets must 76 have static prefixes, which also requires analysis. 78 Although static addressing is in general problematic for renumbering, 79 hosts inside an enterprise may have static addresses for a number of 80 operational reasons: 82 o For some reason, other hosts need to be configured with a literal 83 numeric address for the host in question, so its address must be 84 static. 85 o Even if a site has local DNS support and this is normally used to 86 locate servers, some operators wish their servers to have static 87 addresses so that issues of address lifetime and DNS TTL cannot 88 affect connectivity. 89 o Some approaches to virtual server farms require static addressing. 90 o On some sites, the network operations staff require hosts to have 91 static addresses for asset management purposes and for address- 92 based backtracking of security incidents. 93 o Certain software licensing mechanisms have existed which are based 94 on IP addresses. [Question: Is this still relevant for IPv6 95 addresses?] 96 o Network elements such as routers are usually assigned static 97 addresses, which are also configured into network monitoring and 98 management systems. 100 This document analyses these issues in more detail and presents a 101 problem statement. 103 2. Analysis 105 2.1. Static Addresses Imply Static Prefixes 107 Host addresses can only be static if subnet prefixes are also static. 108 Static prefixes are such a long-established practice in enterprise 109 networks that it is hard to discern the reason for them. Originally, 110 before DHCP became available, there was simply no alternative. Thus 111 it became accepted practice to assign subnet prefixes manually and 112 build them into static router configurations. Today, the static 113 nature of subnet prefixes has become a diagnostic tool in itself, at 114 least in the case of IPv4 where prefixes can easily be memorised. If 115 several users sharing a subnet prefix report problems, the fault can 116 readily be localised. 118 This model is being challenged for the case of unmanaged home IPv6 119 networks, in which it is possible to assign subnet prefixes 120 automatically, at least in a cold start scenario 121 [I-D.baker-homenet-prefix-assignment]. For an enterprise network, 122 the question arises whether automatic subnet prefix assignment can be 123 made using the "without a flag day" approach to renumbering. 124 [RFC4192] specifies that "the new prefix is added to the network 125 infrastructure in parallel with (and without interfering with) the 126 old prefix." Any method for automatic prefix assignment needs to 127 support this. 129 2.2. Other Hosts Need Literal Address 131 This issue commonly arises in small networks without local DNS 132 support, for devices such as printers that all other hosts need to 133 reach. In this case, not only does the host in question have a 134 static address, but that address is also configured in the other 135 hosts. It is long established practice in small IPv4 networks that 136 printers in particular are manually assigned a fixed address 137 (typically an [RFC1918] address) and that users are told to manually 138 configure printer access using that fixed address. For a small 139 network the work involved in doing this is much less than the work 140 involved in doing it "properly" by setting up DNS service, whether 141 local or hosted by an ISP, to give the printer a name. It is also 142 unusual to enable the Service Location Protocol [RFC2608] for the 143 same purpose. In consequence, if the printer is renumbered for any 144 reason, the manual configuration of all users' hosts must be updated. 146 In the case of IPv6, exactly the same situation would be created by 147 numbering the printer statically under the site's ULA prefix 148 [RFC4193]. The disadvantage compared to IPv4 is that an IPv6 address 149 is harder to communicate reliably, compared to something as simple as 150 "10.1.1.10". The process will be significantly more error-prone for 151 IPv6. 153 If such a host is numbered out of a prefix that is potentially 154 subject to renumbering, then a renumbering event will require a 155 configuration change in all hosts using the device in question, and 156 the configuration data are by no means stored in the network layer. 158 2.3. Static Server Addresses 160 On larger sites, it is safe to assume that servers of all kinds, 161 including printers, are identified in user configurations and 162 applications by DNS names. However, it is very widespread 163 operational practice that servers have static IP addresses. If they 164 did not, whenever an address assigned by stateless address auto- 165 configuration [RFC4862] or DHCPv6 [RFC3315] expired, and if the 166 address actually changed for some extraneous reason, sessions in 167 progress might fail (depending on whether the address deprecation 168 period was long enough). Also, since a dynamic DNS update [RFC3007] 169 would be required, remote users would attempt to use the wrong 170 address until the DNS time-to-live expired. 172 Such server addresses can be managed centrally even if they are 173 static, by using DHCPv6 in stateful mode, and by generating both 174 DHCPv6 data and DNS data from a common configuration database. This 175 does normally carry the implication that the database also contains 176 the hardware (MAC) addresses of the relevant LAN interfaces on the 177 servers, so that the correct IPv6 address can be delivered whenever a 178 server requests an address. Not every operator wishes to maintain 179 such a costly database, however, and some sites are very likely today 180 to fall back on manual configuration of server addresses as a result. 182 In the event of renumbering of the prefix covering such servers, the 183 situation should be manageable if there is a common configuration 184 database; the "without a flag day" procedure [RFC4192] could be 185 followed. However, if there is no such database, a manual procedure 186 would have to be adopted. 188 2.4. Static Virtual Machine Addresses 190 According to [I-D.narten-nvo3-overlay-problem-statement], "Placement 191 and movement of VMs in a network effectively requires that VM IP 192 addresses be fixed and static." Otherwise, when a VM is migrated to 193 a different physical server, its IP address would change and 194 transport sessions in progress would be lost. In effect this is a 195 special case of the previous one. 197 If VMs are numbered out of a prefix that is subject to renumbering, 198 there is a direct conflict with transport session continuity, unless 199 a procedure similar to [RFC4192] is followed. 201 2.5. Asset Management and Security Tracing 203 There are some large (campus-sized) sites that not only capture the 204 MAC addresses of servers in a configuration system, but also do so 205 for desktop client machines with wired connections, that are then 206 given static IP addresses. Such hosts are not normally servers, so 207 the two preceding cases do not apply. One motivation for this 208 approach is straightforward asset management (who has which computer, 209 connected to which cable?). Another, more compelling, reason is 210 security incident handling. If, as occurs with reasonable frequency 211 on any large network, a particular host is found to be generating 212 some form of unwanted traffic, it is urgent to be able to track back 213 from its IP address to its physical location, so that an appropriate 214 intervention can be made. 216 Such users will not in most circumstances be significantly 217 inconvenienced by prefix renumbering, as long as it follows the 218 [RFC4192] procedure. The address deprecation mechanism would allow 219 for clean termination of current sessions, including those in which 220 their machine was actually operating as a server, e.g., for a peer- 221 to-peer application. The only users who would be seriously affected 222 would be those running extremely long transport sessions that might 223 outlive the address deprecation period. 225 Note that such large campus sites generally allocate addresses 226 dynamically to wireless hosts, since (in an IPv4 world) addresses are 227 scarce and allocating static addresses to intermittent users is not 228 acceptable. Also, a wireless user may appear on different subnets at 229 different times, so cannot be given a single static address. These 230 users will in most circumstances only be slightly inconvenienced, if 231 at all, by prefix renumbering. 233 2.6. Primitive Software Licensing 235 TBD if relevant. 237 2.7. Network Elements 239 Each interface of a router needs an IP address, and so do other 240 network elements such as firewalls, proxies, and load balancers. 241 Since these are critical infrastructure, they must be monitored and 242 in some cases controlled by a network management system. A 243 conventional approach to this is to assign the necessary IP addresses 244 statically, and also to configure those addresses in the monitoring 245 and management systems. It is quite common practice that some such 246 addresses will have no corresponding DNS entry. If these addresses 247 need to be changed, there will be considerable ramifications. A 248 restart of the network element might be needed, interrupting all user 249 sessions in progress. Simultaneously, the monitoring and management 250 system configurations must be updated, and in the case of a default 251 router, its clients must be informed. To avoid such disruption, 252 network elements must be renumbered according to an [RFC4192] 253 procedure, like any other host. 255 3. Summary of Problem Statement 257 If subnet prefixes are statically assigned, various network elements 258 and the network management system must be informed when they are 259 renumbered. Alternatively, can automatic subnet prefix assignment be 260 performed without interruption to user sessions? 262 If a printer or similar local server is statically addressed out of a 263 non-ULA prefix, and has no DNS name, prefix renumbering will require 264 configuration changes in all hosts using that server. Most likely, 265 these changes will be manual. Even if the server is under a ULA 266 prefix, any subnet rearrangement that causes it to be renumbered will 267 have the same effect. 269 If a server with a DNS name is statically addressed via a common 270 configuration database that supports both DHCPv6 and DNS, then it can 271 be renumbered "without a flag day" by following RFC 4192. However, 272 if there is no common configuration database, then present technology 273 requires manual intervention. Similar considerations apply to 274 virtual servers with static addresses. 276 If client computers such as desktops are statically addressed via a 277 common configuration database and stateful DHCPv6, they can also be 278 renumbered "without a flag day." But other statically addressed 279 clients will need manual intervention. 281 If network elements have static addresses, the network management 282 system and affected client hosts must be informed when they are 283 renumbered. Alternatively, can automatic network element renumbering 284 be performed without interruption to user sessions? 286 4. Security Considerations 288 This document defines no protocol, so does not introduce any new 289 security exposures. 291 5. IANA Considerations 293 This document requests no action by IANA. 295 6. Acknowledgements 297 Valuable comments and contributions were made by ... 299 This document was produced using the xml2rfc tool [RFC2629]. 301 7. Change log [RFC Editor: Please remove] 303 draft-carpenter-6renum-static-problem-00: original version, 304 2011-10-18. 306 8. Informative References 308 [I-D.baker-homenet-prefix-assignment] 309 Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small 310 Networks", draft-baker-homenet-prefix-assignment-00 (work 311 in progress), October 2011. 313 [I-D.jiang-6renum-enterprise] 314 Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 315 Network Renumbering Scenarios and Guidelines", 316 draft-jiang-6renum-enterprise-01 (work in progress), 317 September 2011. 319 [I-D.liu-6renum-gap-analysis] 320 Liu, B. and S. Jiang, "IPv6 Site Renumbering Gap 321 Analysis", draft-liu-6renum-gap-analysis-01 (work in 322 progress), July 2011. 324 [I-D.narten-nvo3-overlay-problem-statement] 325 Narten, T. and M. Sridharan, "Problem Statement: Using L3 326 Overlays for Network Virtualization", 327 draft-narten-nvo3-overlay-problem-statement-00 (work in 328 progress), September 2011. 330 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 331 E. Lear, "Address Allocation for Private Internets", 332 BCP 5, RFC 1918, February 1996. 334 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 335 "Service Location Protocol, Version 2", RFC 2608, 336 June 1999. 338 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 339 June 1999. 341 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 342 Update", RFC 3007, November 2000. 344 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 345 and M. Carney, "Dynamic Host Configuration Protocol for 346 IPv6 (DHCPv6)", RFC 3315, July 2003. 348 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 349 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 350 September 2005. 352 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 353 Addresses", RFC 4193, October 2005. 355 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 356 Address Autoconfiguration", RFC 4862, September 2007. 358 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 359 Still Needs Work", RFC 5887, May 2010. 361 Authors' Addresses 363 Brian Carpenter 364 Department of Computer Science 365 University of Auckland 366 PB 92019 367 Auckland, 1142 368 New Zealand 370 Email: brian.e.carpenter@gmail.com 372 Sheng Jiang 373 Huawei Technologies Co., Ltd 374 Q14, Huawei Campus 375 No.156 Beiqing Road 376 Hai-Dian District, Beijing 100095 377 P.R. China 379 Email: jiangsheng@huawei.com