Subject: [mobile-ip] comments about optimistic DAD for Mobile IPv6

From: "Ed Remmell" <[email-masked]>
Date: Fri, 21 Mar 2003 11:47:54 -0800

Hey,

I've read through the latest optimistic DAD draft,
draft-moore-ipv6-optimistic-dad-02.txt. I'm trying to integrate some of
these ideas into my mobile node design, and I've come up with the following
comments:

1) when the mobile node sends a packet, and the source address of the packet
is tentative, the mobile node skips address resolution and instead forwards
the packet to the default router. This is one of the optimistic DAD
requirements.

Justification: while the source address is tentative, we want to avoid
sending a NS having the same tentative source address containing the Source
Link-Layer option, which we would do for address resolution. In the address
resolution case, the Source Link-Layer option MUST be included, because this
NS is sent to a solicited-node multicast address. Therefore, we avoid doing
address resolution while the source address for the address resolution is
still tentative.

An alternate method would be to use a non-tentative link-local scope address
(if one is available) as the source address of the address resolution NS, if
the source address of the original packet being queued for address
resolution is tentative.

2) when the mobile node sends a RS, it always specifies the source address
as the IPv6 unspecified address. This is a simplification of the optimistic
DAD requirements.

Justification: specifying a unicast source address in the RS is completely
optional, and doesn't really buy you much except for creating or updating an
existing Neighbor Cache entry for that address on the router (which we want
to avoid when this source address is tentative). You would think that there
would be a way to tell the difference between a solicited RA and an
unsolicited RA, but there really isn't in many cases. Even specifying a
unicast source address in the RS does not guarantee that the solicited RA
will be sent to that address, RFC-2461 actually seems to recommend the
opposite: "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."

While going through this material, and revisiting RFC-2461, I also happily
noted that NUD has DELAY_FIRST_PROBE_TIME of 5 seconds, so when the mobile
node discovers a router by receiving a RA containing the Source Link-Layer
option (which MAY be ommitted for load balancing), it creates a Neighbor
Cache entry for the router in the STALE state, it can now use that Neighbor
Cache entry while its link-local address is still tentative without needing
to send NUD probes to the router (a NUD probe, which is a unicast
solicitation, MAY omit the Source Link-Layer option).

Optimistic DAD says:
"   * Never sending Neighbour Solicitations from a Tentative address.
        NSs include a Source Link Layer Address Option, which may cause
        Neighbour Cache disruption.  NSs sent as part of DAD are sent
        from the unspecified address, without a SLLAO."

This is true in the Address Resolution case, but in the NUD case per
RFC-2461:
"On unicast solicitations, an implementation MAY omit the Source Link-Layer
Address option."

The material on setting/clearing the Override bit in the NA makes complete
sense to me.

Thanks.
- Ed Remmell
Elmic Systems, USA

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 21 Mar 2003 14:09:29 -0800

FYI -

Here's how I ended up implementing (a simplified version of) optimistic DAD
in our mobile node (let me know if you have any feedback):

1) changes to sending RS:
Always send RS with source address set to the unspecified address.

Justification: This RS will not include the Source Link-Layer option, which
makes it safer to send rather than using a tentative address and then
accidentally updating another node's Neighbor Cache entry for that tentative
address with the wrong link-layer address.

2) changes to sending NS:
Whenever the auto-configured link-local scope address on the outgoing
interface is tentative, and the source address of the Neighbor Solicitation
is not the IPv6 unspecified address, we must not send the Neighbor
Solicitation message (we pretend like we sent it in this case, but instead
we just drop it). A later retransmission of the NS after we've completed DAD
on the link-local scope address will be successful. Note that this does not
apply to a NS sent for DAD, because that has the source address set to the
unspecified address.

Justification: This NS (i.e. when the link-local scope address is tentative)
is most likely for Address Resolution, not for NUD. By the time Address
Resolution does its retransmission of the NS, we should have completed DAD
on the link-local scope address, so retransmitting the NS later will be
successful (note that RetransTimer can be overridden by the RA/Parameter
Discovery, it is specified in milliseconds: so, if it is very short,
potentially Address Resolution will fail before DAD completes - but then
this can happen anyways if interference/etc. on the link causes these same
packets to be dropped and not to be received correctly). The reason why we
are only checking the status of the link-local address is because we
optimize DAD on the CoAs formed from the same interface ID (so we don't
perform DAD on the CoAs - the DAD on the auto-configured link-local scope
address also tests the auto-configured CoAs). On a foreign link, we normally
don't need to do Address Resolution for any other node on the link besides
the current default router, and in that case we have probably already
discovered the link-layer address of the router from the RA (so we don't
need to send a NS to the router immediately, at least not until 5 seconds
after we've first started sending packets through it which is
DELAY_FIRST_PROBE_TIME).

3) changes to sending NA:
Whenever the auto-configured link-local scope address on the outgoing
interface is tentative, we send the Neighbor Advertisement with the Override
bit cleared.

Justification: The reason why we are only checking the status of the
link-local address is because we optimize DAD on the CoAs formed from the
same interface ID (so we don't perform DAD on the CoAs - the DAD on the
auto-configured link-local scope address also tests the auto-configured
CoAs). Note that this will not be a solicited NA for a tentative address
that we are sending here, because we still implement the basic RFC-2461
requirement of silently discarding the Neighbor Solicitation in that case
and not responding to it (specifically, if the target of the NS is our
tentative link-local address, we will not respond with the solicited NA).
When DAD is optimized, we cheat a little for the CoAs (formed from the
interface ID) because they look like they configure as soon as we receive
the Prefix Information in the RA and auto-configure it, but then if DAD on
the auto-configured link-local scope address fails then all of those CoAs
(formed from the interface ID) are immediately unconfigured.

