Re: [dhcwg] draft-forte-dhc-passive-dad-01

Hi Andrea,

Andrea G Forte wrote:
> Greg,
> 
> please read answers inline.
> 
>> Sorry about the delay in replying.
> No problem at all. I was at the IETF meeting in Dallas.
 > Where you there as well? I would have liked to have your
 > feedback at the meeting after the presentation.

Sorry I couldn't come, my work is less focussed on IPv6
configuration at the moment.

>> Please be aware that the delays for link-local address
>> configuration will not be curtailed for this system,
>> as a link-local address is required to form a DHCP message.
>> For those addresses Optimistic DAD is still needed.
> We never intended pDAD to be a replacement for Optimistic DAD.
> pDAD is meant to address the DAD problem in IPv4 networks. We just 
> wanted to mention that perhaps it could be useful in IPv6 networks as 
> well (with all the limitations we discussed).

Certainly. Sorry I didn't provide feedback earlier about which
limitations are likely to be considered important.

> One thing I wanted to ask you about your last point is that apparently a 
> link-local address would be created mainly according to the client 
> unique ID. Another alternative would be to use something else like a 
> token of some sort. My impression though, would be that the former 
> scenario is more realistic since you want something as unique as possible.

Well, the assumption of uniqueness is not made in IPv6.  DAD is still
performed on all unicast addresses (It may seem like a waste, but it's
a MUST in Section 5.4 of RFC2462 and draft-ietf-ipv6-rfc2462bis-08,
and a MUST be supported in 4.2 and 4.5.2 of
draft-ietf-ipv6-node-requirements-11)...

Please also note that not all IPv6 link-local addresses are generated
from MAC addresses (and not even those are totally unique).

The problem with tokens is that you only want to modify 'clever' nodes
which understand your optimization without requiring changes from
'not so clever' nodes which share the same link.

Probably the best you can do is to restrict 'not so clever' nodes
using existing IPv6 operations (like preventing auto configuration
M=1, A=0).  This doesn't change their autoconfiguration and DAD
operations on the link-local addresses today, since the Autonomous
configuration (A) flags and procedures are prefix-associated.

As such a 'clever' host or system will still interact with hosts
that are performing DAD for autonomously configured link-local.
Today that's achieveable using Opti-DAD for the LL address (there
are other ways though...).

Greg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg