Subject: Re: optimistic dad comments

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 1 Jun 2004 16:16:03 +1000

On 2004-05-31, Pekka Savola wrote:
>
> Below are my comments on draft-ietf-ipv6-optimistic-dad-00.txt.

Thanks for your feedback Pekka, I've added some thoughts/responses 
below.  All comments welcome!

> 1) The draft specifies that instead of using a tentative address as the
> source address for RS, another address or the unspecified address should be
> used instead.  To me, using the unspecified address would seem shortsighted,
> so I'd like to disallow its use in this context. (This might cause a
> problem, though, because I don't think the nodes typically have an another
> address they can use...)

You're right ... it's used when a node has no alternative.  
Using the unspecified address is allowed by RFC2461 6.3.7
(and this is unchanged in -bis-01) so it's a fallback
behaviour for OptiDAD.  Perhaps I need to be more careful
to explain this?

> 2) I don't think the memo is clear enough how a Tentative address on
> an ON compares to the tentative address on a standard node?  I mean,
> if the communication can proceed immediately, this would imply that
> the address should be flagged as non-tentative, or as
> "permanent-optimistic"  (which would be seen as non-tentative outside
> of Neighbor Discovery).  The point is, how are these addresses to be
> handled at RFC3484 and other documents which reference tentative vs
> non-tentative?

That's a really good point, and one I hadn't considered at all :-(.

I'll have a think.  I guess the obvious solution is to 
s/Tentative Address/Optimistic Address/ throughout.  But this would
add an extra state to neighbour discovery, confusing the issue with
RFC3484 further.  Perhaps I could indicate that Optimistic addresses
can be regarded as equivalent to Deprecated, eg: their use should
be avoided if there is an alternative.

> 3) IMHO, section 3.3 on Address Generation is largely redundant or downright
> inappropriate.  It describes a few useful things, but also goes on to
> specify how to regenerate the addresses if a conflict is found.  This is
> IMHO very much out of scope for oDAD.  At the very least, it should be moved
> to an appendix, but I'd vote for removal completely.

Okay, I can see your point.  Thinking about it, the logical place is
perhaps in 2462-bis ... replacing the 5.4.5 behaviour with something
a little more ... mobile-oriented.  Should I leave it as an appendix
in the meantime?

> What might be useful is specifying with which kind of addresses oDAD should
> be assumed: e.g., those addresses with the universal bit on are a prime
> target.  Also those addresses which are randomly generated (RFC3041 or SEND)
> should be OK.  Manual addresses or DHCPv6 in particular should be disallowed.

Yeah, I've said "The Optimistic algorithm SHOULD NOT be used on 
manually configured addresses [...]" in the aforementioned 3.3.

Which is kind of how all that address configuration stuff got drawn
in to OptiDAD in the first place.

> [various comments about boilerplate &c ]

noted.  I will be certain to fix these for -01.

>        An address collision with a router may cause neighbours'
>         IsRouter flags for that address to be cleared, however the RA
>         sent in response will reset the IsRouter flag.
> 
> ==> s/however/even though/ ?

Hmmm.  Actually, I'm not happy with that clause at all, let
me have a think about it and get back to you all.

Thanks again for your feedback ... well, now there's a couple of
open issues I'll have to make an Issues List!

-----Nick
	more info: <http://www.ctie.monash.edu.au/ipv6/fastho/>

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

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 1 Jun 2004 11:45:07 -0700 (PDT)

> problem, though, because I don't think the nodes typically have an another

But RFC 2461 explicitly allows sending RS with an unspecified source.
Is there a bug in RFC 2461 in this area?

> should be OK.  Manual addresses or DHCPv6 in particular should be disallowed.

I can understand manual addresses having a higher collision probability
than universal-bit autoconfigured ones (due to human error).
But why do we think this is the case for DHCP assigned ones?
The DHCP server will check that the address isn't already in its
list of leases before handing it out, so a collision at DAD time would
be very low probability.