Thanks.
- Ed Remmell
Elmic Systems, USA

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ed Remmell
> Sent: Friday, March 21, 2003 11:48 AM
> To: Mobile IPv6 mailling list; [email-masked]
> Subject: [mobile-ip] comments about optimistic DAD for Mobile IPv6
>
>
> Hey,
>

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Mon, 24 Mar 2003 12:29:33 +1100

> apply to a NS sent for DAD, because that has the source address set to the

Yep, the only reason the special "sent it via the router" case is
in there is in case the node needs to talk to a node other than the
router immediately ... okay, so it's a rare case in an "access
network" situation ... the node can't send from its Tentative
address, so it gets to router to relay for it.  Whether this
case is worth worrying about is another matter, which is why it's
a SHOULD in the draft.  How it works if you decide not to is
probably worth mentioning I think.

> The reason why we
> address also tests the auto-configured CoAs).

I've been a bit dubious about the exact status of IIDs these days ...
the optimistic draft is written from the POV that each address may
have a different suffix, and each one must be DADed separately,
but it's easy enough to bend it back to only DADing the LL address
and assuming the IID thing holds.

> interface is tentative, we send the Neighbor Advertisement with the Override

Yep, in my implementation we perform DAD on each address, and the
Tentative flag applies to each address.  If you're going to use IIDs,
then the Tentative flag applies to each _suffix_.  

I'd be interested in hearing people's opinions on whether the
IID thing is still done.  I thought it wasn't, but I don't know
why I think that, and I might be horribly wrong.  In which case,
-03 had better fix that up!

-----N
-- 
Nick 'Sharkey' Moore			<[email-masked]>
Research Fellow, CTIE			Tel: +61 3 9905 3707
Monash University,  Australia		Fax: +61 3 9905 5358

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 24 Mar 2003 10:05:04 -0800

Nick -

> and assuming the IID thing holds.

I was not aware that there was any question about IIDs. It is an integral
part of IPv6 Prefix Discovery and Stateless Address Auto-Configuration.

Mobile IPv6 mobile nodes use Stateless Address Auto-Configuration (with the
IID set on the mobile interface) to auto-configure care-of addresses when
the mobile node is operating away from home. This is the easiest way for a
MN to get a CoA.

Thanks.
- Ed Remmell
Elmic Systems, USA

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 25 Mar 2003 08:09:26 +1100

> part of IPv6 Prefix Discovery and Stateless Address Auto-Configuration.

Ah, Greg has pointed out to me where I got this scurrilous gossip
from:  the Yokohama IPv6 WG session ... 

	http://www.ietf.org/proceedings/02jul/145.htm
	http://www.ietf.org/proceedings/02jul/slides/ipv6-3.pdf

but on the other hand, IIDs are still discussed by 

	draft-ietf-ipngwg-addr-arch-v3-11 (28 Oct 2002)

... and I'm not sure where I should look to find a "IIDs are dead"
draft :-)

Now, I'm not convinced that changing it is a good idea myself,
but I guess that's something we'd have to argue about on the
ipv6 WG.

-----Nick

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 24 Mar 2003 13:30:31 -0800

Nick -

The URL http://www.ietf.org/proceedings/02jul/slides/ipv6-3.pdf says:
"One Proposal from the Chairs
omit DAD for any address containing an IID derived from IEEE 802 or EUI-64
MAC, or generated at random al la RFC-3041
* probability for collision is already very low
	• yes, probability is non-zero, but DAD isn’t 100% reliable anyway
* in our opinion, main reason for DAD is to defend against duplicates from
manual configuration or small DHCP pools"

So, it isn't talking about not using IIDs for stateless address
auto-configuration, it is talking about not performing DAD when
auto-configuring those addresses.

Ahhh... I see maybe what you are getting at. Not "IIDs are dead", but
addresses formed from IIDs (derived from IEEE 802 or EUI-64 MAC, or
generated at random a la RFC-3041) don't require DAD, in which case
optimistic DAD becomes unnecessary. That's a good point. But, currently DAD
is still required, the IPv6 specification hasn't changed yet in that regard
(at least not that I'm aware of).

Thanks.
- Ed

> From: Nick 'Sharkey' Moore [mailto:[email-masked]]
> Sent: Monday, March 24, 2003 1:09 PM
> To: Ed Remmell
> Cc: [email-masked]
> Subject: Re: [mobile-ip] comments about optimistic DAD for Mobile IPv6
>
>

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 25 Mar 2003 08:53:01 +1100

G'day Ed,

> auto-configuring those addresses.

Umm ... the bit I meant was "DAD vs DIID".

In other words, when configuring a new privacy-type address X::Y, do we 

1. (DAD)  Send a NS for X::Y to find out if the ADDRESS is unique?

2. (DIID) If we haven't already configured LL::Y, send a NS for LL::Y
	to find out if the IID is unique.  If we _have_ already
	configured LL::Y, no need to check anything, just use X::Y.

3. (paranoid) Configure and duplicate-test both LL::Y and X::Y.
	If _either_ fails, pick a new Y.

(above, the notation X::Y stands for "prefix X, suffix Y",
and LL stands for the well-known Link Local prefix)

I'm not fussed either way, as long as there's WG consensus.
I can retrofit Optimistic DAD to be Optimistic DIID very easily,
I think it started out that way ...

-----N
-- 
Nick 'Sharkey' Moore  <[email-masked]>  <http://zoic.org/sharkey>
"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense." -- E. W. Dijkstra