Vlad,
Good point. This would work for the normal circumstance, though it would not
deter an attacker, as you point out.
jak
----- Original Message -----
From: "Vladislav Yasevich" <[EMAIL PROTECTED]>
To: "James Kempf" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, October 08, 2002 10:28 AM
Subject: Re: Changing RS Reply Timing for Mobile IPv6
> 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]
--------------------------------------------------------------------
