[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rfc2462bis issue 275] DAD text inconsistencies

> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
> So, I'd now like to propose a concrete change.  The simplest way to
> implement the option would be to remove the second exception shown in
> Section 5.4 of RFC2462.  That is, the revised text would be:
> 5.4 Duplicate Address Detection
>    Duplicate Address Detection is performed on unicast addresses prior
>    to assigning them to an interface whose DupAddrDetectTransmits
>    variable is greater than zero. Duplicate Address Detection MUST take
>    place on all unicast addresses, regardless of whether they are
>    obtained through stateful, stateless or manual configuration. On the
>    other hand, Duplicate Address Detection MUST NOT be performed on
>    anycast addresses.
>    The procedure for detecting duplicate addresses uses Neighbor
>    Solicitation and Advertisement messages as described below...
> Can we live with this simple resolution?

You are ignoring the installed base. There are already out and
delivered, and in real use, implementations which do the DAD only for
the link local. And if the ID is used combined with global prefixes,
the it is assumed DAD on link local is sufficient.

This is valid as per currently valid RFC, and still consider this a
sensible implementation. Apparently, nobody else truly supports the
multiple IDs and prefixes, with full combination? In such case, doing
DAD on each new combination for each announced prefix on RA is

And even with single id and new prefix this is not good: on RA with a
new global prefix, every node on the link is going to do DAD based on
its ID and new prefix. And, as far as I know, there is no delay
requirement here, so everyone is doing it at same time.

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6