But is also isn't clear to me that the probability, even in the manual case,
is high enough to warrant pessimistic mode.
Clearly if there is 50% probability of collisions it would be bad to
be optimistic, since there is some added cost in detecting the duplicate
late and having transport connections initiated in the interim die out.
But if the probability of collisions is 10% let alone 1% (the latter might
be a guess at collision probability for manually configured addresses)
why do we think it would be bad to operate in optimistic mode?

  Erik

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 2 Jun 2004 13:35:48 +1000

[G'day Eric, thanks for your input ...]

On 2004-06-01, Erik Nordmark wrote:
> [Pekka Savola wrote:]

I don't think it's a bug ...

	"A router MAY choose to unicast the response directly to
	the soliciting host's address (if the solicitation's 
	source address is not the unspecified address), but the
	usual case is to multicast the response to the all-nodes
	group" [RFC2461 6.2.6]

... it's a feature, asking the router "please be sure to
broadcast the response back to me since I don't have an address
I'm sure of yet".

The only problem there is the rate-limiting imposed on the
multicast responses, but I think we can assume that access
routers for fast mobile networks will have MinRtrAdvInterval
and related 2461 variables tweaked appropriately and some of
the other rules bent ... and I think that's MipSHOp WG's problem,
not IPv6 WG's problem ...

(I'm probably going to disallow RSes from Optimistic addresses
entirely, so if we don't have any other addresses we'll _have_
to RS from unspecified.  The current draft tries to get around
this with some tricks, but they tickle weird features of 2461,
I think ... see the last sentence of 6.2.6)

...

> > What might be useful is specifying with which kind of addresses
> > oDAD should be assumed: [...] Manual addresses or DHCPv6 in
> > particular should be disallowed.
> 
> [...]
> But is also isn't clear to me that the probability, even in the
> manual case, is high enough to warrant pessimistic mode.

I (personally) tend to agree, but I (editorially) am trying to steer
a course between paranoia and recklessness :-)

>From Pekka's comments, section 3.3 should be removed, and as Pascal
Thubert pointed out in an earlier review, it's not always obvious
whether an address is 'really' manual when we're configuring it.
So this bit of the text definitely needs an overhaul.

> But if the probability of collisions is 10% let alone 1% (the
> latter might be a guess at collision probability for manually
> configured addresses) why do we think it would be bad to operate
> in optimistic mode?

Yeah, I wanted to come up with a limiting number for this, but
stumbled on the problem of estimating the costs in a sensible
way.  All offers of help gladly received!

-----Nick

---

From: Pekka Savola <[email-masked]>
Date: Wed, 2 Jun 2004 08:03:18 +0300 (EEST)

Replying to both in one go..

> broadcast the response back to me since I don't have an address

My concern with using the unspecified address comes from the
experience we had in MAGMA where we had to specify which source
address to use in the MLDv1 packets.  Further, some might want to 
perform some kind of filtering based on the link-local source address, 
and using the unspecified address makes this impossible.

That's why I'd prefer to encourage using other means (if possible) 
than sending RS's..

You already say:

   The ON will immediately send out a Neighbour Solicitation to
   determine if its new address is already in use, and a Neighbour
   Advertisement (with the Override flag cleared) for the address. This
   NA allows communication with neighbours to begin immediately.

I read this so that if you just sent an NS and an NA, you could 
immediately afterwards send the RS from the "optimistic" address?

Maybe this was not clear enough..

> a course between paranoia and recklessness :-)

Sure, but the main concerns about the need for DAD have come from the 
manually configured addresses, so with them, we might say for example 
that the optimistic mode SHOULD NOT be used, and if it is still 
enabled by default, there MUST be a way to disable it (or whatever).

So, if vendors or operators would believe optimistic behaviour for
everything is a good one, they could still go for it, but we might
want to stick to the original DAD plan for those addresses where the
collision probability is not (practically) zero.

I don't feel strongly about this either way, but I think this was an
important argument from those people who were resisting DAD
optimizations in the first place..

[Erik:]
> list of leases before handing it out, so a collision at DAD time would

I mentioned only because DHCP assigned addresses are probably 
indistinguishable (depends on where they sit) from the manual 
addresses, but depending on the deployment, I guess DHCP could be 
giving the EUI64 addresses as well.

