WEBINAR TUESDAY: Can We Make IPv4 Great Again?

Mailman List Mirror (Read Only)
1

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

​==================================================================​

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

2

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

3

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

4

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?

5

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.]

6

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

7

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

8

I think only 22% of networks with an AS announce IPv6 space. Is that
correct ?

Thank You
Bob Evans
CTO

9

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 :frowning:

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

10

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

11

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

12

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

13

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

14

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.

15

PMTUD is broken as designed, the one thing about TCP which directly
violates the end-to-end principle.

-Bill

16

In message <608f5c96-3134-9cdf-6f93-41d14d371d5d@2mbit.com>, Brielle Bruns writ
es:

>
>> 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