You know, it would be really nice to have networking related issues
being discussed on netdev instead ...
[tytso's nice description of pmtu blackholes deleted]
tytso>access to the network via your singleton PPP connection. It also
tytso>comes up with those folks using DSL where the providers are using
tytso>the bomination also known as PPP over Ethernet (PPPOE).
I will have to disagree with you on this one, Ted. PPPOE is a great
simple protocol. But i think this is out of context of this discussion.
tytso> Could anyone please explain this? Is there a better solution than
tytso> disabling MTU discovery?
tytso>The final approach, which apparently some of the DSL providers
tytso>use, is that on the cable modem box or on the DSLAM in the telco's
tytso> central office, they are actively messing with the outgoing
tytso> packets, by looking for TCP packets with the SYN bit set (which
tytso> indicates the beginning of a TCP stream), and change the max MSS
tytso> option in the IP header to be smaller than max MTU caused by the
tytso> PPP over Ethernet overhead. This is incredibly ugly, and violates
tytso> the IP protocol's end-to-end argument. It also breaks in the
tytso> presence of IPSEC, since the DSL provider won't be able to muck
tytso> with the packet without breaking the cryptographic checksums.
I dont know whether telcos are already doing this, but we certainly are in
Linux. I point the finger to Marc Boucher. He did it!
The reason is very simple: NAT that good old friend of IPSEC.
When you have lotsa boxes that you are masquareding for it is hell to go
around and start changing their MTU values or doing any sort of per-box
Disabling PMTU at the masquareding box also doesnt help because
PPPOE adds an extra shim header to the packet. It will break IPSEC in
most cases (maybe not in the case where your masquareding box is also your
>From a philosophical angle:
there is no panacea for these kind of problems. I wonder how long youve
been chasing them. You will continously chase people to try and fix things
for IPSEC's sake ;-> I wonder how you plan to deal with all those "content
switching" startups (since that is the greatest thing since sliced bread
these days). Is the end2end arguement really a dead horse? (I am ducking
ahead of time). Maybe what the IETF needs is to take alls chairs into some
end2end non-breakage indoctrination and give them a qualifying test first.
Having said that, there could be an alternative solution in Linux. The
PPPOE code could be made, after dropping the packet, to generate ICMP "too
big" messages back to the masquareded boxes instead (when packet-size
>PMTU-shim_header). Hopefully, the win* boxes know what to do with these
messages. And this will work also for UDP. Marc?
Now if the telcos are doing this (ouch!) how are you planning to dissuade