idnits 2.17.1 draft-ietf-v6ops-dhcpv6-slaac-problem-04.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 235 has weird spacing: '... with othe...' -- The document date (May 2, 2015) is 3280 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: November 3, 2015 X. Gong 6 W. Wang 7 BUPT University 8 May 2, 2015 10 DHCPv6/SLAAC Interaction Problems on Address Auto-configuration 11 draft-ietf-v6ops-dhcpv6-slaac-problem-04 13 Abstract 15 The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router 16 Advertisement (RA) message. The RA message contains three flags, 17 indicating which auto-configuration mechanisms are available to on- 18 link hosts. These are the M, O and A flags. The M and O flags are 19 advisory, not prescriptive. 21 This document describes divergent host behaviors observed in popular 22 operating systems. It also describes operational problems that 23 divergent behaviors might cause. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 3, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. The M, O and A Flags . . . . . . . . . . . . . . . . . . . . 3 61 2.1. M (Managed) Flag . . . . . . . . . . . . . . . . . . . . 3 62 2.2. O (Otherconfig) Flag . . . . . . . . . . . . . . . . . . 4 63 2.3. A (Autonomous) Flag . . . . . . . . . . . . . . . . . . . 4 64 3. Behavior Ambiguity Analysis . . . . . . . . . . . . . . . . . 4 65 4. Observed Divergent Host Behaviors . . . . . . . . . . . . . . 5 66 5. Operational Problems . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Inappropriate Sources . . . . . . . . . . . . . . . . . . 6 68 5.2. Renumbering Issues . . . . . . . . . . . . . . . . . . . 6 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 9.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Appendix A. Test Results . . . . . . . . . . . . . . . . . . . . 8 76 A.1. Test Environment . . . . . . . . . . . . . . . . . . . . 8 77 A.2. Host Behavior in the Initial State . . . . . . . . . . . 9 78 A.3. Host Behavior in State Transitions . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 IPv6 [RFC2460] hosts invoke Neighbor Discovery (ND) [RFC4861] 84 procedures in order to discover which auto-configuration mechanisms 85 are available to them. The following is a list of auto-configuration 86 mechanisms: 88 o DHCPv6 [RFC3315] 90 o Stateless Address Autoconfiguration (SLAAC) [RFC4862] 92 ND specifies an ICMPv6 [RFC4443] Router Advertisement (RA) message. 93 Routers periodically broadcast the RA message to all on-link nodes. 94 They also unicast RA messages in response to solicitations. The RA 95 message contains: 97 o an M (Managed) flag 99 o an O (OtherConfig) flag 101 o zero or more Prefix Information (PI) Options 103 The M flag indicates that addresses are available from DHCPv6. The O 104 flag indicates that other configuration information (e.g., DNS- 105 related information) is available from DHCPv6. The PI Option 106 includes a prefix, an A (Autonomous) flag and other fields. The A 107 flag indicates that the prefix can be used for SLAAC. The M and O 108 flags are advisory, not prescriptive (although A flag is also 109 advisory in definition in standard, it is quite prescriptive in 110 implementations). For example, the M flag indicates that addresses 111 are available from DHCPv6. It does not indicate that hosts are 112 required to acquire addresses from DHCPv6. Similar statements can be 113 made about the O flag. 115 Because of the advisory definition of the flags, in some cases 116 different operating systems appear divergent behaviors. This 117 document analyzes possible divergent host behaviors might happen 118 (some of the possible divergent behaviors are already observed in 119 popular operating systems) and the operational problems might caused 120 by divergent behaviors. 122 2. The M, O and A Flags 124 This section briefly reviews how the M, O and A flags are defined in 125 [RFC4861]. 127 2.1. M (Managed) Flag 129 The M flag indicates that addresses are available from DHCPv6. If 130 the M flag is set, the O flag is redundant and can be ignored because 131 DHCPv6 will return all available configuration information. 133 M and A flag semantics are independent of one another. The M flag 134 indicates that addresses are available from DHCPv6, regardless of the 135 A flag setting. The following settings are all allowed: 137 o M=0 A=0 139 o M=0 A=1 141 o M=1 A=0 143 o M=1 A=1 145 2.2. O (Otherconfig) Flag 147 The O flag indicates that other configuration information (e.g., DNS- 148 related information) is available from DHCPv6. If the M flag is set, 149 the O flag is redundant and can be ignored because DHCPv6 will return 150 all available configuration information. 152 O and A flag semantics are independent of one another. The O flag 153 indicates that other configuration is available from DHCPv6, 154 regardless of the A flag setting. The following settings are all 155 allowed: 157 o O=0 A=0 159 o O=0 A=1 161 o O=1 A=0 163 o O=1 A=1 165 2.3. A (Autonomous) Flag 167 The A flag indicates that the prefix that is also carried by the PI 168 option can be used for SLAAC. A flag semantics are independent of M 169 and O flag semantics. The A flag indicates that the prefix can be 170 used by SLAAC, regardless of the M and O flag settings. 172 3. Behavior Ambiguity Analysis 174 The flags definition ambiguity means, on interpreting the same 175 messages, different hosts might behave differently. Thus it could be 176 un-controlled or un-predictable for administrators on some 177 operations. The ambiguity is summarized as the following aspects. 179 1) Dependency between DHCPv6 and RA 181 In standards, behavior of DHCPv6 and Neighbor Discovery protocols 182 is specified respectively. But it is not clear that whether there 183 should be any dependency between them. More specifically, it is 184 unclear whether RA (with M=1) is required to trigger DHCPv6; in 185 other words, It is unclear whether hosts should initiate DHCPv6 by 186 themselves If there are no RAs at all. 188 2) Interpretation on Flags Transition 190 When flags are in transition, e.g. the host is already SLAAC- 191 configured, then M flag changes from FALSE to TRUE, it is not 192 clear whether the host should start DHCPv6 or not; or vise versa, 193 the host is already both SLAAC/DHCPv6 configured, then M flag 194 change from TRUE to FALSE, it is also not clear whether the host 195 should turn DHCPv6 off or not. 197 3) Relationship between Address Configuring Method and Address 198 Lifetime 200 When one address configuration method is off, that is, the A flag 201 or M flag changes from TRUE to FALSE, it is not clear whether the 202 host should immediately release the corresponding address(es) or 203 just retain it(them) until expired. 205 4) Dependencies between the Flags 207 The semantics of the flags seems not totally independent, but the 208 standards didn't clearly clarify it. For example, when both M and 209 O flags are TRUE, it is not clear whether the host should initiate 210 one stateful DHCPv6 session to get both address and info- 211 configuration or initiate two independent sessions (one is 212 dedicated for address configuration and the other is for 213 information configuration). When A and M flags are FALSE and O 214 flag is TRUE, it is not clear whether the host should initiate a 215 stand-alone stateless DHCPv6 session. 217 Divergent behaviors on all the four aspects have been observed among 218 some popular operating systems as described in Section 4 below. 220 4. Observed Divergent Host Behaviors 222 The authors tested several popular operating systems in order to 223 determine what behaviors the M, O and A flag elicit. In some cases, 224 the M, O and A flags elicit divergent behaviors. The table below 225 characterizes those cases. For test details, please refer to 226 Appendix A. 228 Host State Input Behavior 230 Host has not No RA Some popular operating systems acquire 231 acquired any addresses from DHCPv6. Others do not. 232 addresses 234 Host has not RA Some popular operating systems acquire 235 acquired any with other information from DHCPv6, regardless 236 addresses M=0, of the A flag setting. Others do so, but 237 O=1 only if A=1 239 Host has acquired RA Some operating systems release DHCPv6 240 addresses from with M addresses immediately. Some release DHCPv6 241 DHCPv6 only (M = =0 addresses when they expire. 242 1) 244 Host has acquired RA Some operating systems acquire DHCPv6 245 addresses from with M addresses immediately. Others do so only if 246 SLAAC only (A=1) = 1 their SLAAC addresses expire and cannot be 247 refreshed. 249 5. Operational Problems 251 This section describes operational issues caused by the divergent 252 behaviors, described above. 254 5.1. Inappropriate Sources 256 Some operating systems base their decision to acquire configuration 257 information upon inappropriate sources. For example, some operating 258 systems acquire other configuration information if M=0, O=1, and A=1, 259 but not if M=0, O=1 and A=0. In other words, on some operating 260 systems, it is impossible to acquire other information from DHCPv6 261 (stateless DHCPv6 configuration) unless addresses are acquired from 262 either DHCPv6 or SLAAC. 264 5.2. Renumbering Issues 266 According to [RFC6879] a renumbering exercise can include the 267 following steps: 269 o Causing hosts that have acquired addresses from one auto- 270 configuration mechanism to release those addresses and acquire new 271 addresses from another auto-configuration mechanism 273 o Causing hosts that have acquired addresses from one auto- 274 configuration mechanism to release those addresses and acquire new 275 addresses from the same auto-configuration mechanism 277 o Causing hosts that have acquired addresses from one auto- 278 configuration mechanism to retain those addresses and acquire new 279 addresses from another auto-configuration mechanism 281 Ideally, these steps could be initiated by broadcasting RA message 282 onto the subnetwork that is being renumbered. Sadly, this is not 283 possible, because the RA message may elicit a different behavior from 284 each host. According to Section 4, renumbering operations would have 285 the following limitations: 287 o When M flag is turned off, some operating systems release DHCPv6 288 acquired addresses immediately, while other will retain then until 289 they expire. This means a flash switch from DHCPv6 to SLAAC would 290 happen on some hosts. Normally, the "make-before-break" approach 291 proposed in [RFC4192] is considered better than flash renumbering. 293 o On some operating systems, if a host has acquired addresses from 294 SLAAC, it is impossible to acquire additional addresses from 295 DHCPv6. This may be required as part of a renumbering operation. 297 6. Security Considerations 299 As this memo does not introduce any new protocols or procedures, it 300 does not introduce any new security vulnerabilities. 302 7. IANA Considerations 304 This draft does not request any IANA action. 306 8. Acknowledgements 308 The authors wish to acknowledge BNRC-BUPT (Broad Network Research 309 Centre in Beijing University of Posts and Telecommunications) for 310 their testing efforts. Special thanks to Xudong Shi, Longyun Yuan 311 and Xiaojian Xue for their extraordinary effort. 313 Special thanks to Ron Bonica who made a lot of significant 314 contribution to this draft, including draft editing and presentations 315 which dramatically improved this work. 317 The authors also wish to acknowledge Brian E Carpenter, Ran Atkinson, 318 Mikael Abrahamsson, Tatuya Jinmei, Mark Andrews and Mark Smith for 319 their helpful comments. 321 9. References 323 9.1. Normative References 325 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 326 (IPv6) Specification", RFC 2460, December 1998. 328 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 329 Message Protocol (ICMPv6) for the Internet Protocol 330 Version 6 (IPv6) Specification", RFC 4443, March 2006. 332 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 333 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 334 September 2007. 336 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 337 Address Autoconfiguration", RFC 4862, September 2007. 339 9.2. Informative References 341 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 342 and M. Carney, "Dynamic Host Configuration Protocol for 343 IPv6 (DHCPv6)", RFC 3315, July 2003. 345 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 346 (DHCP) Service for IPv6", RFC 3736, April 2004. 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 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 353 Network Renumbering Scenarios, Considerations, and 354 Methods", RFC 6879, February 2013. 356 Appendix A. Test Results 358 A.1. Test Environment 359 /-----\ 360 +---------+ // \\ 361 | DHCPv6 | | Router | 362 | server | \\ // 363 +----+----+ \--+--/ 364 | | 365 | | 366 | | 367 ----+--+----------+----------+---+----- 368 | | | 369 | | | 370 | | | 371 +----+---+ +----+---+ +----+---+ 372 | | | | | | 373 | Host 1 | | Host 2 | | Host 3 | 374 +--------+ +--------+ +--------+ 376 Figure 1: Test Environment 378 The test environment depicted Figure 1 in was replicated on a single 379 server using VMware. For simplicity of operation, only one host was 380 run at a time. Network elements were as follows: 382 o Router: Quagga 0.99-19 soft router installed on Ubuntu 11.04 383 virtual host 385 o DHCPv6 Server: Dibbler-server installed on Ubuntu 11.04 virtual 386 host 388 o Host 1: Window 7 / Window 8.1 Virtual Host 390 o Host 2: Ubuntu 14.04 (Linux Kernel 3.12.0) Virtual Host 392 o Host 3: Mac OS X v10.9 Virtual Host 394 o Host 4: IOS 8.0 (model: Apple iPhone 5S, connected via wifi) 396 A.2. Host Behavior in the Initial State 398 The bullet list below describes host behavior in the initial state, 399 when the host has not yet acquired any auto-configuration 400 information. Each bullet item represents an input and the behavior 401 elicited by that input. 403 o A=0, M=0, O=0 405 * Windows 8.1 acquired addresses and other information from 406 DHCPv6. 408 * All other hosts acquired no configuration information. 410 o A=0, M=0, O=1 412 * Windows 8.1 acquired addresses and other information from 413 DHCPv6. 415 * Windows 7, OSX 10.9 and IOS 8.0 acquired other information from 416 DHCPv6. 418 * Ubuntu 14.04 acquired no configuration information. 420 o A=0, M=1, O=0 422 * All hosts acquired addresses and other information from DHCPv6. 424 o A=0, M=1, O=1 426 * All hosts acquired addresses and other information from DHCPv6. 428 o A=1, M=0, O=0 430 * Windows 8.1 acquired addresses from SLAAC and DHCPv6. It also 431 acquired non-address information from DHCPv6. 433 * All the other host acquired addresses from SLAAC 435 o A=1, M=0, O=1 437 * Windows 8.1 acquired addresses from SLAAC and DHCPv6. It also 438 acquired other information from DHCPv6. 440 * All the other hosts acquired addresses from SLAAC and other 441 information from DHCPv6. 443 o A=1, M=1, O=0 445 * All hosts acquired addresses from SLAAC and DHCPv6. They also 446 acquired other information from DHCPv6. 448 o A=1, M=1, O=1 450 * All hosts acquired addresses from SLAAC and DHCPv6. They also 451 acquired other information from DHCPv6. 453 As showed above, four inputs result in divergent behaviors. 455 A.3. Host Behavior in State Transitions 457 The bullet list below describes behavior elicited during state 458 transitions. The value x can represents both 0 and 1. 460 o Old state (M = x, O = x, A = 1) , New state (M = x, O = x, A = 0) 461 (This means a SLAAC-configured host, which is regardless of DHCPv6 462 configured or not, receiving A in transition from 1 to 0. ) 464 * All the hosts retain SLAAC addresses until they expire 466 o Old state (M = 0, O = x, A = 1), New state (M = 1, O = x, A = 1) 467 (This means a SLAAC-only host receiving M in transition from 0 to 468 1.) 470 * Windows 7 acquires addresses from DHCPv6, immediately. 472 * Ubuntu 14.04/OSX 10.9/IOS 8.0 acquires addresses from DHCPv6 473 only if the SLAAC addresses are allowed to expire 475 * Windows 8.1 was not tested because it always acquire addresses 476 from DHCPv6 regardless of the M flag setting. 478 o Old state (M = 1, O = x, A = x), New state (M = 0, O = x, A = x) 479 (This means a DHCPv6-configured host receiving M in transition 480 from 1 to 0.) 482 * Windows 7 immediately released the DHCPv6 address 484 * Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0 keep the DHCPv6 485 addresses until they expire 487 o Old state (M = 1, O = x, A = 0), New state (M = 1, O = x, A = 1) 488 (This means a DHCPv6-only host receiving A in transition from 0 to 489 1.) 491 * All host acquire addresses from SLAAC 493 o Old state (M = 0, O = 1, A = x), New state (M = 1, O = 1, A = x) 494 (This means a Stateless DHCPv6-configured host [RFC3736], which is 495 regardless of SLAAC configured or not, receiving M in transition 496 from 0 to 1 with keeping O=1 ) 498 * Windows 7 acquires addresses and refreshes other information 499 from DHCPv6 501 * Ubuntu 14.04/OSX 10.9/IOS 8.0 does nothing 502 * Windows 8.1 was not tested because it always acquire addresses 503 from DHCPv6 regardless of the M flag setting. 505 o Old state (M = 1, O = 1, A = x), New state (M = 0, O = 1, A = x) 506 (This means a Stateful DHCPv6-configured host, which is regardless 507 of SLAAC configured or not, receiving M in transition from 0 to 1 508 with keeping O=1 ) 510 * Windows 7 released all DHCPv6 addresses and refreshes all 511 DHCPv6 other information. 513 * Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0 does nothing 515 Authors' Addresses 517 Bing Liu 518 Huawei Technologies 519 Q14, Huawei Campus, No.156 Beiqing Road 520 Hai-Dian District, Beijing, 100095 521 P.R. China 523 Email: leo.liubing@huawei.com 525 Sheng Jiang 526 Huawei Technologies 527 Q14, Huawei Campus, No.156 Beiqing Road 528 Hai-Dian District, Beijing, 100095 529 P.R. China 531 Email: jiangsheng@huawei.com 533 Xiangyang Gong 534 BUPT University 535 No.3 Teaching Building 536 Beijing University of Posts and Telecommunications (BUPT) 537 No.10 Xi-Tu-Cheng Rd. 538 Hai-Dian District, Beijing 539 P.R. China 541 Email: xygong@bupt.edu.cn 542 Wendong Wang 543 BUPT University 544 No.3 Teaching Building 545 Beijing University of Posts and Telecommunications (BUPT) 546 No.10 Xi-Tu-Cheng Rd. 547 Hai-Dian District, Beijing 548 P.R. China 550 Email: wdwang@bupt.edu.cn