idnits 2.17.1 draft-ietf-v6ops-dhcpv6-slaac-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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 152: '...rticular, a host MUST NOT reinvoke sta...' RFC 2119 keyword, line 174: '...rticular, a host MUST NOT reinvoke sta...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 18, 2014) is 3592 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3736' is defined on line 317, but no explicit reference was found in the text == Unused Reference: 'RFC5887' is defined on line 320, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- 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: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Liu 2 Internet Draft Huawei Technologies 3 Intended status: Informational R. Bonica 4 Expires: December 20, 2014 Juniper Networks 5 S. Jiang 6 Huawei Technologies 7 X. Gong 8 W. Wang 9 BUPT University 10 June 18, 2014 12 DHCPv6/SLAAC Address Configuration Interaction Problem Statement 13 draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute working 22 documents as Internet-Drafts. The list of current Internet-Drafts is 23 at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on December 18, 2014. 32 Copyright Notice 34 Copyright (c) 2011 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Abstract 49 This document analyzes the DHCPv6/SLAAC interaction issue on host. 50 More specifically, the interaction is regarding with the A, M, and O 51 flags which are defined in ND protocol. Test results identify that 52 current implementations in operating systems have varied on 53 interpreting the flags. The variation might cause some operational 54 issues as described in the document. 56 Table of Contents 58 1. Introduction ................................................. 3 59 2. Host Behavior Definition in Standards ........................ 3 60 2.1. A (Autonomous) Flag ..................................... 4 61 2.2. M (Managed) Flag ........................................ 4 62 2.3. O (Otherconfig) Flag .................................... 4 63 3. Problems Statement ........................................... 5 64 3.1. Host Behavior Ambiguity ................................. 5 65 3.2. Operational Problems Implication ........................ 6 66 3.2.1. Renumbering ........................................ 6 67 3.2.2. Cold Start Problem ................................. 6 68 3.2.3. Specific Management Patterns ....................... 7 69 4. Conclusions .................................................. 7 70 5. Security Considerations ...................................... 7 71 6. IANA Considerations .......................................... 7 72 7. References ................................................... 7 73 7.1. Normative References .................................... 7 74 7.2. Informative References .................................. 8 75 8. Acknowledgments .............................................. 8 76 Appendix A. Test Results of Host Behavior ....................... 9 77 A.1 Detailed Test Results .................................... 9 78 A.1.1 Host Initial Behavior .............................. 10 79 A.1.2 Host Behavior in Flags Transition .................. 10 80 A.2 Observations from the Test .............................. 11 82 1. Introduction 84 In IPv6, both of the DHCPv6 [RFC3315] and Neighbor Discovery [RFC4861] 85 protocols could be utilized for automatic IP address configuration 86 for the hosts. They are known as stateful address auto-configuration 87 and stateless address auto-configuration (SLAAC, [RFC4862]). 88 Sometimes the two address configuration methods might be both 89 available in one network. 91 In ND protocol, there is an M (Managed) flag defined in RA message, 92 indicating the hosts whether there is DHCPv6 service in the network 93 or not. And there is an O (OtherConfig) flag, if set, indicating 94 configure information other than addresses (e.g. DNS, Route .etc) is 95 available through DHCPv6 configuration. Moreover, there's another A 96 (Autonomous) flag defined in ND, indicating the hosts to do SLAAC, 97 may also influent the behavior of hosts. 99 So with these flags, the two address configuration mechanisms are 100 somehow correlated. But for some reasons, the ND protocol didn't 101 define the flags as prescriptive but only advisory. This ambiguous 102 definition might vary the behavior of interpreting the flags by 103 different hosts. This would add additional complexity for both the 104 hosts and the network management. 106 This draft reviews the standard definition of the above mentioned 107 flags, and identifies the potential ambiguous behavior of 108 interpreting these flags. And then analyzes what operational problems 109 might be caused by the ambiguous behavior. 111 In the appendix, detailed test results of several major desktop 112 operating systems' behavior of interpreting the flags are provided. 113 According to the test results, we can see the ambiguity problem is 114 actually happening in current implementations. 116 2. Host Behavior Definition in Standards 118 In this section, we analyzed A, M and O flags definition. 120 Please note that, A flag has no direct relationship with DHCPv6, but 121 it is somewhat correlated with M and O flags. 123 2.1. A (Autonomous) Flag 125 In ND Prefix Information Option, the autonomous address-configuration 126 flag (A flag)is used to indicate whether this prefix can be used for 127 SLAAC. 129 For the host behavior, there is an explicit rule in the SLAAC 130 specification [RFC4862]: "If the Autonomous flag is not set, silently 131 ignore the Prefix Information option." 133 But when A flag is set, the SLAAC protocol didn't provide a 134 prescriptive definition. (However, it is quite obvious that host 135 should do SLAAC when A flag is set.) 137 2.2. M (Managed) Flag 139 In earlier SLAAC specification [RFC2462], the host behavior of 140 interpreting M flag is as below: 142 "On receipt of a valid Router Advertisement, a host copies the value 143 of the advertisement's M bit into ManagedFlag. If the value of 144 ManagedFlag changes from FALSE to TRUE, and the host is not already 145 running the stateful address autoconfiguration protocol, the host 146 should invoke the stateful address auto-configuration protocol, 147 requesting both address information and other information. If the 148 value of the ManagedFlag changes from TRUE to FALSE, the host should 149 continue running the stateful address auto-configuration, i.e., the 150 change in the value of the ManagedFlag has no effect. If the value 151 of the flag stays unchanged, no special action takes place. In 152 particular, a host MUST NOT reinvoke stateful address configuration 153 if it is already participating in the stateful protocol as a result 154 of an earlier advertisement." 156 But in the updated SLAAC specification [RFC4862], the relative 157 description was removed, the reason was "considering the maturity of 158 implementations and operational experiences. ManagedFlag and 159 OtherConfigFlag were removed accordingly. (Note that this change does 160 not mean the use of these flags is deprecated.)" 162 2.3. O (Otherconfig) Flag 164 The situation of O flag is similar with above mentioned M flag. In 165 earlier SLAAC [RFC2462], the host behavior is clear: 167 "If the value of OtherConfigFlag changes from FALSE to TRUE, the host 168 should invoke the stateful autoconfiguration protocol, requesting 169 information (excluding addresses if ManagedFlag is set to FALSE). If 170 the value of the OtherConfigFlag changes from TRUE to FALSE, the host 171 should continue running the stateful address autoconfiguration 172 protocol, i.e., the change in the value of OtherConfigFlag has no 173 effect. If the value of the flag stays unchanged, no special action 174 takes place. In particular, a host MUST NOT reinvoke stateful 175 configuration if it is already participating in the stateful protocol 176 as a result of an earlier advertisement." 178 And there's another description of the relationship of M and O flags 179 in [RFC2462]: 181 "In addition, when the value of the ManagedFlag is TRUE, the value of 182 OtherConfigFlag is implicitely TRUE as well. It is not a valid 183 configuration for a host to use stateful address autoconfiguration to 184 request addresses only, without also accepting other configuration 185 information." 187 3. Problems Statement 189 3.1. Host Behavior Ambiguity 191 The main problem is standard definition ambiguity which means, on 192 interpreting the same messages, different hosts might behave 193 differently. Thus it could be un-controlled or un-predictable for 194 administrators on some operations. The ambiguity is summarized as the 195 following aspects. 197 #1 Dependency between DHCPv6 and RA 199 In standards, behavior of DHCPv6 and Neighbor Discovery protocols is 200 specified respectively. But it is not clear that whether there should 201 be any dependency between them. 203 More specifically, is RA (with M=1) required to trigger DHCPv6? If 204 there are no RAs at all, should hosts initiate DHCPv6 by themselves? 206 #2 Advisory or Prescriptive 208 Some platforms interpret the flags as advisory while others might 209 interpret them prescriptive. Especially when flags are in transition, 210 e.g. the host is already SLAAC-configured, then M flag changes from 211 FALSE to TRUE, it is not clear whether the host should start DHCPv6 212 or not; or vise versa, the host is already both SLAAC/DHCPv6 213 configured, then M flag change from TRUE to FALSE, it is also not 214 clear whether the host should turn DHCPv6 off or not. 216 #3 "Address Configuring Method" and "Address Lifetime" 217 When one address configuration method is off, that is, the A flag or 218 M flag changes from TRUE to FALSE, it is not clear whether the host 219 should immediately release the corresponding address(es) or just 220 retain it(them) until expired. 222 #4 Dependencies between the flags 224 The semantics of the flags seems not totally independent, but the 225 standards didn't clearly clarify it. For example, when both M and O 226 flags are TRUE, it is not clear whether the host should initiate one 227 stateful DHCPv6 session to get both address and info-configuration or 228 initiate two independent sessions of which one is dedicated for 229 address provisioning and the other is for information provision. When 230 A and M flags are FALSE and O flag is TRUE, it is not clear whether 231 the host should initiate a stand-alone stateless DHCPv6 session. 233 3.2. Operational Problems Implication 235 According to the abovementioned host behavior ambiguity, there might 236 be operational issues as the following. 238 3.2.1. Renumbering 240 During IPv6 renumbering, the SLAAC-configured hosts can reconfigure 241 IP addresses by receiving ND Router Advertisement (RA) messages 242 containing new prefix information. The DHCPv6-configured hosts can 243 reconfigure addresses by initialing RENEW sessions when the current 244 addresses' lease time is expired or receiving the reconfiguration 245 messages initialed by the DHCPv6 servers. 247 The above mechanisms have an implicit assumption that SLAAC- 248 configured hosts will remain SLAAC while DHCPv6-managed hosts will 249 remain DHCPv6-managed. But in some situations, SLAAC-configured hosts 250 might need to switch to DHCPv6-managed, or vice versa. In [RFC6879], 251 it described several renumbering scenarios in enterprise network for 252 this requirement; for example, the network may split, merge, relocate 253 or reorganize. But due to current implementations, this requirement 254 is not applicable and has been identified as a gap in [RFC7010]. 256 3.2.2. Cold Start Problem 258 If all nodes, or many nodes, restart at the same time after a power 259 cut, the results might not consistent. 261 3.2.3. Specific Management Patterns 263 Since the host behavior of address configuration is somehow un- 264 controlled by the network side, it might cause gaps to the networks 265 that need some specific management patterns. Examples are: 267 - the hosts have been SLAAC-configured, then the network need the 268 hosts to do DHCPv6 simultaneously (e.g. for multihoming). 269 - the network wants the hosts to do stateless DHCPV6-only; for 270 example, the hosts are configured with self-generated addresses (e.g. 271 ULA), and they also need to contact the DHCPv6 server for info- 272 configuration. 274 4. Conclusions 276 - The host behavior of SLAAC/DHCPv6 interaction is ambiguous in 277 standard. 279 - Varied behavior of implementations has been observed. In [RFC4862] 280 it is said "Removed the text regarding the M and O flags, considering 281 the maturity of implementations and operational experiences." This 282 consideration intended to remain the ambiguity. But in the 283 perspective of operation, ambiguity normally is problematic. 285 - It is foreseeable that the un-uniformed host behavior can cause 286 operational problems. 288 5. Security Considerations 290 No more security considerations than the Neighbor Discovery protocol 291 [RFC4861]. 293 6. IANA Considerations 295 None. 297 7. References 299 7.1. Normative References 301 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 302 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 303 September 2007. 305 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 306 Address Autoconfiguration", RFC 4862, September 2007. 308 7.2. Informative References 310 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 311 Autoconfiguration", RFC 2462, December 1998. 313 [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and 314 M. Carney, "Dynamic Host Configuration Protocol for IPv6 315 (DHCPv6)", RFC 3315, July 2003. 317 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 318 (DHCP) Service for IPv6", RFC 3736, April 2004. 320 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 321 Still Needs Work", RFC 5887, May 2010. 323 [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. 324 George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, 325 September 2013. 327 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 328 Network Renumbering Scenarios, Considerations, and Methods", 329 RFC 6879, February 2013. 331 8. Acknowledgments 333 The test was done by our research partner BNRC-BUPT (Broad Network 334 Research Centre in Beijing University of Posts and 335 Telecommunications). Thanks for the hard efficient work of student 336 Xudong Shi and Longyun Yuan. 338 Valuable comments were received from Sheng Jiang, Brian E Carpenter, 339 Ron Atkinson, Mikael Abrahamsson, Tatuya Jinmei, Mark Andrews and 340 Mark Smith to improve the draft. 342 This document was prepared using 2-Word-v2.0.template.dot. 344 Appendix A. Test Results of Host Behavior 346 We did tests of the behavior of interpreting the flags by current 347 mainstream desktop/mobile operating systems as the following. 349 A.1 Detailed Test Results 351 /-----\ 352 +---------+ // \\ 353 | DHCPv6 | | Router | 354 | server | \\ // 355 +----+----+ \--+--/ 356 | | 357 | | 358 | | 359 ----+--+----------+----------+---+----- 360 | | | 361 | | | 362 | | | 363 +----+---+ +----+---+ +----+---+ 364 | | | | | | 365 | Host1 | | Host2 | | Host3 | 366 +--------+ +--------+ +--------+ 368 Figure 1 Test Environment 370 The 5 elements were all created in Vmware in one computer, for ease 371 of operation. 373 - Router quagga 0.99-19 soft router installed on Ubuntu 11.04 374 virtual host 375 - DHCPv6 Server: dibbler-server installed on Ubuntu 11.04 virtual 376 host 377 - Host A Window 7 Virtual Host 378 - Host B Ubuntu 12.10 Virtual Host 379 - Host C Mac OS X v10.7 Virtual Host 381 Another test was done dedicated for the mobile phone operating 382 systems. The environment is similar (not in VMware, all are real PC 383 and mobile phones): 385 - Router quagga 0.99-17 soft router installed on Ubuntu 12.10 386 - DHCPv6 Server: dibbler-server installed on Ubuntu 12.10 387 - Host D Android 4.0.4 (kernel: 3.0.16-gfa98030; device: HTC 388 Incredible S) 389 - Host E IOS 6.1.3 (model: iPod Touch 4) 390 (Note: The tested Android version didn't support DHCPv6, so the 391 following results don't include Android.) 393 A.1.1 Host Initial Behavior 395 When hosts are not configured yet, we tested their behavior when 396 receiving different A/M/O combinations. The results are as the 397 following: 399 o Window 7/Apple IOS 400 - A=0&M=O&O=0, non-config 401 - A=1&M=0&O=0, SLAAC only 402 - A=1&M=0&O=1, SLAAC + Stateless DHCPv6 403 - A=1&M=1&O=0, SLAAC + DHCPv6 404 - A=1&M=1&O=1, SLAAC + DHCPv6 405 - A=0&M=1&O=0, DHCPv6 only (A=0 or Non-PIO) 406 - A=0&M=1&O=1, DHCPv6 only (A=0 or Non-PIO) 407 - A=0&M=0&O=1, Stateless DHCPv6 only 409 o Linux/MAC OS X 410 - A=0&M=O&O=0, non-config 411 - A=1&M=0&O=0, SLAAC only 412 - A=1&M=0&O=1, SLAAC + Stateless DHCPv6 413 - A=1&M=1&O=0, SLAAC + DHCPv6 414 - A=1&M=1&O=1, SLAAC + DHCPv6 415 - A=0&M=1&O=0, DHCPv6 only (A=0 or Non-PIO) 416 - A=0&M=1&O=1, DHCPv6 only (A=0 or Non-PIO) 417 - A=0&M=0&O=1, non-config 419 As showed above, Linux and MAC OSX acted the same way, but are 420 different from Windows 7 and Apple IOS. The only difference is when 421 A=0&M=0&O=1, Windows 7/Apple IOS did stateless DHCPv6 while Linux/MAC 422 OSX did nothing. 424 A.1.2 Host Behavior in Flags Transition 426 o SLAAC-only host receiving M=1 427 - Window 7 would initiate DHCPv6 428 - Linux/MAC/IOS would keep SLAAC and don't initiate DHCPv6 unless 429 SLAAC is expired and no continuous RAs 431 o DHCPv6-only host receiving A=1 432 - They all do SLAAC 434 o Stateless DHCPv6-configured host receiving M=1 (while keeping O=1) 435 - Window 7 would initiate stateful DHCPv6, configuring address as 436 well as re-configuring other information 437 - Linux/MAC/IOS no action 439 o Statefull DHCPv6-configured host receiving M=0 (while keeping O=1) 440 - Window 7 would release all DHCPv6 configurations including 441 address and other information, and initiate stateless DHCPv6 442 - Linux/MAC/IOS no action 444 A.2 Observations from the Test 446 o A flag 448 A flag is a switch to control whether to do SLAAC, and it is 449 independent with M and O flags, in another word, A is independent 450 with DHCPv6. 452 At the non-SLAAC-configured state (either non-configured or DHCPv6- 453 configured only), all the operating systems acted the same way in 454 interpreting A flag. If A flag is TRUE, they all configure SLAAC, it 455 is obvious and reasonable. 457 o M flag 459 M is a key flag to interact ND and DHCPv6, but the host behaviors on 460 M flag were quite different. 462 At the initialing state, some operating systems would start DHCPv6 463 only if receiving an RA message with M flag set while some would 464 initially start DHCPv6 if RAs are absent. This result reflects the 465 ambiguity problem of #1 Dependency between DHCPv6 and RA in above 466 text. 468 When the hosts are SLAAC-configured, and then the M flag changes from 469 FALSE to TRUE, some operating systems would initiate DHCPv6 while 470 some would not. This reflects the problem #2 Advisory or Prescriptive. 472 o O flag 474 In the test, when M flag is set, the O flag is implicitly set as well; 475 in another word, the hosts would not initial stateful DHCPv6 and 476 stateless DHCPv6 respectively. This is a reasonable behavior. 478 But the O flag is not independent from A flag in some operating 479 systems, which won't initiate stateless DHCPv6 when A flag is FALSE. 480 That is to say, it is not applicable to have a "stateless DHCPv6 481 only" configuration state for some operating systems; it is also not 482 applicable for these operating systems to switch between stateful 483 DHCPv6 and stateless DHCPv6 (according to O flag changing from TRUE 484 to FALSE or vice versa). This reflects the problem #4 Dependencies 485 between the flags. 487 Authors' Addresses 489 Bing Liu 490 Q14-4-A Building 491 Huawei Technologies Co., Ltd 492 Zhong-Guan-Cun Environment Protection Park, No.156 Beiqing Rd. 493 Hai-Dian District, Beijing 494 P.R. China 496 Email: leo.liubing@huawei.com 498 Ron Bonica 499 Juniper Networks 500 Sterling, Virginia 20164 501 USA 503 Email: rbonica@juniper.net 505 Xiangyang Gong 506 No.3 Teaching Building 507 Beijing University of Posts and Telecommunications (BUPT) 508 No.10 Xi-Tu-Cheng Rd. 509 Hai-Dian District, Beijing 510 P.R. China 512 Email: xygong@bupt.edu.cn 514 Wendong Wang 515 No.3 Teaching Building 516 Beijing University of Posts and Telecommunications (BUPT) 517 No.10 Xi-Tu-Cheng Rd. 518 Hai-Dian District, Beijing 519 P.R. China 521 Email: wdwang@bupt.edu.cn