WEBINAR TUESDAY: Can We Make IPv4 Great Again?
marka at isc.org
Tue Mar 7 23:25:09 UTC 2017
In message <608f5c96-3134-9cdf-6f93-41d14d371d5d at 2mbit.com>, Brielle Bruns writ
> On 3/6/17 10:16 AM, valdis.kletnieks at vt.edu wrote:
> > On Mon, 06 Mar 2017 03:08:35 -0500, Joly MacFie said:
> >> routing hardware layer that will be hit & miss. Nevertheless, since much o
> >> the world is still IPv4 dependent, it just could take off.
> > For it to "take off", the very same people who have dragged their heels
> > deploying IPv6 will need to suddenly jump up and upgrade all their gear
> > and personnel to support a *third* protocol.
> > Oh, and you're going to need support buy-in from *at least* Microsoft, Appl
> > Linux, Cisco, Juniper, and a significant chunk of major makers of CPE gear.
> > What's the business case for all these stakeholders to buy into EZIP? For
> > both the "We already do IPv6" and "We don't do IP6v" cases?
> Lets not even get into the fact that we still can't fully utilize things
> like already established standards such as ECN, EDNS, and PMTUD
> effectively because firewall and security vendors still can't extricate
> their heads from backside and handle basic functionality of IPv4 without
> throwing the packets on the floor.
While this is a Checkpoint example and Checkpoint are in the process of
addressing this the issue is in no way limited to Checkpoint.
Firewall R75.20 Administration Guide 20 May 2012
DNS verification of EDNS queries is supported. This allows use of
BIND. EDNS headers are allowed if they contain all zeros, other
than the field that controls the packet length (maximum payload
BIND had the ability to send send and answer EDNS options for years
by then so it should have read if it was honest:
DNS verification of EDNS queries is supported. EDNS headers are
allowed if they contain all zeros, other than the field that controls
the packet length (maximum payload size). This breaks EDNS version
negotiation and prevents the use of EDNS options by BIND and other
name servers. This also breaks the ability to use new EDNS flags
as specified by the IETF.
db30f4bdcb (Mark Andrews 2008-04-03 02:01:08 +0000 6809)
2353. [func] Add support for Name Server ID (RFC 5001).
'dig +nsid' requests NSID from server.
'request-nsid yes;' causes recursive server to send
NSID requests to upstream servers. Server responds
to NSID requests with the string configured by
'server-id' option. [RT #17091]
These sorts of checks should have never been there in the first
place RFC 2671 already defined what to do with EDNS version != 0
queries which is to return a BADVERS error code. What purpose did
blocking version != 0 serve?
Similarly for EDNS flags. These are supposed to be ingored if you
don't support them. What purpose does blocking these flags serve?
RFC 6891 should have bumped the EDNS version number but it was
impractical to do that because firewall vendors decided that only
EDNS version 0 queries are valid rather than letting the nameserver
perform EDNS version negotiation. RFC 6891 cleaned up the handling
of unknown EDNS options (it was under specified) and bumping the
EDNS version number would, in theory, give consistent handling
(ignore unknown options) in EDNS(1) queries.
You are buying this stuff. You need to understand what it is doing
and the vendors need to be clear about how it is breaking stuff.
> If the average 'security' device these days chokes and drops a packet
> due to not recognizing the ECN option, what makes anyone think shoving
> more special stuff in the headers just for IoT crap is a good idea?
> Wouldn't it just be easier to use IPv6 tunneled over Teredo?
> Oh wait, that would require the IoT vendors to actually build decent
> products with software that works.
> Brielle Bruns
> The Summit Open Source Development Group
> http://www.sosdg.org / http://www.ahbl.org
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the NANOG