IPv4 vs. IPv6 ping -s inconsistency

[Bruce Evans]

On Sat, 17 Apr 2010 sthaug at nethelp.no wrote:

> For IPv4 I have to be root to ping with a payload larger than 56  bytes:
>
> sthaug at 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 at 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