>>>>> On Mon, 1 Mar 2004 00:12:11 -0800,
>>>>> "James Kempf" <[EMAIL PROTECTED]> said:
>> 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.
I agree on all the points. And my conclusion still does not change:
I don't see the need for any change on this in rfc2462bis.
I don't know the deployment status of the DIID implementation, and we
should be careful not to underestimate it. However, I think we should
also consider the reality of the problematic case from an operational
point of view.
Recall the scenario I described again. The problem occurs when the
DIID node *happens to* configure fe80::A and P::A. But can this
really occur in a practical sense? In this particular case, "A" is a
CGA identifier, so it cannot equal to a normal EUI-64 identifier.
Also, "A" would look like a non-readable, random 64-bit number, so it
should be very unlikely (in a practical sense) for the DIID node's
administrator to use it as a manually assigned interface identifier.
A similar argument should apply to the case of RFC3041.
Meanwhile, if we agree on the proposed change in rfc2462bis (MUST do
always DAD for each unicast address), new implementations will simply
follow the requirement. Also, existing DIID implementations will
gradually migrate to rfc2462bis. So, the actual odds to have the
problem will get smaller and smaller (starting with very small odds).
It should also be noted that one of the key motivations of the
proposed change in rfc2462bis is to simplify the specification and
implementation. If we introduce an additional defence algorithm to
avoid the "compatibility" issue, the resulting specification will
relatively complicated, degrading the effort to simply it.
To summarize the points, I'd propose to do nothing on this in
rfc2462bis because:
- the actual odds of the problem in the real world should be very low,
even in the current status.
- if we take the proposed change in rfc2462bis, the odds will be
getting lower and lower.
- if we add something for this to rfc2462bis, the protocol will become
complicated, degrading one of the motivations of this clarification.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
