Date: Mon, 19 Apr 2010 03:09:25 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: sthaug@nethelp.no Cc: freebsd-net@FreeBSD.org Subject: Re: IPv4 vs. IPv6 ping -s inconsistency Message-ID: <20100419022830.M3157@delplex.bde.org> In-Reply-To: <20100417.145128.74659691.sthaug@nethelp.no> References: <20100417.145128.74659691.sthaug@nethelp.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 17 Apr 2010 sthaug@nethelp.no wrote: > For IPv4 I have to be root to ping with a payload larger than 56 bytes: > > sthaug@lab1% ping -s 1472 ftp.funet.fi > ping: packet size too large: 1472 > 56: Operation not permitted > > However, for IPv6 the corresponding operation works just fine: > > sthaug@lab1% ping6 -s 1452 -m ftp.funet.fi > PING6(1500=40+8+1452 bytes) 2001:8c0:8b00:1::2 --> 2001:708:10:9::20:2 > 1460 bytes from 2001:708:10:9::20:2, icmp_seq=0 hlim=57 time=15.730 ms > 1460 bytes from 2001:708:10:9::20:2, icmp_seq=1 hlim=57 time=15.770 ms > > I find this highly inconsistent. My *personal* preference would be to > remove the IPv4 check. Alternatively, the IPv6 ping should be changed > to have the same limitation as the IPv4 ping. This is bitrot in ping6. It was cloned from ping before the check was added to the latter. > I realize that the IPv4 limitation is there to make it *slightly* > more difficult to use FreeBSD boxes to perform DoS attacks and the > like. Personally I believe this is misguided, since there are plenty > of other ways to send large (interface MTU) packets. I tend to agree. The restrictions in (at least) plain ping on -i and to a lesser extent -f and -l are even sillier. On a non-slow machine you can send packets much faster than with ping -i 0.001 by using separate ping processes with -c 1, and as a side benefit to this denial of service the separate processes take more CPU too. The flood on the target is thus not limited by -i accept on slow machine. The lower hard-coded limit of 1 millisecond for root is also gratuitous. Granularly of kernel timers normally makes this limit impossible for ping to reach, but this depends on the kernel configuration. -f and -l can flood the target better than -i, so restricting them is reasonable. Note that -f doesn't actually flood. It sends packets as fast as they come back, or every 10 msec, whichever is more often. Once every 10 msec may have been a flood for 1 MBps ethernet, but it no longer is. Also, timer granularity prevents delivering a packet precisely every 10 msec. I think the imprecision was a factor of 2 with HZ = 100 and is still 10% with the excessively high default HZ of 100. In practice, the target usually responds in much less than 10 msec so the flood is limited by the target response time and local buffering and interrupt moderation delays (which can be significant). -l can actually flood, since it never waits. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100419022830.M3157>