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

Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies)

> Putting that aside, a SEND node could well *defend* the address
> fe80::A for DAD/DIID purposes, but it would never actually use it.

I think that's the issue. Should a SEND or 3041 node be required to defend
LL addresses that use suffixes configured for their global unicast addresses
even though they will never use the LL addresses?

Since it's a backward compatibility issue, I think it would depend on how
widely implemented DIID is. If it's not widely implemented, then there's no
point in doing it. My personal feeling is that it is an extra bit of
signaling that is unnecessary unless there is a widely deployed IPv6 capable
OS out there that does DIID.

In any event, the SEND spec doesn't need to change, because this behavior
would have to be specified in RFC 2462bis since it would apply to 3041 nodes
too or for that matter any node that used a different algorithm for
configuring its suffix.


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