Subject: RE: DAD vs. DIID

From: "Bound, Jim" <[email-masked]>
Date: Mon, 12 Aug 2002 22:34:39 -0400

Hi Margaret,

As long as if two networks merge the following is strictly prohibited:

two nodes now appear on the network with:

4ff3::2
4ff3::2

So if two networks heal or merge then DAD must be performed fixed per addr conf as you suggest.

That is not what got presented at Yokohama.

The other issue I have is an implementation one.  If we do this and I am not 100% convinced it is required or what problem we are solving and that would be nice to see.

The implementation is that if two nodes have competing implementations.  If one node checks the entire address and the other does not then we could end up with in practice in the field with what I want to be prohibited.

I also need to think on other architecture ramifications to current implementation like the way we account for duplicate prefixes combined with EUI.

thanks
/jim

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Friday, August 09, 2002 9:59 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: DAD vs. DIID
> 
> 
> 
> Hi Robert,
> 
> >Maybe I am missing something here, but, if the
> >Interface Identifier is not unique anymore on a
> >link, what is it then supposed to identify and
> >be used for ?
> 
> The suggestion doesn't change the purpose of an IID, just
> the scope of its uniqueness.
> 
> In the current (pre-change) addressing architecture, an IID
> is unique on the link.  So, within the scope of a given link,
> the IID can be used to identify a particular interface (and,
> by extension, a given node).  
> 
> This change would modify the scope of that uniqueness to be
> a subnet prefix, not the whole link.  So, within a set of
> interfaces using a particular subnet prefix, the IID would
> identify a particular interface.  Most links will have
> multiple subnet prefixes in use, because they will have a 
> link-local prefix and a global prefix.  Some links may have
> many subnet prefixes in use (link-local, one or more 
> site-local subnets and one or more global subnets).
> 
> Have you seen the slides that Steve Deering presented on
> this subject?  If they aren't already up on the IETF
> proceedings page, they should be shortly.  They give an 
> example of what this means.
> 
> Although the wording is fairly arcane in order to be 
> exactly correct, the real change comes down to this:
> 
>          OLD:    IIDs are required to be unique on a link.
>          
>          NEW:    Only complete addresses are required to 
>                  be unique on a link.
> 
> Relaxing the restriction to the second case makes the use of
> privacy addresses easier, it doesn't require any major changes
> to implementations (we are already doing Duplicate _Address_
> Detection, not Duplicate IID Detection), and it meets the
> requirements to uniquely identify a node for communication.
> 
> A side-effect of this change is that we will need to update
> the Address Autoconfiguration spec to require the use of DAD
> on all addresses, and not allow the currently documented
> optimization to only perform DAD on the link-local address.
> 
> I can only think of two cases where the same IID would get used
> for different hosts on the same link:
> 
>          - If some hosts on the link do not configure global 
>                  addresses, but others do.
> 
>          - If there are two (or more) subnets running over the
>                  same link, and not all of the hosts on the 
>                  link are members of both (or all) subnets.
> 
> >Also, how would then the Link Local address be formed ?
> 
> Not all IIDs are used to create link-local addresses.  An
> interface is required to have at least one link-local address,
> and the IID used to create that address must be different than
> the IIDs used to create link-local addresses on other interfaces
> on the same link (as required by the per-subnet uniqueness clause, 
> and as checked by DAD).  But it is not necessary, for example, to 
> create link-local addresses with the randomly generated IIDs used 
> to create privacy addresses. 
> 
> It is important for folks to understand what we are changing
> here, so please let me know if any of the above is confusing
> or unclear.
> 
> Margaret
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Tue, 13 Aug 2002 21:50:20 +0700

Date:        Mon, 12 Aug 2002 22:34:39 -0400
    From:        "Bound, Jim" <[email-masked]>
    Message-ID:  <[email-masked]>

  | As long as if two networks merge the following is strictly prohibited:
  | 
  | two nodes now appear on the network with:
  | 
  | 4ff3::2
  | 4ff3::2

Jim,

The idea is that DAD must be performed on any address before it
is configured.   So, that wouldn't possibly work.

Of course, if someone just plugs two cable together, nodes aren't
going to do doing (re-doing) DAD on their addresses (any of them,
in either scenario) - this has always been recognised as one of the
failure modes for DAD, but so unlikely, and so hard to fix, that
it isn't worth bothering with.

  | The implementation is that if two nodes have competing implementations.
  | If one node checks the entire address and the other does not then we
  | could end up with in practice in the field with what I want to be
  | prohibited.

Yes, that's true - if there are implementations replying on DIID, and
checking only LL's using DAD, then such an implementation might config
an address that was already in use by a node that doesn't config LL's
for every address it has configured.

But it seems that there aren't actually any such implementations, everyone
I have seen who has reported has said they do DAD on all addresses before
configuring them.   The fact that everyone did that was one of the
motivations for the change.

kre

---

From: Markku Savela <[email-masked]>
Date: Tue, 13 Aug 2002 18:26:45 +0300

> From: Robert Elz <[email-masked]>

> motivations for the change.

Here I have to raise a hand. I wrote implementation that actually
followed the allowed optimization: do DAD only on link-local, and then
freely combine that ID with announced prefixes WITHOUT doing a
separate DAD for EACH prefix*ID combination.

This is still fully allowed by current RFC's, and I still believe this
is GOOD, and should not be changed.

As a consequence, and observing that others may not have chosen this
tactics, the code also defends plain ID, that is: if it sees a DAD for
address which contains one of my ID's, it will reply to the DAD as if
I had the address. I don't see any catastrophic failures resulting
from it.

---

From: Vladimir Ksinant <[email-masked]>
Date: Tue, 13 Aug 2002 17:40:47 +0200

> separate DAD for EACH prefix*ID combination.

Our implementation also follows the optimization.

Vladimir

---

From: Robert Elz <[email-masked]>
Date: Wed, 14 Aug 2002 14:03:39 +0700

Date:        Tue, 13 Aug 2002 18:26:45 +0300
    From:        Markku Savela <[email-masked]>
    Message-ID:  <[email-masked]>

  | As a consequence, and observing that others may not have chosen this
  | tactics, the code also defends plain ID, that is: if it sees a DAD for
  | address which contains one of my ID's, it will reply to the DAD as if
  | I had the address. I don't see any catastrophic failures resulting
  | from it.

Yes, that way should work.

But can you test what happens if you configure an address on some other
node (using a different implementation), that happens to be one that yor
node will assign, without doing DAD on it explicitly, and then start
your node after that.

That's the case where there's a potential for trouble with mixed
implementations I believe.

kre

---

From: Markku Savela <[email-masked]>
Date: Wed, 14 Aug 2002 12:42:07 +0300

> node will assign, without doing DAD on it explicitly, and then start

I think the first discussion should be about the most common normal
case: autoconfiguring using the "globally unique" EUI64 ID (or if not
global, then at least ID which is supposed to be normally unique on
the link).

Ok, first definitions:

- Node A, has "globally unigue" id = AI, implements "link local"
  optimization (does DAD only on fe80::AI).

- Node B is the evil one :-). It has its own "globally unique" id = BI
  for it's link local

- Prefix "P1::/64" is advertised on the link by the router.

Events in order of occurrence:

1. Node B is manually configured with address "P1::AI"

2. Node B does DAD on "P1::AI" and assigns address, because node A is
   not yet connected.

3. Node A comes online on the link

4. Node A does DAD on "fe80::AI", and succeeds.

5. Router send RA with P1::/64

6. Node A uses P1::AI without doing DAD (and probably both A and B
   cannot communicate properly with this address).

Some observations:

- if before (6.), A did DAD on "P1::AI", it would fail and leave A
  without any global address to use. It's options would be

  a) accept the situation and be isolated
  b) generate temporary AIn and use "P1::AIn" (repeat until DAD
     succeeds) (can also redo fe80::AIn).

- it seems that this is a configuration error on the node B, that
  should be detected and fixed.

- situation does not occur in the normal autoconfiguration, where node
  needs to have a link local address first.

The whole issue comes from the introduction of "privacy" and generated
addresses. To me this is a special case, and it should solve it's own
problems, and not break the normal case. And one solution is that,
whatever address "Prefix::Id" you configure, you always do the DAD on
linklocal "fe80::Id" (you don't need to actually generate this
address, if you are not going to use it, just handle DAD as if you had
it).

---

From: Markku Savela <[email-masked]>
Date: Wed, 14 Aug 2002 13:14:05 +0300

> 5. Router send RA with P1::/64

Should be obvious to everyone, but just to be clear: that P1::/64 must
naturally have A=1. If A=0, node A will never try to configure
"P1::AI" and thus there is no collision.

---

From: Robert Elz <[email-masked]>
Date: Wed, 14 Aug 2002 17:28:18 +0700

Date:        Wed, 14 Aug 2002 12:42:07 +0300
    From:        Markku Savela <[email-masked]>
    Message-ID:  <[email-masked]>

  | - Node B is the evil one :-).

I don't think we need to characterize them, no deicide which is misconfigured.

All that matters, is that you have shown what I thought - if we have
some nodes doing DIID (optimising away some DAD checks, as has been
permitted), and others doing pure DAD, we can get into problems.

It is (now) also clear that we have some implementations that work
both ways.

That's not good.

So, we need to require one or the other to avoid the problem.

The Yokohama meeting room's opinion was that "just DAD on every
address before assigning it" was the way to go.

Sure, in your scenario, that means node A might be left with no global
addr it can use.   But that also might be what is intended to happen.
What's important is that the clash is recognised, and reported, so it
if something needs fixing, it can be fixed.

kre

---

From: Markku Savela <[email-masked]>
Date: Wed, 14 Aug 2002 14:24:44 +0300

> address before assigning it" was the way to go.

But, in my honest opinion, that decision is wrong. Doing DAD on every
address is in all respects more costly

- implementation requires more complex code
- it causes more packets on the link

It should be remembered that I do not disallow configuring

  node A: address P1::id1
  node B: address P2::id1

as long as "id1" is not configured as "autoconfigure id" to be
combined with prefixes that have A=1. So, I'm kind of wondering what
functionality is actually missing?

I would propose following rules instead of do DAD on every address:

- if id is used in autoconfigre (combine with prefix that has A=1),
  then doing DAD on "fe80::id" is sufficient

- if id is not used in autoconfigure, it's actually part of full
  configured address "prefix::id", then do DAD on "prefix::id".

- on receiving DAD on any X::id, there are couple of choices

  a) declare collision if "id" matches my id that is used in
     autoconfiguration

  b) declare collision if (a) AND "x::" is a prefix with A=1.

Hoever, it is obvious that (b) is very weak, as RA for X::/64 may come
later...

---

From: Robert Elz <[email-masked]>
Date: Thu, 15 Aug 2002 12:09:00 +0700

Date:        Wed, 14 Aug 2002 14:24:44 +0300
    From:        Markku Savela <[email-masked]>
    Message-ID:  <[email-masked]>

  | - implementation requires more complex code

I don't know how you reach that conclusion.   The DAD approach is
simple to understand and to code ... any time an address is to be
assigned, run the DAD algorithm (which is the same whether it is used
for a pure DAD approach, or a DIID one).   That's it.   No need to
go looking to see if it has run before, no need to invent LL addresses
to run DAD on, no need to do any special case handling of incoming
NS messages to see if they're DAD< and if so reply to ones that wouldn't
otherwise have been replied to,...

  | - it causes more packets on the link

This one is undisputed.  I'm not aware of measurements of how many more.

Do note though that typical DAD NS packets use wire bandwidth, but
nothing else (no-one receives them), so they're not very costly.
They're also not usually very frequent (configuring new addresses
doesn't happen all that often).

  | So, I'm kind of wondering what functionality is actually missing?

I don't think it is really a question of missing functionality, though
a hint of that was presented at the WG meeting.   It is more a case of
there currently being two different implementations of this in the field,
which don't work well together - one of those has to be picked as the
correct one.

  | I would propose following rules instead of do DAD on every address:

And this is simpler than "do DAD on every address" ?

kre

---

From: Francis Dupont <[email-masked]>
Date: Thu, 15 Aug 2002 21:58:38 +0200

In your previous mail you wrote:

=> so you have implemented DIID.

   This is still fully allowed by current RFC's,

=> you can't say this is *fully* allowed by current RFCs. In fact
IMHO this is both allowed and forbiden so RFCs are not sound...

   and I still believe this is GOOD, and should not be changed.
   
=> there are two points:
 - RFCs don't clearly specify DAD or DIID. I believe you agree
   there is a real problem to fix ASAP.
 - we have to choose between DAD and DIID: as almost everybody
   implemented DAD the rough consensus is DAD.

   I had the address.

=> this is a good idea but is not specified at all in RFCs: you've just
shown your DIID choice is not directly compatible with the common DAD
choice, so something (in RFCs, not in your implementation) has to be fixed!

   I don't see any catastrophic failures resulting from it.
   
=> only some hundreds of junk mails in the mobile ip mailing list...

Regards

[email-masked]

---

From: Markku Savela <[email-masked]>
Date: Fri, 16 Aug 2002 00:36:43 +0300

> simple to understand and to code ...

Yes, I guessed my claim would need some further
explanations. "Complexity" can be somewhat subjective thing...

> And this is simpler than "do DAD on every address" ?

Well, I tried be nice and thought to allow doing DAD on manually
configured addresses. But, I can also define even simple rule that
works (but, is "*really* strict ID for one node"):

  "regadless of address you configure, always do DAD on linklocal
  address using the ID-part of your address"

Although, a bit longer statement, the implementation is surely at
least as simple as the "do DAD on every address".

Why do I think "do DAD on every address" is more complex:
---------------------------------------------------------
You need to look under the hood to uncover the nasty bits...

(1) By far the most displeasing fact is that, it has the "delayed
failure mode": when the node comes online, it passes the DAD on link
local, but there there is no guarantee that it remains fully
functional later because

 - at any time later the link may require a use of a prefix (A=1) from
   RA, and when trying to make a global address with it, this can
   "legally fail". Node really cannot complain, it just need to have
   extra complexity of code to generate new id for that prefix. A node
   cannot decide on "autopilot" whether this is error or not.

 - compared to DIID, when node comes online (or an address is
   configured) and passes the DAD on link local, it guaranteed to be
   working with any announced prefix (A=1). Having to nodes trying for
   same link local is ALWAYS an error condition. Node does not need
   any additional logic for generating new ID's on RA's (although, it
   could, but it can also complain loudly on the error log about
   condition).

That is, with "DIID" you can plug in a node (or configure an address)
to a link and watch it autoconfigure in few seconds. If that passes,
you can expect it to stay functional, with whatever prefixes the link
will use now or later.

(2) A minor issue, if your link has 1000 nodes doing "do DAD", a nasty
node can generate nice traffic by fakin RA with multiple prefixes from
different address (as every node will be doing DAD on every prefix*id
combination). MINOR issue, because if bad guy gets this level access to
link, you are hosed anyway...

Anyway, with DIID, RA with any number of prefixes causes ZERO DAD
probes.

***************

Finally, the autoconfigure draft must be changed to allow only one
choice. If people think "do DAD" is it, it can be implemented. It is
just my opinion that DIID would be more simple.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 15 Aug 2002 16:07:27 -0700

Hello folks,

I have been trying to catch up by reading all the e-mails,
but that's very hard these days!

I think that DIID is simpler to understand and
administer, and is besides much more scalable in the
number of prefixes.  Furthermore, try as I have to
understand why anywone would prefer the DAD approach,
I come up emptyhanded except for the single argument
that existing implementations do DAD on every address.
And I have read a lot of e-mails.

Maybe everyone already agrees that DIID is more scalable.
If anyone disagrees, I'd be surprised, but please remind
me.  Then the question is, why do so many people not care
about scalability in this matter?

That is for me the real puzzler.  IPv6 provides so many
addresses and so many prefixes that it's hard for us
to understand.  Therefore, I am sure we do not understand
all possible uses for those many addresses and prefixes.
Taking brute force unscalable approaches now, and 
shooting down a whole galaxy of future possibilities,
is just not very sportsmanlike, much less wise or
conservative with resources.  This is my main concern.
When I have voiced this concern, I get the answer that
"We don't need that many subnet prefixes now". That is
a very bad answer.

There is one other abstract concern that I have, and
one other very concrete concern.  I believe that each
of them clearly indicates the need for specifying DIID
instead of DAD.

The other abstract reason that bothers me about this "DAD"
algorithm is that it assumes that not all nodes
need to carry a link-local address to match their IID.
I believe this is also a bad assumption.  The link-local
address has nice properties for protocol design, and
offers a way to do things like Neighbor Discovery in
the right way.  It's easy to understand, and thus easier
to get correct designs, and correct software and hardware.
My belief is that the "DAD" algorithm substantially impairs
the effectiveness of protocol design at this level.
Simply put, it means that global IP addresses may no
longer be known to satisfy properties that previously
could have been established by protocol using link-local
addresses.  In other words, algorithms which should have
been carried out with the previously useful link-local
addresses would then always have to be carried out
with global addresses, with the further complications
arising from protection against remote attack which
are enabled by globailty.

If DAD proponents also wish to specify that every IID
has to be associated with a link-local address, then
I am thoroughly mystified, but at least the above
problem goes away.
 
