On Wed, Jun 09, 2004 at 19:00:01 -0700, Jonathan Stone wrote:

> >	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 agree. But I can see the potential DoS problem. I think we should
try to think of a better protection than just setting a fixed number.
Maybe we should even rethink the whole pmtud logic.

> Is that really what's going on here?

It doesn't look like it. Today I hope to rule out that I have some
weird setup at home where I see the problem.

I am worried about pmtud, especially in IPv6 where it is mandatory.
I think we do not have much operational experience in cases where
pmtud fails and there is no fragmentation in the network. But I
respect the decision to mandate pmtud in IPv6.

With AAAA glue and DNSSEC, DNS packets are going to be larger. I *think*
pmtud is failing too often (e.g. blocked ICMP). I was trying to do some
measurements to get real data on this when I ran into a pmtud problem on
my own system :-(

The research networks are trying to support jumbo frames widely. When
this happens, we can see a lot more mtu mismatches.

	rvdp