draft-ietf-v6ops-dhcpv6-slaac-problem-05.txt   draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt 
V6OPS B. Liu V6OPS B. Liu
Internet-Draft S. Jiang Internet-Draft S. Jiang
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: January 7, 2016 X. Gong Expires: August 8, 2016 X. Gong
W. Wang W. Wang
BUPT University BUPT University
E. Rey E. Rey
ERNW GmbH ERNW GmbH
July 6, 2015 February 5, 2016
DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration
draft-ietf-v6ops-dhcpv6-slaac-problem-05 draft-ietf-v6ops-dhcpv6-slaac-problem-06
Abstract Abstract
The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router
Advertisement (RA) message. The RA message contains three flags, Advertisement (RA) message. The RA message contains three flags,
indicating the availability of address auto-configuration mechanisms indicating the availability of address auto-configuration mechanisms
and other configuration. These are the M, O, and A flags. These and other configuration such as DNS-related configuration. These are
flags by definition are advisory, not prescriptive. the M, O, and A flags, which by definition are advisory, not
prescriptive.
This document describes divergent host behaviors observed in popular This document describes divergent host behaviors observed in popular
operating systems. It also discusses operational problems that operating systems. It also discusses operational problems that the
divergent behaviors might cause. divergent behaviors might cause.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2016. This Internet-Draft will expire on August 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The M, O and A Flags . . . . . . . . . . . . . . . . . . . . 3 2. The M, O and A Flags . . . . . . . . . . . . . . . . . . . . 3
2.1. Flags Definition . . . . . . . . . . . . . . . . . . . . 3 2.1. Flags Definition . . . . . . . . . . . . . . . . . . . . 4
2.2. Flags Relationship . . . . . . . . . . . . . . . . . . . 4 2.2. Flags Relationship . . . . . . . . . . . . . . . . . . . 4
3. Behavior Ambiguity Analysis . . . . . . . . . . . . . . . . . 4 3. Behavior Ambiguity Analysis . . . . . . . . . . . . . . . . . 4
4. Observed Divergent Host Behaviors . . . . . . . . . . . . . . 5 4. Observed Divergent Host Behaviors . . . . . . . . . . . . . . 6
5. Operational Problems . . . . . . . . . . . . . . . . . . . . 8 4.1. Divergent Behavior on Address Auto-Configuration . . . . 6
5.1. Inappropriate Sources . . . . . . . . . . . . . . . . . . 8 4.2. Divergent Behavior on DNS Configuration . . . . . . . . . 7
5.2. Renumbering Issues . . . . . . . . . . . . . . . . . . . 8 5. Operational Problems . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5.1. Standalone Stateless DHCPv6 Configuration not available . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5.2. Renumbering Issues . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Test Results . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
A.1. Test Set 1 . . . . . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11
A.1.1. Test Environment . . . . . . . . . . . . . . . . . . 11 Appendix A. Test Results . . . . . . . . . . . . . . . . . . . . 12
A.1. Test Set 1 . . . . . . . . . . . . . . . . . . . . . . . 12
A.1.1. Test Environment . . . . . . . . . . . . . . . . . . 12
A.1.2. Address Auto-configuration Behavior in the Initial A.1.2. Address Auto-configuration Behavior in the Initial
State . . . . . . . . . . . . . . . . . . . . . . . . 11 State . . . . . . . . . . . . . . . . . . . . . . . . 12
A.1.3. Address Auto-configuration Behavior in State A.1.3. Address Auto-configuration Behavior in State
Transitions . . . . . . . . . . . . . . . . . . . . . 12 Transitions . . . . . . . . . . . . . . . . . . . . . 13
A.2. Test Set 2 . . . . . . . . . . . . . . . . . . . . . . . 14 A.2. Test Set 2 . . . . . . . . . . . . . . . . . . . . . . . 15
A.2.1. Test Environment . . . . . . . . . . . . . . . . . . 14 A.2.1. Test Environment . . . . . . . . . . . . . . . . . . 15
A.2.2. Address/DNS Auto-configuration Behavior of Using Only A.2.2. Address/DNS Auto-configuration Behavior of Using Only
One IPv6 Router and a DHCPv6 Server . . . . . . . . . 14 One IPv6 Router and a DHCPv6 Server . . . . . . . . . 15
A.2.3. Address/DNS Auto-configuration Behavior of Using Two A.2.3. Address/DNS Auto-configuration Behavior of Using Two
IPv6 Router and a DHCPv6 Server . . . . . . . . . . . 18 IPv6 Router and a DHCPv6 Server . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
IPv6 [RFC2460] hosts invoke Neighbor Discovery (ND) [RFC4861] IPv6 [RFC2460] hosts could invoke Neighbor Discovery (ND) [RFC4861]
procedures in order to discover which auto-configuration mechanisms to to discover which auto-configuration mechanisms are available to
are available to them. The following is a list of auto-configuration them. There are two auto-configuration mechanisms in IPv6:
mechanisms:
o DHCPv6 [RFC3315] o DHCPv6 [RFC3315]
o Stateless Address Autoconfiguration (SLAAC) [RFC4862] o Stateless Address Autoconfiguration (SLAAC) [RFC4862]
ND specifies an ICMPv6 [RFC4443] Router Advertisement (RA) message. ND specifies an ICMPv6-based [RFC4443] Router Advertisement (RA)
Routers periodically broadcast the RA message to all on-link nodes. message. Routers periodically multicast the RA messages to all on-
They also unicast RA messages in response to solicitations. The RA link nodes. They also unicast RA messages in response to
message contains: solicitations. The RA message contains (but not limited to):
o an M (Managed) flag o an M (Managed) flag, indicating that addresses are available from
DHCPv6 or not
o an O (OtherConfig) flag o an O (OtherConfig) flag, indicating that other configuration
information (e.g., DNS-related information) is available from
DHCPv6 or not
o zero or more Prefix Information (PI) Options o zero or more Prefix Information (PI) Options
The M flag indicates that addresses are available from DHCPv6. The O an A (Autonomous) flag is included, indicating that the prefix
flag indicates that other configuration information (e.g., DNS- can be used for SLAAC or not
related information) is available from DHCPv6. The PIO (Prefix
Information Option) includes a prefix, an A (Autonomous) flag and The M and O flags are advisory, not prescriptive. For example, the M
other fields. The A flag indicates that the prefix can be used for flag indicates that addresses are available from DHCPv6, but It does
SLAAC. The M and O flags are advisory, not prescriptive (although A not indicate that hosts are required to acquire addresses from
flag is also advisory in definition in standard, it is quite DHCPv6. Similar statements can be made about the O flag. (A flag is
prescriptive in implementations). For example, the M flag indicates also advisory by definition in standard, but it is quite prescriptive
that addresses are available from DHCPv6. It does not indicate that in implementations according to the test results in the appendix.)
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 Because of the advisory definition of the flags, in some cases
different operating systems appear divergent behaviors. This different operating systems appear divergent behaviors. This
document analyzes possible divergent host behaviors might happen document analyzes possible divergent host behaviors might happen
(some of the possible divergent behaviors are already observed in (most of the possible divergent behaviors are already observed in
popular operating systems) and the operational problems might caused popular operating systems) and the operational problems might caused
by divergent behaviors. by divergent behaviors.
2. The M, O and A Flags 2. The M, O and A Flags
This section briefly reviews how the M, O and A flags are defined in This section briefly reviews how the M, O and A flags are defined in
[RFC4861]. ND[RFC4861] and SLAAC[RFC4862].
2.1. Flags Definition 2.1. Flags Definition
o M (Managed) Flag o M (Managed) Flag
As decribed in [RFC4861], "When set, it indicates that As decribed in [RFC4861], "When set, it indicates that
addresses are available via Dynamic Host Configuration addresses are available via Dynamic Host Configuration
Protocol". Protocol".
o O (Otherconfig) Flag o O (Otherconfig) Flag
skipping to change at page 4, line 4 skipping to change at page 4, line 14
2.1. Flags Definition 2.1. Flags Definition
o M (Managed) Flag o M (Managed) Flag
As decribed in [RFC4861], "When set, it indicates that As decribed in [RFC4861], "When set, it indicates that
addresses are available via Dynamic Host Configuration addresses are available via Dynamic Host Configuration
Protocol". Protocol".
o O (Otherconfig) Flag o O (Otherconfig) Flag
"When set, it indicates that other configuration information is "When set, it indicates that other configuration information is
available via DHCPv6. Examples of such information are DNS- available via DHCPv6. Examples of such information are DNS-
related information or information on other servers within the related information or information on other servers within the
network." [RFC4861] network." [RFC4861]
Besides, [RFC4861]also defines "If neither M nor O flags are "If neither M nor O flags are set, this indicates that no
set, this indicates that no information is available via information is available via DHCPv6" . [RFC4861]
DHCPv6" .
o A (Autonomous) Flag o A (Autonomous) Flag
A flag is defined in the PIO, "When set indicates that this A flag is defined in the PIO, "When set indicates that this
prefix can be used for stateless address configuration as prefix can be used for stateless address configuration as
specified in [RFC4862].". specified in [RFC4862].".
2.2. Flags Relationship 2.2. Flags Relationship
Per [RFC4861], "If the M flag is set, the O flag is redundant and can Per [RFC4861], "If the M flag is set, the O flag is redundant and can
be ignored because DHCPv6 will return all available configuration be ignored because DHCPv6 will return all available configuration
information.". information.".
M/O flags semantics are independent of A flag's. The M/O flags There is no explicit description of the relationship between A flag
indicate that addresses or other configuration are available from and the M/O flags.
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 3. Behavior Ambiguity Analysis
The flags definition ambiguity means, on interpreting the same The ambiguity of the flags definition means that when interpreting
messages, different hosts might behave differently. Thus it could be the same messages, different hosts might behave differently. The
un-controlled or un-predictable for administrators on some ambiguity space is analyzed as the following aspects.
operations. The ambiguity is summarized as the following aspects.
1) Dependency between DHCPv6 and RA 1) Dependency between DHCPv6 and RA
In standards, behavior of DHCPv6 and Neighbor Discovery protocols In standards, behavior of DHCPv6 and Neighbor Discovery protocols
is specified respectively. But it is not clear that whether there is specified respectively. But it is not clear that whether there
should be any dependency between them. More specifically, it is should be any dependency between them. More specifically, it is
unclear whether RA (with M=1) is required to trigger DHCPv6; in unclear whether RA (with M=1) is required to trigger DHCPv6; in
other words, It is unclear whether hosts should initiate DHCPv6 by other words, It is unclear whether hosts should initiate DHCPv6 by
themselves If there are no RAs at all. themselves if there are no RAs at all.
2) Overlapped configuration between DHCPv6 and RA 2) Overlapping configuration between DHCPv6 and RA
When address and DNS configuration are both available from DHCPv6 When address and DNS configuration are both available from DHCPv6
and RA, it is not clear how to deal with the overlapped and RA, it is not clear how to deal with the overlapping
information. Should the hosts accept all the information? Which information. Should the hosts accept all the information? If the
one should be in the higher priority? information conflicts, which one should take higher priority?
For DNS configuration, [RFC6106] clearly specifies "In the case For DNS configuration, [RFC6106] clearly specifies "In the case
where the DNS options of RDNSS and DNSSL can be obtained from where the DNS options of RDNSS and DNSSL can be obtained from
multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep
some DNS options from all sources" and "the DNS information from some DNS options from all sources" and "the DNS information from
DHCP takes precedence over that from RA for DNS queries" DHCP takes precedence over that from RA for DNS queries"
(Section 5.3.1 of [RFC6106]). But for address configuration, (Section 5.3.1 of [RFC6106]). But for address configuration,
there's no such guidance. there's no such guidance.
3) Interpretation on Flags Transition 3) Interpretation on Flags Transition
When flags are in transition, e.g. the host is already SLAAC- - Impact on SLAAC/DHCPv6 on and off
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 When flags are in transition, e.g. the host is already SLAAC-
previous configuration; or cause by another source which has configured, then M flag changes from FALSE to TRUE, it is not
different configuration. clear whether the host should start DHCPv6 or not; or vise
versa, the host is already configured by both SLAAC and DHCPv6,
then M flag change from TRUE to FALSE, it is also not clear
whether the host should turn DHCPv6 off or not.
4) Relationship between Address Configuring Method and Address - Impact on address lifetime
Lifetime
When one address configuration method is off, that is, the A flag When one address configuration method is off, that is, the A
or M flag changes from TRUE to FALSE, it is not clear whether the flag or M flag changes from TRUE to FALSE, it is not clear
host should immediately release the corresponding address(es) or whether one host should immediately release the corresponding
just retain it(them) until expired. address or just retain it until the lifetime expires.
5) Relationship between the Flags 4) Relationship between the Flags
The semantics of the flags seems not totally independent, but the As described above, the relationship between A flag and M/O flags
standards didn't clearly clarify it. For example, can A flag is unspecified.
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 It could be reasonably deduced that M flag should be independent
from A flag. In other words, the M flag only cares DHCPv6 address
configuration, while the A flag only cares SLAAC.
But for A flag and O flag, ambiguity could possibly happen. For
example, when A is FALSE (when M is also FALSE) and O is TRUE, it
is not clear whether the host should initiate a stand-alone
stateless DHCPv6 session.
Divergent behaviors on all these aspects have been observed among
some popular operating systems as described in Section 4 below. some popular operating systems as described in Section 4 below.
4. Observed Divergent Host Behaviors 4. Observed Divergent Host Behaviors
The authors tested several popular operating systems in order to The authors tested several popular operating systems in order to
determine what behaviors the M, O and A flag elicit. In some cases, 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 the M, O and A flags elicit divergent behaviors. The table below
characterizes those cases. For test details, please refer to characterizes those cases. For test details, please refer to
Appendix A. Appendix A.
The divergence contains two aspect: one is regarding to address auto- Operation diverges in two ways: one is regarding to address auto-
configuration; the other is regarding to DNS configuration. configuration; the other is regarding to DNS configuration.
Host State Input Behavior 4.1. Divergent Behavior on Address Auto-Configuration
------------------ ----- --------------------------------------------
Host has not No RA Some popular operating systems acquire Divergence 1-1
acquired any addresses from DHCPv6. Others do not.
addresses
Host has acquired RA Some operating systems release DHCPv6 o Host state: has not acquired any addresses.
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 o Input: no RA.
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 o Divergent Behavior
Host State Input Behavior 1) Acquiring addresses from DHCPv6.
----------- ------------- -------------------------------------------
Host has RA with M=0, Some popular operating systems acquire 2) No DHCPv6 action.
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 Divergence 1-2
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
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 o Host state: has acquired addresses from DHCPv6 only (M = 1).
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 o Input: RA with M =0.
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
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 o Divergent Behavior
1) Releasing DHCPv6 addresses immediately.
2) Releasing DHCPv6 addresses when they expire.
Divergence 1-3
o Host state: has acquired addresses from SLAAC only (A=1).
o Input: RA with M =1.
o Divergent Behavior
1) Acquiring DHCPv6 addresses immediately.
2) Acquiring DHCPv6 addresses only if their SLAAC addresses
expire and cannot be refreshed.
4.2. Divergent Behavior on DNS Configuration
Divergence 2-1
o Host state: has not acquired any addresses or information.
o Input: RA with M=0, O=1, no RDNSS; and a DHCPv6 server on the same
link providing RDNSS (regardless of address provisioning).
o Divergent Behavior
1) Acquiring RDNNS from DHCPv6, regardless of the A flag
setting.
2) Acquiring RDNNS from DHCPv6 only if A=1.
Divergence 2-2
(This divergence is only for those operations systems which
support[RFC6106].)
o Host state: has not acquired any addresses or information.
o Input: RA with M=0/1, A=1, O=1 and an RDNSS is advertised; and a
DHCPv6 server on the same link providing IPv6 addresses and RDNSS.
o Divergent Behavior
1) Getting RDNSS from both the RAs and the DHCPv6 server, and
the RDNSS obtained from the router has a higher priority.
2) Getting RDNSS from both the RAs and the DHCPv6 server, but
the RDNSS obtained from the DHCPv6 server has a higher
priority.
3) Getting RDNSS from the router, and a "domain search list"
information only from the DHCPv6 server(no RDNSS).
Divergence 2-3
(This divergence is only for those operations systems which
support[RFC6106].)
o Host state: has acquired address and RDNSS from the first router's
RAs (M=0, O=0, PIO with A=1, and RDNSS advertised).
o Input: another router advertising M=1, O=1, no prefix information;
and a DHCPv6 server on the same link providing IPv6 addresses and
RDNSS.
o Divergent Behavior
1) Never getting any information (neither IPv6 address nor
RDNSS) from the DHCPv6 server.
2) Getting an IPv6 address and RDNSS from the DHCPv6 server
while retaining the address and RDNSS obtained from the RAs of
the first router.
(More details: the RDNSS obtained from the first router has
a higher priority; when they receive again RAs from the
first router, they lose/forget the information (IPv6 address
and RDNSS) obtained from the DHCPv6 server.)
Divergence 2-4
(This divergence is only for those operations systems which
support[RFC6106].)
o Host state: has acquired address and RDNSS from the DHCPv6 server
indicated by the first router (M=1, O=1, no PIO or RDNSS
advertised).
o Input: another router advertising M=0, O=0, PIO with A=1, and
RNDSS.
o Divergent Behavior
1) Getting address and RDNSS from the second router's RAs, and
releasing the IPv6 address and the RDNSS obtained from the
DHCPv6 server.
(More details: when receiving RAs from the first router
again, it performs the DHCPv6 Confirm/Reply procedure and
gets 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.)
2) Getting address and RDNSS from the second router's RAs, and
retaining the IPv6 address and the "Domain Search list"
obtained from the DHCPv6 server. (It did not get the RDNSS
from the DHCPv6 server, as described in Divergence 2-2.)
(More details: when receiving RAs from the first router
again, there is no change; all the obtained information is
retained.)
3) Getting address but no RDNSS from the second router's RAs,
and also retaining the IPv6 address and the RDNSS obtained from
the DHCPv6 server.
(More details: when receiving RAs from the first router
again, there is no change; all the obtained information is
retained.)
5. Operational Problems 5. Operational Problems
This section describes operational issues caused by the divergent This section is not a full collection of the potential problems. It
behaviors, described above. is some operational issues that the authors could see at current
stage.
5.1. Inappropriate Sources 5.1. Standalone Stateless DHCPv6 Configuration not available
Some operating systems base their decision to acquire configuration It is impossible for some hosts to acquire stateless DHCPv6
information upon inappropriate sources. For example, some operating configuration unless addresses are acquired from either DHCPv6 or
systems acquire other configuration information if M=0, O=1, and A=1, SLAAC (Which requires M flag or A flag is TURE).
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 5.2. Renumbering Issues
According to [RFC6879] a renumbering exercise can include the According to [RFC6879] a renumbering exercise can include the
following steps: following steps:
o Causing hosts that have acquired addresses from one auto- o Causing a host to
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- release the SLAAC address and acquire a new address from
configuration mechanism to retain those addresses and acquire new DHCPv6; or vice-versa.
addresses from another auto-configuration mechanism
Ideally, these steps could be initiated by broadcasting RA message release the current SLAAC address and acquire another new SLAAC
onto the subnetwork that is being renumbered. Sadly, this is not address (might comes from different source).
possible, because the RA message may elicit a different behavior from
each host. According to Section 4, renumbering operations would have
the following limitations:
o When M flag is turned off, some operating systems release DHCPv6 retain current SLAAC or DHCPv6 address and acquire another new
acquired addresses immediately, while other will retain then until address from DHCPv6 or SLAAC.
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 Ideally, these steps could be initiated by multicasting RA messages
SLAAC, it is impossible to acquire additional addresses from onto the link that is being renumbered. Sadly, this is not possible,
DHCPv6. This may be required as part of a renumbering operation. because the RA messages may elicit a different behavior from each
host.
6. Security Considerations 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 An attacker, without having to install a rogue router, can install a
rogue DHCPv6 server and provide IPv6 addresses to Windows 8.1 rogue DHCPv6 server and provide IPv6 addresses to Windows 8.1
systems. This can allow her to interact with these systems in a systems. This can allow her to interact with these systems in a
different scope, which, for instance, is not monitored by an IDPS different scope, which, for instance, is not monitored by an IDPS
system. system.
If you want to perform MiTM using a rogue DNS while legitimate RAs If an attacker wants to perform MiTM (Man in The Middle) using a
with the O flag set are sent to enforce the use of a DHCPv6 server, rogue DNS while legitimates RAs with the O flag set are sent to
you can spoof RAs with the same settings with the legitimate prefix enforce the use of a DHCPv6 server, the attacker can spoof RAs with
(in order to remain undetectable) but advertising YOUR (attacker's) the same settings with the legitimate prefix (in order to remain
DNS using RDNSS. In this case, Fedora 21, Centos 7 and Ubuntu 14.04 undetectable) but advertising the attacker's DNS using RDNSS. In
will use the rogue RDNSS (advertised by the RAs) as a first option. 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 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 using a rogue DNS information either, since the one obtained by the
RAs of the first router has a higher priority. RAs of the first router has a higher priority.
The behaviour of Fedora 21, Centos 7 and Windows 7 can be exploited 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 for DoS purposes. A rogue IPv6 router not only provides its own
information to the clients, but it also removes the previous obtained information to the clients, but it also removes the previous obtained
(legitimate) information. The Fedora and Centos behaviour can also (legitimate) information. The Fedora and Centos behaviour can also
be exploited for MiTM purposes by advertising rogue RDNSS by RAs be exploited for MiTM purposes by advertising rogue RDNSS by RAs
which include RDNSS information. which include RDNSS information.
(Note: the security considerations for specific operating systems are
based on the detailed test results as described in Appendix A.)
7. IANA Considerations 7. IANA Considerations
This draft does not request any IANA action. This draft does not request any IANA action.
8. Acknowledgements 8. Acknowledgements
The authors wish to acknowledge BNRC-BUPT (Broad Network Research The authors wish to acknowledge BNRC-BUPT (Broad Network Research
Centre in Beijing University of Posts and Telecommunications) for Centre in Beijing University of Posts and Telecommunications) for
their testing efforts. Special thanks to Xudong Shi, Longyun Yuan their testing efforts. Special thanks to Xudong Shi, Longyun Yuan
and Xiaojian Xue for their extraordinary effort. and Xiaojian Xue for their extraordinary effort.
skipping to change at page 10, line 20 skipping to change at page 11, line 10
The authors also wish to acknowledge Brian E Carpenter, Ran Atkinson, The authors also wish to acknowledge Brian E Carpenter, Ran Atkinson,
Mikael Abrahamsson, Tatuya Jinmei, Mark Andrews and Mark Smith for Mikael Abrahamsson, Tatuya Jinmei, Mark Andrews and Mark Smith for
their helpful comments. their helpful comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Message Protocol (ICMPv6) for the Internet Protocol Control Message Protocol (ICMPv6) for the Internet
Version 6 (IPv6) Specification", RFC 4443, March 2006. Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010. RFC 6106, DOI 10.17487/RFC6106, November 2010,
<http://www.rfc-editor.org/info/rfc6106>.
9.2. Informative References 9.2. Informative References
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration Protocol
IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736,
April 2004, <http://www.rfc-editor.org/info/rfc3736>.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios, Considerations, and Network Renumbering Scenarios, Considerations, and
Methods", RFC 6879, February 2013. Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013,
<http://www.rfc-editor.org/info/rfc6879>.
Appendix A. Test Results Appendix A. Test Results
The authors from two orgnizations tested different scenarios The authors from two orgnizations tested different scenarios
independent of each other. The following text decribes the two test independent of each other. The following text decribes the two test
sets respectively. sets respectively.
A.1. Test Set 1 A.1. Test Set 1
A.1.1. Test Environment A.1.1. Test Environment
skipping to change at page 15, line 4 skipping to change at page 15, line 48
Router and a DHCPv6 Server Router and a DHCPv6 Server
In these scenarios there is two one router and, unless otherwise In these scenarios there is two one router and, unless otherwise
specified, one DHCPv6 server on the same link. The behaviour of the specified, one DHCPv6 server on the same link. The behaviour of the
router and of the DHCPv6 server remain unchanged during the tests. router and of the DHCPv6 server remain unchanged during the tests.
Case 1: One Router with the Management Flag not Set and a DHCPv6 Case 1: One Router with the Management Flag not Set and a DHCPv6
Server Server
o Set up o Set up
* One IPv6 Router with M=0, A=1, O=0 and an RDNSS is advertised
* 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 * A DHCPv6 server on the same link advertising IPv6 addresses and
RDNSS RDNSS
o Results o Results
* Fedora 21, MAC OS-X, CentOS 7 and Ubuntu 14.04 get an IPv6 * Fedora 21, MAC OS-X, CentOS 7 and Ubuntu 14.04 get an IPv6
address and an RDNSS from the IPv6 router only. address and an RDNSS from the IPv6 router only.
* Windows 7 get an IPv6 address from the router only, but they do * Windows 7 get an IPv6 address from the router only, but they do
not get any DNS information, neither from the router nor from not get any DNS information, neither from the router nor from
 End of changes. 68 change blocks. 
237 lines changed or deleted 278 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/