idnits 2.17.1 draft-liu-6renum-dhcpv6-slaac-switching-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 130: '...rticular, a host MUST NOT reinvoke sta...' RFC 2119 keyword, line 340: '... messages with D=1, it MUST initiate a...' RFC 2119 keyword, line 343: '...-configured, and receives D=1, it MUST...' RFC 2119 keyword, line 345: '... SHOULD deprecate SLAAC-configured a...' RFC 2119 keyword, line 348: '...ges with R=1, it SHOULD release curren...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 15, 2013) is 4081 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: 'RFC2462' is mentioned on line 117, but not defined ** Obsolete undefined reference: RFC 2462 (Obsoleted by RFC 4862) == Unused Reference: 'RFC5887' is defined on line 377, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- No information found for draft-ietf-6renum-gap-analysis - is the name correct? -- No information found for draft-ietf-6renum-enterprise - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 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 Co., Ltd 3 Intended status: Proposed Standard W. Wang 4 Expires: July 18, 2013 X. Gong 5 University of BUPT 6 January 15, 2013 8 DHCPv6/SLAAC Address Configuration Switching for Host Renumbering 9 draft-liu-6renum-dhcpv6-slaac-switching-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute working 18 documents as Internet-Drafts. The list of current Internet-Drafts is 19 at http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on July 18, 2013. 28 Copyright Notice 30 Copyright (c) 2011 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with respect 38 to this document. Code Components extracted from this document must 39 include Simplified BSD License text as described in Section 4.e of 40 the Trust Legal Provisions and are provided without warranty as 41 described in the Simplified BSD License. 43 Abstract 44 Sometimes stateful DHCPv6 address configuration and SLAAC may be both 45 available in one network. In ND protocol, there is a "M" (ManagedFlag) 46 flag defined in RA message, which indicates the hosts the DHCPv6 47 service is available. But for some reason, the ND protocol didn't 48 define the flag as prescriptive but only advisory. This draft 49 proposes to use two reserved bits in RA message to let the network 50 control the hosts that which address configuration mode should be 51 used. This feature is useful for management, especially in a 52 renumbering event. 54 Table of Contents 56 1. Introduction ................................................. 3 57 2. DHCPv6/SLAAC interaction ..................................... 3 58 2.1. Host behavior defined in standards ...................... 3 59 2.2. Test of desktop operating systems' behavior ............. 4 60 2.2.1. Test environment ................................... 4 61 2.2.2. Test scenarios and results ......................... 5 62 2.2.3. Conclusion ......................................... 6 63 3. Requirement of Address Configuration Switching in Renumbering. 6 64 4. Proposed Standard Update ..................................... 7 65 4.1. Adding a "DHCPv6Required" Flag .......................... 8 66 4.2. Adding a "ReleaseDHCPv6" Flag ........................... 8 67 4.3. Host Behavior of Interpreting D/R Flag .................. 8 68 5. Security Considerations ...................................... 9 69 6. IANA Considerations .......................................... 9 70 7. References ................................................... 9 71 7.1. Normative References .................................... 9 72 7.2. Informative References .................................. 9 73 8. Acknowledgments .............................................. 9 74 Authors' Addresses ............................................. 10 76 1. Introduction 78 In IPv6, both of the DHCPv6 [RFC3315] and Neighbor Discovery [RFC4861] 79 protocols can provide automatic IP address configuration for the 80 hosts. They are known as stateful address auto-configuration and 81 SLAAC (stateless address auto-configuration)[RFC4862], and are 82 suitable for different scenarios respectively. 84 Sometimes the two address configuration modes may be both available 85 in one network. This would add more or less additional complexity for 86 both the hosts and the network management. In ND protocol, there is a 87 M (ManagedFlag) flag defined in RA message, which indicates the hosts 88 the DHCPv6 service status in the network. So with using the flag, the 89 two separated address configuration modes are somehow correlated. But 90 for some reason, the ND protocol didn't define the flag as 91 prescriptive but only advisory. This may vary the behavior of hosts 92 when interpreting the M flag. (Note that, there is another O 93 "OtherConfigFlag" flag also indicates the DHCPv6 service status, but 94 it is not in the scope of this draft since it is not about address 95 configuration.) 97 In RFC5887(Renumbering Still Needs Work),it also concerned the M flag 98 issue, it said, "Until this ambiguous behaviour is clearly resolved 99 by the IETF, operational problems are to be expected, since different 100 host operating systems have taken different approaches." In this 101 draft, we provided a brief test result in section 3 to identify 102 "different host operating systems have taken different approaches". 104 This issue may cause inconvenience to the networks that need strong 105 management (for example, the enterprise networks), because the host 106 behavior of address configuration is somehow un-controlled by the 107 network side so that it may violate the management policies. So in 108 section 4, we proposed to use one of the reserved bits in RA message 109 to let the network control the hosts that which address configuration 110 mode should be used. We believe this feature is useful for management, 111 especially in a renumbering event. 113 2. DHCPv6/SLAAC interaction 115 2.1. Host behavior defined in standards 117 In earlier SLAAC specification [RFC2462], the host behavior of 118 interpreting M flag is as below: 120 "On receipt of a valid Router Advertisement, a host copies the value 121 of the advertisement's M bit into ManagedFlag. If the value of 122 ManagedFlag changes from FALSE to TRUE, and the host is not already 123 running the stateful address autoconfiguration protocol, the host 124 should invoke the stateful address autoconfiguration protocol, 125 requesting both address information and other information. If the 126 value of the ManagedFlag changes from TRUE to FALSE, the host should 127 continue running the stateful address autoconfiguration, i.e., the 128 change in the value of the ManagedFlag has no effect. If the value 129 of the flag stays unchanged, no special action takes place. In 130 particular, a host MUST NOT reinvoke stateful address configuration 131 if it is already participating in the stateful protocol as a result 132 of an earlier advertisement." 134 But for some reason, the updated SLAAC specification [RFC4862] 135 removed the relative description, it said in the RFC "considering the 136 maturity of implementations and operational experiences. ManagedFlag 137 and OtherConfigFlag were removed accordingly. (Note that this change 138 does not mean the use of these flags is deprecated.)" So it feels 139 like the IETF encourages operating system vendors to behave as they 140 prefer to do. In the following section 2.2, we provided a test about 141 current desktop operating systems' behavior of DHCPv6/SLAAC 142 interaction. 144 2.2. Test of desktop operating systems' behavior 146 2.2.1. Test environment 148 /-----\ 149 +---------+ // \\ 150 | DHCPv6 | | Router | 151 | server | \\ // 152 +----+----+ \--+--/ 153 | | 154 | | 155 | | 156 ----+--+----------+----------+---+----- 157 | | | 158 | | | 159 | | | 160 +----+---+ +----+---+ +----+---+ 161 | | | | | | 162 | Host1 | | Host2 | | Host3 | 163 +--------+ +--------+ +--------+ 165 Figure 1 Test Environment 167 As the figure 1 shows, it is a simple LAN environment: 168 - The DHCPv6 server is a Linux (Ubuntu 10.04)-based PC installing 169 dibbler-server. 170 - Host1 is a Windows 7 PC. 171 - Host2 is a Linux (Ubuntu 12.04, kernel 3.2.12) PC. 172 - Host3 is a OS X Lion 10.7.3 MacBook. 174 Note that, we only tested M flag behavior, O flag was not included. 175 Because O flag is about other configuration beyond address 176 configuration, it is out of the scope of this draft. 178 2.2.2. Test scenarios and results 180 o Scenario 0 182 Hosts get online, no RA received. 184 - Windows 7: continued sending RS messages for a while, if there is 185 no RA replied, it then began to send DHCPv6 solicit; 187 - Linux-kernel_3.2.12(Ubuntu 12.04): it continued sending RS, and 188 didn't try to send DHCPv6 solicit; 190 - OS X Lion 10.7.3: it continued sending RS, and didn't try to send 191 DHCPv6 solicit (just the same with Linux); 193 o Scenario 1 195 Hosts hadn't configured addresses yet, then if RA messages with M=0 196 received, obviously they'll do SLAAC; if M=1, which meant SLAAC and 197 DHCPv6 were available simultaneously in the link, the behavior is as 198 the following: 200 - Windows 7: using both SLAAC and DHCPv6 to configure the addresses, 201 regardless of whether the prefixes in SLAAC/DHCPv6 are identical 202 of not; 204 - Linux-kernel_3.2.12(Ubuntu 12.04): the same action with Windows 7; 206 - OS X Lion 10.7.3: the same action with Windows 7; 208 o Scenario 2 210 Hosts were already SLAAC-configured only, then received RA messages 211 with M=1: 213 - Windows 7: using DHCPv6 to configure another address while keep the 214 former SLAAC-configured address; 216 - Linux(Ubuntu 12.04): no action.(Note that, it's different with 217 scenarios 1); 219 - OS X Lion 10.7.3: no action, the same with Linux; 221 o Scenario 3 223 Hosts already configured by DHCPv6 only, then received RA messages: 225 - Windows 7: If M=1, it configured another address with SLAAC and 226 kept the DHCPv6 configuration; else M=0, it released the DHCPv6 227 address and configured with SLAAC; 229 - Linux-kernel_3.2.12(Ubuntu 12.04): there's no DHCPv6-only situation 230 for it, only in scenario 1 when M=1 it would configured with SLAAC 231 and DHCPv6 simultaneously; 233 - OS X Lion 10.7.3: the same situation with Linux; 235 o Scenario 4 237 Hosts already configured with SLAAC/DHCPv6 simultaneously, then RA 238 messages with M=0 received: 240 - Windows 7: it released the DHCPv6 address and configured with SLAAC; 242 - Linux(Ubuntu 12.04): no action; 244 - OS X Lion 10.7.3: no action; 246 2.2.3. Conclusion 248 Obviously, the operating systems interpreting the M flag quite 249 differently. Windows 7 treats the flag as instruction, it even 250 released DHCPv6 session when M=0. Linux and OS X were likely to treat 251 the flag as advisory, when SLAAC was done, it won't care about M=1, 252 and M=0 won't cause operation for the already configured DHCPv6 253 addresses. 255 3. Requirement of Address Configuration Switching in Renumbering 257 During IPv6 renumbering, the SLAAC-configured hosts can reconfigure 258 IP addresses by receiving ND Router Advertisement (RA) messages 259 containing new prefix information. The DHCPv6-configured hosts can 260 reconfigure addresses by initialing RENEW sessions when the current 261 addresses' lease time is expired or receiving the reconfiguration 262 messages initialed by the DHCPv6 servers. 264 The above mechanisms have an implicit assumption that SLAAC- 265 configured hosts will remain SLAAC while DHCPv6-managed hosts will 266 remain DHCPv6-managed. In [I-D.ietf-6renum-enterprise], it described 267 several renumbering scenarios in enterprise network. For example, the 268 network may split, merge, grow, relocate or reorganize. In these 269 situations, it is possible that SLAAC-configured hosts may need to 270 switch to DHCPv6-managed, or verse vice. 272 As discussed in section 2, the semantic of M bit is ambiguous, for 273 example, M=0 is efficient for Windows 7 PCs to switch from DHCPv6- 274 managed to SLAAC, but for Linux or OS X it is just invalid. So in the 275 following section 4, we proposed to use another two flags to indicate 276 the hosts switching between SLAAC/DHCPv6. 278 4. Proposed Standard Update 280 4.1. Semantic Space of SLAAC/DHCPv6 Interaction 282 We summarize the semantic instructions from network side to host side 283 as the following. Some of them are already covered by existing 284 implementation while some may need protocol extentions. 286 - Network side provides both, let the hosts select by themselves 288 It is exactly what M=1 meaning in RFC4861. 290 - Network side requires the hosts to do DHCPv6 when online 292 As the tests showed, when get online, all the three major OSes will 293 initial DHCPv6 when M=1. Especially, when M=1 and RAs don't include 294 PIO (Prefix Information Option), the host would ''have to'' initial 295 DHCPv6 for address autoconfiguration. So we can consider this 296 semantics has been covered. 298 - Network side requires the already SLAAC-configured hosts to do 299 DHCPv6 301 As the test showed, with current ambiguous M=1 definition, OSes 302 varied the behaviors. So this could be considered as a semantic gap. 304 - Network side requires the hosts to release DHCPv6 addresses 305 As analyzed in section 3, the network may need the hosts to switch 306 configuration modes. With M=0, the OS behaviors are different as the 307 test results showed. So this is another semantic gap. 309 4.2. Adding a "DHCPv6Required" Flag 311 We propose to add a flag in the standard RA message format[RFC4861], 312 the "DHCPv6Required" D flag, which will occupy one bit in the 313 reserved field as showed in the following figure 2. 315 4.3. Adding a "ReleaseDHCPv6" Flag 317 We propose to add one more flag in the standard RA message format, 318 the "ReleaseDHCPv6" R flag, which will occupy one more bit in the 319 reserved field as showed in the following figure 2. 321 0 1 2 3 322 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Type | Code | Checksum | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Cur Hop Limit |M|O|D|R| Rsvd | Router Lifetime | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Reachable Time | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Retrans Timer | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Options ... 333 +-+-+-+-+-+-+-+-+-+-+-+- 335 Figure 2 DHCPv6Required and ReleaseDHCPv6 flags in RA message 337 4.4. Host Behavior of Interpreting D/R Flag 339 When a host has not configured its addresses (just like scenario 0 in 340 section 2.2) and receives RA messages with D=1, it MUST initiate a 341 DHCPv6 stateful address autoconfiguration process. 343 When a host has been SLAAC-configured, and receives D=1, it MUST 344 initiate a DHCPv6 stateful address autoconfiguration process and 345 SHOULD deprecate SLAAC-configured addresses. 347 When a host has been address-configured with DHCPv6, and receives RA 348 messages with R=1, it SHOULD release current DHCPv6 address 349 configuration and do SLAAC. 351 5. Security Considerations 353 No more security considerations than the Neighbor Discovery protocol 354 [RFC4861]. 356 6. IANA Considerations 358 None. 360 7. References 362 7.1. Normative References 364 [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and 365 M. Carney, "Dynamic Host Configuration Protocol for IPv6 366 (DHCPv6)", RFC 3315, July 2003. 368 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 369 "Neighbor Discovery for IP version 6 (IPv6)", RFC 370 4861,September 2007. 372 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 373 Address Autoconfiguration", RFC 4862, September 2007. 375 7.2. Informative References 377 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 378 Still Needs Work", RFC 5887, May 2010. 380 [I-D.ietf-6renum-gap-analysis] 381 Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap 382 Analysis", Working in Progress, March 2012 384 [I-D.ietf-6renum-enterprise] 385 Jiang, S., and B. Liu, "IPv6 Enterprise Network Renumbering 386 Scenarios and Guidelines ", Working in Progress, March 2012. 388 8. Acknowledgments 390 The tests were done in a lab in BUPT. Thank Xudong Shi very much. He 391 is a master student in the lab, and did a great job for the tests. 393 This work adopts some content from [I-D.ietf-6renum-gap-analysis]. 395 This document was prepared using 2-Word-v2.0.template.dot. 397 Authors' Addresses 399 Bing Liu 400 Q14-4-A Building 401 Huawei Technologies Co., Ltd 402 Zhong-Guan-Cun Environment Protection Park, No.156 Beiqing Rd. 403 Hai-Dian District, Beijing 404 P.R. China 406 Email: leo.liubing@huawei.com 408 Wendong Wang 409 No.3 Teaching Building 410 Beijing University of Posts and Telecommunications 411 No.10 Xi-Tu-Cheng Rd. 412 Hai-Dian District, Beijing 413 P.R. China 415 Email: wdwang@bupt.edu.cn 417 Xiangyang Gong 418 No.3 Teaching Building 419 Beijing University of Posts and Telecommunications 420 No.10 Xi-Tu-Cheng Rd. 421 Hai-Dian District, Beijing 422 P.R. China