Are you sure DHCP servers check that no duplicates are given?  
Another potential scenario might be that the DHCP server is
reconfigured (one node removed, another added with the same address),
but the removed node still keeps its address and the new node will be
on the same link..
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 2 Jun 2004 17:08:26 +1000

On 2004-06-02, Pekka Savola wrote:
> address to use in the MLDv1 packets [...]

This is another one of those situations where I'm not trying
to improve 2461/2 behaviour in any other way than making it faster!

> manually configured addresses [...] 

Yep, which is why it's currently a SHOULD NOT in the draft.

> but the removed node still keeps its address and the new node will be

These kind of hopefully rare cases will still be picked up by
OptiDAD and prevented from serious consequences ... if it wasn't
for the rare cases, it wouldn't be worth doing DAD at all!

cheers,

-----Nick

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 2 Jun 2004 16:19:42 -0700 (PDT)

> address to use in the MLDv1 packets.  

RFC 3590 does allow the unspecified source for MLD messages during DAD,
so the parallel for RS works quite fine.

> Further, some might want to 

What type of filtering do you have in mind?
What problem would such filtering solve?

> giving the EUI64 addresses as well.

Is this an implementation concern i.e. that the code which decides
whether to do optimistic DAD might not know whether the address was
assigned by the DHCP client or manually by an administrator?
That implementation concern is easy to handle; I even know an implementation
which sets IFF_DHCPRUNNING for the addresses that are managed by the
dhcp client.

> Are you sure DHCP servers check that no duplicates are given?  

Am I sure that the IEEE and the vendors don't hand out duplicate
blocks/adresses? No - life is full of different probabilities.

> but the removed node still keeps its address and the new node will be

But such a DHCP server doesn't work well with laptops which might be
temporarily disconnected while the DAD occurs. Thus a good DHCP server would
retain state about its leases in stable storage to minimize the risk of
crashes or reconfiguration resulting in handing out duplicate
addresses.

  Erik

---

From: Greg Daley <[email-masked]>
Date: Thu, 03 Jun 2004 09:19:57 +1000

G'day Sharkey,

> I think ... see the last sentence of 6.2.6)

Actually, I think that tweaking the advertisement intervals for
multicast router advertisements (solicited or unsolicited) are
problematic.  All-nodes multicast packets will consume bandwidth
on every LAN segment or cell within the IP subnet equally.

Allowing faster rates of unsolicited RAs as in MIPv6 wastes bandwidth
to no purpose when devices aren't moving into a new cell.

Allowing shorter intervals between multicast RAs puts an upper limit
on the scalability of IP access networks since more devices are likely
to be soliciting/configuring at any time. Such solicitations would
therefore reduce available bandwidth uniformly across constrained
LAN segments (or cells).

Unicast (and potentially Solicited-Nodes multicast) packets only
consume bandwidth on segments where a host would be interested in
receiving them.  This allows significantly greater scalability when
the configuring nodes are spread across many different LAN segments
or cells.

The issue which you describe is the setting of the IsRouter flag
to false on the reception of a Router Solicitation from a tentative
node.

Although this is a new issue caused by the presence of a node which
hasn't completed DAD. This flag is normally unset upon reception
of (neighbour or router) solicitations sent from the router itself,
when a new neighbour cache entry is created.

RFC2461's Section 7.2.3 describes the router's own recovery from
this incorrect state, by sending subsequent router or neigbour
advertisements.

Considering that the device doing optimistic DAD which erroneously
causes the IsRouter flag to be unset has already sent a DAD NS to the
address owner (in this case the router), the router will schedule an
NA to all-nodes within a second of this NS's reception.

Assuming that the NA is received by the other routers, the NA will
set the IsRouter flag in the NC entries on the receving routers.
Otherwise, any router or neighbour advertisements will repair the
damage, as described in RFC2461's appendix D.

Please also be aware there is no issue for default router selection
on hosts, (which is what the IsRouter flag is for) since they never
receive the RS in the first place.

This issue is very close to my interest, since I've been looking
at fast ways of soliciting configuration when a host may have
just arrived on a link.

It seems that treating addresses as tentative is an appropriate
precaution in this case.

