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

[Ole Troan <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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" <[e-mail]> wrote:
> 
>> 
>>> On Aug 10, 2015, at 09:59, Don Sturek <[e-mail]> wrote:
>>> 
>>> 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.
>> 
>> 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.
>> 
>>> Don Sturek
>>> 
>>> 
>>> 
>>> On 8/10/15 7:44 AM, "ipv6 on behalf of David Farmer"
>>> <[e-mail] on behalf of [e-mail]> wrote:
>>> 
>>>> 
>>>> 
>>>>> On Aug 10, 2015, at 04:34, Pascal Thubert (pthubert)
>>>>> <[e-mail]> 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.
>>>> 
>>>> 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
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: ipv6 [mailto:[e-mail]] On Behalf Of Mark Smith
>>>>>> Sent: lundi 10 août 2015 09:05
>>>>>> To: Lorenzo Colitti <[e-mail]>
>>>>>> Cc: Tore Anderson <[e-mail]>; 6man WG <[e-mail]>
>>>>>> Subject: Re: SLAAC/DHCPv6 sharing prefix(es) legitimate?
>>>>>> 
>>>>>>> On 10 August 2015 at 17:00, Lorenzo Colitti <[e-mail]>
>>>>>>> wrote:
>>>>>>>> On Mon, Aug 10, 2015 at 2:45 PM, Tore Anderson <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> 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.
>>>>>> 
>>>>>> +static/manually configured addresses.
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> 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?
>>>>>> 
>>>>>> I would think so.
>>>>>> 
>>>>>> There does seem to be a RFC3315bis in development.
>> 
>> --
>> ===============================================
>> David Farmer                          Email: [e-mail]
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE         Phone: [phone]
>> Minneapolis, MN 55414-3029   Cell: [phone]
>> ===============================================
>> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------