Margaret,
On further consideration, I think the bandwidth-based method might actually
be dangerous in some situations. Suppose there were asymmetric paths
between nodes A and B; the path A->B consisting of all 1Gbps links and
the path B->A consisting of at least one long, thin link (56Kb modem, 3GPP
wireless, etc.) Even if B is able to authenticate the source addresses in
packets it receives from A, if the bandwidth-based method is used based
on a percentage of the bandwith of B's outgoing 1Gbps interface the queue
on a router at the head of a long thin link on the path B->A will overflow. In
other words, B might cause harmful denial-of-service if it blindly uses a
bandwidth-based estimate, since it has no way of knowing whether long,
thin links will occur on the return path.
As to timer-based, I think Mukesh has already given a good reason as to
why it is suboptimal; I think an arguement could also be constructed that
shows it to cause interoperability problems in some cases. So, I find
myself in the rare position of agreeing with Pekka on this subject.
Fred
Margaret Wasserman <[EMAIL PROTECTED]> wrote:
Hi Mukesh,
>One of the issues raised was about rate limiting methods
>suggested by the draft. The draft suggests Timer-based,
>Bandwidth-based and Token-bucket based methods for limiting
>the rate of the ICMP messages.
>
>After going through the discussion about this in the archive
>and thinking about this a little bit, I propose that we
>remove the Timer-based and Bandwidth-based methods and just
>keep the Token-bucket based method in the draft. (look at
>the arguments at the end of this mail)
>
>I would like to hear from people who would like to keep the
>Timer-based and Bandwidth-based methods with logical reasons.
I'm not sure if these are logical reasons, but... I am
concerned about making a change that will invalidate any
existing ICMPv6 implementations, unless that change is
absolutely necessary (e.g. to block a serious security
hole or to prevent a significant operational problem).
Would it work to state in the new draft that implementations
SHOULD implement the Token-bucket method, but MAY implement
the other methods?
I think that would appropriately encourage implementation of
the Token-bucket method without invalidating existing
implementations that use one of the others.
Thoughts?
Margaret
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