The concrete reason this proposal is unwelcome for me is
that it is very bad for Mobile IP.    When a home agent
receives a Binding Update, it has to ensure that the
mobile node's home addresses remains valid on the link
(the mobile node's home network).  If the mobile node
has not yet sent any Binding Update to the home agent,
or if the last Binding Update has expired, the mobile
node's addresses will remain undefended on the home network.
Then, when the Binding Update is received, the first thing
the home agent has to do is to ensure that the mobile
node's home addresses have not been taken by some other
node.

If this home agent has to do this for dozens or hundreds
of home addresses, it could be quite a burst of protocol.
If this happens for a lot of mobile nodes at once, then
the situation would just be that much (linearly) worse.
Whenever a horde of mobile nodes all suddenly emerge into
new radio coverage, this is quite likely to happen.

Put briefly, "DAD" is "BAD" for:
- scalability for subnet prefix utilization
- link-local protocol design
- Mobile IP
- network administrator sanity (I didn't mention this,
  but hopefully it's obvious).

As best I can tell, DIID is BAD for some existing
implementations, and no other reason.  In a way, this
is benign, for two reasons:
- Really using hundreds of subnets is not a concern
  with existing IPv6 deployments.  Thus, if some
  platforms don't get it perfect just now, no worries.
- By the time it really matters, the chances that existing
  platforms will have undergone _zero_ software upgrades
  is, approximately, _zero_.

I hope this note will have some effect towards moderating
the sentiments towards DAD that were in evidence in
Yokohama.

Regards,
Charlie P.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 21 Aug 2002 11:16:21 -0400

> I had the address. I don't see any catastrophic failures resulting

But I assume we are all in agreement that this is not supported by any
of the relevant specs. It is not necessarily forbidden by any spec,
but it is not suggested that this  be done in any spec. Yours is the
first implementation that I've heard that has done this.

Note: one thing we could all be better about is defining just what
"DAD vs. DIID" means.

Some people seem to think that that DIID means "for every address,
also create a link-local address and run DAD on it too." This in
general, will achieve DIID. But this is not required by the specs
today, and folks have consistently objected that requiring every
address also be assigned a corresponding LL address is being
unreasonable. There are also other ways of achieving DIID.

There is also Markku's variant.

One could also imagine modifying ND so that comparisons were done on
the IID part alone (in some or all cases). But this has the issue of
possibly not being backwards compatable with existing
implementations. 

Some also seem to be saying (???) that if one runs DAD on all
addresses, that's DIID. But I don't think so. That just means you are
doing DAD on all addresses. You can still end up with different nodes
using different addresses but sharing an IID (I'm not saying this is
necessarily good/desirable, but it is not ruled out).

So for those who are advocating some sort of DIID, please be very
clear about what it is you are calling for. Just saying "I'm for DIID"
isn't specific enough. 

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 21 Aug 2002 11:17:02 -0400

> addresses.

Actually, not so. The issue can also comes up with DHCP-assigned
addresses.

Thomas

---

From: Markku Savela <[email-masked]>
Date: Thu, 22 Aug 2002 00:46:24 +0300

> From: Thomas Narten <[email-masked]>
> 

I had my implementation before the term "DIID" was coined. I suppose,
in the effect, if I have the "id defense mode" turned on, it is very
close.

The main fact is that my version is just an implementation based on
the autoconfigure RFC, taking the allowed DAD optimization (= do DAD
on link-local, combine id with announced prefixes without doing DAD on
those combinations).

Some want to disallow the DAD optimization. I would like to present
another proposal:

  ********************************************
  leave autoconfigure basicly RFC as it is now
  ********************************************

Autoconfigururation deals only with an ID that is assigned to host and
is combined with announced prefixes (A=1). If host does this, it must
do DAD on link-local and doing DAD other addresses based on same ID is
not required.

I think autoconfiguration should be the normal mode how IPv6 nodes get
their addresses. Anything else is to be treated *exceptional*, and such
other mechanisms have to define their own ways of avoiding address
collisions. For example,

- if address is not link local, they could do DAD on corresponding
  link local, or

- they could assign the ID from a range that is not used by the
  autoconfigure (put asides id range 1-1024 or somesuch for the
  purpose).

- they guarantee that the prefix part of the address is never
  announced on the link with A=1 (this also guarantees that address
  never going to collide with autoconfigured addresses).

- just hope you are lucky

- etc.

I have explained in other messages, that the "Do DAD on every combined
address" has some unpleasant features, caused by the "delayed fail
mode". This adds complexity, compared to the "optimized DAD", where
you do it once, and if passed, you don't have to worry about it.

Choosing this does not require a change in any stacks that do DAD on
all addresses (KAME, Microsoft). It only affects abnormal address
configurations.

---

From: Robert Elz <[email-masked]>
Date: Thu, 22 Aug 2002 20:09:24 +0700

Date:        Thu, 22 Aug 2002 00:46:24 +0300
    From:        Markku Savela <[email-masked]>
    Message-ID:  <[email-masked]>

  | The main fact is that my version is just an implementation based on
  | the autoconfigure RFC, taking the allowed DAD optimization (= do DAD
  | on link-local, combine id with announced prefixes without doing DAD on
  | those combinations).

The problem is that this only works if no-one is allowed to create
addresses that don't have link local - otherwise the order in which
the addresses are created makes a race condition wrt DAD.

  | Some want to disallow the DAD optimization. I would like to present
  | another proposal:
  | 
  |   ********************************************
  |   leave autoconfigure basicly RFC as it is now
  |   ********************************************

That doesn't work.   Something has to solve the problem that has been
identified.

  | I think autoconfiguration should be the normal mode how IPv6 nodes get
  | their addresses.

Autoconfiguration has always been planned as just one way that addresses
can be allocated.   It may turn out to be the most common, but it certainly
shouldn't yet be being elevated to the status of being the "normal" way.

  | - just hope you are lucky

Well, I'm not sure if you were in Yokohama, but Steve Deering started
to make a proposal along those lines.   It was going to be essential if
the DIID proposal was adopted (I'll let Steve explain it, and why, if
he feels inclined) - it kind of just fell by the wayside, when DAD was
preferred by just about everyone in the room.

  | Choosing this does not require a change in any stacks that do DAD on
  | all addresses (KAME, Microsoft). It only affects abnormal address
  | configurations.

Obviously you can define "abnormal" so as anything affected fits, but
certainly KAME (and I suspect Microsoft) would need to change, as it
allows addresses that aren't based upon a LL address to be defined.

Such addresses are subject to DAD, so that's OK, they won't be duplicates,
but the IID part isn't defended against attempts to re-use it in other
addresses (different prefix).   They would need to change.

It is true that there's a tiny chance that when a new prefix
is advertised, a node will fail to be able to assign it, because some other
node had already assigned itself that prefix with the node's IID (the
chance of this in reality seem about as great as the chances of duplicate
3041 addresses, assuming good random number generators, but never mind).
DIID would avoid that tiny possibility.

On the other hand, DIID forbids subnets being merged into one link, if
they happen to have nodes assigned with the same IID (like "1").   There
is no problem with uniqueness of the addresses, the prefixes differ, but
because the IIDs don't, DIID would prohibit them from being used on the
same link.

I know which of those I believe is the more likely to actually happen in
practice, and which is the more serious if it does happen - and it isn't
the first in either case.

kre

---

From: Markku Savela <[email-masked]>
Date: Thu, 22 Aug 2002 16:45:22 +0300

> the addresses are created makes a race condition wrt DAD.

It can be made to work, if those who want to define addresses without
corresponding link local, take care of not tresspassing the addresses
generated by autoconfigure process. I listed some examples of
approaches.

"DIID" or equivalent is one possible apporach, but I'm not proposing
proposing that. I just want to keep the autoconfigure DAD optimization
as allowed. Other address configuration MUST take that into account.

> allows addresses that aren't based upon a LL address to be defined.

Yes, my stack allows defining any address manually. I don't code
programs that pretend to be more clever than the user. I assume if the
user wants some specific address, then he/she will get it (if it
passes DAD). In manual configuration I assume user KNOWS from that the
address will not collide with autoconfigured (as a root you can always
shoot your foot).

> addresses (different prefix).

I'm not proposing defending plain ID part (that is just an option that
is available).

