In message <20040610014909.6A0CE64@coconut.itojun.org>,
Jun-ichiro itojun Hagino writes:

>> On Fri, Jun 04, 2004 at 20:15:51 +0900, Jun-ichiro itojun Hagino wrote:

[...]

>> I use the attached program. This is what I do:
>> - delete the host route
>> - start tcpdump in xterm 1
>> - start the program in xterm 2
>
>	with sendto() (without connnect()) on udp, udp6_ctlinput passes 0
>	as the last argument to icmp6_mtudisc_update().  in that case, unless
>	you have tons of (> 256) routing entries created PMTUD, path MTU
>	discovery should work.

Huh? 256 remote peers on different nets is not `tons'; its a very,
very modest number.  If the 250-dd remote peers are all on distinct
remote networks, with distinct next-hop gateways as the path-mtu 
bottleneck, I could envisage 256 distinct remote PMTU entries very easily.

I for one would be very disappointed to learn that NetBSD's PMTU
implementation was geared within limits that can, in all honesty and
fairness, be described as "toy system".

Is that really what's going on here?