In message <608f5c96-3134-9cdf-6f93-41d14d371d5d@2mbit.com>, Brielle Bruns writ es:
On 3/6/17 10:16 AM, valdis.kletnieks@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 f 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 e, 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 size). 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. Mark
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@isc.org