On 02/07/2017 05:06 PM, otroan(_at_)employees(_dot_)org wrote:
Could you expand on your view of how this pertains to advancing
RFC1981?
It's called last call input. My input is that this document needs
to be more realistic in noting that, for all intents, ICMP-based
MTU discovery isn't viable and that other methods need to be
*expected*, not just that they're available.
Right, but if you are correct that ICMP-based MTU discovery is not
viable then this document should not be advanced. At the same time
for many protocols we have nothing else. An operator can break any
protocol if that's their policy. And that's the breakage we're
talking about here, not any issues with the protocol specification.
There is a philosophical aspect of this. (Which I'm not the best
person to represent as I skipped my University studies in philosophy
and used the student loan to buy a motorcycle... (and only read the
art of motorcycle maintenance years later) ) This is a tussle. The
IETF specifies protocols under the assumption that operators treat
those protocols largely as specified. The 5-10% failure of PMTUD
messages may be caused by misconfiguration, misunderstanding or
mis-intent... Many of our protocols are suffering from the same fate.
Should the IETF adjust all its protocols to be as middlebox friendly
as possible? You can make this argument about IPv6 fragments, any
packet with IPv6 extension headers, IPv4 fragments. Or anything but
TCP port 443/80 and UDP port 53 for that matter. Are we as the IETF
going to continue standardising protocols to work as best as they
possible can, ignoring protocol abuse, or are we going to bend over
and do whatever it takes to make it work for those 5-10% who've
actively broken the protocol? What about the 90-90% where the
protocols work as expected?
There are two things to note here:
1) the folk breaking PMTUD is probably not the guy suffering from that
breakage. So the had that "bad-hevaed" nodes hurt the "well behaved"
nodes (i.e., you cannot claim "you're shooting your own foot).
2) Being an engineering group I would expect our protocols to work in
the real world -- that's the point of engineering: solving problems. At
the end of the day, you can build stuff that works, or complain that way
too many people are doing dumb things (for some meaning of "dumb"). --
But the later will not make protocols work, nor solve problems.
In that sense, I agree with Joe, and Randy Bush here.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492