idnits 2.17.1 draft-liu-bonica-dhcpv6-slaac-problem-02.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 5 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 148: '...rticular, a host MUST NOT reinvoke sta...' RFC 2119 keyword, line 170: '...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 (September 16, 2013) is 3868 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.liu-6renum-dhcpv6-slaac-switching' is mentioned on line 437, but not defined == Unused Reference: 'RFC3736' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'RFC5887' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6renum-enterprise' is defined on line 330, 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 (~~), 5 warnings (==), 4 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: Proposed Standard R. Bonica 4 Expires: March 21, 2014 Juniper Networks 5 September 16, 2013 7 DHCPv6/SLAAC Address Configuration Interaction Problem Statement 8 draft-liu-bonica-dhcpv6-slaac-problem-02.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF). Note that other groups may also distribute working 17 documents as Internet-Drafts. The list of current Internet-Drafts is 18 at http://datatracker.ietf.org/drafts/current/. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 This Internet-Draft will expire on March 21, 2014. 27 Copyright Notice 29 Copyright (c) 2011 IETF Trust and the persons identified as the 30 document authors. All rights reserved. 32 This document is subject to BCP 78 and the IETF Trust's Legal 33 Provisions Relating to IETF Documents 34 (http://trustee.ietf.org/license-info) in effect on the date of 35 publication of this document. Please review these documents 36 carefully, as they describe your rights and restrictions with respect 37 to this document. Code Components extracted from this document must 38 include Simplified BSD License text as described in Section 4.e of 39 the Trust Legal Provisions and are provided without warranty as 40 described in the Simplified BSD License. 42 Abstract 44 This document analyzes the host behavior of DHCPv6/SLAAC interaction 45 issue. It reviews the standard definition of the host behaviors and 46 provides the test results of current mainstream implementations. Some 47 potential operational gaps of the interaction are also described. 49 Table of Contents 51 1. Introduction ................................................. 3 52 2. Host Behavior of DHCPv6/SLAAC Interaction .................... 3 53 2.1. Relevant RA Flags Defined in Standards .................. 4 54 2.1.1. A (Autonomous) Flag ................................ 4 55 2.1.2. M (Managed) Flag ................................... 4 56 2.1.3. O (Otherconfig) Flag ............................... 4 57 2.2. Behaviors of Current Implementations .................... 5 58 2.2.1. A flag ................................... ......... 5 59 2.2.2. M flag ..................................... ....... 5 60 2.2.3. O flag ........................................ .... 6 61 3. Possible Operational Gaps of DHCPv6/SLAAC Interaction ........ 6 62 3.1. Renumbering ............................................. 6 63 3.2. Cold Start Problems ..................................... 7 64 3.3. Strong Management ....................................... 7 65 4. Conclusions .................................................. 7 66 5. Security Considerations ...................................... 7 67 6. IANA Considerations .......................................... 7 68 7. References ................................................... 8 69 7.1. Normative References .................................... 8 70 7.2. Informative References .................................. 8 71 8. Acknowledgments .............................................. 8 72 Appendix A. Test Details of Host Behaviors ..................... 10 73 A.1 Host Initialing Behavior ................................ 10 74 A.2 Host SLAAC/DHCPv6 Switching Behavior .................... 11 75 A.3 Host Stateful/Stateless DHCPv6 Behavior ................. 12 76 Authors' Addresses ............................................. 13 78 1. Introduction 80 In IPv6, both of the DHCPv6 [RFC3315] and Neighbor Discovery [RFC4861] 81 protocols can provide automatic IP address configuration for the 82 hosts. They are known as stateful address auto-configuration and 83 SLAAC (stateless address auto-configuration)[RFC4862], and are 84 suitable for different scenarios respectively. Sometimes the two 85 address configuration modes may be both available in one network. 87 In ND protocol, there is a M (ManagedFlag) flag defined in RA message, 88 indicating the hosts there is DHCPv6 service in the network if the 89 flag is set. And there is an O "OtherConfigFlag", if set, indicating 90 configure information other than addresses (e.g. DNS, Route .etc) is 91 available through DHCPv6 configuration. Moreover, there's another A 92 (Autonomous) flag defined in ND, which indicating the hosts to do 93 SLAAC, may also influent the behavior of hosts. 95 So with the A/M/O flags, the two separated address configuration 96 modes are somehow correlated. But for some reason, the ND protocol 97 didn't define the flags as prescriptive but only advisory. This 98 ambiguous definition may vary the behavior of hosts when interpreting 99 the flags. In section 2, we provided a brief test result to identify 100 different host operating systems have taken different approaches. 101 This would add additional complexity for both the hosts and the 102 network management. 104 This draft reviews the standard definition of the above mentioned 105 flags, and provides a test result of several major desktop operating 106 systems' behavior. And then identifies potential requirement/gaps of 107 DHCPv6/SLAAC interaction. 109 2. Host Behavior of DHCPv6/SLAAC Interaction 111 In this section, we analyzed A/M/O flags definition, and provide the 112 test result of host behavior of interpreting these flags in 113 mainstream operating systems implementations. 115 Please note that, A flag has no direct relationship with DHCPv6, but 116 it is somewhat correlated with M/O flags. 118 2.1. Relevant RA Flags Defined in Standards 120 2.1.1. A (Autonomous) Flag 122 In ND Prefix Information Option, the autonomous address-configuration 123 flag (A flag). When set indicates that this prefix can be used for 124 stateless address configuration as specified in SLAAC. 126 For the host behavior, there is an explicit rule in the SLAAC 127 specification [RFC4862]: "If the Autonomous flag is not set, silently 128 ignore the Prefix Information option." 130 But when A flag is set, the SLAAC protocol didn't provide a 131 prescriptive definition. 133 2.1.2. M (Managed) Flag 135 In earlier SLAAC specification [RFC2462], the host behavior of 136 interpreting M flag is as below: 138 "On receipt of a valid Router Advertisement, a host copies the value 139 of the advertisement's M bit into ManagedFlag. If the value of 140 ManagedFlag changes from FALSE to TRUE, and the host is not already 141 running the stateful address autoconfiguration protocol, the host 142 should invoke the stateful address auto-configuration protocol, 143 requesting both address information and other information. If the 144 value of the ManagedFlag changes from TRUE to FALSE, the host should 145 continue running the stateful address auto-configuration, i.e., the 146 change in the value of the ManagedFlag has no effect. If the value 147 of the flag stays unchanged, no special action takes place. In 148 particular, a host MUST NOT reinvoke stateful address configuration 149 if it is already participating in the stateful protocol as a result 150 of an earlier advertisement." 152 But in the updated SLAAC specification [RFC4862], the relative 153 description was removed, the reason was "considering the maturity of 154 implementations and operational experiences. ManagedFlag and 155 OtherConfigFlag were removed accordingly. (Note that this change does 156 not mean the use of these flags is deprecated.)" 158 2.1.3. O (Otherconfig) Flag 160 As mentioned above, the situation of O flag is similar with M. In 161 earlier SLAAC [RFC2462], the host behavior is clear: 163 "If the value of OtherConfigFlag changes from FALSE to TRUE, the host 164 should invoke the stateful autoconfiguration protocol, requesting 165 information (excluding addresses if ManagedFlag is set to FALSE). If 166 the value of the OtherConfigFlag changes from TRUE to FALSE, the host 167 should continue running the stateful address autoconfiguration 168 protocol, i.e., the change in the value of OtherConfigFlag has no 169 effect. If the value of the flag stays unchanged, no special action 170 takes place. In particular, a host MUST NOT reinvoke stateful 171 configuration if it is already participating in the stateful protocol 172 as a result of an earlier advertisement." 174 And there's another description of the relationship of M and O flags 175 in [RFC2462]: 177 "In addition, when the value of the ManagedFlag is TRUE, the value of 178 OtherConfigFlag is implicitely TRUE as well. It is not a valid 179 configuration for a host to use stateful address autoconfiguration to 180 request addresses only, without also accepting other configuration 181 information." 183 2.2. Behaviors of Current Implementations 185 We did tests of current 3 mainstream desktop operating systems on the 186 behaviors; please refer to the appendix for details. This section 187 illustrates the important results of the tests. 189 2.2.1. A flag 191 A flag is a switch to control whether to do SLAAC, and it is 192 independent with M/O flags, in another word, A is independent with 193 DHCPv6. 195 At the non-SLAAC-config state (either non-configured or DHCPv6- 196 configured only), the 3 OSes acted the same with A flag, if A set, 197 they all configured SLAAC, it is obvious and reasonable. But when 198 SLAAC-configured, and A changed from 1 to 0, the behaviors varied, 199 some deprecated SLAAC while some ignored the RA messages. 201 2.2.2. M flag 203 M is a key flag to interact ND/DHCPv6, but the host behaviors on M 204 flag were quite different. 206 In our test, one OS treats the flag as instruction, it even released 207 DHCPv6 session when M=0. But the other two just treat the flag as 208 advisory, when SLAAC was done, it won't care about M=1, and M=0 won't 209 cause operation for the already configured DHCPv6 addresses. Moreover, 210 the two OSes even would not initiate DHCPv6 session until they 211 receives RA messages with M=1, this behavior has an implication that 212 DHCPv6 somehow depends on ND. 214 Please refer to [I-D.liu-6renum-dhcpv6-slaac-switching] for more 215 details. 217 2.2.3. O flag 219 In our tests, when M flag is set, the O flag is implicitly set as 220 well; in another word, the hosts would not initial stateful DHCPv6 221 and stateless DHCPv6 respectively. This is a reasonable behavior. 223 But the O flag is not independent from A flag in some OSes. In our 224 test, there are two OSes won't initiate stateless DHCPv6 when A flag 225 is not set, that is to say, it is not applicable to have a "stateless 226 DHCPv6 only" configuration state for some operating systems; it is 227 also not applicable for these two OSes to switch between stateful 228 DHCPv6 and stateless DHCPv6 (according to O flag changing from 0 to 1 229 or verse vice). 231 3. Possible Operational Gaps of DHCPv6/SLAAC Interaction 233 According to the abovementioned tests, there are possible operational 234 issues as the following. 236 3.1. Renumbering 238 During IPv6 renumbering, the SLAAC-configured hosts can reconfigure 239 IP addresses by receiving ND Router Advertisement (RA) messages 240 containing new prefix information. The DHCPv6-configured hosts can 241 reconfigure addresses by initialing RENEW sessions when the current 242 addresses' lease time is expired or receiving the reconfiguration 243 messages initialed by the DHCPv6 servers. 245 The above mechanisms have an implicit assumption that SLAAC- 246 configured hosts will remain SLAAC while DHCPv6-managed hosts will 247 remain DHCPv6-managed. But in some situations, SLAAC-configured hosts 248 may need to switch to DHCPv6-managed, or verse vice. In [I-D.ietf- 249 6renum-enterprise], it described several renumbering scenarios in 250 enterprise network for this requirement; for example, the network may 251 split, merge, relocate or reorganize. But due to current 252 implementations, this requirement is not applicable and has been 253 identified as a gap in [I-D.ietf-6renum-gap-analysis]. 255 3.2. Cold Start Problems 257 If all nodes, or many nodes, restart at the same time after a power 258 cut, the results might not consistent. 260 3.3. Strong Management 262 Since the host behavior of address configuration is somehow un- 263 controlled by the network side, it might cause gaps to the networks 264 that need strong management (for example, the enterprise networks and 265 the ISP CPE networks). Examples are: 267 - the network wants the hosts to do DHCPv6-only configuration, it is 268 not applicable for some operating systems due to current 269 implementation unless manually configure the hosts to DHCPv6-only 270 model 271 - the hosts have been SLAAC-configured, then the network need the 272 hosts to do DHCPv6 simultaneously (e.g. for multihoming) 273 - the network wants the hosts to do statelssDHCPV6-only; for example, 274 the hosts are configured with self-generated addresses (e.g. ULA), 275 and they also need to contact the DHCPv6 server for info- 276 configuration 278 4. Conclusions 280 - The host behavior of SLAAC/DHCPv6 interaction is ambiguous in 281 standard. 283 - The implementations have been varied on this issue. In [RFC4862] it 284 is said "Removed the text regarding the M and O flags, considering 285 the maturity of implementations and operational experiences." The 286 description seems not true anymore. 288 - It is foreseeable that the un-uniformed host behavior can cause 289 operational gaps, e.g. in renumbering and strong management. 291 5. Security Considerations 293 No more security considerations than the Neighbor Discovery protocol 294 [RFC4861]. 296 6. IANA Considerations 298 None. 300 7. References 302 7.1. Normative References 304 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 305 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 306 September 2007. 308 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 309 Address Autoconfiguration", RFC 4862, September 2007. 311 7.2. Informative References 313 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 314 Autoconfiguration", RFC 2462, December 1998. 316 [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and 317 M. Carney, "Dynamic Host Configuration Protocol for IPv6 318 (DHCPv6)", RFC 3315, July 2003. 320 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 321 (DHCP) Service for IPv6", RFC 3736, April 2004. 323 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 324 Still Needs Work", RFC 5887, May 2010. 326 [I-D.ietf-6renum-gap-analysis] 327 Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap 328 Analysis", Working in Progress, March 2012 330 [I-D.ietf-6renum-enterprise] 331 Jiang, S., and B. Liu, "IPv6 Enterprise Network Renumbering 332 Scenarios and Guidelines ", Working in Progress, March 2012. 334 8. Acknowledgments 336 The test was done by our research partner BNRC-BUPT (Broad Network 337 Research Centre in Beijing University of Posts and 338 Telecommunications). Thanks for the hard efficient work of student 339 Xudong Shi and the tutors Prof. Wendong Wang and Prof. Xiangyang Gong. 341 Valuable comment was received from Brian E Carpenter to improve the 342 draft. 344 This document was prepared using 2-Word-v2.0.template.dot. 346 Appendix A. Test Details of Host Behaviors 348 /-----\ 349 +---------+ // \\ 350 | DHCPv6 | | Router | 351 | server | \\ // 352 +----+----+ \--+--/ 353 | | 354 | | 355 | | 356 ----+--+----------+----------+---+----- 357 | | | 358 | | | 359 | | | 360 +----+---+ +----+---+ +----+---+ 361 | | | | | | 362 | Host1 | | Host2 | | Host3 | 363 +--------+ +--------+ +--------+ 365 Figure 1 Test Environment 367 The 5 elements were all created in Vmware in one computer, for ease 368 of operation. 370 - Router quagga 0.99-19 soft router installed on Ubuntu 11.04 371 virtual host 372 - DHCPv6 Server: dibbler-server installed on Ubuntu 11.04 virtual 373 host 374 - Host A Window 7 Virtual Host 375 - Host B Ubuntu 12.10 Virtual Host 376 - Host C Mac OS X v10.7 Virtual Host 378 A.1 Host Initialing Behavior 380 Host from non-configured to configured, we tested different A/M/O 381 combinations in each OS platform. The states are enumerated as the 382 following, 3 operation systems respectively: 384 o Window 7 385 - A=0&M=O&O=0, non-config 386 - A=1&M=0&O=0, SLAAC only 387 - A=1&M=0&O=1, SLAAC + Stateless DHCPv6 388 - A=1&M=1&O=0, SLAAC + DHCPv6 389 - A=1&M=1&O=1, SLAAC + DHCPv6 390 - A=0&M=1&O=0, DHCPv6 only (A=0 or Non-PIO) 391 - A=0&M=1&O=1, DHCPv6 only (A=0 or Non-PIO) 392 - A=0&M=0&O=1, Stateless DHCPv6 only 394 o Linux/MAC OS X 395 - A=0&M=O&O=0, non-config 396 - A=1&M=0&O=0, SLAAC only 397 - A=1&M=0&O=1, SLAAC + Stateless DHCPv6 398 - A=1&M=1&O=0, SLAAC + DHCPv6 399 - A=1&M=1&O=1, SLAAC + DHCPv6 400 - A=0&M=1&O=0, DHCPv6 only (A=0 or Non-PIO) 401 - A=0&M=1&O=1, DHCPv6 only (A=0 or Non-PIO) 402 - A=0&M=0&O=1, non-config 404 As showed above, Linux and MAC OSX acted the same way, but differated 405 from Windows 7. The only difference is when A=0&M=0&O=1, Windows 7 406 did stateless DHCPv6 while Linux/MAC OSX did nothing. 408 Result summary: 410 - A is interpreted as prescript in each OS at the initial state 411 - M is interpreted as prescript in each OS at the initial state 412 - O is interpreted as prescript in Windows 7 413 - A and M are independent in each OS at the initial state 414 - A and O are not totally independent in Linux and Mac, A=1 is 415 required for O=1 triggering DHCPv6 info-request 416 - M and O are not totally independent in each OS. M=1 has the 417 implication O=1 419 A.2 Host SLAAC/DHCPv6 Switching Behavior 421 o SLAAC-only host receiving A=0&M=1 422 - Window 7 would deprecate SLAAC and initiate DHCPv6 423 - Linux/MAC would keep SLAAC and don't initiate DHCPv6 unless SLAAC 424 is expired and no continuous RA 426 o DHCPv6-only host receiving A=1&M=0 427 - Window 7 would release DHCPv6 and do SLAAC 428 - Linux/MAC would keep DHCPv6 and do SLAAC 430 When the host has been configured, either by SLAAC or DHCPv6, the 431 operating systems interpreting the M flag quite differently. Windows 432 7 treats the flag as instruction, it even released DHCPv6 session 433 when M=0. Linux and OS X were likely to treat the flag as advisory, 434 when SLAAC was done, it won't care about M=1, and M=0 won't cause 435 operation for the already configured DHCPv6 addresses. 437 Please refer to [I-D.liu-6renum-dhcpv6-slaac-switching] for more 438 details. 440 A.3 Host Stateful/Stateless DHCPv6 Behavior 442 o StatelessDHCPv6-configured host receiving M=1 (while keeping O=1) 443 - Window 7 would initiate stateful DHCPv6, configuring address as 444 well as re-configuring other information 445 - Linux/MAC no action 447 o StatefullDHCPv6-configured host receiving M=0 (while keeping O=1) 448 - Window 7 would release all DHCPv6 configurations including 449 address and other information, and initiate stateless DHCPv6 450 - Linux/MAC no action 452 Authors' Addresses 454 Bing Liu 455 Q14-4-A Building 456 Huawei Technologies Co., Ltd 457 Zhong-Guan-Cun Environment Protection Park, No.156 Beiqing Rd. 458 Hai-Dian District, Beijing 459 P.R. China 461 Email: leo.liubing@huawei.com 463 Ron Bonica 464 Juniper Networks 465 Sterling, Virginia 20164 466 USA 468 Email: rbonica@juniper.net