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

From: "James Kempf" <[email-masked]>
Date: Sun, 29 Feb 2004 22:12:50 -0800

> My assumption is that SEND WG will adapt to the changes that RFC2462bis
> will make.  So if we tweak 2462 to require configuration of a link-local
> address per suffix, SEND-CGA nodes will do this.  This will then prevent
> (well, detect) collision as discussed above.
>

SEND doesn't use a common suffix, so I am not sure how this applies to them.
Basically, SEND will DAD all addresses. Could you clarify?

> Why not just specify this in SEND then?  Well, because it's a DAD
> issue which applies to other protocols which would like to configure
> one or more arbitrary suffixes, eg: privacy addressing.
>

SEND doesn't make changes in the basic DAD algorithm, so it will conform to
whatever 2462bis specifies.

Since the SEND spec is about to be sent to the IESG, the SEND WG needs to
know if any changes are needed in the SEND spec right now. So far, I don't
see any.

            jak

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Mar 2004 00:12:11 -0800

> 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.

            jak

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 01 Mar 2004 18:28:25 +0900

>>>>> On Mon, 1 Mar 2004 00:12:11 -0800, 
>>>>> "James Kempf" <[email-masked]> said:

> too or for that matter any node that used a different algorithm for

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-masked]
--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 1 Mar 2004 19:06:53 +0900

>   complicated, degrading one of the motivations of this clarification.

 From the SEND point of view, looks good.

--Pekka Nikander

---

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Mar 2004 02:47:13 -0800

I agree.

            jak

----- Original Message ----- 
From: <JINMEI Tatuya / $B?@L@C#:H (B <[email-masked]>)>
To: "James Kempf" <[email-masked]>
Cc: "Pekka Nikander" <[email-masked]>; "Nick 'Sharkey' Moore"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, March 01, 2004 1:28 AM
Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275]
DAD text inconsistencies)