RE: WEBINAR TUESDAY: Can We Make IPv4 Great Again?
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
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.
AFAICT, Cisco V6 HSRP (mentioning that brand only because it caused me to try to figure something out, a coincidence that this is in reply to Jakob from Cisco but is based on what he wrote) relies on Link Local addresses. I didn't understand why link locals should be there in the first place seemed klugey and have googled, looked at rfcs and tried to understand why link local addresses were baked into V6. The only thing I found was that it enabled interfaces on point to point links to be unaddressed in V6. (To save address space!??) Can anyone point me in a direction to understand the reasoning for link local addressing? dennis
On Tue, 07 Mar 2017 18:27:06 -0500, Dennis Bohn said:
AFAICT, Cisco V6 HSRP (mentioning that brand only because it caused me to try to figure something out, a coincidence that this is in reply to Jakob from Cisco but is based on what he wrote) relies on Link Local addresses. I didn't understand why link locals should be there in the first place seemed klugey and have googled, looked at rfcs and tried to understand why link local addresses were baked into V6. The only thing I found was that it enabled interfaces on point to point links to be unaddressed in V6. (To save address space!??) Can anyone point me in a direction to understand the reasoning for link local addressing?
Because there are a lot of corner cases where you may want to talk to the network before you find out what your network address is. And if it's a stand-alone network, it may not *have* a well-define network prefix to use for SLAAC auto-config addressing. Think about all the places in IPv4 where you toss packets on the net with your MAC address or a bogus placeholder IP address because you don't have an IP address yet (ARP, DHCP for starters). Link-Local is basically the same thing in the IPv6 world.
On 7 March 2017 at 23:27, Dennis Bohn <bohn@adelphi.edu> wrote:
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.
AFAICT, Cisco V6 HSRP (mentioning that brand only because it caused me to try to figure something out, a coincidence that this is in reply to Jakob from Cisco but is based on what he wrote) relies on Link Local addresses. I didn't understand why link locals should be there in the first place seemed klugey and have googled, looked at rfcs and tried to understand why link local addresses were baked into V6. The only thing I found was that it enabled interfaces on point to point links to be unaddressed in V6. (To save address space!??) Can anyone point me in a direction to understand the reasoning for link local addressing?
So you can print whilst your Internet connection is down. IPv6 allowed people to rethink IPv4 assumptions, and they realised that a lot of IPv4 things were hacks to work around a lack of functionality in the protocol. NAT has polluted peoples minds when it comes to the distinctions between local and global addressing. Why would you use a global address, with an extra code check to make sure it is on a directly attached interface, to point a route at? "Router 2 on interface B" makes more sense to me than "Router with global address 12345" in this context. I would also have loved it if the all-routers-anycast thing had been better defined rather than deprecated. One of the potential default behaviours could have been fe80:: as a default gateway on every segment, with a logical meaning of "All upstream routers on this interface". - Mike
On 08-03-2017 00:27, Dennis Bohn wrote:
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.
AFAICT, Cisco V6 HSRP (mentioning that brand only because it caused me to try to figure something out, a coincidence that this is in reply to Jakob from Cisco but is based on what he wrote) relies on Link Local addresses. I didn't understand why link locals should be there in the first place seemed klugey and have googled, looked at rfcs and tried to understand why link local addresses were baked into V6. The only thing I found was that it enabled interfaces on point to point links to be unaddressed in V6. (To save address space!??) Can anyone point me in a direction to understand the reasoning for link local addressing?
dennis
Many features of IPv6 depends on link local. Take a look at the routing table of your computer - you will find that most routes have a next hop with a link local address. Many buildin protocols, such as RA and DHCPv6, use link local to communicate without depending on any configuration. Many protocols with automatic discovery will use link local - why would you want your printer or local NAS server to use a public IP when link local works? In fact, you may prefer the printer to be only on link local so it can not be accessed from outside. The public IP is something your ISP assigns to you, so using that unnecessary only makes your setup vulnerable to problems if the internet is down. You could assign an ULA prefix https://en.wikipedia.org/wiki/Unique_local_address for your network but most people wont. Regards, Baldur
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
participants (5)
-
Baldur Norddahl -
Dennis Bohn -
Jakob Heitz (jheitz) -
Mike Jones -
valdis.kletnieks＠vt.edu