Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Baldur Norddahl <baldur.norddahl () gmail com>]

EZIP has no transition strategy and is not backwards compatible with 
IPv4. The scheme is unworkable.

It is not possible to dual stack EZIP because it pretends to be IPv4.

The author of EZIP should demonstrate a working prototype. We need to 
see a setup with two clients on a shared external IP address. Then 
demonstrate that the clients can access an EZIP enabled site and also 
that the clients can access unmodified IPv4 sites such as Google.com and 
Facebook.com.

The later test will fail and there is no fix. EZIP requires a big bang 
transition where the whole world implements EZIP on the same day.

EZIP embeds extra address information in IP option headers. The remote 
site needs to take that extra address information and send back in the 
replies. The remote site needs to read the extra "source EZIP" option 
header and put that as an "destination EZIP" option header on reply 
packets. Legacy IPv4 sites do not know the meaning the extra option 
headers and can not do send them back. Packets will arrive at the EZIP 
gateway without option headers. The EZIP gateway will have no option 
other than to drop the packets, because without option headers nothing 
will differentiate the multiple clients behind the gateway.

The EZIP gateway could fall back to NAT when the remote site does not 
have EZIP support. However no method is provided that can tell the EZIP 
gateway wether the remote has EZIP support or not. Since the EZIP 
gateway works on the IP level, we can not use some DNS tricks like 
NAT64/DNS64.

Regards,

Baldur


On 07-03-2017 18:46, Jakob Heitz (jheitz) wrote:
> 1.1.1.1.e.f and 2.2.2.2.e.f both get translated to 192.168.e.f.
>
> Some higher layer protocols embed IP addresses into their data.
>
> These points make changing IP so difficult.
>
> In addition, IPv6 has link local addresses.
> This one seemingly insignificant detail causes so much code churn
> and is probably responsible for 10 years of the IPv6 drag.
> Thakfully, site local was deprecated.
>
> Thanks,
> Jakob.
>
> > Date: Mon, 6 Mar 2017 22:00:45 +0100
> > From: Baldur Norddahl <baldur.norddahl () gmail com>
> > To: nanog () nanog org
> > Subject: Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?
> > Message-ID: <5645714e-e468-4655-34cf-6e70aa7cfa26 () gmail com>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > 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