I agree.
jak
----- Original Message -----
From: <JINMEI Tatuya / [EMAIL PROTECTED]@C#:H (B <[EMAIL PROTECTED]>)>
To: "James Kempf" <[EMAIL PROTECTED]>
Cc: "Pekka Nikander" <[EMAIL PROTECTED]>; "Nick 'Sharkey' Moore"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, March 01, 2004 1:28 AM
Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275]
DAD text inconsistencies)
> >>>>> 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
--------------------------------------------------------------------
