idnits 2.17.1 draft-liu-v6ops-dhcpv6-slaac-guidance-03.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4861], [I-D.ietf-v6ops-dhcpv6-slaac-problem]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 161: '...e administrators MUST turn the A flag ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3469 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-dhcpv6-slaac-problem-02 == Outdated reference: A later version (-03) exists of draft-liu-v6ops-running-multiple-prefixes-02 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6OPS B. Liu 3 Internet-Draft Huawei Technologies 4 Intended status: Informational R. Bonica 5 Expires: April 30, 2015 Juniper Networks 6 T. Yang 7 China Mobile 8 October 27, 2014 10 DHCPv6/SLAAC Interaction Operational Guidance 11 draft-liu-v6ops-dhcpv6-slaac-guidance-03 13 Abstract 15 The IPv6 Neighbor Discovery (ND) Protocol [RFC4861] specifies an 16 ICMPv6 Router Advertisement (RA) message. The RA message contains 17 three flags that indicate which address autoconfiguration mechanisms 18 are available to on-link hosts. These are the M, O and A flags. The 19 M, O and A flags are all advisory, not prescriptive. 21 In [I-D.ietf-v6ops-dhcpv6-slaac-problem], test results show that in 22 several cases the M, O and A flags elicit divergent host behaviors, 23 which might cause some operational problems. This document aims to 24 provide some operational guidance to eliminate the impact caused by 25 divergent host behaviors as much as possible. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 30, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Operational Guidance . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Always Turn RAs On . . . . . . . . . . . . . . . . . . . 3 64 2.2. Guidance for DHCPv6/SLAAC Provisioning Scenarios . . . . 3 65 2.2.1. DHCPv6-only . . . . . . . . . . . . . . . . . . . . . 3 66 2.2.2. SLAAC-only . . . . . . . . . . . . . . . . . . . . . 4 67 2.2.3. DHCPv6/SLAAC Co-existence . . . . . . . . . . . . . . 4 68 2.3. Guidance for Renumbering . . . . . . . . . . . . . . . . 5 69 2.3.1. Adding a New Address from another Address 70 Configuration Mechanisms . . . . . . . . . . . . . . 5 71 2.3.2. Switching one Address Configuration Mechanism to 72 another . . . . . . . . . . . . . . . . . . . . . . . 6 73 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 78 6.2. Informative References . . . . . . . . . . . . . . . . . 7 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 81 1. Introduction 83 The IPv6 Neighbor Discovery (ND) Protocol [RFC4861] specifies an 84 ICMPv6 Router Advertisement (RA) message. The RA message contains 85 three flags that indicate which address autoconfiguration mechanisms 86 are available to on-link hosts. These are the M, O and A flags. The 87 M, O and A flags are all advisory, not prescriptive. 89 In [I-D.ietf-v6ops-dhcpv6-slaac-problem], test results show that in 90 several cases the M, O and A flags elicit divergent host behaviors, 91 which might cause some operational problems. This document aims to 92 provide some operational guidance to eliminate the impact caused by 93 divergent host behaviors as much as possible. 95 This document does not intent to cover the topic of selection between 96 RA and DHCPv6 [RFC3315] for the overlapped functions. There always 97 are arguments about what should be done through RA options or through 98 DHCPv6 options. For this general issue, draft 99 [I-D.yourtchenko-ra-dhcpv6-comparison] could be referred. 101 2. Operational Guidance 103 2.1. Always Turn RAs On 105 Currently, turning RAs on is actually a basic requirement for running 106 IPv6 networks since only RAs could advertise default route(s) for the 107 end nodes. And if the nodes want to communicate with each other on 108 the same link via DHCPv6-configured addresses, they also need to be 109 advertised with L flag set in RAs. So for current networks, an IPv6 110 network could NOT run without RAs, unless the network only demands a 111 communication via link-local addresses. 113 2.2. Guidance for DHCPv6/SLAAC Provisioning Scenarios 115 2.2.1. DHCPv6-only 117 In IPv4, there is only one method (DHCPv4) for automatically 118 configuring the hosts. Many network operations/mechanisms, 119 especially in enterprise networks, are built around this central- 120 managed model. So it is reasonable for people who are accustomed to 121 DHCPv4-only deployment still prefer DHCPv6-only in IPv6 networks. 122 Besides, some networks just prefer central management of all IP 123 addressing. These networks may want to assign addresses only via 124 DHCPv6. 126 This can be accomplished by sending RAs that indicate DHCPv6 is 127 available (M=1), installing DHCPv6 servers or DHCPv6 relays on all 128 links, and setting A=0 in the Prefix Information Options of all 129 prefixes in the RAs. (Instead of forcing the A flag off, simply not 130 including any PIO in RAs could also make the same effect). But 131 before doing this, the administrators need to be sure that every node 132 in their intended management scope supports DHCPv6. 134 Note that RAs are still necessary in order for hosts to be able to 135 use these addresses. This is for two reasons: 137 o If there is no RA, some hosts will not attempt to obtain address 138 configuration via DHCPv6 at all. 140 o DHCPv6 can assign addresses but not routing. Routing can be 141 implemented on hosts by means of accepting and implementing 142 information from RA messages containing default-route, Prefix 143 Information Option with O=1, or Route Information Option, or by 144 configuring manual routing. Without routing, IPv6 addresses won't 145 be used for communication outside the host. Thus, for example, if 146 there is no RA and no static routing, then addresses assigned by 147 DHCPv6 cannot be used even for communication between hosts on the 148 same link. 150 Also note that unlike SLAAC [RFC4862], DHCPv6 is not a strict 151 requirement for IPv6 hosts [RFC6434], and some nodes do not support 152 DHCPv6. Thus, this model can only be used if all the hosts that need 153 IPv6 connectivity support DHCPv6. 155 2.2.2. SLAAC-only 157 In contrast with DHCPv6-only, some scenarios might be suitable for 158 SLAAC-only which allows minimal administration burden and node 159 capability requirement. 161 The administrators MUST turn the A flag on, and MUST turn M flag off. 162 Note that some platforms (e.g. Windows 8) might still initiate 163 DHCPv6 session regardless of M flag off. But since there is no 164 DHCPv6 service available, the only problem is that there would be 165 some unnecessary traffic. 167 2.2.3. DHCPv6/SLAAC Co-existence 169 - Scenarios of DHCPv6/SLAAC Co-existence 171 * For provisioning redundancy: If the administrators want all 172 nodes at least could configure a global scope address, then 173 they could turn A flag and M flag both on in case some nodes 174 only support one of the mechanisms. For example, some hosts 175 might only support SLAAC; while some hosts might only support 176 DHCPv6 due to manual/mistaken configurations. 178 * For different provisioning: the two address configuration 179 mechanisms might provide two addresses for the nodes 180 respectively. For example, SLAAC-configured address is for 181 basic connectivity and another address configured by DHCPv6 is 182 for a specific service. 184 - Cautions 186 * Notice that enabling both DHCPv6 and SLAAC would cause one host 187 to configure more IPv6 addresses. Typically, there would be 188 one more DHCPv6-configured address than SLAAC-only 189 configuration; and two more addresses based on SLAAC and 190 privacy extension than DHCPv6-only configuration. Too many 191 addresses might cause ND cache overflow problem in some 192 situations (please refer to Section 3.4 of 193 [I-D.liu-v6ops-running-multiple-prefixes] for details). 195 * For provisioning redundancy scenario, there is a concern that 196 SLAAC/DHCPv6 addresses based on the same prefix might cause 197 some applications confusing. [Open Question] Call for real 198 experiences on this issues. 200 * Besides address configuration, DNS can also be configured both 201 by SLAAC and DHCPv6. If the DNS information in RAs and DHCPv6 202 are different, the host might confuse. So in terms of 203 operation, the operators should make sure DNS configuration in 204 RAs and DHCPv6 are the same. 206 2.3. Guidance for Renumbering 208 This document only considers the renumbering cases where DHCPv6/SLAAC 209 interaction is involved. These renumbering operations need the A/M 210 flags transition which might cause unpredictable host behaviors. Two 211 renumbering cases are discussed as the following. 213 2.3.1. Adding a New Address from another Address Configuration 214 Mechanisms 216 o Adding a DHCPv6 Address for a SLAAC-configured Host 218 As discussed in Section 2.2.3, some operating systems that 219 having configured SLAAC addersses would NOT care about the 220 newly added DHCPv6 provision unless the current SLAAC address 221 lifetime is expired. In theory, one possible way is to stop 222 advertising RAs and wait the SLAAC addresses expired (this 223 makes the hosts return to the initial stage), then advertise 224 RAs again with the M flag set, so that the host would configure 225 SLAAC and DHCPv6 addresses simultaneously. However, there 226 would be some outage period during this operation, which might 227 be unacceptable for many situations. Thus, It is better for 228 the administrators to carefully plan the network provisioning 229 so that to make SLAAC and DHCPv6 available simultaneously 230 (through RA with M=1) at the initial stage rather than 231 configuring one and then configuring another. 233 o Adding a SLAAC Address for a DHCPv6-configured Host 235 As tested in [I-D.ietf-v6ops-dhcpv6-slaac-problem].), current 236 mainstream operating systems all support this renumbering 237 operation. The only thing need to care about is to make sure 238 the M flag is on in the RAs, since some operating systems would 239 immediately release the DHCPv6 addresses if M flag is off. 241 2.3.2. Switching one Address Configuration Mechanism to another 243 o DHCPv6 to SLAAC 245 This operation is supported by all the tested operating systems 246 in [I-D.ietf-v6ops-dhcpv6-slaac-problem]. However, the 247 behaviors are different. As said above, if A flag is on while 248 M flag is off, a flash switching renumbering would happen on 249 some operating systems. So while turning the A flag on, it is 250 recommended to retain the M flag on and stop the DHCPv6 server 251 to response the renew messages so that the DHCPv6 addresses 252 could be released when the lifetimes expired. 254 o SLAAC to DHCPv6 256 This operation is also supported by all the tested operating 257 systems. And the behaviors are the same since no operating 258 systems would immediatly release the SLAAC addresses when A 259 flag is off. However, for safe operation, while turning the M 260 flag on, it is also recommended to retain the A flag on and 261 stop advertising RAs so that the SLAAC addresses could be 262 released when the lifetimes expired. 264 3. Security Considerations 266 No more security considerations than the Neighbor Discovery protocol 267 [RFC4861]. 269 4. IANA Considerations 271 This draft does not request any IANA action. 273 5. Acknowledgements 275 Valuable comments were received from Sheng Jiang and Brian E 276 Carpenter to initiate the draft. Some texts in Section 2.2.1 were 277 based on Lorenzo Colitti and Mikael Abrahamsson's proposal. There 278 were also comments from Erik Nordmark, Ralph Droms, John Brzozowski, 279 Andrew Yourtchenko and Wesley George to improve the draft. The 280 authors would like to thank all the above contributors. 282 This document was produced using the xml2rfc tool [RFC2629]. (This 283 document was initiallly prepared using 2-Word-v2.0.template.dot. ) 285 6. References 287 6.1. Normative References 289 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 290 June 1999. 292 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 293 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 294 September 2007. 296 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 297 Address Autoconfiguration", RFC 4862, September 2007. 299 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 300 Requirements", RFC 6434, December 2011. 302 6.2. Informative References 304 [I-D.ietf-v6ops-dhcpv6-slaac-problem] 305 Liu, B., Jiang, S., Bonica, R., Gong, X., and W. Wang, 306 "DHCPv6/SLAAC Address Configuration Interaction Problem 307 Statement", draft-ietf-v6ops-dhcpv6-slaac-problem-02 (work 308 in progress), October 2014. 310 [I-D.liu-v6ops-running-multiple-prefixes] 311 Liu, B., Jiang, S., and Y. Bo, "Considerations for Running 312 Multiple IPv6 Prefixes", draft-liu-v6ops-running-multiple- 313 prefixes-02 (work in progress), October 2014. 315 [I-D.yourtchenko-ra-dhcpv6-comparison] 316 Yourtchenko, A., "A comparison between the DHCPv6 and RA 317 based host configuration", draft-yourtchenko-ra- 318 dhcpv6-comparison-00 (work in progress), November 2013. 320 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 321 and M. Carney, "Dynamic Host Configuration Protocol for 322 IPv6 (DHCPv6)", RFC 3315, July 2003. 324 Authors' Addresses 326 Bing Liu 327 Huawei Technologies 328 Q14, Huawei Campus, No.156 Beiqing Road 329 Hai-Dian District, Beijing, 100095 330 P.R. China 332 Email: leo.liubing@huawei.com 333 Ron Bonica 334 Juniper Networks 335 Sterling, Virginia 336 20164 337 USA 339 Email: rbonica@juniper.net 341 Tianle Yang 342 China Mobile 343 32, Xuanwumenxi Ave. 344 Xicheng District, Beijing 100053 345 P.R. China 347 Email: yangtianle@chinamobile.com