If Optimistic DAD doesn't allow for unicast responses to
router solicitations, the potential for fast advertisement
to such hosts is severely diminished.

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 2 Jun 2004 16:54:12 -0700 (PDT)

> to such hosts is severely diminished.

So how could something work?

I'm assuming that somehow, perhaps using a token bucket filter
instead of a fix 1 every 3 seconds limit, we can accomplish faster
RA responses to RSes, but the DAD interactions are still perplexing.

Alternative 1:
The RS contains the tentative address as the source, but no source
link-layer address option (since that would override any link-layer
address recorded in the routers in the case of an address conflict).

Thus in order for the router to unicast the RA it needs to
perform a NS/NA exchange with the host. This is only done when the router
doesn't have a neighbor cache entry, and the resulting NA has override=0.
So this will never replace a cached link-layer address in the case of
a conflict. But the exchange is 4 packets instead of 2.

Alternative 2:
Why not conceptually define the override flag for the RS to accomplish
a 2 packet exchange?
A compatible way to do this is to define a new "tentative source link-layer
address option" which would only be used by the receiver if it doesn't
have a cached address i.e., would never override an existing address.
(As an aside, this could also be used for NS packets.)

  Erik

---

From: Greg Daley <[email-masked]>
Date: Thu, 03 Jun 2004 10:23:29 +1000

Hi Erik,

> a conflict. But the exchange is 4 packets instead of 2.

Indeed.

This is what is already working in router implementations when
the SLLAO is not present.

The 4 packet exchange is not ideal.
I'd prefer to get the exchange down to 2 (RS/RA).

> (As an aside, this could also be used for NS packets.

I've seen your proposal before (was it on a mailing list?,
or in an e-mail round with JinHyeock?).

It's a good idea since the fallback position (where the option
isn't interpreted by the router) works in the same fashion
as Alternative 1.

I'll contact you on aside to see if we can cover the
salient issues and describe how such an idea could work reliably.

Greg

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 3 Jun 2004 13:06:35 +1000

> NA to all-nodes within a second of this NS's reception.

Aha!  The draft suggests an RA will reset it, but on rereading it
I realized this was wrong.  Seems like the NA will fix the problem ...

> receive the RS in the first place.

... insofar as it is a problem in the first place.  Anyone know
of a situation in which a temporary toggling of the IsRouter bit
_on another router_ will affect anything?  Alternately, we could
consider that last clause of 2461 6.2.6 to be a bug (why _shouldn't_
a router send a RS if it wants to?) and this whole thing a rare
enough case to not worry about.

In that case I think I'll correct the text and make it clearer,
leaving the option to send with a source address but no SLLAO
in there for these hurried types.

It doesn't solve the 'four signals' problem (RS - NS - NA - RA), but
improving the RS/RA exchange is beyond the scope of this particular
draft I feel.

-----N
-- 
Nick 'Sharkey' Moore  <[email-masked]>  <http://zoic.org/sharkey/>
"World Domination Through Enhanced Shareholder Value!"

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 3 Jun 2004 13:06:25 +1000

> (As an aside, this could also be used for NS packets.)

Yep, I'd like to do something like that.  The 'O' flag in 
NAs is the only reason any of this is possible!  The reason I haven't
gone down that path is that I'd like OptiDAD to work with unmodified
routers.  I think it has to if OptiDAD is to be widely deployed.

-----Nick
-- 
Nick 'Sharkey' Moore  <[email-masked]>  <http://zoic.org/sharkey/>
Hofstadters Law: It always takes longer than you expect - even when
you take Hofstadters Law into account.

---

From: Greg Daley <[email-masked]>
Date: Thu, 03 Jun 2004 13:29:33 +1000

Hi Nick.

> enough case to not worry about.

I'd prefer not to rely on changes to 2461.
2461 nodes are our 'deployed base'.

> improving the RS/RA exchange is beyond the scope of this particular

For the case of wireless hosts (as in DNA), I think that
there may be a case where a neighbour cache entry for the host
already exists.

This is because a nice host may may be doing (optimistic?) DAD
on the link-local address when it checks if the current configuration
is valid.  If it sends an RS without a SLLAO, then the router with
an existing NC entry for the host can immediately send back an
RA.

