> Given that the original (RFC2462, 5.4.2) is a "should delay":
> |
> | 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_DELA
On 2005-11-06, Christian Vogt wrote:
>
> I see, it's an implementation issue.
Sadly, true. Whilst we're not really meant to worry about these,
sometimes they can't be ignored.
> (3) Given that you cannot really know whether the ON is stationary or
> mobile, the following may be a good approach
Hi Nick.
> Ah, now, this is pushing the scope of OptiDAD, I feel. Just as it
> has proven tricky to be sure if an address is "manually assigned"
> vs. assigned by a higher layer (or a script, or something), I think
> it'll be hard for our poor IPv6 stack to make this call.
I see, it's an impleme
On 2005-10-31, Christian Vogt wrote:
>
> ...there was consensus on the IPv6 mailing list [1] not to include any
> specific support for mobility into the successors to RFC2461/2462. At
> least, this was said in the context of delays imposed on MLD Report
> transmissions.
>
> (Note: IMO, this is
> Actually, I disagree. In order to provide timely address
> configuration, we MUST violate these delays.
Nick,
my assumption in writing the above text passage was that the
delays for MLD Reports should be relaxed elsewhere, e.g. as part of
RFC2462bis.
On the other hand, thinking more about
On 2005-10-19, Christian Vogt wrote:
>
> "The initial Neighbor Solicitation MUST be transmitted as early as
> possible after the Optimistic Address has been flagged as 'Optimistic',
> but it MUST NOT violate any delays or rate limitations set forth by
> RFC2461 or RFC2462.
Actually, I disagree.
Hey Nick.
> Ah, yes. I see what you mean.
>
> Actually, even worse, "as soon as [it] is sent" is somewhat
> ambiguous given L2 queuing, etc.
True, but you could consider this to be written from the IP layer's
perspective, where "sending" a message would mean delivering it to the
interface layer.
On 2005-10-17, Christian Vogt wrote:
> Hi Nick, hi everybody.
>
> First of all, I take up the cudgels for this draft. It defines an
> optimization which is going to be a prerequisite for efficient mobility
> support. The draft is in excellent shape, too. Overall, very good work!
Cheers, thanks
Hi Nick, hi everybody.
First of all, I take up the cudgels for this draft. It defines an
optimization which is going to be a prerequisite for efficient mobility
support. The draft is in excellent shape, too. Overall, very good work!
One thing, though. Section 3.3 of the draft says:
>> * (mod
