In message <fa928b87-a687-4e48-a3f1-33e170142...@puck.nether.net>, Jared Mauch writes: > > 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: s > etting NOEDNS flag in adb cache for '192.76.85.133#53' That one isn't outside the spec. The server answers EDNS queries, it's just a old (RFC 1035), server. What is outside the spec in silently dropping queries if you see something you don't understand. RFC 1035 has a error code (FORMERR) for that and it should be returned. What is unconscionable, is firewall vendor shipping products in 2012 which don't handle protocol changes from 1999. EDNS is designed to interoperate with RFC 1035 bases servers. Dropping of fragmented packets is slowly disappearing with the deployment of DNSSEC. The DNS get slower and slower and eventually people start complaining. Fixing firewalls that are dropping fragmented packets usually just requires a rule change. > 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 > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
