Subject: RE: [mobile-ip] RE: RFC 2462 DAD optimization

From: "Dave Thaler" <[email-masked]>
Date: Mon, 3 Jun 2002 11:46:03 -0700

Robert Elz writes:
> ps: don't we already have a way to tell from RAs which prefix is
multi-
> link
> and which is not 

No.  In fact, I would expect that if any prefix is multilink, then all
of them should be.  

> (because it matters to whether we send packets to routers
> of just do ND for them?).   

There is a bit that says whether to send packets to routers or just do
ND
for them, which is probably what you're thinking of.  However, a
multilink
subnet can work either way (see section 4.1 of the multilink draft), 
so that bit doesn't tell you anything about whether you're on a
multilink subnet.  

> If so, we can use that to solve the DAD
> optimisation problem can't we?   That is, simply prohibit DAD
optimisation
> for multi-link prefixes.   If we don't currently have such a method,
there
> are still spare bits in the RA that can easily be used to mark a
prefix as
> multi-subnet and hence ban DAD optimisation for it.

My preference is that we just ban DAD optimization in all cases.

-Dave

---

From: Robert Elz <[email-masked]>
Date: Tue, 04 Jun 2002 16:39:11 +0700

| No.  In fact, I would expect that if any prefix is multilink, then all
  | of them should be.

Why?   I'm no expert on multi-link, in fact, I'm not sure I understand
the need for it at all really, but nor do I know enough to object.

  | There is a bit that says whether to send packets to routers or just do
  | ND for them, which is probably what you're thinking of.

Yes, that's probably it.

  | However, a multilink
  | subnet can work either way (see section 4.1 of the multilink draft),

OK.

  | My preference is that we just ban DAD optimization in all cases.

That's certainly an option.   The "new prefix causes several thousand
nodes to all attempt DAD at the same time" argument is the one which
makes me hesitant to simply support this without further investigation.

kre

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 4 Jun 2002 12:26:31 +0200 (CEST)

> makes me hesitant to simply support this without further investigation.

If that is a problem then the "MAY" for the optimization in RFC 2462
wouldn't be sufficient as a solution - very few implementations do
the optimization today. 

Possible solutions to the new prefix DAD flood could be:
 - mandate the DAD optimization with a MUST
 - update RFC 2462 to day that when a new prefix is configured (past
   the original "attachment" to the link) the host MUST insert a random
   delay before performing the DAD.
 - others?

But do we agree that the DAD flood when a new prefix is announced is
an important problem to solve?

  Erik

---

From: Robert Elz <[email-masked]>
Date: Tue, 04 Jun 2002 21:10:35 +0700

| If that is a problem then the "MAY" for the optimization in RFC 2462
  | wouldn't be sufficient as a solution - very few implementations do
  | the optimization today. 

It depends upon whether the problem is one that always needs solving, or
just one that needs to be able to be solved.

  | Possible solutions to the new prefix DAD flood could be:
  |  - mandate the DAD optimization with a MUST

So, I don't think we need to do that, whatever else happens.   Then we
get to implementation quality and all that - in an environment where
it matters, users may want to insist on implementations that work well.

In any case, we would need a way to indicate which prefixes should not
be DAD optimized (MUST NOT) because of the multi-link issue.

  |  - update RFC 2462 to day that when a new prefix is configured (past
  |    the original "attachment" to the link) the host MUST insert a random
  |    delay before performing the DAD.

That's certainly a reasonable approach (though I'd prase it as "before
configuring an address using the prefix" to make it more clear that it
isn't only the DAD that needs to be delayed).

  | But do we agree that the DAD flood when a new prefix is announced is
  | an important problem to solve?

Like a lot of this, I suspect this may be known only when we get IPv6
nets that are really big enough that the effects can be measured.  I'm
not sure there are all that many.   I suspect that even the IETF net
won't have enough IPv6 nodes actively connected to it to run an experiment
there and see what happens.

kre