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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 1 Mar 2004 16:56:17 +0900

Nick,

> (well, detect) collision as discussed above.

Well, strictly speaking, a (pure) SEND node cannot configure a 
link-local
address with such a suffix, since the resulting address will not be a
SEND address.  The CGA test will fail.

Let me clarify:

  1. Say that a (pure, strict) SEND node configures a new
     global address P::A, where A is computed by the CGA
     algorithm:  A = cga(public key, prefix P, other info)

  2. If a SEND node now would like to configure a link local
     address fe80::A, it (strictly speaking) cannot do that,
     since for fe80 it MUST use a different suffix, L,
     where L = cga(public key, prefix fe80, other info).

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

--Pekka Nikander

---

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

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

---

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)

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Mon, 1 Mar 2004 22:13:26 +1100

> I don't see the need for any change on this in rfc2462bis.

Okay, no worries, I'm happy too:
I had assumed the DIID behaviour
was widespread. 

>[...]  In this particular case, "A" is a

I had not thought of this! So
it is not a problem at all.

In that case I'm entirely happy
to go with just raising SHOULD
to MUST and deleting the text
explaining DIID.

Sorry to have wasted your time ...

-----Nick

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 02 Mar 2004 00:25:34 +0900

>>>>> On Mon, 1 Mar 2004 22:13:26 +1100, 
>>>>> "Nick 'Sharkey' Moore" <[email-masked]> said:

> to MUST and deleting the text

Okay, I'm happy to reach the consensus, too.

> Sorry to have wasted your time ...

No need for an apology, you identified an issue that no one has ever
imagined, and I think the discussion so far was really productive.
Thanks for taking your time.

					JINMEI, Tatuya

---

From: Mika Liljeberg <[email-masked]>
Date: Mon, 01 Mar 2004 22:34:47 +0200

> Okay, I'm happy to reach the consensus, too.

Futile though it may be, I would like to register disagreement.

If the intention truly was to simplify the specification, we would be
going to pure DIID. As it is, removing mention of DIID seems like a
gratuitous change at best. As an author of one of those DIID
implementations, I find this somewhat unfortunate.

Also, there is the problem of DAD storms occurring whenever a new prefix
appears on a link. Will the revision be introducing a random delay
before a node begins the DAD procedure for each new address, or will
that make the specification too complex?

	MikaL

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 02 Mar 2004 15:25:17 +0900

>>>>> On Mon, 01 Mar 2004 22:34:47 +0200, 
>>>>> Mika Liljeberg <[email-masked]> said:

> Futile though it may be, I would like to register disagreement.

I think it is not necessarily futile, though in my understanding (I
must admit it may be biased) many people have agreed on the proposed
change.

> implementations, I find this somewhat unfortunate.

Please check the proposed change posted to this list the other day
(attached below).  This is basically "removing mention of DIID" on
which you seem to be able to agree.  Actually, we'd need to change
"DAD MUST take place on all unicast addresses" to "DAD SHOULD take
place on all unicast addresses" in a literal sense of what you said,
but I'm personally fine with the change as already stated.

> that make the specification too complex?

Valid point.  I've already filed this as a separate issue, and I admit
this may affect the decision of this particular issue.  So far, I
personally believe we will not have to change the decision here
regardless of the conclusion of the other problem.  But I'm sure we'll
need further discission on the other one.

					JINMEI, Tatuya

Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies
From: JINMEI Tatuya / 神明達哉 <[email-masked]>
To: [email-masked]
Date: Thu, 26 Feb 2004 17:38:47 +0900
List-Id: IP Version 6 Working Group (ipv6) <ipv6.ietf.org>

>>>>> On Mon, 23 Feb 2004 22:21:49 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> Since we have a discussion about optimistic DAD, this is probably a
> good chance to start a related discussion for rfc2462bis.

(...snip...)

> Having considered these points, possible resolutions *for rfc2462bis*
> that I can think of are:

> 1. harden the requirement: Each individual unicast address MUST be
>    tested for uniqueness.  No MAY for omitting the rule (i.e., remove
>    it).  We can use SHOULD instead of MUST if we need compromise.

> I personally prefer option 1, because this makes the intention very
> clear, avoiding further similar discussions and waste of energy.
> "MUST" may be too strong for compatibility with existing
> implementations, and if so, we can use "SHOULD".  (And this does even
> not conflict with the proposed "optimistic DAD")

So far, I've not seen an objection to Option 1, and two people
(Francis and Jari) seem to agree on this approach.

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?

