V6OPS B. Liu Internet-Draft S. Jiang Intended status: Informational Huawei Technologies Expires: January 7, 2016 X. Gong W. Wang BUPT University E. Rey ERNW GmbH July 6, 2015 DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration draft-ietf-v6ops-dhcpv6-slaac-problem-05 Abstract The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router Advertisement (RA) message. The RA message contains three flags, indicating the availability of address auto-configuration mechanisms and other configuration. These are the M, O, and A flags. These flags by definition are advisory, not prescriptive. This document describes divergent host behaviors observed in popular operating systems. It also discusses operational problems that divergent behaviors might cause. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 7, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Liu, et al. Expires January 7, 2016 [Page 1] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The M, O and A Flags . . . . . . . . . . . . . . . . . . . . 3 2.1. Flags Definition . . . . . . . . . . . . . . . . . . . . 3 2.2. Flags Relationship . . . . . . . . . . . . . . . . . . . 4 3. Behavior Ambiguity Analysis . . . . . . . . . . . . . . . . . 4 4. Observed Divergent Host Behaviors . . . . . . . . . . . . . . 5 5. Operational Problems . . . . . . . . . . . . . . . . . . . . 8 5.1. Inappropriate Sources . . . . . . . . . . . . . . . . . . 8 5.2. Renumbering Issues . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Test Results . . . . . . . . . . . . . . . . . . . . 11 A.1. Test Set 1 . . . . . . . . . . . . . . . . . . . . . . . 11 A.1.1. Test Environment . . . . . . . . . . . . . . . . . . 11 A.1.2. Address Auto-configuration Behavior in the Initial State . . . . . . . . . . . . . . . . . . . . . . . . 11 A.1.3. Address Auto-configuration Behavior in State Transitions . . . . . . . . . . . . . . . . . . . . . 12 A.2. Test Set 2 . . . . . . . . . . . . . . . . . . . . . . . 14 A.2.1. Test Environment . . . . . . . . . . . . . . . . . . 14 A.2.2. Address/DNS Auto-configuration Behavior of Using Only One IPv6 Router and a DHCPv6 Server . . . . . . . . . 14 A.2.3. Address/DNS Auto-configuration Behavior of Using Two IPv6 Router and a DHCPv6 Server . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction IPv6 [RFC2460] hosts invoke Neighbor Discovery (ND) [RFC4861] procedures in order to discover which auto-configuration mechanisms are available to them. The following is a list of auto-configuration mechanisms: Liu, et al. Expires January 7, 2016 [Page 2] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 o DHCPv6 [RFC3315] o Stateless Address Autoconfiguration (SLAAC) [RFC4862] ND specifies an ICMPv6 [RFC4443] Router Advertisement (RA) message. Routers periodically broadcast the RA message to all on-link nodes. They also unicast RA messages in response to solicitations. The RA message contains: o an M (Managed) flag o an O (OtherConfig) flag o zero or more Prefix Information (PI) Options The M flag indicates that addresses are available from DHCPv6. The O flag indicates that other configuration information (e.g., DNS- related information) is available from DHCPv6. The PIO (Prefix Information Option) includes a prefix, an A (Autonomous) flag and other fields. The A flag indicates that the prefix can be used for SLAAC. The M and O flags are advisory, not prescriptive (although A flag is also advisory in definition in standard, it is quite prescriptive in implementations). For example, the M flag indicates that addresses are available from DHCPv6. It does not indicate that hosts are required to acquire addresses from DHCPv6. Similar statements can be made about the O flag. Because of the advisory definition of the flags, in some cases different operating systems appear divergent behaviors. This document analyzes possible divergent host behaviors might happen (some of the possible divergent behaviors are already observed in popular operating systems) and the operational problems might caused by divergent behaviors. 2. The M, O and A Flags This section briefly reviews how the M, O and A flags are defined in [RFC4861]. 2.1. Flags Definition o M (Managed) Flag As decribed in [RFC4861], "When set, it indicates that addresses are available via Dynamic Host Configuration Protocol". o O (Otherconfig) Flag Liu, et al. Expires January 7, 2016 [Page 3] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 "When set, it indicates that other configuration information is available via DHCPv6. Examples of such information are DNS- related information or information on other servers within the network." [RFC4861] Besides, [RFC4861]also defines "If neither M nor O flags are set, this indicates that no information is available via DHCPv6" . o A (Autonomous) Flag A flag is defined in the PIO, "When set indicates that this prefix can be used for stateless address configuration as specified in [RFC4862].". 2.2. Flags Relationship Per [RFC4861], "If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information.". M/O flags semantics are independent of A flag's. The M/O flags indicate that addresses or other configuration are available from DHCPv6, regardless of the A flag setting. Vice versa, The A flag indicates that the prefix can be used by SLAAC, regardless of the M/O flags settings. 3. Behavior Ambiguity Analysis The flags definition ambiguity means, on interpreting the same messages, different hosts might behave differently. Thus it could be un-controlled or un-predictable for administrators on some operations. The ambiguity is summarized as the following aspects. 1) Dependency between DHCPv6 and RA In standards, behavior of DHCPv6 and Neighbor Discovery protocols is specified respectively. But it is not clear that whether there should be any dependency between them. More specifically, it is unclear whether RA (with M=1) is required to trigger DHCPv6; in other words, It is unclear whether hosts should initiate DHCPv6 by themselves If there are no RAs at all. 2) Overlapped configuration between DHCPv6 and RA When address and DNS configuration are both available from DHCPv6 and RA, it is not clear how to deal with the overlapped Liu, et al. Expires January 7, 2016 [Page 4] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 information. Should the hosts accept all the information? Which one should be in the higher priority? For DNS configuration, [RFC6106] clearly specifies "In the case where the DNS options of RDNSS and DNSSL can be obtained from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep some DNS options from all sources" and "the DNS information from DHCP takes precedence over that from RA for DNS queries" (Section 5.3.1 of [RFC6106]). But for address configuration, there's no such guidance. 3) Interpretation on Flags Transition When flags are in transition, e.g. the host is already SLAAC- configured, then M flag changes from FALSE to TRUE, it is not clear whether the host should start DHCPv6 or not; or vise versa, the host is already both SLAAC/DHCPv6 configured, then M flag change from TRUE to FALSE, it is also not clear whether the host should turn DHCPv6 off or not. Transition might caused by the same source that changes the previous configuration; or cause by another source which has different configuration. 4) Relationship between Address Configuring Method and Address Lifetime When one address configuration method is off, that is, the A flag or M flag changes from TRUE to FALSE, it is not clear whether the host should immediately release the corresponding address(es) or just retain it(them) until expired. 5) Relationship between the Flags The semantics of the flags seems not totally independent, but the standards didn't clearly clarify it. For example, can A flag influence the behavior of O flag? (Specifically, when A and M flags are FALSE and O flag is TRUE, it is not clear whether the host should initiate a stand-alone stateless DHCPv6 session.) Divergent behaviors on all the five aspects have been observed among some popular operating systems as described in Section 4 below. 4. Observed Divergent Host Behaviors The authors tested several popular operating systems in order to determine what behaviors the M, O and A flag elicit. In some cases, the M, O and A flags elicit divergent behaviors. The table below Liu, et al. Expires January 7, 2016 [Page 5] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 characterizes those cases. For test details, please refer to Appendix A. The divergence contains two aspect: one is regarding to address auto- configuration; the other is regarding to DNS configuration. Host State Input Behavior ------------------ ----- -------------------------------------------- Host has not No RA Some popular operating systems acquire acquired any addresses from DHCPv6. Others do not. addresses Host has acquired RA Some operating systems release DHCPv6 addresses from with addresses immediately. Some release DHCPv6 DHCPv6 only (M = M =0 addresses when they expire. 1) Host has acquired RA Some operating systems acquire DHCPv6 addresses from with addresses immediately. Others do so only if SLAAC only (A=1) M = 1 their SLAAC addresses expire and cannot be refreshed. Divergent Behaviors on Address Auto-Configuration Host State Input Behavior ----------- ------------- ------------------------------------------- Host has RA with M=0, Some popular operating systems acquire not O=1, no RDNNS from DHCPv6, regardless of the A flag acquired RDNSS; A setting. Others do so, but only if A=1. any DHCPv6 server addresses on the same or link information providing RDNSS (regardless of address provisioning) Host has RA with (Only for those operations systems which not M=0/1, A=1, support [RFC6106]) 1) getting RDNSS from acquired O=1 and an both the RAs and the DHCPv6 server, and the any RDNSS is RDNSS obtained from the router has a higher addresses advertised;A priority. 2) getting RDNSS from both, but Liu, et al. Expires January 7, 2016 [Page 6] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 or DHCPv6 server the RDNSS obtained from the DHCPv6 server information on the same has a higher priority. 3) getting an RDNSS link from the router, and a "domain search list" providing information from the DHCPv6 server- but not IPv6 RDNSS information. addresses and RDNSS Host has Another (Only for those operations systems which acquired router support [RFC6106]) 1) never get any address and advertising information (IPv6 address or RDNSS) from RDNSS from M=1, O=1, no the DHCPv6 server. 2) When receiving an RA the first prefix from router 2, getting an IPv6 address and router information; RDNSS from the DHCPv6 server while (M=0, O=0, A DHCPv6 retaining the address and RDNSS obtained A=1 and server on the from the RAs of the first router. The RDNSS RDNSS same link obtained from the first router has a higher advertised) providing priority; when they receive again RAs from IPv6 the first router, they lose/forget the addresses and information (IPv6 address and RDNSS) RDNSS obtained from the DHCPv6 server. Host has Another (Only for those operations systems which acquired router support [RFC6106]) 1) When they receive RAs address and advertising from the second router, they get RDNSS from M=0, O=0, address(es) and RDNSS from these RAs. At the first A=1, and the same time, the IPv6 address and the router RNDSS RDNSS obtained from the DHCPv6 server are (M=1, O=1, gone. When they receives again an RA from no PIO or the first router, they perform the DHCPv6 RDNSS Confirm/Reply procedure and they get an advertised) IPv6 address and RDNSS from the DHCPv6 server while retaining the ones obtained from the RAs of the second router. Moreover, the RDNSS from router 1 has higher priority than the one from DHCPv6. 2) When it receives RAs from the second router, it also gets information from it, but it does not lose the information obtained from the DHCPv6 server. It retains both. It only gets "Domain Search list" from the DHCPv6 server-no RDNSS information. When it receives RAs from the first router, there is no change; it retains all the obtained information. 3) When it gets RAs from the second router, it also gets a SLAAC IPv6 address but no RDNSS information from the RAs of this router. It Liu, et al. Expires January 7, 2016 [Page 7] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 also does not lose any information obtained from DHCPv6. When it gets RAs from the first router again, the situation does not change (IPv6 addresses from both the DHCPv6 and SLAAC process are retained, but RDNSS information only from the DHCPv6 server). Divergent Behaviors on DNS Configuration 5. Operational Problems This section describes operational issues caused by the divergent behaviors, described above. 5.1. Inappropriate Sources Some operating systems base their decision to acquire configuration information upon inappropriate sources. For example, some operating systems acquire other configuration information if M=0, O=1, and A=1, but not if M=0, O=1 and A=0. In other words, on some operating systems, it is impossible to acquire other information from DHCPv6 (stateless DHCPv6 configuration) unless addresses are acquired from either DHCPv6 or SLAAC. 5.2. Renumbering Issues According to [RFC6879] a renumbering exercise can include the following steps: o Causing hosts that have acquired addresses from one auto- configuration mechanism to release those addresses and acquire new addresses from another auto-configuration mechanism o Causing hosts that have acquired addresses from one auto- configuration mechanism to release those addresses and acquire new addresses from the same auto-configuration mechanism o Causing hosts that have acquired addresses from one auto- configuration mechanism to retain those addresses and acquire new addresses from another auto-configuration mechanism Ideally, these steps could be initiated by broadcasting RA message onto the subnetwork that is being renumbered. Sadly, this is not possible, because the RA message may elicit a different behavior from each host. According to Section 4, renumbering operations would have the following limitations: Liu, et al. Expires January 7, 2016 [Page 8] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 o When M flag is turned off, some operating systems release DHCPv6 acquired addresses immediately, while other will retain then until they expire. This means a flash switch from DHCPv6 to SLAAC would happen on some hosts. Normally, the "make-before-break" approach proposed in [RFC4192] is considered better than flash renumbering. o On some operating systems, if a host has acquired addresses from SLAAC, it is impossible to acquire additional addresses from DHCPv6. This may be required as part of a renumbering operation. 6. Security Considerations (Note: the security considerations for specific operating systems are based on the detailed test results as described in Appendix A.) An attacker, without having to install a rogue router, can install a rogue DHCPv6 server and provide IPv6 addresses to Windows 8.1 systems. This can allow her to interact with these systems in a different scope, which, for instance, is not monitored by an IDPS system. If you want to perform MiTM using a rogue DNS while legitimate RAs with the O flag set are sent to enforce the use of a DHCPv6 server, you can spoof RAs with the same settings with the legitimate prefix (in order to remain undetectable) but advertising YOUR (attacker's) DNS using RDNSS. In this case, Fedora 21, Centos 7 and Ubuntu 14.04 will use the rogue RDNSS (advertised by the RAs) as a first option. Fedora 21 and Centos 7 behaviour cannot be explored for a MiTM attack using a rogue DNS information either, since the one obtained by the RAs of the first router has a higher priority. The behaviour of Fedora 21, Centos 7 and Windows 7 can be exploited for DoS purposes. A rogue IPv6 router not only provides its own information to the clients, but it also removes the previous obtained (legitimate) information. The Fedora and Centos behaviour can also be exploited for MiTM purposes by advertising rogue RDNSS by RAs which include RDNSS information. 7. IANA Considerations This draft does not request any IANA action. 8. Acknowledgements The authors wish to acknowledge BNRC-BUPT (Broad Network Research Centre in Beijing University of Posts and Telecommunications) for Liu, et al. Expires January 7, 2016 [Page 9] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 their testing efforts. Special thanks to Xudong Shi, Longyun Yuan and Xiaojian Xue for their extraordinary effort. Special thanks to Ron Bonica who made a lot of significant contribution to this draft, including draft editing and presentations which dramatically improved this work. The authors also wish to acknowledge Brian E Carpenter, Ran Atkinson, Mikael Abrahamsson, Tatuya Jinmei, Mark Andrews and Mark Smith for their helpful comments. 9. References 9.1. Normative References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010. 9.2. Informative References [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. Liu, et al. Expires January 7, 2016 [Page 10] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013. Appendix A. Test Results The authors from two orgnizations tested different scenarios independent of each other. The following text decribes the two test sets respectively. A.1. Test Set 1 A.1.1. Test Environment The test environment was replicated on a single server using VMware. For simplicity of operation, only one host was run at a time. Network elements were as follows: o Router: Quagga 0.99-19 soft router installed on Ubuntu 11.04 virtual host o DHCPv6 Server: Dibbler-server installed on Ubuntu 11.04 virtual host o Host 1: Window 7 / Window 8.1 Virtual Host o Host 2: Ubuntu 14.04 (Linux Kernel 3.12.0) Virtual Host o Host 3: Mac OS X v10.9 Virtual Host o Host 4: IOS 8.0 (model: Apple iPhone 5S, connected via wifi) A.1.2. Address Auto-configuration Behavior in the Initial State The bullet list below describes host behavior in the initial state, when the host has not yet acquired any auto-configuration information. Each bullet item represents an input and the behavior elicited by that input. o A=0, M=0, O=0 * Windows 8.1 acquired addresses and other information from DHCPv6. * All other hosts acquired no configuration information. o A=0, M=0, O=1 Liu, et al. Expires January 7, 2016 [Page 11] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 * Windows 8.1 acquired addresses and other information from DHCPv6. * Windows 7, OSX 10.9 and IOS 8.0 acquired other information from DHCPv6. * Ubuntu 14.04 acquired no configuration information. o A=0, M=1, O=0 * All hosts acquired addresses and other information from DHCPv6. o A=0, M=1, O=1 * All hosts acquired addresses and other information from DHCPv6. o A=1, M=0, O=0 * Windows 8.1 acquired addresses from SLAAC and DHCPv6. It also acquired non-address information from DHCPv6. * All the other host acquired addresses from SLAAC o A=1, M=0, O=1 * Windows 8.1 acquired addresses from SLAAC and DHCPv6. It also acquired other information from DHCPv6. * All the other hosts acquired addresses from SLAAC and other information from DHCPv6. o A=1, M=1, O=0 * All hosts acquired addresses from SLAAC and DHCPv6. They also acquired other information from DHCPv6. o A=1, M=1, O=1 * All hosts acquired addresses from SLAAC and DHCPv6. They also acquired other information from DHCPv6. As showed above, four inputs result in divergent behaviors. A.1.3. Address Auto-configuration Behavior in State Transitions The bullet list below describes behavior elicited during state transitions. The value x can represents both 0 and 1. Liu, et al. Expires January 7, 2016 [Page 12] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 o Old state (M = x, O = x, A = 1) , New state (M = x, O = x, A = 0) (This means a SLAAC-configured host, which is regardless of DHCPv6 configured or not, receiving A in transition from 1 to 0. ) * All the hosts retain SLAAC addresses until they expire o Old state (M = 0, O = x, A = 1), New state (M = 1, O = x, A = 1) (This means a SLAAC-only host receiving M in transition from 0 to 1.) * Windows 7 acquires addresses from DHCPv6, immediately. * Ubuntu 14.04/OSX 10.9/IOS 8.0 acquires addresses from DHCPv6 only if the SLAAC addresses are allowed to expire * Windows 8.1 was not tested because it always acquire addresses from DHCPv6 regardless of the M flag setting. o Old state (M = 1, O = x, A = x), New state (M = 0, O = x, A = x) (This means a DHCPv6-configured host receiving M in transition from 1 to 0.) * Windows 7 immediately released the DHCPv6 address * Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0 keep the DHCPv6 addresses until they expire o Old state (M = 1, O = x, A = 0), New state (M = 1, O = x, A = 1) (This means a DHCPv6-only host receiving A in transition from 0 to 1.) * All host acquire addresses from SLAAC o Old state (M = 0, O = 1, A = x), New state (M = 1, O = 1, A = x) (This means a Stateless DHCPv6-configured host [RFC3736], which is regardless of SLAAC configured or not, receiving M in transition from 0 to 1 with keeping O=1 ) * Windows 7 acquires addresses and refreshes other information from DHCPv6 * Ubuntu 14.04/OSX 10.9/IOS 8.0 does nothing * Windows 8.1 was not tested because it always acquire addresses from DHCPv6 regardless of the M flag setting. o Old state (M = 1, O = 1, A = x), New state (M = 0, O = 1, A = x) Liu, et al. Expires January 7, 2016 [Page 13] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 (This means a Stateful DHCPv6-configured host, which is regardless of SLAAC configured or not, receiving M in transition from 0 to 1 with keeping O=1 ) * Windows 7 released all DHCPv6 addresses and refreshes all DHCPv6 other information. * Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0 does nothing A.2. Test Set 2 A.2.1. Test Environment This test was built on real devices. All the devices are located on the same link. o A DHCPv6 Server and specifically, a DHCP ISC Version 4.3.1 installed in CentOs 6.6. The DHCPv6 server is configured to provide both IPv6 addresses and RDNSS information. o Two routers Cisco 4321 using Cisco IOS Software version 15.5(1)S. o The following OS as clients: * Fedora 21, kernel version 3.18.3-201 x64 * Ubuntu 14.04.1 LTS, kernel version 3.13.0-44-generic (rdnssd packet installed) * CentOS 7, kernel version 3.10.0-123.13.2.el7 * Mac OS-X 10.10.2 Yosemite 14.0.0 Darwin * Windows 7 * Windows 8.1 A.2.2. Address/DNS Auto-configuration Behavior of Using Only One IPv6 Router and a DHCPv6 Server In these scenarios there is two one router and, unless otherwise specified, one DHCPv6 server on the same link. The behaviour of the router and of the DHCPv6 server remain unchanged during the tests. Case 1: One Router with the Management Flag not Set and a DHCPv6 Server o Set up Liu, et al. Expires January 7, 2016 [Page 14] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 * One IPv6 Router with M=0, A=1, O=0 and an RDNSS is advertised * A DHCPv6 server on the same link advertising IPv6 addresses and RDNSS o Results * Fedora 21, MAC OS-X, CentOS 7 and Ubuntu 14.04 get an IPv6 address and an RDNSS from the IPv6 router only. * Windows 7 get an IPv6 address from the router only, but they do not get any DNS information, neither from the router nor from the DHCPv6 server. They also do not get IPv6 address from the DHCPv6 server. * Windows 8.1 get an IPv6 address from both the IPv6 router and the DHCPv6 server, despite the fact that the Management flag (M) is not set. They get RDNSS information from the DHCPv6 only. Case 2: One Router with Conflicting Parameters and a DHCPv6 Server o Set up * One IPv6 Router with M=0, A=1, O=1 and an RDNSS is advertised * A DHCPv6 server on the same link advertising IPv6 addresses and RDNSS o Results * Fedora 21, Centos 7 and Ubuntu 14.04 get IPv6 address using SLAAC only (no address from the DHCPv6 server). + Fedora 21, Centos 7 get RDNSS from both the RAs and the DHCPv6 server. The RDNSS obtained from the router has a higher priority though. + Ubuntu 14.04 gets an RDNSS from the router, and a "domain search list" information from the DHCPv6 server - but not RDNSS information. * MAC OS-X also gets RDNSS from both, IPv6 address using SLAAC (no IPv6 address from the DHCPv6 server) but the RDNSS obtained from the DHCPv6 server is first (it has a higher priority). However, the other obtained from the RAs is also present. Liu, et al. Expires January 7, 2016 [Page 15] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 * Windows 7 and Windows 8.1 obtain IPv6 addresses using SLAAC and RDNSS from the DHCPv6 server. They do not get IPv6 address from the DHCPv6 server. Compare the Windows 8.1 behaviour with the previous case. Case 3: Same as Case 2 but Without a DHCPv6 Server o Set up * One IPv6 Router with M=0, A=1, O=1 and an RDNSS is advertised * no DHCPv6 present o Results * Windows 7 and Windows 8.1 get an IPv6 address using SLAAC but they do not get RDNSS information. * MAC OS-X, Fedora 21, Centos 7 and Ubuntu 14.04 get an IPv6 address using SLAAC and RDNSS from the RAs. Case 4: All Flags are Set and a DHCPv6 Server is Present o Set up * One IPv6 Router with M=1, A=1, O=1 and an RDNSS is advertised * A DHCPv6 server on the same link advertising IPv6 addresses and RDNSS o Results * Fedora 21 and Centos 7: + They get IPv6 address both from SLAAC and DHCPv6 server. + They get RDNSS both from RAs and DHCPv6 server. + The DNS of the RAs has higher priority. * Ubuntu 14.04: + It gets IPv6 address both using SLAAC and from the DHCPv6 server. + It gets RDNSS from RAs only. Liu, et al. Expires January 7, 2016 [Page 16] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 + From the DHCPv6 server it only gets "Domain Search List" information, no RDNSS. * MAC OS-X: + It gets IPv6 addresses both using SLAAC and from the DHCPv6 server. + It also gets RDNSS both from RAs and the DHCPv6 server. + The DNS server of the DHCPv6 has higher priority. * Windows 7 and Windows 8.1: + They get IPv6 address both from SLAAC and DHCPv6 server. + They get RDNSS only from the DHCPv6 server. Case 5: All Flags are Set and There is No DHCPv6 Server is Present o Set up * One IPv6 Router with M=1, A=1, O=1 and an RDNSS is advertised * no DHCPv6 is present o Results * Windows 7 and Windows 8.1 get an IPv6 address using SLAAC but no RDNSS information. * MAC OS-X, Fedora 21, Centos 7, Ubuntu 14.04 get an IPv6 address using SLAAC and RDNSS from the RAs. Case 6: A Prefix is Advertised by RAs but the 'A' flag is not Set o Set up * An IPv6 Router with M=0, A=0 (while a prefix information is advertised), O=0 and an RDNSS is advertised. * DHCPv6 is present o Results * Fedora 21, Centos 7, Ubuntu 14.04 and MAC OS-X: Liu, et al. Expires January 7, 2016 [Page 17] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 + They do not get any IPv6 address (neither from the RAs, nor from the DHCPv6). + They get a RDNSS from the router only (not from DHCPv6). * Windows 8.1 + They get IPv6 address and RDNSS from the DHCPv6 server ("last resort" behaviour). + They do not get any information (neither IPv6 address not RDNSS) from the router. * Windows 7: + They get nothing (neither IPv6 address nor RDNSS) from any source (RA or DHCPv6). A.2.3. Address/DNS Auto-configuration Behavior of Using Two IPv6 Router and a DHCPv6 Server these scenarios there are two routers on the same link. At first, only one router is present (resembling the "legitimate router)", while the second one joins the link after the clients first configured by the RAs of the first router. Our goal is to examine the behaviour of the clients during the interchange of the RAs from the two different routers. Case 7: Router 1 Advertising M=0, O=0 and RDNSS, and then Router 2 advertising M=1, O=1 while DHCPv6 is Present o Set up * Initially: + One IPv6 router with M=0, O=0, A=1 and RDNSS advertised and 15 seconds time interval of the RAs * After a while (when clients are configured by the RAs of the above router): + Another IPv6 router with M=1, O=1, no advertised prefix information, and 30 seconds time interval of the RAs. + A DHCPv6 server on the same link providing IPv6 addresses and RDNSS. o Results Liu, et al. Expires January 7, 2016 [Page 18] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 * MAC OS-X and Ubuntu 14.04: + Initially they get address and RDNSS from the first router. + When they receive RAs from the second router, they never get any information (IPv6 address or RDNSS) from the DHCPv6 server. * Windows 7: + Initially they get address from the first router - no RDNSS. + When they receive RAs from the second router, they never get any information (IPv6 address or RDNSS) from the DHCPv6 server. * Fedora 21 and Centos 7: + Initially they get IPv6 address and RDNSS from the RAs of the first router. o + When they receive an RA from router 2, they also get an IPv6 address and RDNSS from the DHCPv6 server while retaining the ones (IPv6 address and RDNSS) obtained from the RAs of the first router. The RDNSS obtained from the first router has a higher priority than the one obtained from the DHCPv6 server (probably because it was received first). o + When they receive again RAs from the first router, they lose/forget the information (IPv6 address and RDNSS) obtained from the DHCPv6 server. * Windows 8.1: + Initially, they get just an IPv6 address from the first router 1 - no RDNSS information (since they do not implement RFC 6106). + When they receive RAs from the second router, then they also get an IPv6 address from the DHCPv6 server, as well as RDNSS from it. They do not lose the IPv6 address obtained by the first router using SLAAC. + When they receive RA from the first router, they retain all the obtained so far information (there isn't any change). Case 8: (Router 2) Initially M=1, O=1 and DHCPv6, then 2nd Router (Router 1) Rogue RAs Using M=0, O=0 and RDNSS Provided Liu, et al. Expires January 7, 2016 [Page 19] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 o Set up * Initially: + One IPv6 router with M=1, O=1, no advertised prefix information, and 30 seconds time interval of the RAs. + A DHCPv6 server on the same link advertising IPv6 addresses and RDNSS. * After a while (when clients are configured by the RAs of the above router): + Another IPv6 router with M=0, O=0, A=1, RDNSS advertised and 15 seconds time interval of the RAs. o Results * Fedora 21 and Centos 7: + At first, they get information (IPv6 address and RDNSS) from the DHCPv6 server. + When they receive RAs from the second router, they get address(es) and RDNSS from these RAs. At the same time, the IPv6 address and the RDNSS obtained from the DHCPv6 server are gone. + When they receives again an RA from the first router, they perform the DHCPv6 Confirm/Reply procedure and they get an IPv6 address and RDNSS from the DHCPv6 server while retaining the ones obtained from the RAs of the second router. Moreover, the RDNSS from router 1 has higher priority than the one from DHCPv6. * Ubuntu 14.04: + At first, it gets information (IPv6 address and RDNSS) from the DHCPv6 server. + When it receives RAs from the second router, it also gets information from it, but it does not lose the information obtained from the DHCPv6 server. It retains both. It only gets "Domain Search list" from the DHCPv6 server-no RDNSS information. + When it receives RAs from the first router, there is no change; it retains all the obtained information. Liu, et al. Expires January 7, 2016 [Page 20] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 * Windows 7: + Initially they get IPv6 address and RDNSS from the DHCPv6 server. + When they get RAs from the second router, they lose this information (IPv6 address and RDNSS obtained from the DHCPv6 server) and they get only SLAAC addresses using the RAs of the second router-no RDNSS. + When they receive RAs from the first router again, they get RDNSS and IPv6 address from the DHCPv6 server, but they also keep the SLAAC addresses. * Windows 8.1: + Initially they get information (IPv6 address and RDNSS) from the DHCPv6 server. + When they receive RAs from the second router, they never get any information from them. * MAC OS-X: + Initially it gets information (IPv6 address and RDNSS) from the DHCPv6 server. + When it gets RAs from the second router, it also gets a SLAAC IPv6 address but no RDNSS information from the RAs of this router. It also does not lose any information obtained from DHCPv6. + When it gets RAs from the first router again, the situation does not change (IPv6 addresses from both the DHCPv6 and SLAAC process are retained, but RDNSS information only from the DHCPv6 server). Authors' Addresses Bing Liu Huawei Technologies Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: leo.liubing@huawei.com Liu, et al. Expires January 7, 2016 [Page 21] Internet-Draft DHCPv6/SLAAC Interact Problems July 2015 Sheng Jiang Huawei Technologies Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: jiangsheng@huawei.com Xiangyang Gong BUPT University No.3 Teaching Building Beijing University of Posts and Telecommunications (BUPT) No.10 Xi-Tu-Cheng Rd. Hai-Dian District, Beijing P.R. China Email: xygong@bupt.edu.cn Wendong Wang BUPT University No.3 Teaching Building Beijing University of Posts and Telecommunications (BUPT) No.10 Xi-Tu-Cheng Rd. Hai-Dian District, Beijing P.R. China Email: wdwang@bupt.edu.cn Enno Rey ERNW GmbH Email: erey@ernw.de Liu, et al. Expires January 7, 2016 [Page 22]