Subject: [Mip6] Re: A list of issues for RFC2462 update

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 04 Nov 2003 11:09:31 +0900

>>>>> On Thu, 23 Oct 2003 18:11:55 -0700, 
>>>>> Vijay Devarapalli <[email-masked]> said:

> here is another issue. it involves both 2461 and 2462.

> RFC 2461 says

>     Before a host sends an initial solicitation, it SHOULD delay the
>     transmission for a random amount of time between 0 and
>     MAX_RTR_SOLICITATION_DELAY.

> RFC 2462 says

>     If the Neighbor Solicitation is the first message to be sent from an
>     interface after interface (re)initialization, the node should delay
>     sending the message by a random delay between 0 and
>     MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY].

> lets assume a Mobile Node moves and attaches to a new
> link. it does router discovery and configures a Care-of
> address. the mobile node cannot send a Binding Update
> until it completes DAD for the Care-of address. these
> two random delays (before router discovery and before
> DAD) contribute a lot to the movement detection delay.
> I think this needs to be fixed.
> MAX_RTR_SOLICITATION_DELAY is 1 second. taking the worst
> case scenario, it could be 1 second before a sending
> router solicitation, one second before sending neighbor
> solicitation for DAD and then 1 second before DAD
> completes. the Binding Update cannot be sent until then.

Thanks for the pointer.  I'll add this to my local issue list.

(Note to everyone: this does not mean I'm going to propose a change on
RFC2462 to address this.)

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

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 4 Nov 2003 08:52:10 -0800

> solicitation 
> > for DAD and then 1 second before DAD completes. the Binding Update 
> > cannot be sent until then.

Please re-read the above RFC-2462 requirement closely:
"If the Neighbor Solicitation is the first message to be sent from an
interface after interface (re)initialization..."

The DAD NS in this case is *NOT* the first message to be sent, the RS
is. Therefore, you do not need the random delay prior to sending the DAD
NS in this case. The same random delay before sending the RS can apply
to the DAD NS (because it is sent after the RS).

That's the way we implement it currently, and it causes us to fail a
couple of TAHI tests :-( but we believe we are 100% compliant with the
RFCs w/ regards to implementing it this way.

Thanks.
- Ed Remmell
Elmic Systems, USA

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003