On Jan 4, 2012, at 9:55 PM, Brian E Carpenter wrote: > The point is that paranoid firewalls will turn this into an > arms race - if they are paranoid enough to block ICMP PTB, > which apparently many are, why wouldn't they block any other > signalling mechanism - especially a new one? > > That's why RFC 4821 describes MTU probing hidden in the transport > layer, where hopefully firewalls would let it be. You will > probably look in vain for widely deployed versions of RFC 4821.
We will not win a discussion with people who fail to understand how the technology actually works vs their concept of it. I'm waiting for the likely millions of users to have trouble when dns more often requires TCP transport for some queries/responses. I see the side-effects of this in my name server logs daily for people not doing EDNS and who can't handle udp packets past 512. Jan 5 07:35:55 puck named[26179]: fldsmtpe02.verizon.com/A: changed rcode: setting NOEDNS flag in adb cache for '192.76.85.133#53' We can't protect people from doing something wrong/outside spec, nor do I feel we should spend a lot of effort catering to solve their problems for them. Just because my prius can go off-road doesn't mean it's the intended operation nor is covered when I abuse it. Same goes here, vendors and carriers need to tell customers their security technique is unsupported and will break things. It's not the role of the carrier to solve all the problems for the customer who does something weird in this case, unless they're the one creating the problem by using 1000 mtu links w/ IPv6. Any vendor that supports setting the mtu under 1280 on IPv6 should face a reality check sooner vs later. - Jared -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
