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

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

[Oops, sent reply to Ed and forgot the list!]

On Fri, Mar 21, 2003 at 11:47:54AM -0800, Ed Remmell wrote:
> 
> 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:

G'day Ed!  Thanks for your comments :-)

> [bouncing packets to the router to avoid having to NS] 
> 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.

Interesting point.  I'd considered something like this for RS, 
but it should be okay for NS I guess.  The only problem is, in
a handover case the odds are that all addresses are tentative ...
even the link-local has to be tested for ...

> 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.

Yep, that's fine too.  I think all I'd said was "Another address, or the
unspecified address, may be used", so that nodes which have a configured
address and want a unicast reply can try and get one.  The only reason
you'd want to do that is to make FastRA happy, I think ...

> 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).

Yep, that's how Optimistic nodes "boot-strap" themselves ... they
know the LLA of the router, and they can use that to redirect 
traffic to neighbours if they need to.

> 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."

Hmmmm, I should mention that case also ... since DELAY_FIRST_PROBE_TIME >
RETRANS_TIMER, it's never come up in testing and I'd never considered
it. 

Thanks for looking into the draft so closely!  I hope your 
implementation goes well ...

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

---

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

-----N