There's some of that, but there are also apps that tune down their application PDU size until things work. I guess my instinct is that this problem can only be generically solved at transport level and above, as RFC 4821 begins to recognize.
Agreed. If we knew that 4821 was going to make it into a predominance of hosts, this wouldn't be nearly the issue that it is...
Other link-layer technologies are not creating this problem. Tunneling is.But it wouldn't, if we simply placed a (recursive) requirement on tunnelsto deliver adequate MTU at the innermost level. Which is of course an operational, not a protocol, solution.
True, but it's not a reasonable operational requirement due to the large deployed base of 1500B MTU media.
And as long as we're going to make significant architectural changes, we should be making things cleaner than when we got here.I can't disagree with the principle. But to my taste, we're headed towardscomplexity instead of simplicity.
Agreed. I hope that we can do better.
Also - isn't this issue applicable to all the VPNish things being developed these days, i.e. signiicantly broader than RRG?
In some ways, yes. It has been an issue since we started tunneling over IP and it's not going to go away soon. The big difference, the reason why RRG has to solve this if we want to tunnel, is that we're making tunneling a first class part of the architecture. If LISP were to be deployed ubiquitously, for example, we'd end up with something like 99.99% of all Internet core traffic being tunneled and being susceptible to the PMTUD problems that we've discussed. This would include tunneling a large percentage of the folks without their knowledge and consent. This is very different than inflicting pain on a small subset of sophisticated folks who are using a specialized application.
Tony -- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg