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 James Kempf wrote: > Mohamad Khalil, Brett Pentland, and I just submitted a draft on modifying the RS > reply timing: > > http://www.ietf.org/internet-drafts/draft-mkhalil-ipv6-fastra-02.txt > > I didn't see an announcement from the drafts editor in this group. > > In summary, the draft amends RFC 2461 to allow at most one router on a link to > reply immediately to an RS instead of waiting a random amount of time between 0 > and MAX_RA_DELAY_TIME. The router is allowed to reply to at most MAX_FAST_RAS > since the last unsolicited multicast is sent. If this number is exceeded, the > router rolls over to scheduling a multicast RA as soon as possible. This is > intended to avoid DoS attacks on the router. > > We believe this amendment will be necessary for achieving good handover > performance with standard Mobile IPv6 movement detection. If the mobile node is > capable of detecting when the link changes, it can immediately send an RS rather > than wait for a multicast RA. This can significantly decrease the amount of time > required for movement detection. In addition to theoretical considerations, we > have some amount of implementation experience with the existing movement > detection algorithm to suggest that the RS reply protocol in RFC 2461 could have > moderate to severe performance limiting effects on standard MIPv6 handover. > > We would like to have review and discussion of this draft prior to the WG > meeting in Atlanta, and finish up the discussion there, with a goal of making > this a WG document. The Mobile IP working group will be finishing up the MIPv6 > draft soon, and we would like to be able to publish this draft in about the same > time frame, so implementors have some guidance. > > jak > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