For new nodes 4 signals would be required for unicast delivery,
except if the router and host both supported Erik's tentative
(existing NC entry safe) source link-layer address option.

In any case, a router may choose to multicast a response.
If it does, theres no way to make it send the RA faster, nor
is there a need for neighbour solicitation.

Greg

---

From: Markku Savela <[email-masked]>
Date: Thu, 3 Jun 2004 10:44:30 +0300

Minor detail correction...

> From: Greg Daley <[email-masked]>

> receive the RS in the first place.

IsRouter only implies router, but it does not need to be a default
router (e.g. IsRouter is set for a router that sends RA with
RouterLifeTime = 0, which means "not a default router").

---

From: Pekka Savola <[email-masked]>
Date: Thu, 3 Jun 2004 10:48:27 +0300 (EEST)

> so the parallel for RS works quite fine.

That must be allowed (more or less) for MLD because there is no choice 
if there are MLD snoopers out there..
 
> What problem would such filtering solve?

I'm mainly thinking of xDSL systems where all the customers appear to
be on the same subnet (e.g. a shared IPv4 /19 prefix), but are
filtered so that they are actually separate from each other (sorry, I
can't describe it much better).

I would also imagine that minimizing the use of the unspecified 
address might make SEND-like mechanisms easier, because the 
unspecified address does not belong to just one node, and you cannot 
distinguish the different nodes using the unspecified address.

> assigned by the DHCP client or manually by an administrator?

This can be fixed by the implementation, of course, by appropriate
flags for adding new addresses.  A question is should this feature be 
spelled out if it's required by oDAD.

> which sets IFF_DHCPRUNNING for the addresses that are managed by the

On addresses?  Aren't IFF flags typically per interface, not per 
address?
 
> blocks/adresses? No - life is full of different probabilities.

:-) -- I meant whether the DHCP specs state that this kind of thing 
should be done, rather than us depending on the implementations to do 
that (some probably do, many probably don't).
 
> crashes or reconfiguration resulting in handing out duplicate

Actually at least DHCPv4 spec has a MUST that the leases must be kept 
in a stable storage.

But I'm not sure if that this the same scenario..

---

From: Greg Daley <[email-masked]>
Date: Thu, 03 Jun 2004 23:21:15 +1000

Hi Pekka,

> if there are MLD snoopers out there..

Indeed.
Let IP devices beware...

> distinguish the different nodes using the unspecified address.

I think that the issue with SEND is credible, for router
solicitations more than neighbour solicitations (since
unspecified address solicitations are for DAD, and the
CGA address is in the Target Address.

Given that we were talking about RS here anyway, you may
have a point that the unspecified address RS is unidentifiable,
except by its signed public key (in the message).

I think that ruling out RS entirely here would be premature
though until we consult SEND WG...

It's worth asking the question over there.

Personally, I don't think unidentified and unspecified RS's
are given significant power in any case, so there may be no need
to identify them (rather, we need to make sure that
no additional power goes to them).

If SEND is in use, then certainly there is no CGA, but the
message is still signed and sent from an address which is
covered by the signature at the end of the packet.

That public key did send the message, and if you know the public
key (have seen it before and perhaps trust it), then you could
even treat that differently to a device which you've never seen.

[dhcp issues cut].

Greg

---

From: Ralph Droms <[email-masked]>
Date: Thu, 03 Jun 2004 11:04:13 -0400

Comments in line...

>can't describe it much better).

I imagine such filtering and proxying is more likely to be done on the
basis of physical port or MAC address rather than source address...

>distinguish the different nodes using the unspecified address.

But it seems like there will be situations where the host has
no choice but to use the unspecified address?  Would text to the
effect of "only use the unspecified address if no other address
is available" be appropriate?

>spelled out if it's required by oDAD.

Doesn't seem necessary - the draft text is "Optimistic algorithm SHOULD
NOT be used on manually configured addresses," which seems sufficient
without telling the implementor that some method to differentiate
"manually configured addresses" is required.

>that (some probably do, many probably don't).

RFC 3315, section 18.18, requires the use of DAD by the client: "The client
SHOULD perform duplicate address detection on each of the addresses [...] it
receives [...]."  The DHCP server is presumed to operate correctly and not
hand out duplicate addresses to its clients.  DAD is more reliable than any
check the DHCP server could make to detect conflict with addresses not
assigned by the server.

>But I'm not sure if that this the same scenario..

Is the scenario:

* DHCP server assigns IP1 to A
* A configures its interface with IP1
* Operator removes A from DHCP server configuration, returning
   IP1 to pool of available addresses
* DHCP server assigns IP1 to B
* B configures its interface with IP1
* A and B have an address conflict

If I have that right, I would consider that scenario to be
Operator Error...

- Ralph

---

From: "James Kempf" <[email-masked]>
Date: Thu, 3 Jun 2004 08:48:49 -0700

Hi Greg,

No need to go over there for comments. :-)

SEND allows the unspecified address to be used on RSs but the CGA option is
not included, so, as a practical matter, the signature can't be either since
the CGA option contains the key.

A message sent with an unspecified address is not treated as insecure
however, unlike other ND/RD messages without a CGA option and signature.

            jak

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "Pekka Savola" <[email-masked]>
Cc: "Nick 'Sharkey' Moore" <[email-masked]>; "Erik Nordmark"
<[email-masked]>; <[email-masked]>
Sent: Thursday, June 03, 2004 6:21 AM
Subject: Re: optimistic dad comments

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 3 Jun 2004 12:00:10 -0700 (PDT)

> can't describe it much better).

As Ralph said, isn't this done by filtering on the source MAC address
(with only one MAC address being allowed by each subscriber).
That is at least how I think cable modem setups work.

> distinguish the different nodes using the unspecified address.

Using the unspecified source address to cause a state or behavioral
change in a neighboring node would be problematic in the place where
SEND is used. But the RS case doesn't do this. It is just "send me some
public information". (And the MLD report isn't either; the multicast
router ignores it, and the MLD snooping switches actually act on
the port/MAC address from which the packet came.)

> spelled out if it's required by oDAD.

No, it's all implementation. Just making the document clear should be
sufficient.

> On addresses?  Aren't IFF flags typically per interface, not per 

Solaris diverged from BSD on this point 10+ years ago.
Instead of aliases under a single interface name the
multiple IP addresses are "named" with logical interface names such
as hme0:1. See 
http://docs.sun.com/db/doc/817-0690/6mgflntb5?q=ifconfig&a=view

   Erik

---

From: Greg Daley <[email-masked]>
Date: Fri, 04 Jun 2004 10:31:45 +1000

Hi James,

> however, unlike other ND/RD messages without a CGA option and signature.

Thanks for that, I'll have to read SEND more closely.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 4 Jun 2004 09:29:11 +0300 (EEST)

Replying to both Erik and Ralph..

> That is at least how I think cable modem setups work.

No, each subscriber is allowed to have multiple MAC addresses (but 
each of those MAC addresses get their own IP address and are isolated 
from the others) -- at least for xDSL.

But you're still correct, using MAC address or a port is more reliable 
than trying to filter based on the address.

[Ralph:]
> is available" be appropriate?

Yes, this is good enough for me.  The text doesn't quite say that at 
the moment.
 
> the port/MAC address from which the packet came.)

