Subject: SLAAC/DHCPv6 sharing prefix(es) legitimate?

From: Mark Smith <[email-masked]>
Date: Mon, 10 Aug 2015 13:06:30 +1000

Hi,

So I was having a read of Fred and Brian's "Host routing in a
multi-prefix network" ID, and came across this bit of text:

"A host receives on-link prefixes in a Router Advertisement [RFC4861],
   which goes on to identify preference order among them and whether
   they are usable by SLAAC [RFC4862] [RFC4941] [RFC7217], or whether
   they must be assigned using DHCPv6 [RFC3315]."

which I read as meaning that prefixes in RA PIOs are exclusively used
for either SLAAC or DHCPv6 address assignment, and is what I would
expect. If DHCPv6 is enabled in addition to SLAAC, its possible
prefixes would be the ones that don't have the A bit switched on in
the PIO(s).

This text caught my attention though because my OpenWRT 14.07 router
is enabling the M bit in RAs, as well as setting the A bit in the PIOs
for both my ULA and Global Prefix. This results in my hosts that
support both SLAAC and DHCPv6 (Fedora 22) getting :

- (One or more) ULA and Global addresses via SLAAC, from both the ULA
and Global Prefixes
- Only a global address via DHCPv6

while other hosts that only support SLAAC get addresses via SLAAC.

I thought I may have enabled stateful DHCPv6 myself at some point in
the past, however I loaded up the latest RC candidate for the next
version of OpenWRT and it is enabling SLAAC and DHCPv6 for address
assignment by default.

So what OpenWRT is doing is different to what is described in the ID.
Is it legitimate for a router/DHCPv6 server to be providing addresses
from within the same prefix(es) via both SLAAC and DHCPv6? Broadly I
think it is, as DAD would identify when e.g., the DHCPv6 server gave
out an address that was already in use by another SLAAC only host
(although RFC3315 says DAD is a SHOULD not a MUST for IA addresses).

So if this is a legitimate DHCPv6+SLAAC configuration, then I think
that means that more broadly, prefixes cannot be considered SLAAC only
or DHCPv6 only for address assignment.

Regards,
Mark.

---

From: Tore Anderson <[email-masked]>
Date: Mon, 10 Aug 2015 07:45:36 +0200

* Mark Smith <[email-masked]>

> or DHCPv6 only for address assignment.

There's no such thing as a "DHCPv6 prefix"; DHCPv6 can only assign
individual addresses. See RFC5942 section 5. (Disregarding IA_PD here.)

In any case, RFC4862 makes it clear your configuration is legitimate:

Section 1:

   Both stateless address autoconfiguration and DHCPv6 may be used
   simultaneously.

Section 4:

   It should be noted that a host may use both stateless address
   autoconfiguration and DHCPv6 simultaneously.  

Section 5.6:

   It is possible for hosts to obtain address information using both
   stateless autoconfiguration and DHCPv6 since both may be enabled at
   the same time. [...] Hosts accept the union of all information
   received via Neighbor Discovery and DHCPv6.

