Hi Vlad,

I'm not sure that there is a requirement to use a fastra flag.

There may be situations where multiple nodes come up on a link
in the duration between multicast advertisements but this may be
handled by the MAX_FAST_RAS being set high enough to handle this.
In the case where many nodes come up on the link, it may
be more effective to schedule a multicast RA in any case.

I'm pretty sure that there's no problem on a network configured
for fastra to give a few of the advertisements to non-mobile nodes.

I believe that the presence of an 'F' bit in a router solicitation
was discussed when the FastRA came up.  In that solution, nodes
desiring FastRA (MIPv6 MN's?) set the bit in every RS, since they
could not determine whether the network supported FastRA or not,
or (possibly) where they were (otherwise they wouldn't be sending the
RS).

If the bit is used, why wouldn't anyone just ask for fast response
anyway?  Isn't it reasonable to expect that all nodes desire
fastest possible autoconfiguration?

I don't see any reason to create an optimization which only applies
to especially configured subnets (access networks?) and then tell
people not to implement it in clients, since it's for MIPv6 mobile
nodes only.

Greg Daley


Vladislav Yasevich wrote:
> James
> 
> I think that the draft is missing a trigger mechanism for a fast RA
> response.  What I mean is, that if any node not requiring a fast RA
> joins the link, it will use up a fast RA that will potentially cause
> delays for a node that would really like a fast answer.
> 
> You could take one of the reserved bits from the RS (there are 32 of them)
> and turn it in to the fast RA flag.  The node that would really like
> a fast answer must set the flag.  The flag will be ignored by routers
> that do not support fast RAs (according to 2461).
> 
> This doesn't get rid of the malicious node consuming all of the fast
> RAs, but it provides the ablility to send the RAs sparingly.
> 
> -vlad
> 
>

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to