idnits 2.17.1 draft-ietf-v6ops-dhcpv6-slaac-problem-07.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 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 197: '...RA and DHCP, the IPv6 host SHOULD keep...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 17, 2016) is 2807 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) -- 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: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6OPS B. Liu 3 Internet-Draft S. Jiang 4 Intended status: Informational Huawei Technologies 5 Expires: February 18, 2017 X. Gong 6 W. Wang 7 BUPT University 8 E. Rey 9 ERNW GmbH 10 August 17, 2016 12 DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration 13 draft-ietf-v6ops-dhcpv6-slaac-problem-07 15 Abstract 17 The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router 18 Advertisement (RA) message. The RA message contains three flags, 19 indicating the availability of address auto-configuration mechanisms 20 and other configuration such as DNS-related configuration. These are 21 the M, O, and A flags, which by definition are advisory, not 22 prescriptive. 24 This document describes divergent host behaviors observed in popular 25 operating systems. It also discusses operational problems that the 26 divergent behaviors might cause. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on February 18, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. The M, O and A Flags . . . . . . . . . . . . . . . . . . . . 3 64 2.1. Flags Definition . . . . . . . . . . . . . . . . . . . . 4 65 2.2. Flags Relationship . . . . . . . . . . . . . . . . . . . 4 66 3. Behavior Ambiguity Analysis . . . . . . . . . . . . . . . . . 4 67 4. Observed Divergent Host Behaviors . . . . . . . . . . . . . . 6 68 4.1. Divergent Behavior on Address Auto-Configuration . . . . 6 69 4.2. Divergent Behavior on DNS Configuration . . . . . . . . . 7 70 5. Operational Problems . . . . . . . . . . . . . . . . . . . . 9 71 5.1. Standalone Stateless DHCPv6 Configuration not available . 9 72 5.2. Renumbering Issues . . . . . . . . . . . . . . . . . . . 9 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 78 9.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Appendix A. Test Results . . . . . . . . . . . . . . . . . . . . 12 80 A.1. Test Set 1 . . . . . . . . . . . . . . . . . . . . . . . 12 81 A.1.1. Test Environment . . . . . . . . . . . . . . . . . . 12 82 A.1.2. Address Auto-configuration Behavior in the Initial 83 State . . . . . . . . . . . . . . . . . . . . . . . . 12 84 A.1.3. Address Auto-configuration Behavior in State 85 Transitions . . . . . . . . . . . . . . . . . . . . . 13 86 A.2. Test Set 2 . . . . . . . . . . . . . . . . . . . . . . . 15 87 A.2.1. Test Environment . . . . . . . . . . . . . . . . . . 15 88 A.2.2. Address/DNS Auto-configuration Behavior of Using Only 89 One IPv6 Router and a DHCPv6 Server . . . . . . . . . 15 90 A.2.3. Address/DNS Auto-configuration Behavior of Using Two 91 IPv6 Router and a DHCPv6 Server . . . . . . . . . . . 19 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 94 1. Introduction 96 IPv6 [RFC2460] hosts could invoke Neighbor Discovery (ND) [RFC4861] 97 to to discover which auto-configuration mechanisms are available to 98 them. There are two auto-configuration mechanisms in IPv6: 100 o DHCPv6 [RFC3315] 102 o Stateless Address Autoconfiguration (SLAAC) [RFC4862] 104 ND specifies an ICMPv6-based [RFC4443] Router Advertisement (RA) 105 message. Routers periodically multicast the RA messages to all on- 106 link nodes. They also unicast RA messages in response to 107 solicitations. The RA message contains (but not limited to): 109 o an M (Managed) flag, indicating that addresses are available from 110 DHCPv6 or not 112 o an O (OtherConfig) flag, indicating that other configuration 113 information (e.g., DNS-related information) is available from 114 DHCPv6 or not 116 o zero or more Prefix Information (PI) Options 118 an A (Autonomous) flag is included, indicating that the prefix 119 can be used for SLAAC or not 121 The M and O flags are advisory, not prescriptive. For example, the M 122 flag indicates that addresses are available from DHCPv6, but It does 123 not indicate that hosts are required to acquire addresses from 124 DHCPv6. Similar statements can be made about the O flag. (A flag is 125 also advisory by definition in standard, but it is quite prescriptive 126 in implementations according to the test results in the appendix.) 128 Because of the advisory definition of the flags, in some cases 129 different operating systems appear divergent behaviors. This 130 document analyzes possible divergent host behaviors might happen 131 (most of the possible divergent behaviors are already observed in 132 popular operating systems) and the operational problems might caused 133 by divergent behaviors. 135 2. The M, O and A Flags 137 This section briefly reviews how the M, O and A flags are defined in 138 ND[RFC4861] and SLAAC[RFC4862]. 140 2.1. Flags Definition 142 o M (Managed) Flag 144 As decribed in [RFC4861], "When set, it indicates that 145 addresses are available via Dynamic Host Configuration 146 Protocol". 148 o O (Otherconfig) Flag 150 "When set, it indicates that other configuration information is 151 available via DHCPv6. Examples of such information are DNS- 152 related information or information on other servers within the 153 network." [RFC4861] 155 "If neither M nor O flags are set, this indicates that no 156 information is available via DHCPv6" . [RFC4861] 158 o A (Autonomous) Flag 160 A flag is defined in the PIO, "When set indicates that this 161 prefix can be used for stateless address configuration as 162 specified in [RFC4862].". 164 2.2. Flags Relationship 166 Per [RFC4861], "If the M flag is set, the O flag is redundant and can 167 be ignored because DHCPv6 will return all available configuration 168 information.". 170 There is no explicit description of the relationship between A flag 171 and the M/O flags. 173 3. Behavior Ambiguity Analysis 175 The ambiguity of the flags definition means that when interpreting 176 the same messages, different hosts might behave differently. The 177 ambiguity space is analyzed as the following aspects. 179 1) Dependency between DHCPv6 and RA 181 In standards, behavior of DHCPv6 and Neighbor Discovery protocols 182 is specified respectively. But it is not clear that whether there 183 should be any dependency between them. More specifically, it is 184 unclear whether RA (with M=1) is required to trigger DHCPv6; in 185 other words, It is unclear whether hosts should initiate DHCPv6 by 186 themselves if there are no RAs at all. 188 2) Overlapping configuration between DHCPv6 and RA 190 When address and DNS configuration are both available from DHCPv6 191 and RA, it is not clear how to deal with the overlapping 192 information. Should the hosts accept all the information? If the 193 information conflicts, which one should take higher priority? 195 For DNS configuration, [RFC6106] clearly specifies "In the case 196 where the DNS options of RDNSS and DNSSL can be obtained from 197 multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep 198 some DNS options from all sources" and "the DNS information from 199 DHCP takes precedence over that from RA for DNS queries" 200 (Section 5.3.1 of [RFC6106]). But for address configuration, 201 there's no such guidance. 203 3) Interpretation on Flags Transition 205 - Impact on SLAAC/DHCPv6 on and off 207 When flags are in transition, e.g. the host is already SLAAC- 208 configured, then M flag changes from FALSE to TRUE, it is not 209 clear whether the host should start DHCPv6 or not; or vise 210 versa, the host is already configured by both SLAAC and DHCPv6, 211 then M flag change from TRUE to FALSE, it is also not clear 212 whether the host should turn DHCPv6 off or not. 214 - Impact on address lifetime 216 When one address configuration method is off, that is, the A 217 flag or M flag changes from TRUE to FALSE, it is not clear 218 whether one host should immediately release the corresponding 219 address or just retain it until the lifetime expires. 221 4) Relationship between the Flags 223 As described above, the relationship between A flag and M/O flags 224 is unspecified. 226 It could be reasonably deduced that M flag should be independent 227 from A flag. In other words, the M flag only cares DHCPv6 address 228 configuration, while the A flag only cares SLAAC. 230 But for A flag and O flag, ambiguity could possibly happen. For 231 example, when A is FALSE (when M is also FALSE) and O is TRUE, it 232 is not clear whether the host should initiate a stand-alone 233 stateless DHCPv6 session. 235 Divergent behaviors on all these aspects have been observed among 236 some popular operating systems as described in Section 4 below. 238 4. Observed Divergent Host Behaviors 240 The authors tested several popular operating systems in order to 241 determine what behaviors the M, O and A flag elicit. In some cases, 242 the M, O and A flags elicit divergent behaviors. The table below 243 characterizes those cases. For test details, please refer to 244 Appendix A. 246 Operation diverges in two ways: one is regarding to address auto- 247 configuration; the other is regarding to DNS configuration. 249 4.1. Divergent Behavior on Address Auto-Configuration 251 Divergence 1-1 253 o Host state: has not acquired any addresses. 255 o Input: no RA. 257 o Divergent Behavior 259 1) Acquiring addresses from DHCPv6. 261 2) No DHCPv6 action. 263 Divergence 1-2 265 o Host state: has acquired addresses from DHCPv6 only (M = 1). 267 o Input: RA with M =0. 269 o Divergent Behavior 271 1) Releasing DHCPv6 addresses immediately. 273 2) Releasing DHCPv6 addresses when they expire. 275 Divergence 1-3 277 o Host state: has acquired addresses from SLAAC only (A=1). 279 o Input: RA with M =1. 281 o Divergent Behavior 282 1) Acquiring DHCPv6 addresses immediately. 284 2) Acquiring DHCPv6 addresses only if their SLAAC addresses 285 expire and cannot be refreshed. 287 4.2. Divergent Behavior on DNS Configuration 289 Divergence 2-1 291 o Host state: has not acquired any addresses or information. 293 o Input: RA with M=0, O=1, no RDNSS; and a DHCPv6 server on the same 294 link providing RDNSS (regardless of address provisioning). 296 o Divergent Behavior 298 1) Acquiring RDNNS from DHCPv6, regardless of the A flag 299 setting. 301 2) Acquiring RDNNS from DHCPv6 only if A=1. 303 Divergence 2-2 305 (This divergence is only for those operations systems which 306 support[RFC6106].) 308 o Host state: has not acquired any addresses or information. 310 o Input: RA with M=0/1, A=1, O=1 and an RDNSS is advertised; and a 311 DHCPv6 server on the same link providing IPv6 addresses and RDNSS. 313 o Divergent Behavior 315 1) Getting RDNSS from both the RAs and the DHCPv6 server, and 316 the RDNSS obtained from the router has a higher priority. 318 2) Getting RDNSS from both the RAs and the DHCPv6 server, but 319 the RDNSS obtained from the DHCPv6 server has a higher 320 priority. 322 3) Getting RDNSS from the router, and a "domain search list" 323 information only from the DHCPv6 server(no RDNSS). 325 Divergence 2-3 327 (This divergence is only for those operations systems which 328 support[RFC6106].) 329 o Host state: has acquired address and RDNSS from the first router's 330 RAs (M=0, O=0, PIO with A=1, and RDNSS advertised). 332 o Input: another router advertising M=1, O=1, no prefix information; 333 and a DHCPv6 server on the same link providing IPv6 addresses and 334 RDNSS. 336 o Divergent Behavior 338 1) Never getting any information (neither IPv6 address nor 339 RDNSS) from the DHCPv6 server. 341 2) Getting an IPv6 address and RDNSS from the DHCPv6 server 342 while retaining the address and RDNSS obtained from the RAs of 343 the first router. 345 (More details: the RDNSS obtained from the first router has 346 a higher priority; when they receive again RAs from the 347 first router, they lose/forget the information (IPv6 address 348 and RDNSS) obtained from the DHCPv6 server.) 350 Divergence 2-4 352 (This divergence is only for those operations systems which 353 support[RFC6106].) 355 o Host state: has acquired address and RDNSS from the DHCPv6 server 356 indicated by the first router (M=1, O=1, no PIO or RDNSS 357 advertised). 359 o Input: another router advertising M=0, O=0, PIO with A=1, and 360 RNDSS. 362 o Divergent Behavior 364 1) Getting address and RDNSS from the second router's RAs, and 365 releasing the IPv6 address and the RDNSS obtained from the 366 DHCPv6 server. 368 (More details: when receiving RAs from the first router 369 again, it performs the DHCPv6 Confirm/Reply procedure and 370 gets an IPv6 address and RDNSS from the DHCPv6 server while 371 retaining the ones obtained from the RAs of the second 372 router. Moreover, the RDNSS from router 1 has higher 373 priority than the one from DHCPv6.) 375 2) Getting address and RDNSS from the second router's RAs, and 376 retaining the IPv6 address and the "Domain Search list" 377 obtained from the DHCPv6 server. (It did not get the RDNSS 378 from the DHCPv6 server, as described in Divergence 2-2.) 380 (More details: when receiving RAs from the first router 381 again, there is no change; all the obtained information is 382 retained.) 384 3) Getting address but no RDNSS from the second router's RAs, 385 and also retaining the IPv6 address and the RDNSS obtained from 386 the DHCPv6 server. 388 (More details: when receiving RAs from the first router 389 again, there is no change; all the obtained information is 390 retained.) 392 5. Operational Problems 394 This section is not a full collection of the potential problems. It 395 is some operational issues that the authors could see at current 396 stage. 398 5.1. Standalone Stateless DHCPv6 Configuration not available 400 It is impossible for some hosts to acquire stateless DHCPv6 401 configuration unless addresses are acquired from either DHCPv6 or 402 SLAAC (Which requires M flag or A flag is TURE). 404 5.2. Renumbering Issues 406 According to [RFC6879] a renumbering exercise can include the 407 following steps: 409 o Causing a host to 411 release the SLAAC address and acquire a new address from 412 DHCPv6; or vice-versa. 414 release the current SLAAC address and acquire another new SLAAC 415 address (might comes from different source). 417 retain current SLAAC or DHCPv6 address and acquire another new 418 address from DHCPv6 or SLAAC. 420 Ideally, these steps could be initiated by multicasting RA messages 421 onto the link that is being renumbered. Sadly, this is not possible, 422 because the RA messages may elicit a different behavior from each 423 host. 425 6. Security Considerations 427 An attacker, without having to install a rogue router, can install a 428 rogue DHCPv6 server and provide IPv6 addresses to Windows 8.1 429 systems. This can allow her to interact with these systems in a 430 different scope, which, for instance, is not monitored by an IDPS 431 system. 433 If an attacker wants to perform MiTM (Man in The Middle) using a 434 rogue DNS while legitimates RAs with the O flag set are sent to 435 enforce the use of a DHCPv6 server, the attacker can spoof RAs with 436 the same settings with the legitimate prefix (in order to remain 437 undetectable) but advertising the attacker's DNS using RDNSS. In 438 this case, Fedora 21, Centos 7 and Ubuntu 14.04 will use the rogue 439 RDNSS (advertised by the RAs) as a first option. 441 Fedora 21 and Centos 7 behaviour cannot be explored for a MiTM attack 442 using a rogue DNS information either, since the one obtained by the 443 RAs of the first router has a higher priority. 445 The behaviour of Fedora 21, Centos 7 and Windows 7 can be exploited 446 for DoS purposes. A rogue IPv6 router not only provides its own 447 information to the clients, but it also removes the previous obtained 448 (legitimate) information. The Fedora and Centos behaviour can also 449 be exploited for MiTM purposes by advertising rogue RDNSS by RAs 450 which include RDNSS information. 452 (Note: the security considerations for specific operating systems are 453 based on the detailed test results as described in Appendix A.) 455 7. IANA Considerations 457 This draft does not request any IANA action. 459 8. Acknowledgements 461 The authors wish to acknowledge BNRC-BUPT (Broad Network Research 462 Centre in Beijing University of Posts and Telecommunications) for 463 their testing efforts. Special thanks to Xudong Shi, Longyun Yuan 464 and Xiaojian Xue for their extraordinary effort. 466 Special thanks to Ron Bonica who made a lot of significant 467 contribution to this draft, including draft editing and presentations 468 which dramatically improved this work. 470 The authors also wish to acknowledge Brian E Carpenter, Ran Atkinson, 471 Mikael Abrahamsson, Tatuya Jinmei, Mark Andrews and Mark Smith for 472 their helpful comments. 474 9. References 476 9.1. Normative References 478 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 479 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 480 December 1998, . 482 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 483 Control Message Protocol (ICMPv6) for the Internet 484 Protocol Version 6 (IPv6) Specification", RFC 4443, 485 DOI 10.17487/RFC4443, March 2006, 486 . 488 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 489 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 490 DOI 10.17487/RFC4861, September 2007, 491 . 493 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 494 Address Autoconfiguration", RFC 4862, 495 DOI 10.17487/RFC4862, September 2007, 496 . 498 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 499 "IPv6 Router Advertisement Options for DNS Configuration", 500 RFC 6106, DOI 10.17487/RFC6106, November 2010, 501 . 503 9.2. Informative References 505 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 506 C., and M. Carney, "Dynamic Host Configuration Protocol 507 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 508 2003, . 510 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 511 (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, 512 April 2004, . 514 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 515 Network Renumbering Scenarios, Considerations, and 516 Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, 517 . 519 Appendix A. Test Results 521 The authors from two orgnizations tested different scenarios 522 independent of each other. The following text decribes the two test 523 sets respectively. 525 A.1. Test Set 1 527 A.1.1. Test Environment 529 The test environment was replicated on a single server using VMware. 530 For simplicity of operation, only one host was run at a time. 531 Network elements were as follows: 533 o Router: Quagga 0.99-19 soft router installed on Ubuntu 11.04 534 virtual host 536 o DHCPv6 Server: Dibbler-server installed on Ubuntu 11.04 virtual 537 host 539 o Host 1: Window 7 / Window 8.1 Virtual Host 541 o Host 2: Ubuntu 14.04 (Linux Kernel 3.12.0) Virtual Host 543 o Host 3: Mac OS X v10.9 Virtual Host 545 o Host 4: IOS 8.0 (model: Apple iPhone 5S, connected via wifi) 547 A.1.2. Address Auto-configuration Behavior in the Initial State 549 The bullet list below describes host behavior in the initial state, 550 when the host has not yet acquired any auto-configuration 551 information. Each bullet item represents an input and the behavior 552 elicited by that input. 554 o A=0, M=0, O=0 556 * Windows 8.1 acquired addresses and other information from 557 DHCPv6. 559 * All other hosts acquired no configuration information. 561 o A=0, M=0, O=1 563 * Windows 8.1 acquired addresses and other information from 564 DHCPv6. 566 * Windows 7, OSX 10.9 and IOS 8.0 acquired other information from 567 DHCPv6. 569 * Ubuntu 14.04 acquired no configuration information. 571 o A=0, M=1, O=0 573 * All hosts acquired addresses and other information from DHCPv6. 575 o A=0, M=1, O=1 577 * All hosts acquired addresses and other information from DHCPv6. 579 o A=1, M=0, O=0 581 * Windows 8.1 acquired addresses from SLAAC and DHCPv6. It also 582 acquired non-address information from DHCPv6. 584 * All the other host acquired addresses from SLAAC 586 o A=1, M=0, O=1 588 * Windows 8.1 acquired addresses from SLAAC and DHCPv6. It also 589 acquired other information from DHCPv6. 591 * All the other hosts acquired addresses from SLAAC and other 592 information from DHCPv6. 594 o A=1, M=1, O=0 596 * All hosts acquired addresses from SLAAC and DHCPv6. They also 597 acquired other information from DHCPv6. 599 o A=1, M=1, O=1 601 * All hosts acquired addresses from SLAAC and DHCPv6. They also 602 acquired other information from DHCPv6. 604 As showed above, four inputs result in divergent behaviors. 606 A.1.3. Address Auto-configuration Behavior in State Transitions 608 The bullet list below describes behavior elicited during state 609 transitions. The value x can represents both 0 and 1. 611 o Old state (M = x, O = x, A = 1) , New state (M = x, O = x, A = 0) 612 (This means a SLAAC-configured host, which is regardless of DHCPv6 613 configured or not, receiving A in transition from 1 to 0. ) 614 * All the hosts retain SLAAC addresses until they expire 616 o Old state (M = 0, O = x, A = 1), New state (M = 1, O = x, A = 1) 617 (This means a SLAAC-only host receiving M in transition from 0 to 618 1.) 620 * Windows 7 acquires addresses from DHCPv6, immediately. 622 * Ubuntu 14.04/OSX 10.9/IOS 8.0 acquires addresses from DHCPv6 623 only if the SLAAC addresses are allowed to expire 625 * Windows 8.1 was not tested because it always acquire addresses 626 from DHCPv6 regardless of the M flag setting. 628 o Old state (M = 1, O = x, A = x), New state (M = 0, O = x, A = x) 629 (This means a DHCPv6-configured host receiving M in transition 630 from 1 to 0.) 632 * Windows 7 immediately released the DHCPv6 address 634 * Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0 keep the DHCPv6 635 addresses until they expire 637 o Old state (M = 1, O = x, A = 0), New state (M = 1, O = x, A = 1) 638 (This means a DHCPv6-only host receiving A in transition from 0 to 639 1.) 641 * All host acquire addresses from SLAAC 643 o Old state (M = 0, O = 1, A = x), New state (M = 1, O = 1, A = x) 644 (This means a Stateless DHCPv6-configured host [RFC3736], which is 645 regardless of SLAAC configured or not, receiving M in transition 646 from 0 to 1 with keeping O=1 ) 648 * Windows 7 acquires addresses and refreshes other information 649 from DHCPv6 651 * Ubuntu 14.04/OSX 10.9/IOS 8.0 does nothing 653 * Windows 8.1 was not tested because it always acquire addresses 654 from DHCPv6 regardless of the M flag setting. 656 o Old state (M = 1, O = 1, A = x), New state (M = 0, O = 1, A = x) 657 (This means a Stateful DHCPv6-configured host, which is regardless 658 of SLAAC configured or not, receiving M in transition from 0 to 1 659 with keeping O=1 ) 660 * Windows 7 released all DHCPv6 addresses and refreshes all 661 DHCPv6 other information. 663 * Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0 does nothing 665 A.2. Test Set 2 667 A.2.1. Test Environment 669 This test was built on real devices. All the devices are located on 670 the same link. 672 o A DHCPv6 Server and specifically, a DHCP ISC Version 4.3.1 673 installed in CentOs 6.6. The DHCPv6 server is configured to 674 provide both IPv6 addresses and RDNSS information. 676 o Two routers Cisco 4321 using Cisco IOS Software version 15.5(1)S. 678 o The following OS as clients: 680 * Fedora 21, kernel version 3.18.3-201 x64 682 * Ubuntu 14.04.1 LTS, kernel version 3.13.0-44-generic (rdnssd 683 packet installed) 685 * CentOS 7, kernel version 3.10.0-123.13.2.el7 687 * Mac OS-X 10.10.2 Yosemite 14.0.0 Darwin 689 * Windows 7 691 * Windows 8.1 693 A.2.2. Address/DNS Auto-configuration Behavior of Using Only One IPv6 694 Router and a DHCPv6 Server 696 In these scenarios there is two one router and, unless otherwise 697 specified, one DHCPv6 server on the same link. The behaviour of the 698 router and of the DHCPv6 server remain unchanged during the tests. 700 Case 1: One Router with the Management Flag not Set and a DHCPv6 701 Server 703 o Set up 705 * One IPv6 Router with M=0, A=1, O=0 and an RDNSS is advertised 706 * A DHCPv6 server on the same link advertising IPv6 addresses and 707 RDNSS 709 o Results 711 * Fedora 21, MAC OS-X, CentOS 7 and Ubuntu 14.04 get an IPv6 712 address and an RDNSS from the IPv6 router only. 714 * Windows 7 get an IPv6 address from the router only, but they do 715 not get any DNS information, neither from the router nor from 716 the DHCPv6 server. They also do not get IPv6 address from the 717 DHCPv6 server. 719 * Windows 8.1 get an IPv6 address from both the IPv6 router and 720 the DHCPv6 server, despite the fact that the Management flag 721 (M) is not set. They get RDNSS information from the DHCPv6 722 only. 724 Case 2: One Router with Conflicting Parameters and a DHCPv6 Server 726 o Set up 728 * One IPv6 Router with M=0, A=1, O=1 and an RDNSS is advertised 730 * A DHCPv6 server on the same link advertising IPv6 addresses and 731 RDNSS 733 o Results 735 * Fedora 21, Centos 7 and Ubuntu 14.04 get IPv6 address using 736 SLAAC only (no address from the DHCPv6 server). 738 + Fedora 21, Centos 7 get RDNSS from both the RAs and the 739 DHCPv6 server. The RDNSS obtained from the router has a 740 higher priority though. 742 + Ubuntu 14.04 gets an RDNSS from the router, and a "domain 743 search list" information from the DHCPv6 server - but not 744 RDNSS information. 746 * MAC OS-X also gets RDNSS from both, IPv6 address using SLAAC 747 (no IPv6 address from the DHCPv6 server) but the RDNSS obtained 748 from the DHCPv6 server is first (it has a higher priority). 749 However, the other obtained from the RAs is also present. 751 * Windows 7 and Windows 8.1 obtain IPv6 addresses using SLAAC and 752 RDNSS from the DHCPv6 server. They do not get IPv6 address 753 from the DHCPv6 server. Compare the Windows 8.1 behaviour with 754 the previous case. 756 Case 3: Same as Case 2 but Without a DHCPv6 Server 758 o Set up 760 * One IPv6 Router with M=0, A=1, O=1 and an RDNSS is advertised 762 * no DHCPv6 present 764 o Results 766 * Windows 7 and Windows 8.1 get an IPv6 address using SLAAC but 767 they do not get RDNSS information. 769 * MAC OS-X, Fedora 21, Centos 7 and Ubuntu 14.04 get an IPv6 770 address using SLAAC and RDNSS from the RAs. 772 Case 4: All Flags are Set and a DHCPv6 Server is Present 774 o Set up 776 * One IPv6 Router with M=1, A=1, O=1 and an RDNSS is advertised 778 * A DHCPv6 server on the same link advertising IPv6 addresses and 779 RDNSS 781 o Results 783 * Fedora 21 and Centos 7: 785 + They get IPv6 address both from SLAAC and DHCPv6 server. 787 + They get RDNSS both from RAs and DHCPv6 server. 789 + The DNS of the RAs has higher priority. 791 * Ubuntu 14.04: 793 + It gets IPv6 address both using SLAAC and from the DHCPv6 794 server. 796 + It gets RDNSS from RAs only. 798 + From the DHCPv6 server it only gets "Domain Search List" 799 information, no RDNSS. 801 * MAC OS-X: 803 + It gets IPv6 addresses both using SLAAC and from the DHCPv6 804 server. 806 + It also gets RDNSS both from RAs and the DHCPv6 server. 808 + The DNS server of the DHCPv6 has higher priority. 810 * Windows 7 and Windows 8.1: 812 + They get IPv6 address both from SLAAC and DHCPv6 server. 814 + They get RDNSS only from the DHCPv6 server. 816 Case 5: All Flags are Set and There is No DHCPv6 Server is Present 818 o Set up 820 * One IPv6 Router with M=1, A=1, O=1 and an RDNSS is advertised 822 * no DHCPv6 is present 824 o Results 826 * Windows 7 and Windows 8.1 get an IPv6 address using SLAAC but 827 no RDNSS information. 829 * MAC OS-X, Fedora 21, Centos 7, Ubuntu 14.04 get an IPv6 address 830 using SLAAC and RDNSS from the RAs. 832 Case 6: A Prefix is Advertised by RAs but the 'A' flag is not Set 834 o Set up 836 * An IPv6 Router with M=0, A=0 (while a prefix information is 837 advertised), O=0 and an RDNSS is advertised. 839 * DHCPv6 is present 841 o Results 843 * Fedora 21, Centos 7, Ubuntu 14.04 and MAC OS-X: 845 + They do not get any IPv6 address (neither from the RAs, nor 846 from the DHCPv6). 848 + They get a RDNSS from the router only (not from DHCPv6). 850 * Windows 8.1 852 + They get IPv6 address and RDNSS from the DHCPv6 server 853 ("last resort" behaviour). 855 + They do not get any information (neither IPv6 address not 856 RDNSS) from the router. 858 * Windows 7: 860 + They get nothing (neither IPv6 address nor RDNSS) from any 861 source (RA or DHCPv6). 863 A.2.3. Address/DNS Auto-configuration Behavior of Using Two IPv6 Router 864 and a DHCPv6 Server 866 these scenarios there are two routers on the same link. At first, 867 only one router is present (resembling the "legitimate router)", 868 while the second one joins the link after the clients first 869 configured by the RAs of the first router. Our goal is to examine 870 the behaviour of the clients during the interchange of the RAs from 871 the two different routers. 873 Case 7: Router 1 Advertising M=0, O=0 and RDNSS, and then Router 2 874 advertising M=1, O=1 while DHCPv6 is Present 876 o Set up 878 * Initially: 880 + One IPv6 router with M=0, O=0, A=1 and RDNSS advertised and 881 15 seconds time interval of the RAs 883 * After a while (when clients are configured by the RAs of the 884 above router): 886 + Another IPv6 router with M=1, O=1, no advertised prefix 887 information, and 30 seconds time interval of the RAs. 889 + A DHCPv6 server on the same link providing IPv6 addresses 890 and RDNSS. 892 o Results 894 * MAC OS-X and Ubuntu 14.04: 896 + Initially they get address and RDNSS from the first router. 898 + When they receive RAs from the second router, they never get 899 any information (IPv6 address or RDNSS) from the DHCPv6 900 server. 902 * Windows 7: 904 + Initially they get address from the first router - no RDNSS. 906 + When they receive RAs from the second router, they never get 907 any information (IPv6 address or RDNSS) from the DHCPv6 908 server. 910 * Fedora 21 and Centos 7: 912 + Initially they get IPv6 address and RDNSS from the RAs of 913 the first router. o 915 + When they receive an RA from router 2, they also get an IPv6 916 address and RDNSS from the DHCPv6 server while retaining the 917 ones (IPv6 address and RDNSS) obtained from the RAs of the 918 first router. The RDNSS obtained from the first router has 919 a higher priority than the one obtained from the DHCPv6 920 server (probably because it was received first). o 922 + When they receive again RAs from the first router, they 923 lose/forget the information (IPv6 address and RDNSS) 924 obtained from the DHCPv6 server. 926 * Windows 8.1: 928 + Initially, they get just an IPv6 address from the first 929 router 1 - no RDNSS information (since they do not implement 930 RFC 6106). 932 + When they receive RAs from the second router, then they also 933 get an IPv6 address from the DHCPv6 server, as well as RDNSS 934 from it. They do not lose the IPv6 address obtained by the 935 first router using SLAAC. 937 + When they receive RA from the first router, they retain all 938 the obtained so far information (there isn't any change). 940 Case 8: (Router 2) Initially M=1, O=1 and DHCPv6, then 2nd Router 941 (Router 1) Rogue RAs Using M=0, O=0 and RDNSS Provided 943 o Set up 945 * Initially: 947 + One IPv6 router with M=1, O=1, no advertised prefix 948 information, and 30 seconds time interval of the RAs. 950 + A DHCPv6 server on the same link advertising IPv6 addresses 951 and RDNSS. 953 * After a while (when clients are configured by the RAs of the 954 above router): 956 + Another IPv6 router with M=0, O=0, A=1, RDNSS advertised and 957 15 seconds time interval of the RAs. 959 o Results 961 * Fedora 21 and Centos 7: 963 + At first, they get information (IPv6 address and RDNSS) from 964 the DHCPv6 server. 966 + When they receive RAs from the second router, they get 967 address(es) and RDNSS from these RAs. At the same time, the 968 IPv6 address and the RDNSS obtained from the DHCPv6 server 969 are gone. 971 + When they receives again an RA from the first router, they 972 perform the DHCPv6 Confirm/Reply procedure and they get an 973 IPv6 address and RDNSS from the DHCPv6 server while 974 retaining the ones obtained from the RAs of the second 975 router. Moreover, the RDNSS from router 1 has higher 976 priority than the one from DHCPv6. 978 * Ubuntu 14.04: 980 + At first, it gets information (IPv6 address and RDNSS) from 981 the DHCPv6 server. 983 + When it receives RAs from the second router, it also gets 984 information from it, but it does not lose the information 985 obtained from the DHCPv6 server. It retains both. It only 986 gets "Domain Search list" from the DHCPv6 server-no RDNSS 987 information. 989 + When it receives RAs from the first router, there is no 990 change; it retains all the obtained information. 992 * Windows 7: 994 + Initially they get IPv6 address and RDNSS from the DHCPv6 995 server. 997 + When they get RAs from the second router, they lose this 998 information (IPv6 address and RDNSS obtained from the DHCPv6 999 server) and they get only SLAAC addresses using the RAs of 1000 the second router-no RDNSS. 1002 + When they receive RAs from the first router again, they get 1003 RDNSS and IPv6 address from the DHCPv6 server, but they also 1004 keep the SLAAC addresses. 1006 * Windows 8.1: 1008 + Initially they get information (IPv6 address and RDNSS) from 1009 the DHCPv6 server. 1011 + When they receive RAs from the second router, they never get 1012 any information from them. 1014 * MAC OS-X: 1016 + Initially it gets information (IPv6 address and RDNSS) from 1017 the DHCPv6 server. 1019 + When it gets RAs from the second router, it also gets a 1020 SLAAC IPv6 address but no RDNSS information from the RAs of 1021 this router. It also does not lose any information obtained 1022 from DHCPv6. 1024 + When it gets RAs from the first router again, the situation 1025 does not change (IPv6 addresses from both the DHCPv6 and 1026 SLAAC process are retained, but RDNSS information only from 1027 the DHCPv6 server). 1029 Authors' Addresses 1031 Bing Liu 1032 Huawei Technologies 1033 Q14, Huawei Campus, No.156 Beiqing Road 1034 Hai-Dian District, Beijing, 100095 1035 P.R. China 1037 Email: leo.liubing@huawei.com 1038 Sheng Jiang 1039 Huawei Technologies 1040 Q14, Huawei Campus, No.156 Beiqing Road 1041 Hai-Dian District, Beijing, 100095 1042 P.R. China 1044 Email: jiangsheng@huawei.com 1046 Xiangyang Gong 1047 BUPT University 1048 No.3 Teaching Building 1049 Beijing University of Posts and Telecommunications (BUPT) 1050 No.10 Xi-Tu-Cheng Rd. 1051 Hai-Dian District, Beijing 1052 P.R. China 1054 Email: xygong@bupt.edu.cn 1056 Wendong Wang 1057 BUPT University 1058 No.3 Teaching Building 1059 Beijing University of Posts and Telecommunications (BUPT) 1060 No.10 Xi-Tu-Cheng Rd. 1061 Hai-Dian District, Beijing 1062 P.R. China 1064 Email: wdwang@bupt.edu.cn 1066 Enno Rey 1067 ERNW GmbH 1069 Email: erey@ernw.de