WEBINAR TUESDAY: Can We Make IPv4 Great Again?
To say that Mr. Chen's EZIP proposal has not, thus far, been received with open arms by the networking community would be an understatement. It is seen as delaying the inevitable and introducing an impractical extra routing hardware layer that will be hit & miss. Nevertheless, since much of the world is still IPv4 dependent, it just could take off. ISOC-NY is happy to give him the opportunity to expound on its merits. We'd welcome some expert respondents. See: https://tools.ietf.org/html/draft-chen-ati-ipv4-with-adaptive-address-space-... ================================================================== WEBINAR TUESDAY: Can We Make IPv4 Great Again? w/ @AbrahamYChen On Tuesday March 8 2017 at noon EST the Internet Society New York Chapter (ISOC-NY) presents a webinar Can We Make IPv4 Great Again?. Abraham Y. Chen, VP of Engineering, Avinta Communications, will present his EzIP proposal to reinvigorate the diminishing pool of IPv4 addresses. Optional registration at the link below. This will be recorded. What: WEBINAR: Can We Make IPv4 Great Again? When: Tuesday March 8 2017 Noon EST | 17:00 UTC Register + info: https://www.meetup.com/isoc-ny/events/238164448/ Computer: https://zoom.us/j/914492141 Phone: http://bit.ly/zoomphone ID: 914 492 141 Twitter: #ezip ==================================================================== Permalink http://isoc-ny.org/p2/9031 -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- -
On Mon, Mar 6, 2017 at 3:08 AM, Joly MacFie <joly@punkcast.com> wrote:
To say that Mr. Chen's EZIP proposal has not, thus far, been received with open arms by the networking community would be an understatement. It is seen as delaying the inevitable and introducing an impractical extra routing hardware layer that will be hit & miss. Nevertheless, since much of the world is still IPv4 dependent, it just could take off. ISOC-NY is happy to give him the opportunity to expound on its merits. We'd welcome some expert respondents.
See: https://tools.ietf.org/html/draft-chen-ati-ipv4-with-adaptive-address-space-...
Hi Joly, If something like this was going to happen, we could have expanded the v4 address space to 64 bits with IPxl: http://bill.herrin.us/network/ipxl.html At this point IPv6 has enough momentum that it can be safely expected to happen. That means all proposals for extending the IPv4 address space are basically dead in the water, especially complicated ones. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
I believe that. However it behooves us to give any of our members' ideas a fair hearing. I'm hoping he'll get some good push back in the session. Joly MacFie joly@punkcast.com 218 565 9365 On Mar 6, 2017 11:14 AM, "William Herrin" <bill@herrin.us> wrote:
On Mon, Mar 6, 2017 at 3:08 AM, Joly MacFie <joly@punkcast.com> wrote:
To say that Mr. Chen's EZIP proposal has not, thus far, been received with open arms by the networking community would be an understatement. It is seen as delaying the inevitable and introducing an impractical extra routing hardware layer that will be hit & miss. Nevertheless, since much of the world is still IPv4 dependent, it just could take off. ISOC-NY is happy to give him the opportunity to expound on its merits. We'd welcome some expert respondents.
See: https://tools.ietf.org/html/draft-chen-ati-ipv4-with- adaptive-address-space-00
Hi Joly,
If something like this was going to happen, we could have expanded the v4 address space to 64 bits with IPxl: http://bill.herrin.us/network/ipxl.html
At this point IPv6 has enough momentum that it can be safely expected to happen. That means all proposals for extending the IPv4 address space are basically dead in the water, especially complicated ones.
Regards, Bill Herrin
-- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Mon, 06 Mar 2017 03:08:35 -0500, Joly MacFie said:
routing hardware layer that will be hit & miss. Nevertheless, since much of 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, Apple, 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?
In a message written on Mon, Mar 06, 2017 at 12:16:32PM -0500, valdis.kletnieks@vt.edu wrote:
Oh, and you're going to need support buy-in from *at least* Microsoft, Apple, Linux, Cisco, Juniper, and a significant chunk of major makers of CPE gear.
Valdis is just spouting a bunch of fake requirements. It's all lies folks. I mean the thing is called "EZIP", the EZ is right in the name. We're going to drain that IETF swamp of all their so-called experts and make sure simple proposals like this that regular people can understand get a fair shot. It's going to change the Internet, bigly. And, what about the e-mails? I mean, come on, what are those SMTP people hiding? [For the humor impared, it's a joke folks.] -- Leo Bicknell - bicknell@ufp.org PGP keys at http://www.ufp.org/~bicknell/
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 of 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, Apple, 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. 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
On Mon, Mar 6, 2017 at 9:13 PM, Brielle Bruns <bruns@2mbit.com> wrote:
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.
PMTUD is broken as designed, the one thing about TCP which directly violates the end-to-end principle. -Bill -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
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
That proposal is far too wordy. Here is the executive summary: Encode extra address bits in extension headers. Add a network element near the destination that converts such that the destination IP of a packet to IP a.b.c.d with extension header containing e.f is translated to 192.168.e.f. In the reverse direction translate source address 192.168.e.f to a.b.c.d and add option header with e.f. Executive summary end. As far as I can tell, the only advantage of this proposal over IPv6 is that the network core does not need to be changed. You could communicate with someone that had an EZIP address regardless that your ISP did nothing to support EZIP. The disadvantage is that every single server out there would need to be changed so it does not just drop the option headers on the reply packets. All firewalls updated so they do not block packets with option headers. All applications updated so they understand a new address format. Servers and applications could also confuse TCP or UDP streams that are apparently from the same source, same port numbers, only thing that differentiates the streams is some option header that the server does not understand. The customers of the ISP that deploys EZIP would not need to update anything (unless they need to communicate with other poor souls that got assigned EZIP addresses), however everyone else would. This is not a good balance. The customers would experience an internet where almost nothing works. It would be magnitudes worse than the experience of an IPv6 only network with NAT64. It is a fix for the wrong problem. Major ISPs have IPv6 support now. It is the sites (=servers) that are lacking. If Twitter did not deploy IPv6 why would you expect them to deploy EZIP? Why would some old forgotten site with old song texts in some backwater country somewhere? We already have better solutions such as CGN with dual stack, NAT64, DS-Lite, MAP etc. None of that is discussed in the RFC. Is the author aware of it? Regards, Baldur Den 06/03/2017 kl. 09.08 skrev Joly MacFie:
To say that Mr. Chen's EZIP proposal has not, thus far, been received with open arms by the networking community would be an understatement. It is seen as delaying the inevitable and introducing an impractical extra routing hardware layer that will be hit & miss. Nevertheless, since much of the world is still IPv4 dependent, it just could take off. ISOC-NY is happy to give him the opportunity to expound on its merits. We'd welcome some expert respondents.
See: https://tools.ietf.org/html/draft-chen-ati-ipv4-with-adaptive-address-space-...
==================================================================
WEBINAR TUESDAY: Can We Make IPv4 Great Again? w/ @AbrahamYChen
On Tuesday March 8 2017 at noon EST the Internet Society New York Chapter (ISOC-NY) presents a webinar Can We Make IPv4 Great Again?. Abraham Y. Chen, VP of Engineering, Avinta Communications, will present his EzIP proposal to reinvigorate the diminishing pool of IPv4 addresses. Optional registration at the link below. This will be recorded.
What: WEBINAR: Can We Make IPv4 Great Again? When: Tuesday March 8 2017 Noon EST | 17:00 UTC Register + info: https://www.meetup.com/isoc-ny/events/238164448/ Computer: https://zoom.us/j/914492141 Phone: http://bit.ly/zoomphone ID: 914 492 141 Twitter: #ezip
====================================================================
Permalink
-- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- -
On Mon, Mar 6, 2017 at 4:00 PM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
Major ISPs have IPv6 support now. It is the sites (=servers) that are lacking.
Hi Baldur, Not exactly. My Verizon FiOS does not support IPv6. Neither does my Cox Cable Internet. My Verizon Wireless service supports IPv6 but my AT&T Wireless service does not. All four of these entities have IPv6 somewhere in their networks but that's not at all the same thing as saying they "have IPv6 support." IPv6 deployment has gathered some momentum, enough that it's unlikely to sputter out, but it's still laughably weak. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
I think only 22% of networks with an AS announce IPv6 space. Is that correct ? Thank You Bob Evans CTO
On Mon, Mar 6, 2017 at 4:00 PM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
Major ISPs have IPv6 support now. It is the sites (=servers) that are lacking.
Hi Baldur,
Not exactly. My Verizon FiOS does not support IPv6. Neither does my Cox Cable Internet. My Verizon Wireless service supports IPv6 but my AT&T Wireless service does not.
All four of these entities have IPv6 somewhere in their networks but that's not at all the same thing as saying they "have IPv6 support."
IPv6 deployment has gathered some momentum, enough that it's unlikely to sputter out, but it's still laughably weak.
Regards, Bill Herrin
-- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
Well try to get ATT to announce IPv6 though our AS! Lol Been on the phone with the for over a month. Still no ETA :( Dennis Burgess - Network Solution Engineer - Consultant MikroTik Certified Trainer/Consultant - MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE For Wireless Hardware/Routers visit www.linktechs.net Radio Frequiency Coverages: www.towercoverage.com Office: 314-735-0270 E-Mail: dmburgess@linktechs.net -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Bob Evans Sent: Monday, March 6, 2017 3:34 PM To: William Herrin <bill@herrin.us> Cc: nanog@nanog.org Subject: Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again? I think only 22% of networks with an AS announce IPv6 space. Is that correct ? Thank You Bob Evans CTO
On Mon, Mar 6, 2017 at 4:00 PM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
Major ISPs have IPv6 support now. It is the sites (=servers) that are lacking.
Hi Baldur,
Not exactly. My Verizon FiOS does not support IPv6. Neither does my Cox Cable Internet. My Verizon Wireless service supports IPv6 but my AT&T Wireless service does not.
All four of these entities have IPv6 somewhere in their networks but that's not at all the same thing as saying they "have IPv6 support."
IPv6 deployment has gathered some momentum, enough that it's unlikely to sputter out, but it's still laughably weak.
Regards, Bill Herrin
-- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
On 3/6/17 14:04, Dennis Burgess wrote:
Well try to get ATT to announce IPv6 though our AS! Lol Been on the phone with the for over a month. Still no ETA :(
Requests driven from the sales side should have the best results. Before Charter's sales turned into a hole of poor service, I had a account manager that actually cared about the whole picture. I told him the reason nobody before him was able to sell to us is because we have requirements that need to be deliverable (no native IPv6 no sale), can't deal in promises. Of course he's no longer there and I'm back to idiots that just want to see how high of a price they can get you to sign for, especially if you're already a customer there's no need to pretend to care further. ~Seth
I have had ipv4 transit with ATT for years (one provider of many)....and the order originally placed was for both ipv4 and 6....yep still waiting. Thank You Bob Evans CTO
On 3/6/17 14:04, Dennis Burgess wrote:
Well try to get ATT to announce IPv6 though our AS! Lol Been on the phone with the for over a month. Still no ETA :(
Requests driven from the sales side should have the best results.
Before Charter's sales turned into a hole of poor service, I had a account manager that actually cared about the whole picture. I told him the reason nobody before him was able to sell to us is because we have requirements that need to be deliverable (no native IPv6 no sale), can't deal in promises. Of course he's no longer there and I'm back to idiots that just want to see how high of a price they can get you to sign for, especially if you're already a customer there's no need to pretend to care further.
~Seth
In message <59f04cec29296d59f589ee671c65edc8.squirrel@66.201.44.180>, "Bob Evans" writes:
I have had ipv4 transit with ATT for years (one provider of many)....and the order originally placed was for both ipv4 and 6....yep still waiting.
Thank You Bob Evans CTO
Cancel your service and say it is because they failed to deliver IPv6. If they try to fight you for breaking the contract they don't have a leg to stand on because they have failed to deliver on their part of the contract. I more people did this you would see IPv6 move up the priority stack. Mark
On 3/6/17 14:04, Dennis Burgess wrote:
Well try to get ATT to announce IPv6 though our AS! Lol Been on the phone with the for over a month. Still no ETA :(
Requests driven from the sales side should have the best results.
Before Charter's sales turned into a hole of poor service, I had a account manager that actually cared about the whole picture. I told him the reason nobody before him was able to sell to us is because we have requirements that need to be deliverable (no native IPv6 no sale), can't deal in promises. Of course he's no longer there and I'm back to idiots that just want to see how high of a price they can get you to sign for, especially if you're already a customer there's no need to pretend to care further.
~Seth
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 6 Mar 2017, at 22:00, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
Encode extra address bits in extension headers. Add a network element near the destination that converts such that the destination IP of a packet to IP a.b.c.d with extension header containing e.f is translated to 192.168.e.f. In the reverse direction translate source address 192.168.e.f to a.b.c.d and add option header with e.f.
6to4 essentially did this already. The main problem with 6to4 that made us stop using it was communicating to non-6to4 (“native”) IPv6 addresses; if you don’t want that, you have running code for both router and host side and plenty of gear that already works. (All this is still complete nonsense in the face of accelerating native IPv6 adoption; I write this just to show that the idea already has been implemented out there.) Grüße, Carsten
participants (11)
-
Baldur Norddahl -
Bob Evans -
Brielle Bruns -
Carsten Bormann -
Dennis Burgess -
Joly MacFie -
Leo Bicknell -
Mark Andrews -
Seth Mattinen -
valdis.kletnieks＠vt.edu -
William Herrin