On 15 aug 2008, at 22:14, Christian Huitema wrote:
1) In the original model, senders of datagrams with the DF bit set (Don't Fragment) received no information back.
"Fragmentation needed and DF set" is defined in RFC 792, predating path MTU discovery by the better part of a decade.
4) Around 2000, broadband connections start being equipped with tiny
"home
routers" whose NAT function does a pretty bad job at reassembling
IP packets
Hosts that send packets too large observe terrible
performance, and they
are in a bind since PMTU discovery does not work well.
All the home NAT boxes I've used can handle common ICMP messages just fine as traceroute works through them.
5) By 2008, the IETF might recognize that firewalls are here to stay, that we could just as well forget about ICMP, but that we really need another solution.
Considering you work for Microsoft, I'm interested to learn what you guys plan to do about this.
In May there was a discussion on NANOG in May about the fact that the *.microsoft.com servers send packets with DF set, but ignore incoming ICMP too big messages. Now obviously that combination of actions doesn't work.
So are you going to abolish PMTUD and send packets with DF=0 and IPv6 packets that are no larger than 1280 bytes? (If you make a Windows XP box an IPv6 router it will create PMTUD black holes because it filters incoming too bigs.)
Or maybe you're going to implement RFC 4821? But then what about correspondents that don't implement this (yet)? And what about transport protocols that are incompatible with RFC 4821 because they can't change their message size easily?