> because the IIDs don't, DIID would prohibit them from being used on the

If you have two subnets with different prefixes. Apparently you then
have a router on both subnets which announce their prefixes. When you
merge the subnets, ALL nodes will see both routers and will
autoconfigure both prefixes with all of their addresses.

Yes, in this case if two nodes happen to have same id, doing DAD on
all addresses would detect the collision. But, you are hosed anyway,
as those same nodes are also using the same link local address (they
have same id, they are on same link => both have fe80::id, and
Neighbor discovery breaks totally for them...).
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Markku Savela <[email-masked]>
Date: Thu, 22 Aug 2002 16:49:37 +0300

a clarification...

> Neighbor discovery breaks totally for them...).

Naturally, if the id=1 is not used in autoconfiguration, then there is
no problem, since neither host combines the announced prefixes with
this particular id.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Fri, 23 Aug 2002 15:15:23 +0700

Date:        Thu, 22 Aug 2002 16:45:22 +0300
    From:        Markku Savela <[email-masked]>
    Message-ID:  <[email-masked]>

  | It can be made to work, if those who want to define addresses without
  | corresponding link local, take care of not tresspassing the addresses
  | generated by autoconfigure process.

Yes, it can be made to work.   But as things are now, it doesn't just
work, and no finessing of the definitions will make it so.   Some
implementations have to change.   The question is which.

  | "DIID" or equivalent is one possible apporach, but I'm not proposing
  | proposing that. I just want to keep the autoconfigure DAD optimization
  | as allowed. Other address configuration MUST take that into account.

But they haven't, because no-one really understood what that meant
before.   The docs don't make it explicit, and if you don't understand
the problem (which I think no-one did initially), you're not going to
go and do the extra work to implement it.

So, we clearly need to amend the docs.   Now we understand more about
what that optimisation really means is required, it is understandable
that people are questioning its benefits, isn't it?

