On Tue, 6 Jan 2004, Francis Dupont wrote:
>    I have to disagree here.  Even if a very small device was not a
>    router, it would have to respond to traceroutes etc., even though with
>    lower probability that multiple ones would be happening
>    simultaneously.  But still, if e.g. a "dumb" host is connected to a
>    network, and someone close by (e.g. 3-4 hops) sends a traceroute, the 
>    packets could be sent e.g. 1 ms apart.  Any timer-based mechanism is 
>    inappropriate, unless it has some kind of "burst allowance", which was 
>    what Robert Elz also argued for -- but that's token-based filter just 
>    with different words.
>    
> => it seems you are confusing ping and traceroute: even a (too) stupid
> rate-limiting device is never a problem on the target of a traceroute
> because when one'd like to test reachability one uses ping (with the
> standard one second delay between probes).

Even the target of the traceroute replies with ICMP unreachables.

13:16:09.430527 192.88.99.1 > 80.186.174.139: 2001:670:86:3001::1.58692 > 
2002:50ba:ae8b::1.33434: udp 16 [hlim 1]
13:16:09.430806 80.186.174.139 > 192.88.99.1: 2002:50ba:ae8b::1 > 2001:670:86:3001::1: 
icmp6: 2002:50ba:ae8b::1 udp port 33434 unreachable
13:16:09.464535 192.88.99.1 > 80.186.174.139: 2001:670:86:3001::1.58692 > 
2002:50ba:ae8b::1.33434: udp 16 [hlim 1]
13:16:09.464726 80.186.174.139 > 192.88.99.1: 2002:50ba:ae8b::1 > 2001:670:86:3001::1: 
icmp6: 2002:50ba:ae8b::1 udp port 33434 unreachable
13:16:09.494352 192.88.99.1 > 80.186.174.139: 2001:670:86:3001::1.58692 > 
2002:50ba:ae8b::1.33434: udp 16 [hlim 1]
13:16:09.494545 80.186.174.139 > 192.88.99.1: 2002:50ba:ae8b::1 > 2001:670:86:3001::1: 
icmp6: 2002:50ba:ae8b::1 udp port 33434 unreachable

So, if such a dumb box is the target of traceroute, an "asterisk" does
appear if the limiting is not implemented properly, i.e. there is no 
allowance for the bursts.

> => this is an operational issue so the requirements should come from
> the v6ops WG and then we could see if token-based method should be made
> mandatory. Because today the only argument we have is for rate-limitation
> using any reasonable method.

If it's not enough that at least one member of v6ops says traceroute
is a must, and rate-limiting must take that into an account, one could
take the thread there explicitly.. depending on how formally that
would be done it might cause none or a lot of delay.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to