WEBINAR TUESDAY: Can We Make IPv4 Great Again?

Baldur Norddahl baldur.norddahl at gmail.com
Mon Mar 6 21:00:45 UTC 2017


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-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
>
>
>
>
>
>
>
>
> --
> ---------------------------------------------------------------
> Joly MacFie  218 565 9365 Skype:punkcast
> --------------------------------------------------------------
> -




More information about the NANOG mailing list