idnits 2.17.1 draft-liu-bonica-dhcpv6-slaac-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 : ---------------------------------------------------------------------------- ** There are 3 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 143: '...rticular, a host MUST NOT reinvoke sta...' RFC 2119 keyword, line 165: '...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 (February 18, 2013) is 4085 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 270, but not defined == Unused Reference: 'RFC3736' is defined on line 356, but no explicit reference was found in the text == Unused Reference: 'RFC5887' is defined on line 359, 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 (~~), 4 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: August 21, 2013 Juniper Networks 5 February 18, 2013 7 DHCPv6/SLAAC Address Configuration Interaction Problem Statement 8 draft-liu-bonica-dhcpv6-slaac-problem-00.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 August 21, 2013. 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 ....................................... 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. Test of Current Implementations ......................... 5 58 2.2.1. Host Initialing Behavior ........................... 6 59 2.2.2. Host SLAAC/DHCPv6 Switching Behavior ............... 7 60 2.2.3. Host Stateful/Stateless DHCPv6 Behavior ............ 7 61 3. Potential Operational Gaps of DHCPv6/SLAAC Interaction ....... 7 62 3.1. Renumbering ............................................. 7 63 3.2. Strong Management ....................................... 8 64 4. Conclusions .................................................. 8 65 5. Security Considerations ...................................... 8 66 6. IANA Considerations .......................................... 8 67 7. References ................................................... 9 68 7.1. Normative References .................................... 9 69 7.2. Informative References .................................. 9 70 8. Acknowledgments .............................................. 9 71 Authors' Addresses ............................................. 10 73 1. Introduction 75 In IPv6, both of the DHCPv6 [RFC3315] and Neighbor Discovery [RFC4861] 76 protocols can provide automatic IP address configuration for the 77 hosts. They are known as stateful address auto-configuration and 78 SLAAC (stateless address auto-configuration)[RFC4862], and are 79 suitable for different scenarios respectively. Sometimes the two 80 address configuration modes may be both available in one network. 82 In ND protocol, there is a M (ManagedFlag) flag defined in RA message, 83 indicating the hosts there is DHCPv6 service in the network if the 84 flag is set. And there is an O "OtherConfigFlag", if set, indicating 85 configure information other than addresses (e.g. DNS, Route .etc) is 86 available through DHCPv6 configuration. Moreover, there's another A 87 (Autonomous) flag defined in ND, which indicating the hosts to do 88 SLAAC, may also influent the behavior of hosts. 90 So with the A/M/O flags, the two separated address configuration 91 modes are somehow correlated. But for some reason, the ND protocol 92 didn't define the flags as prescriptive but only advisory. This 93 ambiguous definition may vary the behavior of hosts when interpreting 94 the flags. In section 2, we provided a brief test result to identify 95 different host operating systems have taken different approaches. 96 This would add additional complexity for both the hosts and the 97 network management. 99 This draft reviews the standard definition of the above mentioned 100 flags, and provides a test result of several major desktop operating 101 systems' behavior. And then identifies potential requirement/gaps of 102 DHCPv6/SLAAC interaction. 104 2. Host Behavior of DHCPv6/SLAAC Interaction 106 In this section, we analyzed A/M/O flags definition, and provide the 107 test result of host behavior of interpreting these flags in 108 mainstream operating systems implementations. 110 Please note that, A flag has no direct relationship with DHCPv6, but 111 it is somewhat correlated with M/O flags. 113 2.1. Relevant RA Flags 115 2.1.1. A (Autonomous) Flag 117 In ND Prefix Information Option, there is a 1-bit autonomous address- 118 configuration flag (A flag). When set indicates that this prefix can 119 be used for stateless address configuration as specified in SLAAC. 121 For the host behavior, there is an explicit rule in the SLAAC 122 specification [RFC4862]: "If the Autonomous flag is not set, silently 123 ignore the Prefix Information option." 125 But when A flag is set, the SLAAC protocol didn't provide a 126 prescriptive definition. 128 2.1.2. M (Managed) Flag 130 In earlier SLAAC specification [RFC2462], the host behavior of 131 interpreting M flag is as below: 133 "On receipt of a valid Router Advertisement, a host copies the value 134 of the advertisement's M bit into ManagedFlag. If the value of 135 ManagedFlag changes from FALSE to TRUE, and the host is not already 136 running the stateful address autoconfiguration protocol, the host 137 should invoke the stateful address auto-configuration protocol, 138 requesting both address information and other information. If the 139 value of the ManagedFlag changes from TRUE to FALSE, the host should 140 continue running the stateful address auto-configuration, i.e., the 141 change in the value of the ManagedFlag has no effect. If the value 142 of the flag stays unchanged, no special action takes place. In 143 particular, a host MUST NOT reinvoke stateful address configuration 144 if it is already participating in the stateful protocol as a result 145 of an earlier advertisement." 147 But in the updated SLAAC specification [RFC4862], the relative 148 description was removed, the reason was "considering the maturity of 149 implementations and operational experiences. ManagedFlag and 150 OtherConfigFlag were removed accordingly. (Note that this change does 151 not mean the use of these flags is deprecated.)" 153 2.1.3. O (Otherconfig) Flag 155 As mentioned above, the situation of O flag is similar with M. In 156 earlier SLAAC [RFC2462], the host behavior is clear: 158 "If the value of OtherConfigFlag changes from FALSE to TRUE, the host 159 should invoke the stateful autoconfiguration protocol, requesting 160 information (excluding addresses if ManagedFlag is set to FALSE). If 161 the value of the OtherConfigFlag changes from TRUE to FALSE, the host 162 should continue running the stateful address autoconfiguration 163 protocol, i.e., the change in the value of OtherConfigFlag has no 164 effect. If the value of the flag stays unchanged, no special action 165 takes place. In particular, a host MUST NOT reinvoke stateful 166 configuration if it is already participating in the stateful protocol 167 as a result of an earlier advertisement." 169 And there's another description of the relationship of M and O flags 170 in [RFC2462]: 172 "In addition, when the value of the ManagedFlag is TRUE, the value of 173 OtherConfigFlag is implicitely TRUE as well. It is not a valid 174 configuration for a host to use stateful address autoconfiguration to 175 request addresses only, without also accepting other configuration 176 information." 178 2.2. Test of Current Implementations 180 /-----\ 181 +---------+ // \\ 182 | DHCPv6 | | Router | 183 | server | \\ // 184 +----+----+ \--+--/ 185 | | 186 | | 187 | | 188 ----+--+----------+----------+---+----- 189 | | | 190 | | | 191 | | | 192 +----+---+ +----+---+ +----+---+ 193 | | | | | | 194 | Host1 | | Host2 | | Host3 | 195 +--------+ +--------+ +--------+ 197 Figure 1 Test Environment 199 The 5 elements were all created in Vmware in one computer, for ease 200 of operation. 202 - Router quagga 0.99-19 soft router installed on Ubuntu 11.04 203 virtual host 204 - DHCPv6 Server: dibbler-server installed on Ubuntu 11.04 virtual 205 host 206 - Host A Window 7 Virtual Host 207 - Host B Ubuntu 12.10 Virtual Host 208 - Host C Mac OS X v10.7 Virtual Host 210 2.2.1. Host Initialing Behavior 212 Host from non-configured to configured, we tested different A/M/O 213 combinations in each OS platform. The states are enumerated as the 214 following, 3 operation systems respectively: 216 o Window 7 217 - A=0&M=O&O=0, non-config 218 - A=1&M=0&O=0, SLAAC only 219 - A=1&M=0&O=1, SLAAC + Stateless DHCPv6 220 - A=1&M=1&O=0, SLAAC + DHCPv6 221 - A=1&M=1&O=1, SLAAC + DHCPv6 222 - A=0&M=1&O=0, DHCPv6 only (A=0 or Non-PIO) 223 - A=0&M=1&O=1, DHCPv6 only (A=0 or Non-PIO) 224 - A=0&M=0&O=1, Stateless DHCPv6 only 226 o Linux/MAC OS X 227 - A=0&M=O&O=0, non-config 228 - A=1&M=0&O=0, SLAAC only 229 - A=1&M=0&O=1, SLAAC + Stateless DHCPv6 230 - A=1&M=1&O=0, SLAAC + DHCPv6 231 - A=1&M=1&O=1, SLAAC + DHCPv6 232 - A=0&M=1&O=0, DHCPv6 only (A=0 or Non-PIO) 233 - A=0&M=1&O=1, DHCPv6 only (A=0 or Non-PIO) 234 - A=0&M=0&O=1, non-config 236 As showed above, Linux and MAC OSX acted the same way, but differated 237 from Windows 7. The only difference is when A=0&M=0&O=1, Windows 7 238 did stateless DHCPv6 while Linux/MAC OSX did nothing. 240 Result summary: 242 - A is interpreted as prescript in each OS at the initial state 243 - M is interpreted as prescript in each OS at the initial state 244 - O is interpreted as prescript in Windows 7 245 - A and M are independent in each OS at the initial state 246 - A and O are not totally independent in Linux and Mac, A=1 is 247 required for O=1 triggering DHCPv6 info-request 249 - M and O are not totally independent in each OS. M=1 has the 250 implication O=1 252 2.2.2. Host SLAAC/DHCPv6 Switching Behavior 254 o SLAAC-only host receiving A=0&M=1 255 - Window 7 would deprecate SLAAC and initiate DHCPv6 256 - Linux/MAC would keep SLAAC and don't initiate DHCPv6 unless SLAAC 257 is expired and no continuous RA 259 o DHCPv6-only host receiving A=1&M=0 260 - Window 7 would release DHCPv6 and do SLAAC 261 - Linux/MAC would keep DHCPv6 and do SLAAC 263 When the host has been configured, either by SLAAC or DHCPv6, the 264 operating systems interpreting the M flag quite differently. Windows 265 7 treats the flag as instruction, it even released DHCPv6 session 266 when M=0. Linux and OS X were likely to treat the flag as advisory, 267 when SLAAC was done, it won't care about M=1, and M=0 won't cause 268 operation for the already configured DHCPv6 addresses. 270 Please refer to [I-D.liu-6renum-dhcpv6-slaac-switching] for more 271 details. 273 2.2.3. Host Stateful/Stateless DHCPv6 Behavior 275 o StatelessDHCPv6-configured host receiving M=1 (while keeping O=1) 276 - Window 7 would initiate stateful DHCPv6, configuring address as 277 well as re-configuring other information 278 - Linux/MAC no action 280 o StatefullDHCPv6-configured host receiving M=0 (while keeping O=1) 281 - Window 7 would release all DHCPv6 configurations including 282 address and other information, and initiate stateless DHCPv6 283 - Linux/MAC no action 285 3. Potential Operational Gaps of DHCPv6/SLAAC Interaction 287 3.1. Renumbering 289 During IPv6 renumbering, the SLAAC-configured hosts can reconfigure 290 IP addresses by receiving ND Router Advertisement (RA) messages 291 containing new prefix information. The DHCPv6-configured hosts can 292 reconfigure addresses by initialing RENEW sessions when the current 293 addresses' lease time is expired or receiving the reconfiguration 294 messages initialed by the DHCPv6 servers. 296 The above mechanisms have an implicit assumption that SLAAC- 297 configured hosts will remain SLAAC while DHCPv6-managed hosts will 298 remain DHCPv6-managed. In [I-D.ietf-6renum-enterprise], it described 299 several renumbering scenarios in enterprise network. For example, the 300 network may split, merge, grow, relocate or reorganize. In these 301 situations, it is possible that SLAAC-configured hosts may need to 302 switch to DHCPv6-managed, or verse vice. This requirement has been 303 identified as a protocol gap in [I-D.ietf-6renum-gap-analysis]. 305 3.2. Strong Management 307 The interaction issue may cause inconvenience to the networks that 308 need strong management (for example, the enterprise networks and the 309 ISP CPE networks), because the host behavior of address configuration 310 is somehow un-controlled by the network side so that it may be 311 impossible to enforce the management policies. 313 4. Conclusions 315 - The host behavior of SLAAC/DHCPv6 interaction is ambiguous in 316 standard. 318 - The implementations have been varied on this issue. In [RFC4862] it 319 is said "Removed the text regarding the M and O flags, considering 320 the maturity of implementations and operational experiences." The 321 description seems not true any more. 323 - It is foreseeable that the un-uniformed host behavior can cause 324 operational gaps and complexity, e.g. in renumbering and strong 325 management. 327 5. Security Considerations 329 No more security considerations than the Neighbor Discovery protocol 330 [RFC4861]. 332 6. IANA Considerations 334 None. 336 7. References 338 7.1. Normative References 340 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 341 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 342 September 2007. 344 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 345 Address Autoconfiguration", RFC 4862, September 2007. 347 7.2. Informative References 349 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 350 Autoconfiguration", RFC 2462, December 1998. 352 [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and 353 M. Carney, "Dynamic Host Configuration Protocol for IPv6 354 (DHCPv6)", RFC 3315, July 2003. 356 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 357 (DHCP) Service for IPv6", RFC 3736, April 2004. 359 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 360 Still Needs Work", RFC 5887, May 2010. 362 [I-D.ietf-6renum-gap-analysis] 363 Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap 364 Analysis", Working in Progress, March 2012 366 [I-D.ietf-6renum-enterprise] 367 Jiang, S., and B. Liu, "IPv6 Enterprise Network Renumbering 368 Scenarios and Guidelines ", Working in Progress, March 2012. 370 8. Acknowledgments 372 The test was done by our research partner BNRC-BUPT (Broad Network 373 Research Centre in Beijing University of Posts and 374 Telecommunications). Thanks for the student Xudong Shi and the tutors 375 Prof. Wendong Wang and Prof. Xiangyang Gong. 377 This document was prepared using 2-Word-v2.0.template.dot. 379 Authors' Addresses 381 Bing Liu 382 Q14-4-A Building 383 Huawei Technologies Co., Ltd 384 Zhong-Guan-Cun Environment Protection Park, No.156 Beiqing Rd. 385 Hai-Dian District, Beijing 386 P.R. China 388 Email: leo.liubing@huawei.com 390 Ron Bonica 391 Juniper Networks 392 Sterling, Virginia 20164 393 USA 395 Email: rbonica@juniper.net