(There's probably more. I stopped looking.)

Tore

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Aug 2015 18:42:54 +1200

In any case, the point in draft-baker-6man-multi-homed-host
is that there need to be RAs regardless of how the addresses
are allocated. Clearly we need to tweak the text to clarify
that both SLAAC and DHCPv6 might be active simultaneously

Regards
   Brian

On 10/08/2015 17:45, Tore Anderson wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Aug 2015 16:51:33 +1000

Hi Tore,

> individual addresses. See RFC5942 section 5. (Disregarding IA_PD here.)

I think conceptually there is such thing as a "DHCPv6 prefix", meaning
address space assigned to the link (likely a /64) from within which
the DHCPv6 server will assign addresses.

For example, with OpenWRT, although my LAN has both GUA and ULA /64s,
the "DHCPv6 prefix" is the GUA, because my hosts that support DHCPv6
are not being given ULA addresses.

> (There's probably more. I stopped looking.)

So the first statement is a general one, however the second two are
from the perspective of hosts support of concurrent SLAAC and DHCPv6.
Hosts are just expected to accept or generate addresses from whatever
prefixes either the router advertises or the DHCPv6 server is
configured with.

My thoughts/questions were from the router/DHCPv6 server perspective.
Have there been any prohibitions or are there common expectations that
if SLAAC and DHCPv6 are operating concurrently, then the address
spaces for each of them won't overlap? Or more specifically, should
DHCPv6 not be handing out addresses from prefixes that are in RA PIOs
that have the A bit switched on? I think Fred and Brian's text, and my
own previous position, was that it was expected that the SLAAC and
stateful DHCPv6 link assigned address spaces would be different.

OpenWRT's operation might be valid, however I don't really understand
why both SLAAC + stateful DHCPv6 has been enabled by default, as I
don't see what benefit it is providing - it isn't showing the SLAAC
only devices. That can't be answered here, however it is an
observation that somebody might have seen some value in enabling SLAAC
and stateful DHCPv6 to operate within the same address space assigned
to the link.

"DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration"
(draft-ietf-v6ops-dhcpv6-slaac-problem) is related, however it too is
only discussing host side processing and interaction of SLAAC/DHCPv6
flags.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Aug 2015 16:00:20 +0900

>    received via Neighbor Discovery and DHCPv6.

If we want that to work, then hosts must perform DAD for all DHCPv6
addresses and DECLINE them if DAD fails. If so, then we need to update
RFC3315 from SHOULD do DAD to MUST do DAD. Yes?

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Aug 2015 17:04:49 +1000

>>    received via Neighbor Discovery and DHCPv6.

+static/manually configured addresses.

> RFC3315 from SHOULD do DAD to MUST do DAD. Yes?

I would think so.

There does seem to be a RFC3315bis in development.

---

From: Tore Anderson <[email-masked]>
Date: Mon, 10 Aug 2015 09:09:42 +0200

Hi again,

> the DHCPv6 server will assign addresses.

No, that would a conflation of two different concepts. A prefix
assigned and routed to the link is one thing. The pool from which the
DHCPv6 server assigns addresses is another.

While both can possibly be expressed as a prefix in the CIDR style,
they are two different. Consider for example:

Link prefix:                2001:db8::/64
DHCPv6 server's IA_NA pool: 2001:db8::d:0/112

> are not being given ULA addresses.

That's sounds like an implementation-specific limitation to me.

> spaces for each of them won't overlap?

Overlaps are actually legal, too. RFC4862 section 5.5.3(d):

 It could be possible that an address already in the list, configured
 either manually or by DHCPv6, happens to be identical to the newly
 created address, whereas such a case should be atypical.

FWIW, yhe DHCPv6 server in my Cisco EPC eRouter will "helpfully" assign
IA_NA addresses with Modified EUI-64 interface identifier to downstream
nodes on the LAN by default. (It's legit, but not a particularly good
idea IMHO.)

Tore

---

From: Tore Anderson <[email-masked]>
Date: Mon, 10 Aug 2015 09:24:11 +0200

* Lorenzo Colitti <[email-masked]>

> RFC3315 from SHOULD do DAD to MUST do DAD. Yes?

I'm guessing that in a DHCPv6-only network, the authoritative DHCPv6
server can (and should) assure the uniqueness of the addresses it
assigns to DHCPv6 clients. Coupled with appropriate layer-2 security
mechanisms to prevent any non-DHCPv6 addresses from being used, the use
of DAD seems superfluos to me.

But in general, yes, by default DHCPv6 clients really ought to be
performing DAD on its assigned addresses.

Tore

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Aug 2015 16:35:12 +0900

> of DAD seems superfluos to me.

That seems like a small subset of all networks that have both SLAAC and
DHCPv6 enabled. I bet lots and lots of residential CPEs support both SLAAC
and DHCPv6.

Also, what is a "DHCPv6-only network"? How does the host know if a network
is DHCPv6-only? If all the PIOs it has received have A=0? Does that mean
that DHCPv6 address leases can only be accepted once the host has obtained
a list of on-link prefixes from PIO received in RAs?

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Aug 2015 17:51:24 +1000

Hi Tore,

> DHCPv6 server's IA_NA pool: 2001:db8::d:0/112

Sure, however I think people would think, "I'm going to add this "/112
prefix" into the DHCPv6 pool."

> That's sounds like an implementation-specific limitation to me.

So I think this is a scenario where prefixes/prefix types matter in
DHCPv6 addressing, because they need to be used to create different
pools. My hosts should be receiving at least two addresses, a GUA and
ULA, from two separate pools. A single pool containing the full set of
GUA and ULA addresses isn't going to be providing either enough
addresses to hosts (one instead of two) or always equivalent addresses
(i.e., some hosts get GUAs, others get ULAs).

Multiple GUA /64s and multiple ULA /64s on the link for DHCPv6
addressing is also interesting. Should there be a pool for each
prefix, so a host gets as many addresses as there are prefixes on the
link (I think so, as that is equivalent to multiple SLAAC RA PIOs).
OTOH, if all addresses within the same prefix type are considered
equivalent, then there could be a single GUA pool and a single ULA
pool, respectively each holding all of the GUA and ULA addresses.

> nodes on the LAN by default. (It's legit, but not a particularly good

Actually, I was also looking a bit into the DHCPv6 server used by
OpenWRT as the addresses it hands out come from quite a small range,
rather than the whole /64 (it seems they reuse the IPv4 range). So the
protection from unsolicited probing I'm getting from the SLAAC
addresses disappears because of the DHCPv6 addresses.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Aug 2015 17:58:01 +1000

On 10 August 2015 at 17:35, Lorenzo Colitti <[email-masked]> wrote:
> DHCPv6 enabled.

That's why I noticed OpenWRT's default of enabling both, as it means
there are now instances "in the wild" where SLAAC + DHCPv6 have been
enabled without an active operator decision to do so.

> I bet lots and lots of residential CPEs support both SLAAC
> and DHCPv6.
>
> that DHCPv6 address leases can only be accepted once the host has obtained a
> list of on-link prefixes from PIO received in RAs?

I think that's the real question. How independent or not are SLAAC +
stateful DHCPv6 operations when they're both enabled on the same link?

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 09:59:47 +0200 (CEST)

On Mon, 10 Aug 2015, Lorenzo Colitti wrote:

> Also, what is a "DHCPv6-only network"? How does the host know if a 
> network is DHCPv6-only? If all the PIOs it has received have A=0? Does 
> that mean that DHCPv6 address leases can only be accepted once the host 
> has obtained a list of on-link prefixes from PIO received in RAs?

You don't need to have on-link (or off-link) prefixes in RA for DHCPv6 
IA_NA to work.

I've myself tested to announce no prefix at all in RAs and set M=1, the 
host will ask for IA_NA, receive an address, and the result is a ::/0 
route towards the router and the IA_NA /128 on the interface, and nothing 
else, and this is a perfectly valid configuration per the specs as far as 
I can tell.

For the router to know what's going on though, it either needs to have a 
static /128 pointed to the interface in question, or have a prefix there 
that corresponds to whatever IA_NA was handed out.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 10:02:09 +0200 (CEST)

> enabled without an active operator decision to do so.

Might be so. I ran this configuration for years before, I had /64 A=1, 
M=1, a DHCPv6 IA_NA pool within the same /64, and hosts used both SLAAC 
and DHCPv6 IA_NA at the same time (most hosts had at least 2 SLAAC (one 
privacy, one EUI64) and 1 IA_NA based address.

> stateful DHCPv6 operations when they're both enabled on the same link?

Independent in what way? There was work on documenting what happened when 
you transitioned between different settings of the flags, and different 
OSes behaved differently when the flags were toggled.

---

From: Tore Anderson <[email-masked]>
Date: Mon, 10 Aug 2015 10:04:18 +0200

> DHCPv6 enabled. I bet lots and lots of residential CPEs support both
> SLAAC and DHCPv6.

I agree that in a network where both SLAAC and DHCPv6 are enabled, DAD
MUST be performed for DHCPv6-assigned addresses.

However, the sentence in RFC3315 section 18.1.8 that says SHOULD do DAD
doesn't say anything about SLAAC being simultaneously enabled or not. 

> network is DHCPv6-only?

This would have to be known some other way. For example, if FooCorp
knows their enterprise network is only using DHCPv6 I think it would be
a legitimate for FooCorp to ignore the loose SHOULD-requirement and
install DHCPv6 client software on their workstations that do not
implement DAD.

Another possible case would be if the DHCPv6 client is running on a
PPP/PtP interface. (Aside, but related: While not permitted by RFC4862,
I think it would make sense for a 3GPP UE to forego DAD on its
SLAAC-acquired addresses for much the same reasons.)

But when talking about general-purpose DHCPv6 client implementations
that cannot make any such assumptions about the network(s) they're
connecting to I would consider that the RFC2119 conditions for ignoring
the SHOULD requirement in RFC3315 aren't being met, and therefore they
"MUST" indeed perform DAD.

Also note that RFC4862 section 5.4 says:

   Duplicate Address Detection MUST be performed on all unicast
   addresses prior to assigning them to an interface, regardless of
   whether they are obtained through stateless autoconfiguration,
   DHCPv6, or manual configuration, with the following exceptions:

So I suppose the two RFCs aren't in full agreement here...

Tore

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Aug 2015 17:06:21 +0900

> So I suppose the two RFCs aren't in full agreement here...

Sounds like a bug that needs to be fixed in RFC3315bis. Anyone already
involved in that discussion and would care to report it?

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Aug 2015 18:27:38 +1000

On 10 August 2015 at 18:02, Mikael Abrahamsson <[email-masked]> wrote:
>> That's why I noticed OpenWRT's default of enabling both, as it means there
>> are now instances "in the wild" where SLAAC + DHCPv6 have been enabled
>> without an active operator decision to do so.
>
>
> Might be so. I ran this configuration for years before, I had /64 A=1, M=1,
> a DHCPv6 IA_NA pool within the same /64, and hosts used both SLAAC and
> DHCPv6 IA_NA at the same time (most hosts had at least 2 SLAAC (one privacy,
> one EUI64) and 1 IA_NA based address.
>

It's simple when there is only a single prefix on the link (in
addition to link-local), when SLAAC and DHCPv6 are both
generating/assigning addresses from that single prefix.

OpenWRT is now automatically generating ULAs and announcing them, so
when you also get a GUA via DHCPv6-PD, how should DHCPv6 + SLAAC
operate when there are multiple non-link-local prefixes.

One perspective could be that DHCPv6 only hands out addresses that
don't fall into SLAAC covered prefixes. I think that would be
mentally/operationally simper - you'd be able to look at an address on
a host's interface and be able to think "that is a SLAAC assigned
address" or "that is a DHCPv6 assigned address", purely by looking at
the prefix it came from. That could be useful during a transition
period from SLAAC to DHCPv6 or vice versa. To ensure that though, the
DHCPv6 server would need to be aware of the RA PIOs prefixes and A bit
values. (e.g., with OpenWRT, SLAAC for ULAs, DHCPv6 for the DHCPv6-PD
GUA)

The other perspective would be that SLAAC and stateful DHCPv6 operate
completely independently of each other, and if there is address space
overlaps, it is assumed to be intentional, and DAD must be used to
sort out collisions. In the OpenWRT case, both SLAAC and DHCPv6 should
be use for/handing out addresses from both the ULA and GUA prefixes if
SLAAC and DHCPv6 are enabled.

Before today I though the first perspective was the more "correct
one", and it was up to the operator to check to ensure the SLAAC and
DHCPv6 address ranges/prefixes didn't overlap. I now think the latter
is more correct (noting that it doesn't prevent operating the first
perspective).

> you transitioned between different settings of the flags, and different OSes
> behaved differently when the flags were toggled.
>

That is about hosts' interpretation of RA flags and corresponding
SLAAC and DHCPv6 client behaviour. The independence or not of the
"server" side operation of SLAAC and DHCPv6 was my interest.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 10:51:06 +0200 (CEST)

> operate when there are multiple non-link-local prefixes.

I don't see how having multiple /64s is a problem.

> values. (e.g., with OpenWRT, SLAAC for ULAs, DHCPv6 for the DHCPv6-PD

The problem here is that from the router perspective you need a route for 
the DHCPv6 IA_NA prefix pointing to the interface where the address was 
handed out. So if the pool is a /112, then there needs to be a /112 
pointing to that interface. This doesn't need to be advertised in the RAs 
though, that's optional.

> overlaps, it is assumed to be intentional, and DAD must be used to sort 
> out collisions. In the OpenWRT case, both SLAAC and DHCPv6 should be use 
> for/handing out addresses from both the ULA and GUA prefixes if SLAAC 
> and DHCPv6 are enabled.

I would like to see DHCPv6 IA_NA addresses being done DAD for.

> is more correct (noting that it doesn't prevent operating the first

I agree, for me the second way (having everything with in the same /64) is 
more natural. If I wanted to lock down the address handling so much so I 
went with IA_NA and nothing else, I wouldn't want the stations talking to 
each other directly anyway (because the reason to do this would be to 
assure complete control and thus client isolation would be needed).

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Aug 2015 19:00:03 +1000

> On Mon, 10 Aug 2015, Mark Smith wrote:
<snip>
> handed out. So if the pool is a /112, then there needs to be a /112 pointing
> to that interface. This doesn't need to be advertised in the RAs though,
> that's optional.
>

So I don't like the idea of small DHCPv6 pools e.g., /112s, because
they reduce or inhibit privacy address mechanisms and don't provide
much or any protection against unsolicited address probing. I'd want
the pool to hold at least a /64s worth of addresses so that either
SLAAC or stateful DHCPv6 provide equivalent protection against these
attacks.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 11:30:16 +0200 (CEST)

On Mon, 10 Aug 2015, Mark Smith wrote:

> So I don't like the idea of small DHCPv6 pools e.g., /112s, because they 
> reduce or inhibit privacy address mechanisms and don't provide much or 
> any protection against unsolicited address probing. I'd want the pool to 
> hold at least a /64s worth of addresses so that either SLAAC or stateful 
> DHCPv6 provide equivalent protection against these attacks.

Well, then you need a separate /64 for the DHCPv6 IA_NA pool, bringing the 
number of /64s on the interface up to 3. (ULA + SLAAC-GUA + DHCPv6-GUA). 
This isn't really a problem, but just saying...

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Aug 2015 09:34:53 +0000

There are deployments in IOT that use DHCP only or reserve some space for DHCP so that DHCP addresses do not collision with anything else by network design. Such deployments can reach thousands of nodes over low power lossy mesh networks. 

In a case like this,  DAD is omitted voluntarily. It would be unwelcome from the IETF to change the rule in 3315 brutally without consideration for the impact in such cases.

I like Ralph's approach, that adds words around the SHOULD to discuss cases where it seems acceptable to ignore the general rule. So if there's a new 3315; my suggestion would be to keep the SHOULD, explain that DAD MAY be avoided for instance if the DHCP server owns some address range, so collisions with other assignment techniques such as manual, SLAAC and 6LoWPAN ND, are not possible. The text could add that large IOT meshes with such range isolation is a case where DAD is actually NOT RECOMMENDED. This would enable IoT people, for once, to feel good about what they have to implement, rather than adding another SHOULD to the long list that they ignore with their fingers crossed.  

Cheers,

Pascal

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Mark Smith
> Sent: lundi 10 août 2015 09:05
> To: Lorenzo Colitti <[email-masked]>
> Cc: Tore Anderson <[email-masked]>; 6man WG <[email-masked]>
> Subject: Re: SLAAC/DHCPv6 sharing prefix(es) legitimate?
>

---

From: "Turner, Randy" <[email-masked]>
Date: Mon, 10 Aug 2015 09:40:55 +0000

+1 to what Pascal says below. Tthere are very large deployments that could specifically map DUIDs to the IP address for assignment. In cases like this DAD is unnecessary

Randy

> On Aug 10, 2015, at 5:35 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
>

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Aug 2015 18:45:53 +0900

On Mon, Aug 10, 2015 at 6:34 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> There are deployments in IOT that use DHCP only or reserve some space for
> DHCP so that DHCP addresses do not collision with anything else by network
> design. Such deployments can reach thousands of nodes over low power lossy
> mesh networks.
>
> In a case like this,  DAD is omitted voluntarily. It would be unwelcome
> from the IETF to change the rule in 3315 brutally without consideration for
> the impact in such cases.
>

As Tore points out, such networks are already violating a MUST in RFC4862
section 5.4 anyway. So MUST in RFC3315bis is more correct than SHOULD.  It
should probably say "MUST unless the link layer guarantees uniqueness".

If certain IPv6 over foo documents say that they require the use of DHCPv6,
do not support anything else, and prefer to increase the chance of address
collisions in order to save power, then those documents can update RFC 4862.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Aug 2015 11:05:57 +0000

Hi Lorenzo

This is highly debatable since it appears that RFC4862 redefines the behavior of another protocol in that section and a spec should not be doing that (that should be an overarching RFC such as a 2460bis).
If one protocol needs rewriting to fix this issue, I suggest that it should be RFC4862.

Also, if the final word goes to the last who spoke, then RFC6775 has precedence, section 3.1. Note that this section does not redefine another protocol’s behavior, but is more specific about what to do with the SHOULD in RFC3315. Exactly what the developer needs.

Ultimately, good sense should prevail. IOT devices do the right thing for their cases. The bother is that this means ignoring 6MAN’s SHOULDs in multiple occasions, with no clear indication whether it’s really bad and what the consequences are.

Cheers,

Pascal

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: lundi 10 août 2015 11:46
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Mark Smith <[email-masked]>; Tore Anderson <[email-masked]>; 6man WG <[email-masked]>; Ralph Droms <[email-masked]>
Subject: Re: SLAAC/DHCPv6 sharing prefix(es) legitimate?

On Mon, Aug 10, 2015 at 6:34 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
There are deployments in IOT that use DHCP only or reserve some space for DHCP so that DHCP addresses do not collision with anything else by network design. Such deployments can reach thousands of nodes over low power lossy mesh networks.

As Tore points out, such networks are already violating a MUST in RFC4862 section 5.4 anyway. So MUST in RFC3315bis is more correct than SHOULD.  It should probably say "MUST unless the link layer guarantees uniqueness".

If certain IPv6 over foo documents say that they require the use of DHCPv6, do not support anything else, and prefer to increase the chance of address collisions in order to save power, then those documents can update RFC 4862.

---

From: David Farmer <[email-masked]>
Date: Mon, 10 Aug 2015 09:44:07 -0500

> On Aug 10, 2015, at 04:34, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 

Any omission of DAD, for what ever reason, makes an IPv6 network brittle. Are there situations where a network will function without DAD, sure.  But those situations are not robust, simple and fairly normal changes to such a network can easily cause duplicate addresses.  Use of IPv6 without DAD requires extreme caution and is intrinsically unstable and brittle. 
 
> I like Ralph's approach, that adds words around the SHOULD to discuss cases where it seems acceptable to ignore the general rule. So if there's a new 3315; my suggestion would be to keep the SHOULD…

Sorry, but no one should feel good about not implementing DAD, not implementing DAD maybe the lesser of two evils, and even necessary in some limited situations.  But not implementing DAD is like not using seat-belts in a car.  Most days you will get away with it just fine, but in the long run its a bad idea.

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: Don Sturek <[email-masked]>
Date: Mon, 10 Aug 2015 07:59:22 -0700

Hi David,

Could not disagree with you more.   For many mesh deployments using
technologies like IEEE 802.15.4/6LoWPAN, etc., NOT performing DAD is the
norm.  I would expect that most Automatic Metering, smart cities, etc
applications that deploy mesh routing will disallow DAD.

You are right that address allocation/management must be carefully
performed in such networks.  However, with strict use of SLAAC (for
smaller networks), DHCPv6 for larger networks and certification testing
you will find that DAD does nothing but occupy valuable bandwidth in these
"stub" networks.

Don Sturek

On 8/10/15 7:44 AM, "ipv6 on behalf of David Farmer"
<[email-masked] on behalf of [email-masked]> wrote:

>> There are deployments in IOT that use DHCP only or reserve some space
>>for DHCP so that DHCP addresses do not collision with anything else by
>>network design. Such deployments can reach thousands of nodes over low
>>power lossy mesh networks.
>> 
>>from the IETF to change the rule in 3315 brutally without consideration
>>for the impact in such cases.
>
>Any omission of DAD, for what ever reason, makes an IPv6 network brittle.
>Are there situations where a network will function without DAD, sure.
>But those situations are not robust, simple and fairly normal changes to
>such a network can easily cause duplicate addresses.  Use of IPv6 without
>DAD requires extreme caution and is intrinsically unstable and brittle.
> 
>> I like Ralph's approach, that adds words around the SHOULD to discuss
>>cases where it seems acceptable to ignore the general rule. So if
>>there's a new 3315; my suggestion would be to keep the SHOULD, explain
>>that DAD MAY be avoided for instance if the DHCP server owns some
>>address range, so collisions with other assignment techniques such as
>>manual, SLAAC and 6LoWPAN ND, are not possible. The text could add that
>>large IOT meshes with such range isolation is a case where DAD is
>>actually NOT RECOMMENDED. This would enable IoT people, for once, to
>>feel good about what they have to implement, rather than adding another
>>SHOULD to the long list that they ignore with their fingers crossed.
>
>Sorry, but no one should feel good about not implementing DAD, not
>implementing DAD maybe the lesser of two evils, and even necessary in
>some limited situations.  But not implementing DAD is like not using
>seat-belts in a car.  Most days you will get away with it just fine, but
>in the long run its a bad idea.
>
>> Cheers,
>> 
>> Pascal
>>

---

From: David Farmer <[email-masked]>
Date: Mon, 10 Aug 2015 10:43:31 -0500

> On Aug 10, 2015, at 09:59, Don Sturek <[email-masked]> wrote:
> 
> Hi David,
> 

You just made my point, if everything is done perfectly and nothing goes wrong, you are fine, we agree.  But that is called brittle. Robustness assumes things will go wrong and that people will make mistakes.

What happens when the DHCP sever is accidentally rebooted and the previous addressing state is not saved? And the DHCP server starts telling devices to use an address used by another device, because it forgot it told the other device to use that address?

Can you build a robust system with out DAD, probably, but just tuning off DAD with DHCP as currently specified is not robust.

Is there a cost for that robustness sure, and in some situations does the cost out ways it's benefit, maybe.  If you assume everything is done correctly, then DAD is unnecessary.

But here is the problem I have; I've got building systems engineers that think they can attach just attach their IEEE 802.15.4/6LoWPAN, etc... networks to my campus network willy-nilly, and it will work just fine.  Well it won't, because my campus networks, and most of the devices on them, assume that DAD is there to protect them. 

So, just like you believe I'm not accounting for the costs associated with DAD, I believe you are not accounting for the costs associated with having to operate IEEE 802.15.4/6LoWPAN, etc... networks differently from the thousands of other networks I have to operate.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 10 Aug 2015 17:52:05 +0200

> You just made my point, if everything is done perfectly and nothing
> goes wrong, you are fine, we agree.  But that is called brittle.
> Robustness assumes things will go wrong and that people will make
> mistakes.
> 
> What happens when the DHCP sever is accidentally rebooted and the
> previous addressing state is not saved? And the DHCP server starts
> telling devices to use an address used by another device, because
> it forgot it told the other device to use that address?

What about moving this to the operator?

Allocate a bit in RA and DHCPv6 that disables DAD. Hosts perform DAD unless
the bit is set.

---

From: Don Sturek <[email-masked]>
Date: Mon, 10 Aug 2015 08:58:40 -0700

Hi David,

I then think there is a place for new I-D to tame the bandwidth use of DAD
(something similar to what RFC 6775 did for RFC 4861).

Don

On 8/10/15 8:43 AM, "David Farmer" <[email-masked]> wrote:

>You just made my point, if everything is done perfectly and nothing goes
>wrong, you are fine, we agree.  But that is called brittle. Robustness
>assumes things will go wrong and that people will make mistakes.
>
>telling devices to use an address used by another device, because it
>forgot it told the other device to use that address?
>
>Can you build a robust system with out DAD, probably, but just tuning off
>DAD with DHCP as currently specified is not robust.
>
>Is there a cost for that robustness sure, and in some situations does the
>cost out ways it's benefit, maybe.  If you assume everything is done
>correctly, then DAD is unnecessary.
>
>But here is the problem I have; I've got building systems engineers that
>think they can attach just attach their IEEE 802.15.4/6LoWPAN, etc...
>networks to my campus network willy-nilly, and it will work just fine.
>Well it won't, because my campus networks, and most of the devices on
>them, assume that DAD is there to protect them.
>
>So, just like you believe I'm not accounting for the costs associated
>with DAD, I believe you are not accounting for the costs associated with
>having to operate IEEE 802.15.4/6LoWPAN, etc... networks differently from
>the thousands of other networks I have to operate.
>
>> Don Sturek
>> 
>> 
>>

---

From: Ole Troan <[email-masked]>
Date: Mon, 10 Aug 2015 18:03:36 +0200

Don,

if you think bandwidth usage (one single packet on connecting to the link by default) is too high, then please get that issue added to http://tools.ietf.org/html/draft-yourtchenko-6man-dad-issues

David F: which by the way makes a reasonable case for DAD being brittle. I’d certainly wouldn’t have bought my seat belts, if they were designed by the same people that designed DAD. ;-)

cheers,
Ole

> On 10 Aug 2015, at 17:58 , Don Sturek <[email-masked]> wrote:
> 
> Hi David,
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Aug 2015 16:04:22 +0000

I do not see that happening, David.

In most cases today 6LoWPAN networks are their own subnet. The 6LoWPAN network will not make your network any less robust than it is.

If you effectively place the 6LoWPAN devices in a same subnet as your current stuff, then you'll need a proxy function which will defend the devices on their behalf while they sleep. With DAD. And the proxy will also reject the registration of an address that already exists in the subnet. With DAD.

Hoping that DAD is fixed by then. Because if you rely on DAD's robustness to make your network work you may be in trouble already; the reason why DAD seems to work in most cases is that duplications effectively do not occur.
 
Cheers,

Pascal

> From: David Farmer [mailto:[email-masked]]
> Sent: lundi 10 août 2015 17:44
> To: Don Sturek <[email-masked]>
> Cc: Pascal Thubert (pthubert) <[email-masked]>; Tore Anderson
> <[email-masked]>; 6man WG <[email-masked]>; Ralph Droms
> <[email-masked]>
> > technologies like IEEE 802.15.4/6LoWPAN, etc., NOT performing DAD is
> > the norm.  I would expect that most Automatic Metering, smart cities,
> > etc applications that deploy mesh routing will disallow DAD.
> >
> > smaller networks), DHCPv6 for larger networks and certification
> > testing you will find that DAD does nothing but occupy valuable
> > bandwidth in these "stub" networks.
> 
> previous addressing state is not saved? And the DHCP server starts telling
> devices to use an address used by another device, because it forgot it told
> the other device to use that address?
> 
> networks to my campus network willy-nilly, and it will work just fine.  Well
> it won't, because my campus networks, and most of the devices on them,
> assume that DAD is there to protect them.
> 
> So, just like you believe I'm not accounting for the costs associated with
> DAD, I believe you are not accounting for the costs associated with having
> to operate IEEE 802.15.4/6LoWPAN, etc... networks differently from the
> thousands of other networks I have to operate.
> 
> > Don Sturek
> >
> >
> >
> >>> There are deployments in IOT that use DHCP only or reserve some
> >>> space for DHCP so that DHCP addresses do not collision with anything
> >>> else by network design. Such deployments can reach thousands of
> >>> nodes over low power lossy mesh networks.
> >>>
> >>> In a case like this,  DAD is omitted voluntarily. It would be
> >>> unwelcome from the IETF to change the rule in 3315 brutally without
> >>> consideration for the impact in such cases.
> >>
> >> But those situations are not robust, simple and fairly normal changes
> >> to such a network can easily cause duplicate addresses.  Use of IPv6
> >> without DAD requires extreme caution and is intrinsically unstable and
> brittle.
> >>
> >>> I like Ralph's approach, that adds words around the SHOULD to
> >>> discuss cases where it seems acceptable to ignore the general rule.
> >>> So if there's a new 3315; my suggestion would be to keep the SHOULD,
> >>> explain that DAD MAY be avoided for instance if the DHCP server owns
> >>> some address range, so collisions with other assignment techniques
> >>> such as manual, SLAAC and 6LoWPAN ND, are not possible. The text
> >>> could add that large IOT meshes with such range isolation is a case
> >>> where DAD is actually NOT RECOMMENDED. This would enable IoT
> people,
> >>> for once, to feel good about what they have to implement, rather
> >>> than adding another SHOULD to the long list that they ignore with their
> fingers crossed.
> >>
> >> seat-belts in a car.  Most days you will get away with it just fine,
> >> but in the long run its a bad idea.
> >>
> >>> Cheers,
> >>>
> >>> Pascal
> >>>
> >>>>>>  It is possible for hosts to obtain address information using
> >>>>>> both  stateless autoconfiguration and DHCPv6 since both may be
> >>>>>> enabled at  the same time. [...] Hosts accept the union of all
> >>>>>> information  received via Neighbor Discovery and DHCPv6.
> >>>>
> >>>>> If we want that to work, then hosts must perform DAD for all
> >>>>> DHCPv6 addresses and DECLINE them if DAD fails. If so, then we
> >>>>> need to update

---

From: Tore Anderson <[email-masked]>
Date: Mon, 10 Aug 2015 18:16:45 +0200

Hello,

* Lorenzo Colitti

> > space for DHCP so that DHCP addresses do not collision with
> > anything else by network design. Such deployments can reach
> > thousands of nodes over low power lossy mesh networks.
> >
> As Tore points out, such networks are already violating a MUST in
> RFC4862 section 5.4 anyway. So MUST in RFC3315bis is more correct than
> SHOULD.  It should probably say "MUST unless the link layer guarantees
> uniqueness".
> 
> If certain IPv6 over foo documents say that they require the use of
> DHCPv6, do not support anything else, and prefer to increase the
> chance of address collisions in order to save power, then those
> documents can update RFC 4862.

Actually, those IPv6 over foo documents have another way to disable DAD
without updating RFC4862. From RFC4862 section 5.1.:

   A node MUST allow the following autoconfiguration-related variable to
   be configured by system management for each multicast-capable
   interface:

   DupAddrDetectTransmits  The number of consecutive Neighbor
      Solicitation messages sent while performing Duplicate Address
      Detection on a tentative address.  A value of zero indicates that
      Duplicate Address Detection is not performed on tentative
      addresses.  A value of one indicates a single transmission with no
      follow-up retransmissions.

      Default: 1, but may be overridden by a link-type specific value in
      the document that covers issues related to the transmission of IP
      over a particular link type (e.g., [RFC2464]).

So the IPv6 over foo document can say simply state that for interfaces
of the foo type, DupAddrDetectTransmits shall be (or default to) 0.
Interfaces with DupAddrDetectTransmits=0 are explicitly listed as an
exception to the "MUST do DAD" requirement in section 5.4 of RFC4862,
and IMHO "the interface in question having DupAddrDetectTransmits=0"
would be a valid reason to ignore the SHOULD in RFC3315 (per RFC2119's
definition of SHOULD anyway).

In the light of this I think the "SHOULD" currently in RFC3315 is
appropriate, because if it was turned into a MUST in RFC3315bis,
RFC3315bis and RFC4862 would the way I see it end up contradicting each
other on whether or not to do DAD for DHCPv6-assigned addresses on
interfaces with DupAddrDetectTransmits=0.

Tore

---

From: 神明達哉 <[email-masked]>
Date: Mon, 10 Aug 2015 11:15:17 -0700

At Mon, 10 Aug 2015 11:05:57 +0000,

> If one protocol needs rewriting to fix this issue, I suggest that it should be RFC4862.

Do you mean the MUST in Section 5.4 of RFC4862:

and DHCPv6 (RFC3315) by "another protocol"?  If so, I'd say RFC4862 at
least does not "redefine" the behavior.  RFC2462 (published way before
RFC3315) already said essentially the same thing:

   Duplicate Address Detection MUST take
   place on all unicast addresses, regardless of whether they are
   obtained through stateful, stateless or manual configuration, with
   the exception of the following cases:

It used the term "stateful" simply because we didn't have a standard
DHCPv6 protocol at that point.  RFC4862 only clarified that "the
stateful" protocol is DHCPv6.  If anything, it's RFC3315 that
"redefines" the behavior defined in RFC2462.

--
JINMEI, Tatuya