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

From: Margaret Wasserman <[email-masked]>
Date: Mon, 19 Aug 2002 21:15:13 -0400

At 06:26 AM 6/4/02 , Erik Nordmark wrote:
> >   | 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.

If thousands of nodes are involved, the DAD optimization may not be 
enough to fix this problem. 

Instead, we might need some sort of random delay on the creation of 
addresses when a new prefix is received.

Margaret

---

From: Markku Savela <[email-masked]>
Date: Tue, 20 Aug 2002 11:29:40 +0300

> From: Margaret Wasserman <[email-masked]>

> enough to fix this problem. 

Umm? DAD optimization definitely removes the quoted problem. When
optimized, DAD is only done on the link local address when a node is
attached (or booted) to the network.

> addresses when a new prefix is received.

The random delay is already specified for DAD in the boot/attach
process.

The delay is less suitable for DAD's done on RA. In optimized
environment, addresses are useable immediately after RA. With
non-optimized and delayed DAD, we would have undetermined gap after
RA, when an address retrieved from DNS might not work. I would like my
network to be as deterministic as possible, avoid randomness when not
absolutely necessary.

---

From: Robert Elz <[email-masked]>
Date: Tue, 20 Aug 2002 19:49:28 +0700

| The delay is less suitable for DAD's done on RA. In optimized
  | environment, addresses are useable immediately after RA.

That's true, but I'm not sure this is important.

  | With
  | non-optimized and delayed DAD, we would have undetermined gap after
  | RA, when an address retrieved from DNS might not work.

If you're sticking things in the DNS simultaneously with RA, or even
before the RA is issued, then yes, I'd expect breakage.   But I can't
imagine why anyone would do that.

Usually, I'd expect, you'd advertise the new prefix (via RA) then
after that's done, advertise the new addresses in the DNS - either
by manually waiting for the RA to take effect (which might involve
waiting a few RA transmit cycles - some hosts might be busy and
miss the first RA after all) and then editing the DNS, or by using
dynamic DNS, and having each host update its own address(es) as they
are installed in the host.

  | I would like my
  | network to be as deterministic as possible, avoid randomness when not
  | absolutely necessary.

The way to achieve that is to test that the hosts have picked up the new
prefix before advertising it in the DNS, not by assuming that every host
will necessarily have the address available the instant that the RA is
transmitted.

kre

---

From: Markku Savela <[email-masked]>
Date: Tue, 20 Aug 2002 16:15:37 +0300

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

> imagine why anyone would do that.

But, this is exactly the normal situation. The prefix, that is
announced in RA, is one the global prefixes for link. I assume global
addresses are in the DNS.

It can be just situation that router was temporarily down and then
came online/reachable again. At least in our system, application can
connect to an global address, but if there is no route, the connect
can be on hold for a while in wait for router advertisement. If such
arrives, onlink route for the prefix is intalled, and immediately also
the connections are activated (SYN packets sent causing the Neighbor
solitications for the destionations). Now, if the other hosts are
delaying their replies, I may get unreachable... perhaps not a big
deal, but still not pretty either.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 20 Aug 2002 15:39:58 +0200

=> IMHO the delay should be in the DAD itself. We already got a
random delay between 0 and MAX_RTR_SOLICITATION_DELAY for the first DAD
on an interface, why not require it in all cases?
Another detail: before doing DAD, the solicited group must be joined
and this is another cause of collisions when implementations are buggy
(i.e., no new report should be sent because the node is already a member
of the group).

Regards

[email-masked]

---

From: Markku Savela <[email-masked]>
Date: Tue, 20 Aug 2002 17:10:31 +0300

> From: Francis Dupont <[email-masked]>

> (i.e., no new report should be sent because the node is already a member

What report? Solicited node is LINKLOCAL group, there is no need to
send any joins on those? Or is some weird multilink hack again
breaking the basic assumptions about Link Local?

---

From: Francis Dupont <[email-masked]>
Date: Tue, 20 Aug 2002 16:27:37 +0200

=> from RFC 2710:

   MLD messages ARE sent for multicast addresses whose scope is 2
   (link-local), including Solicited-Node multicast addresses [ADDR-
   ARCH], except for the link-scope, all-nodes address (FF02::1).

PS: the reason is that layer-2 devices need to know if they can
remove multicast packets to nodes which are not listening for them
(cf draft-ietf-magma-snoop-02.txt).

---

From: [email-masked]
Date: Tue, 27 Aug 2002 18:17:46 +0900

>In my view this is crap! Why must IP layer bend over so much for some
>kludgy layer-2 devices? If there are such devices, they could quite
>easily detect the equivalent of solicited node participants from the
>normal ND traffic!

	because otherwise multicast traffic will be flooded to every
	switch ports.

>I'm going to ingore RFC 2710 on this point. I do not send MLD for link
>local multicast groups.

	then your device will have trouble operating on coming switches
	that support MLD snooping, and it will be very difficult to
	track the issue down (extraordinary support load to your colleagues).
	i suggest you to follow RFC2710.

itojun

---

From: Markku Savela <[email-masked]>
Date: Tue, 27 Aug 2002 12:14:34 +0300

Returning to this..

---

From: Markku Savela <[email-masked]>
Date: Tue, 27 Aug 2002 12:33:34 +0300

> From: [email-masked]

> 	i suggest you to follow RFC2710.

Although, I don't see much sense in using MLD other link local
multicast groups, I'm here primarily talking about the solicited node
groups. In my view, sending MLD on those is waste, because the *SAME*
information is quite clearly available to the "snoopers" from the
neighbor discovery traffic (DAD, NA, NS).

In my system MLD is a separate component, I would like to be able to
use IPv6 stack *without* MLD. (Which it does quite well, unless these
layer-2 kludges come in and  mess things).

---

From: Francis Dupont <[email-masked]>
Date: Sat, 31 Aug 2002 17:07:33 +0200

> 	i suggest you to follow RFC2710.
   
=> I strongly support Itojun! Please don't ignore standards just because
NIBY.