And the general opinion seems to be that the optimisation is just too
costly, and the benefits it produces not great enough, that it just
isn't worth the bother, and the easiest simplest, and cleanest solution
is simply to recognise that we made a mistake, we attempted to optimise
before we had things correct, and that was wrong - delete the optimisation
and get things correct.

And DIIDD isn't just one possible approach, for the optimisation to work,
DIIDD, or something with the same effect, is required.

That is, if I am allowed to configure addresses without DAD, and I want
some assurance that they won't be duplicates, I have to be certain that
the IID isn't in use by any other node, for any purpose at all.  To get
that I need DIIDD.   How it is implemented wouldn't be crucial, but the
functionality must be there.

  | In manual configuration I assume user KNOWS from that the
  | address will not collide with autoconfigured (as a root you can always
  | shoot your foot).

This is a particularly bad assumption - though I believe you mean that
the user will suffer the consequences by not getting the address assigned
if a mistake is made.   But you really shouldn't be writing off manually
configured addresses as a weird special case, I kind of suspect that
most servers will get that kind of address, as having addresses that
just randomly change whenever the hardware is upgraded isn't a solution
that works.

  | I'm not proposing defending plain ID part (that is just an option that
  | is available).

It is the only option (other than "just ignore the problem") that
actually works.

  | If you have two subnets with different prefixes. Apparently you then
  | have a router on both subnets which announce their prefixes. When you
  | merge the subnets, ALL nodes will see both routers and will
  | autoconfigure both prefixes with all of their addresses.

Again, you keep assuming that autoconf is being used.   It *isn't*.
Other nodes on the link are doing autoconf, the ones I'm concerned
about aren't.

  | Yes, in this case if two nodes happen to have same id, doing DAD on
  | all addresses would detect the collision. But, you are hosed anyway,
  | as those same nodes are also using the same link local address (they
  | have same id, they are on same link => both have fe80::id, and
  | Neighbor discovery breaks totally for them...).

[email-masked] said:
  | a clarification...

  | Naturally, if the id=1 is not used in autoconfiguration, then there is no
  | problem, since neither host combines the announced prefixes with this
  | particular id. 

But let's assume the id isn't one, but is 206:5bff:feda:45ad (that happens
to be the low 64 bits of an IPv6 address for my laptop).   When I'm home,
I can use that address, or I can plug in a wireless card (I have one of
those 100 wired/802.11 wireless hubs, that merges them all together).
When I'm using wireless, the natural IID would be different - but if
I allow that, when I switch from wireless to wired (or perhaps more likely,
when I unplug the wire, and go wireless) all my connections will break.

So, what I want to do, is just move the IID from the wired interface to
the wireless one.    Note how much it looks like a normal auto-configured
address?

All this probably works OK if I start from the wired IID (which the one
above is), but if I happened to start from the wireless one, and then
switch to wired, and since I am wired, I pop the wireless card, and
plug that into another system ...   now that other system can't get
my global address, it can and should fail, but it can still get its
LL address (I won't be using the magic IID for LL addresses, my wired
card will have its own auto-configured LL, my wireless will have its
own, I don't run connections from LL addresses, so I don't care how
frequently those things alter).

On the new laptop, the one that now has the wireless card, I can easily
configure a new global address, either using a different IID, or using
a different prefix (in fact, if I have multiple prefixes, it is quite
possible that it managed to autoconfig its address in some of them,
as I might have only needed to retain one for my purposes - and even
if I didn't, I could just add an extra prefix to the net so there
would certainly be a global prefix that I'm not using (since I switched
to using configured addresses, I will have disabled autoconf).

All in all requiring IIDs to be unique on a link (any of the IIDs)
imposes too many restrictions on operation of the net.  Its benefit
is tiny (the packet benefit isn't worth counting, the possibility of
suddenly not being able to get a new address is too miniscule to
worry about).

Always do DAD, no optimisation allowed, is the best approach.

kre

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Aug 2002 17:21:48 +0200

=> I fully agree and I'd like to see according specifications updated ASAP.

Regards