idnits 2.17.1 draft-ietf-v6ops-dhcpv6-slaac-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 == Line 199 has weird spacing: '... with othe...' -- The document date (October 27, 2014) is 3467 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6OPS B. Liu 3 Internet-Draft S. Jiang 4 Intended status: Informational Huawei Technologies 5 Expires: April 30, 2015 R. Bonica 6 Juniper Networks 7 X. Gong 8 W. Wang 9 BUPT University 10 October 27, 2014 12 DHCPv6/SLAAC Address Configuration Interaction Problem Statement 13 draft-ietf-v6ops-dhcpv6-slaac-problem-03 15 Abstract 17 The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router 18 Advertisement (RA) message. The RA message contains three flags, 19 indicating which autoconfiguration mechanisms are available to on- 20 link hosts. These are the M, O and A flags. The M and O flags are 21 advisory, not prescriptive. 23 This document describes divergent host behaviors observed in popular 24 operating systems. It also describes operational problems that 25 divergent behaviors cause. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 30, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. The M, O and A Flags . . . . . . . . . . . . . . . . . . . . 3 63 2.1. M (Managed) Flag . . . . . . . . . . . . . . . . . . . . 3 64 2.2. O (Otherconfig) Flag . . . . . . . . . . . . . . . . . . 4 65 2.3. A (Autonomous) Flag . . . . . . . . . . . . . . . . . . . 4 66 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Divergent Host Behaviors . . . . . . . . . . . . . . . . 4 68 3.2. Operational Problems . . . . . . . . . . . . . . . . . . 5 69 3.2.1. Inappropriate Sources . . . . . . . . . . . . . . . . 5 70 3.2.2. Renumbering . . . . . . . . . . . . . . . . . . . . . 5 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 7.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Appendix A. Test Results . . . . . . . . . . . . . . . . . . . . 7 78 A.1. Test Environment . . . . . . . . . . . . . . . . . . . . 7 79 A.2. Host Behavior in the Initial State . . . . . . . . . . . 8 80 A.3. Host Behavior in State Transitions . . . . . . . . . . . 10 81 Appendix B. Analysis of the Ambiguities . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 IPv6 [RFC2460] hosts invoke Neighbor Discovery (ND) [RFC4861] 87 procedures in order to discover which autoconfiguration mechanisms 88 are available to them. The following is a list of autoconfiguration 89 mechanisms: 91 o DHCPv6 [RFC3315] 93 o Stateless Address Autoconfiguration (SLAAC) [RFC4862] 95 ND specifies an ICMPv6 [RFC4443] Router Advertisement (RA) message. 96 Routers periodically broadcast the RA message to all on-link nodes. 98 They also unicast RA messages in response to solicitations. The RA 99 message contains: 101 o an M (Managed) flag 103 o an O (OtherConfig) flag 105 o zero or more Prefix Information (PI) Options 107 The M flag indicates that addresses are available from DHCPv6. The O 108 flag indicates that other configuration information (e.g., DNS- 109 related information) is available from DHCPv6. The PI Option 110 includes a prefix, an A (Autonomous) flag and other fields. The A 111 flag indicates that the prefix can be used for SLAAC. The M and O 112 flags are advisory, not prescriptive (although A flag is also 113 advisory in definition in standard, it is quite prescriptive in 114 implementations). For example, the M flag indicates that addresses 115 are available from DHCPv6. It does not indicate that hosts are 116 required to acquire addresses from DHCPv6. Similar statements can be 117 made about the O flag. 119 In most cases, the M, O and A flags elicit identical behaviors from 120 most popular operating systems. However, in several cases, the M, O 121 and A flags elicit divergent behaviors. For example, when a router 122 changes the settings of the M, O, and A flag from one RA message to 123 the next, it is likely to elicit one behavior from hosts running one 124 operating system and another behavior from hosts running a different 125 operating system. 127 This document describes divergent host behaviors observed in popular 128 operating systems. It also describes operational problems that 129 divergent behaviors cause. 131 2. The M, O and A Flags 133 This section briefly reviews how the M, O and A flags are defined in 134 [RFC4861]. 136 2.1. M (Managed) Flag 138 The M flag indicates that addresses are available from DHCPv6. If 139 the M flag is set, the O flag is redundant and can be ignored because 140 DHCPv6 will return all available configuration information. 142 M and A flag semantics are independent of one another. The M flag 143 indicates that addresses are available from DHCPv6, regardless of the 144 A flag setting. The following settings are all allowed: 146 o M=0 A=0 148 o M=0 A=1 150 o M=1 A=0 152 o M=1 A=1 154 2.2. O (Otherconfig) Flag 156 The O flag indicates that other configuration information (e.g., DNS- 157 related information) is available from DHCPv6. If the M flag is set, 158 the O flag is redundant and can be ignored because DHCPv6 will return 159 all available configuration information. 161 O and A flag semantics are independent of one another. The O flag 162 indicates that other configuration is available from DHCPv6, 163 regardless of the A flag setting. The following settings are all 164 allowed: 166 o O=0 A=0 168 o O=0 A=1 170 o O=1 A=0 172 o O=1 A=1 174 2.3. A (Autonomous) Flag 176 The A flag indicates that the prefix that is also carried by the PI 177 option can be used for SLAAC. A flag semantics are independent of M 178 and O flag semantics. The A flag indicates that the prefix can be 179 used by SLAAC, regardless of the M and O flag settings. 181 3. Problem Statement 183 3.1. Divergent Host Behaviors 185 The authors tested several popular operating systems in order to 186 determine what behaviors the M, O and A flag elicit. In some cases, 187 the M, A and O flags elicit identical behaviors from most popular 188 operating systems. However, in several cases, the M, O and A flags 189 elicit divergent behaviors. The table below characterizes those 190 cases: 192 Host State Input Behavior 194 Host has not No RA Some popular operating systems acquire 195 acquired any addresses from DHCPv6. Others do not. 196 addresses 198 Host has not RA Some popular operating systems acquire 199 acquired any with other information from DHCPv6, regardless 200 addresses M=0, of the A flag setting. Others do so, but 201 O=1 only if A=1 203 Host has acquired RA Some operating systems release DHCPv6 204 addresses from with M addresses immediately. Some release DHCPv6 205 DHCPv6 only (M = =0 addresses when they expire. 206 1) 208 Host has acquired RA Some operating systems acquire DHCPv6 209 addresses from with M addresses immediately. Others do so only 210 SLAAC only (A=1) = 1 if their SLAAC addresses expire and cannot 211 be refreshed. 213 3.2. Operational Problems 215 This section describes operational issues caused by the divergent 216 behaviors, described above. 218 3.2.1. Inappropriate Sources 220 Some operating systems base their decision to acquire configuration 221 information upon inappropriate sources. For example, some operating 222 systems acquire other configuration information if M = 0, O = 1, and 223 A = 1, but not if M = 0, 0 = 1 and A = 0. In other words, on some 224 operating systems, it is impossible to acquire other information from 225 DHCPv6 unless addresses are acquired from either DHCPv6 or SLAAC. 227 3.2.2. Renumbering 229 According to [RFC6879] a renumbering exercise can include the 230 following steps: 232 o Causing hosts that have acquired addresses from one 233 autoconfiguration mechanism to release those addresses and acquire 234 new addresses from another autoconfiguration mechanism 236 o Causing hosts that have acquired addresses from one 237 autoconfiguration mechanism to release those addresses and acquire 238 new addresses from the same autoconfiguration mechanism 240 o Causing hosts that have acquired addresses from one 241 autoconfiguration mechanism to retain those addresses and acquire 242 new addresses from another autoconfiguration mechanism 244 Ideally, these steps could be initiated by broadcasting RA message 245 onto the subnetwork that is being renumbered. Sadly, this is not 246 possible, because the RA message may elicit a different behavior from 247 each host. According to Section 3.1, renumbering operations would 248 have the following limitations: 250 o When M flag is turned off, some operating systems release DHCPv6 251 acquired addresses immediately, while other will retain then until 252 they expire. This means a flash switch from DHCPv6 to SLAAC would 253 happen on some hosts. Normally, the "make-before-break" approach 254 proposed in [RFC4192] is considered better than flash renumbering. 256 o On some operating systems, if a host has acquired addresses from 257 SLAAC, it is impossible to acquire additional addresses from 258 DHCPv6. This may be required as part of a renumbering operation. 260 4. Security Considerations 262 As this memo does not introduce any new protocols or procedures, it 263 does not introduce any new security vulnerabilities. 265 5. IANA Considerations 267 This draft does not request any IANA action. 269 6. Acknowledgements 271 The authors wish to acknowledge BNRC-BUPT (Broad Network Research 272 Centre in Beijing University of Posts and Telecommunications) for 273 their testing efforts. Special thanks to Xudong Shi, Longyun Yuan 274 and Xiaojian Xue for their extraordinary effort. 276 The authors also wish to acknowledge Brian E Carpenter, Ran Atkinson, 277 Mikael Abrahamsson, Tatuya Jinmei, Mark Andrews and Mark Smith for 278 their helpful comments. 280 7. References 282 7.1. Normative References 284 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 285 (IPv6) Specification", RFC 2460, December 1998. 287 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 288 Message Protocol (ICMPv6) for the Internet Protocol 289 Version 6 (IPv6) Specification", RFC 4443, March 2006. 291 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 292 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 293 September 2007. 295 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 296 Address Autoconfiguration", RFC 4862, September 2007. 298 7.2. Informative References 300 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 301 and M. Carney, "Dynamic Host Configuration Protocol for 302 IPv6 (DHCPv6)", RFC 3315, July 2003. 304 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 305 (DHCP) Service for IPv6", RFC 3736, April 2004. 307 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 308 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 309 September 2005. 311 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 312 Network Renumbering Scenarios, Considerations, and 313 Methods", RFC 6879, February 2013. 315 Appendix A. Test Results 317 A.1. Test Environment 318 /-----\ 319 +---------+ // \\ 320 | DHCPv6 | | Router | 321 | server | \\ // 322 +----+----+ \--+--/ 323 | | 324 | | 325 | | 326 ----+--+----------+----------+---+----- 327 | | | 328 | | | 329 | | | 330 +----+---+ +----+---+ +----+---+ 331 | | | | | | 332 | Host 1 | | Host 2 | | Host 3 | 333 +--------+ +--------+ +--------+ 335 Figure 1: Test Environment 337 The test environment depicted Figure 1 in was replicated on a single 338 server using VMware. For simplicity of operation, only one host was 339 run at a time. Network elements were as follows: 341 o Router: Quagga 0.99-19 soft router installed on Ubuntu 11.04 342 virtual host 344 o DHCPv6 Server: Dibbler-server installed on Ubuntu 11.04 virtual 345 host 347 o Host 1: Window 7 / Window 8.1 Virtual Host 349 o Host 2: Ubuntu 14.04 (Linux Kernel 3.12.0) Virtual Host 351 o Host 3: Mac OS X v10.9 Virtual Host 353 o Host 4: IOS 8.0 (model: Apple iPhone 5S, connected via wifi) 355 A.2. Host Behavior in the Initial State 357 The bullet list below describes host behavior in the initial state, 358 when the host has not yet acquired any autoconfiguration information. 359 Each bullet item represents an input and the behavior elicited by 360 that input. 362 o A=0, M=0, O=0 364 * Windows 8.1 acquired addresses and other information from 365 DHCPv6. 367 * All other hosts acquired no configuration information. 369 o A=0, M=0, O=1 371 * Windows 8.1 acquired addresses and other information from 372 DHCPv6. 374 * Windows 7, OSX 10.9 and IOS 8.0 acquired other information from 375 DHCPv6. 377 * Ubuntu 14.04 acquired no configuration information. 379 o A=0, M=1, O=0 381 * All hosts acquired addresses and other information from DHCPv6. 383 o A=0, M=1, O=1 385 * All hosts acquired addresses and other information from DHCPv6. 387 o A=1, M=0, O=0 389 * Windows 8.1 acquired addresses from SLAAC and DHCPv6. It also 390 acquired non-address information from DHCPv6. 392 * All the other host acquired addresses from SLAAC 394 o A=1, M=0, O=1 396 * Windows 8.1 acquired addresses from SLAAC and DHCPv6. It also 397 acquired other information from DHCPv6. 399 * All the other hosts acquired addresses from SLAAC and other 400 information from DHCPv6. 402 o A=1, M=1, O=0 404 * All hosts acquired addresses from SLAAC and DHCPv6. They also 405 acquired other information from DHCPv6. 407 o A=1, M=1, O=1 409 * All hosts acquired addresses from SLAAC and DHCPv6. They also 410 acquired other information from DHCPv6. 412 As showed above, four inputs result in divergent behaviors. 414 A.3. Host Behavior in State Transitions 416 The bullet list below describes behavior elicited during state 417 transitions. The value x can represents both 0 and 1. 419 o Old state (M = x, O = x, A = 1) , New state (M = x, O = x, A = 0) 420 (This means a SLAAC-configured host, which is regardless of DHCPv6 421 configured or not, receiving A transitioning from 1 to 0. ) 423 * All the hosts retain SLAAC addresses until they expire 425 o Old state (M = 0, O = x, A = 1), New state (M = 1, O = x, A = 1) 426 (This means a SLAAC-only host receiving M transitioning from 0 to 427 1.) 429 * Windows 7 acquires addresses from DHCPv6, immediately. 431 * Ubuntu 14.04/OSX 10.9/IOS 8.0 acquires addresses from DHCPv6 432 only if the SLAAC addresses are allowed to expire 434 * Windows 8.1 was not tested because it always acquire addresses 435 from DHCPv6 regardless of the M flag setting. 437 o Old state (M = 1, O = x, A = x), New state (M = 0, O = x, A = x) 438 (This means a DHCPv6-configured host receiving M transitioning 439 from 1 to 0.) 441 * Windows 7 immediately released the DHCPv6 address 443 * Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0 keep the DHCPv6 444 addresses until they expire 446 o Old state (M = 1, O = x, A = 0), New state (M = 1, O = x, A = 1) 447 (This means a DHCPv6-only host receiving A transitioning from 0 to 448 1.) 450 * All host acquire addresses from SLAAC 452 o Old state (M = 0, O = 1, A = x), New state (M = 1, O = 1, A = x) 453 (This means a Stateless DHCPv6-configured host [RFC3736], which is 454 regardless of SLAAC configured or not, receiving M transitioning 455 from 0 to 1 with keeping O=1 ) 457 * Windows 7 acquires addresses and refreshes other information 458 from DHCPv6 460 * Ubuntu 14.04/OSX 10.9/IOS 8.0 does nothing 461 * Windows 8.1 was not tested because it always acquire addresses 462 from DHCPv6 regardless of the M flag setting. 464 o Old state (M = 1, O = 1, A = x), New state (M = 0, O = 1, A = x) 465 (This means a Stateful DHCPv6-configured host, which is regardless 466 of SLAAC configured or not, receiving M transitioning from 0 to 1 467 with keeping O=1 ) 469 * Windows 7 released all DHCPv6 addresses and refreshes all 470 DHCPv6 other information. 472 * Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0 does nothing 474 Appendix B. Analysis of the Ambiguities 476 Following is a comprehensive analysis of the ambiguities as defined 477 in the standards. In theory, all the ambiguities might cause 478 divergent host behavior. Some of the divergence has been identified 479 by the tests while some haven't. It is worth to document all the 480 ambiguities. 482 1. Dependency between DHCPv6 and RA 484 In standards, behavior of DHCPv6 and Neighbor Discovery protocols 485 is specified respectively. But it is not clear that whether there 486 should be any dependency between them. More specifically, is RA 487 (with M=1) required to trigger DHCPv6? If there are no RAs at 488 all, should hosts initiate DHCPv6 by themselves? 490 2. Behaviors of Flag Transition 492 When flags are in transition, e.g. the host is already SLAAC- 493 configured, then M flag changes from FALSE to TRUE, it is not 494 clear whether the host should start DHCPv6 or not; or vise versa, 495 the host is already both SLAAC/DHCPv6 configured, then M flag 496 change from TRUE to FALSE, it is also not clear whether the host 497 should turn DHCPv6 off or not. 499 3. Distinction between "Address Configuring Method" and "Address 500 Lifetime" 502 When one address configuration method is off, that is, the A flag 503 or M flag changes from TRUE to FALSE, it is not clear whether the 504 host should immediately release the corresponding address(es) or 505 just retain it(them) until expired. 507 4. Dependencies between the flags 508 The semantics of the flags seems not totally independent, but the 509 standards didn't clearly clarify it. For example, when both M and 510 O flags are TRUE, it is not clear whether the host should initiate 511 one stateful DHCPv6 session to get both address and info- 512 configuration or initiate two independent sessions of which one is 513 dedicated for address provisioning and the other is for 514 information provision. When A and M flags are FALSE and O flag is 515 TRUE, it is not clear whether the host should initiate a stand- 516 alone stateless DHCPv6 session. 518 Authors' Addresses 520 Bing Liu 521 Huawei Technologies 522 Q14, Huawei Campus, No.156 Beiqing Road 523 Hai-Dian District, Beijing, 100095 524 P.R. China 526 Email: leo.liubing@huawei.com 528 Sheng Jiang 529 Huawei Technologies 530 Q14, Huawei Campus, No.156 Beiqing Road 531 Hai-Dian District, Beijing, 100095 532 P.R. China 534 Email: jiangsheng@huawei.com 536 Ron Bonica 537 Juniper Networks 538 Sterling, Virginia 539 20164 540 USA 542 Email: rbonica@juniper.net 544 Xiangyang Gong 545 BUPT University 546 No.3 Teaching Building 547 Beijing University of Posts and Telecommunications (BUPT) 548 No.10 Xi-Tu-Cheng Rd. 549 Hai-Dian District, Beijing 550 P.R. China 552 Email: xygong@bupt.edu.cn 553 Wendong Wang 554 BUPT University 555 No.3 Teaching Building 556 Beijing University of Posts and Telecommunications (BUPT) 557 No.10 Xi-Tu-Cheng Rd. 558 Hai-Dian District, Beijing 559 P.R. China 561 Email: wdwang@bupt.edu.cn