True -- this should not be a problem for SEND because state is not 
changed.

[snip implementation-specific issues]

[Ralph:]
> check the DHCP server could make to detect conflict with addresses not

True -- as long as the DHCP server knows that the addresses it's 

> If I have that right, I would consider that scenario to be

Precisely this scenario.  Manually misconfiguring an address is also
an operator error, which DAD is intended to protect from.  Because
here the DHCP server cannot know that it should not hand out out IP1
quite yet, it might make sense for the clients to do DAD on the
address.

Doing DAD also protects from misbehaving/buggy DHCP server
implementations (if any).

We probably agree that the probability of collision with DHCP-assigned
addresses is significantly higher than with SLAAC'ed addresses, but
somewhat lower than with manually configured addresses.  Whether this
warrants a pessimistic DAD mode is open to the debate, and I don't
have too strong opinions either way.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 4 Jun 2004 09:32:09 -0700 (PDT)

> from the others) -- at least for xDSL.

But each subscriber has a separate subnet prefix, right?
Or how does broadcast work?

Or are you talking about the broken configuration when each subscriber
sees e.g. a /24 subnet, but some of the IP addresses in that subnet
are allocated to other subscribers whom they can't talk do (because some
filtering blocks the ARP packets?)

I'm confused.

 Erik

---