If yes, is the requirement of "DAD **MUST** take place" acceptable?  I
believe this is acceptable in essence, but I'd like to know this does
not cause a severe compatibility issue with existing implementations
that conform to RFC2462.

					JINMEI, Tatuya

---

From: Mika Liljeberg <[email-masked]>
Date: Tue, 02 Mar 2004 20:37:39 +0200

> must admit it may be biased) many people have agreed on the proposed

Admittedly I am also biased due to having a DIID implementation out
there.

> (attached below).

I did.

> This is basically "removing mention of DIID" on
> which you seem to be able to agree.

That's not what I said. Please let me clarify what I meant.

I find the change gratuitous, because it seems unnecessary. It does not
appear to achieve much besides removing a useful optimization (and one
short paragraph of text from the RFC). It's already been pointed out (by
you amongst others) that SEND addresses aren't likely to collide with
addresses autoconfigured by DIID nodes.

I find the change unfortunate, because it makes a class of deployed
implementations incompatible with the new specification. You have stated
that this is not the intention, but intentions are not written into the
RFC. Unfortunately, writers of conformance tests only read the RFC.

So, I'm opposed on the grounds that the change achieves little besides
inconveniencing people who have DIID implementations out there.

	MikaL

---

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: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Mon, 1 Mar 2004 16:51:13 +1100

On 2004-02-29, James Kempf wrote:
> 
> No, the SEND node performs DAD for fe80::C, where C is a function of the key
> and some other parameters. The [suffix] on LL addresses is also calculated
> from the key.

Hiya James, correct me if I'm wrong but the suffixes are both
calculated from the same key, but since the "other parameters"
are different, the suffixes will be different.

> Yes, that's the concern. If the DIID node comes on the link second, then it
> will assume that A is a unique prefix even though it only DADs it for the LL
> address.

Yep, that's what I'm talking about too.

-----Nick (who couldn't fit in the door at mip6!)

---

From: "James Kempf" <[email-masked]>
Date: Sun, 29 Feb 2004 21:00:20 -0800

----- Original Message ----- 
From: "James Kempf" <[email-masked]>
Cc: "Nick 'Sharkey' Moore" <[email-masked]>; "IPV6 WG" <[email-masked]>
Sent: Sunday, February 29, 2004 8:53 PM
Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275]

> > We have two nodes, a "SEND node" and a "DIID node".
> >
> > SEND node:
> >   - (for simplicity) do not implement the DIID-style optimization
> >   - have an (e.g.,) EUI-64 based interface identifier, I.
> >   - configure a SEND (CGA) address P:A (where A is the identifier, A !=
I)
> >
> > DIID node
> >   - implement the DIID-style optimization
> >   - (for simplicity) do not implement SEND
> >   - happen to have A as an interface identifier
> >
> > The SEND node comes to a link.  It perform DAD for both fe80::I and
> > P:A, and confirms that these are unique.
> >
>
> and some other parameters. The prefix on LL addresses is also calculated
> from the key.
>

Sorry, I meant suffix.

            jak

> > Then the DIID node comes to the same link.  It performs DAD for
> > fe80::A, and confirms it is unique.  So the DIID node start using
> > P:A without doing DAD while P:A is actually duplicate.
> >
>

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Fri, 27 Feb 2004 07:09:02 +1100

On 2004-02-26, Markku Savela wrote:
> 
> Yes, DIID probably (or something similar). I believe that simplest
> solution is that a specific ID value can be allowed only for single
> node on the link. Any use of same ID part with any prefix by another
> node should be viewed as an address collision.

I can see where you are coming from: for DAD to safely
interoperate with DIID it must send even more messages: wouldn't
it be nice to just send a single NS/NA pair?  After all,
DIID is already compatible with DIID.

I'm convinced that a change needs to be made to the wording to
resolve this issue, but I'm not sure which is the better option.
I'm also dubious about relying on votes at IETF meetings for
technical issues ... because often an option which seems 'obvious'
at the time actually isn't once the drafts have been considered
in detail.  And most of the WG attendees won't have considered
them in detail before the meeting.  Sad but true.

Questions for the group:

* DIID offers less signalling.   What advantages does DAD offer?

* Does DAD retain these advantages when made compatible with DIID?
	(by testing/defending LL::X, as per my earlier suggestion)

* Can backwards compatibility be dispensed with?
	(I'm going to be a hard sell on that one ...)

To be honest, unless there's some advantage to DAD which I
haven't thought of, I'm starting to lean back towards DIID ...
although since I'm keen on crypto and privacy addresses, I 
guess that's really Duplicate Suffix Detection (DSD), eh?

-----Nick