From: Pekka Savola <[email-masked]>
Date: Sat, 5 Jun 2004 09:02:58 +0300 (EEST)

> Or how does broadcast work?

The subnet prefix is shared.

> filtering blocks the ARP packets?)

ARP is blocked between hosts in the same subnet, and the router 
proxy-arp's for everyone else, so they can still communicate.

I think this draft explains this somewhat:  
draft-melsen-mac-forced-fwd-01.txt (I've only glanced through it so
I'm not 100% sure whether it's it)

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 8 Jun 2004 20:41:35 +1000

> Below are my comments on draft-ietf-ipv6-optimistic-dad-00.txt.

PS:  I've started an Issues List at:
	http://www.ctie.monash.edu.au/ipv6/fastho/opti_dad_issues.html
although it isn't very organized or complete yet.  I'll be updating
it over the next few days, and if we can get it down to 0 open issues
I'll release a -01.  I've already put in all your editorial changes,
thanks!

-----Nick

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 09 Jun 2004 12:04:31 +0900

>>>>> On Tue, 1 Jun 2004 16:16:03 +1000, 
>>>>> "Nick 'Sharkey' Moore" <[email-masked]> said:

> a little more ... mobile-oriented.  Should I leave it as an appendix

I don't think this should go to rfc2462bis, since the goal of
rfc2462bis is basically bug fixes and clarifications while
regenerating an address upon duplication is IMO an extension.

The best place should definitely be outside rfc2462bis.  It's probably
an appendix of the oDAD document or perhaps a new separate document.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 9 Jun 2004 13:35:35 +1000

> regenerating an address upon duplication is IMO an extension.

Okay, I can see that.  It's a bit big to be a bug fix :-)

> an appendix of the oDAD document or perhaps a new separate document.

I'm leaning towards moving it to an appendix and removing all
requirement words ... would this be sufficient for all parties?

It could be followed up in another document, but I'd hate to
make Opti-DAD dependent on anything else ... it's been too long
in the pipeline as it is.

-----Nick

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 09 Jun 2004 13:03:33 +0900

(I'm going to concentrate on one specific issue, so I've changed the
subject.)

>>>>> On Wed, 2 Jun 2004 08:03:18 +0300 (EEST), 
>>>>> Pekka Savola <[email-masked]> said:

> optimizations in the first place..

I would vote for disabling optimistic DAD for manually configured
addresses and addresses assigned via DHCPv6.

The main reason is that the default strategy of optimistic DAD should
be conservative and very careful not to break anything deployed
without the optimistic behavior.  I believe this is the basic deal
(perhaps implicitly) when we agreed on working on this draft in this
wg.

It is obvious that the probability of collision among manually
configured addresses is higher than that among (e.g.,) EUI-64 based
addresses.  Regarding addresses assinged by DHCPv6, they can still
collide with addresses configured by a different method (typically by
manual configuration), as I thought Ralph pointed out.  DHCPv6
addresses can even collide each other with misconfiguration.  It's
true that this is an operational error, but detecting such an error
should be one of the main purposes of DAD in the first place.

I don't know how high the collision possibility is for these addresses
comparing to EUI-64 or randomly generated addresses.  But, according
to the "conservative" strategy, the appropriate logic I should take is
that we do not perform the optimistic behavior for addresses unless
we are very sure that the collision probability for these addresses is
low as that for EUI-64 or randomly generated addresses (IMO).

Besides, if I understand it correctly, the original motivation of
optimistic DAD should be helping mobile end devices roam networks as
fast as possible.  I believe these devices are very unlikely to
configure their addresses manually, so disabling the optimistic
behavior for manually configured addresses would not decrease the
value for the original motivation.  (The case of DHCPv6-configured
addresses might be controversial in this sense, though.)

					JINMEI, Tatuya