IPv6 woes - RFC

Sat Sep 25 02:26:18 UTC 2021

> On Sep 24, 2021, at 10:53 AM, borg at uu3.net wrote:
> 
> Well, I see IPv6 as double failure really. First, IPv6 itself is too
> different from IPv4. What Internet wanted is IPv4+ (aka IPv4 with
> bigger address space, likely 64bit). Of course we could not extend IPv4,
> so having new protocol is fine. It should just fix problem (do we have other
> problems I am not aware of with IPv4?) of address space and thats it.
> Im happy with IPv4, after 30+ years of usage we pretty much fixed all 
> problems we had.

Lack of address space is a key problem with IPv4 resolved by IPv6.
Lack of address transparency is another one, but that’s largely a side-effect
of the hacks applied to try and (temporarily cope with the first one). (also
solved by IPv6)
Inability to scale routing by using topology indicators separate from addresses
is a problem inherent in both IPv4 and IPv6. No, I do not consider that the
various hacks that have been applied on this, including LISP, are a solution.
Zeroconf in IPv4 is quite a bit less functional than in IPv6.
PMTU-D is a problem in both protocols, but in some ways, not quite as bad in IPv6.

> As for details, that list is just my dream IPv6 protocol ;)
> But lets talk about details:
> - Loopback on IPv6 is ::1/128
>  I have setups where I need more addresses there that are local only.
>  Yeah I know, we can put extra aliases on interfaces etc.. but its extra
>  work and not w/o problems

I haven’t had a problem assigining additional lo addresses, but whatever.
I think wasting an entire /8 on loopbacks was utterly stupid. Do you have
any situation where you need more than 18 quintillion loopbacks? If not,
then an IPv6 /64 would be fine worst case. (0:0:0:1::/64?)
> - IPv6 Link Local is forced.
>  I mean, its always on interface, nevermind you assign static IP.
>  LL is still there and gets in the way (OSPFv3... hell yeah)
How is it in the way? It’s quite useful and utilitarian.
OSPFv3 uses LL because it doesn’t want to risk having its traffic forwarded
off-link and this guarantees that it won’t.

> - ULA space, well.. its like RFC1918 but there are some issues with it
>  (or at least was? maybe its fixed) like source IP selection on with 
>  multiple addresses.

Isn’t that an issue in IPv4 if you assign a host a 1918 address and a GUA
on the same interface, too?

Bottom line, if you have GUA, ULA is mostly pointless in most scenarios.
This isn’t a problem unique to IPv6, save for the fact that you don’t
usually have the option of putting GUA where you put RFC-1918 because
if you have GUA, you don’t usually want 1918. So I really don’t see
any difference here other than the fact that IPv6 gives you an additional
choice you don’t generally have in IPv4, but that choice does come with
some additional tradeoffs.

> - Neighbor Discovery protocol... quite a bit problems it created.
>  What was wrong w/ good old ARP? I tought we fixed all those problems
>  already like ARP poisoning via port security.. etc

What are the problems you’re seeing with ND? In my experience, it mostly
just works.

> - NAT is there in IPv6 so no futher comments

Sadly, this is true. The good news is that hardly anyone uses it and
most people doing IPv6 seem to understand that it’s a really bad idea.

> - DHCP start to get working on IPv6.. but it still pain sometimes

I haven’t seen anything in DHCPv6 that is significantly harder than in
IPv4 other than the need to chase the DUID format that a particular
host uses in order to set up a fixed address.

> And biggest problem, interop w/ IPv4 was completly failure.
> Currently we have best Internet to migrate to new protocol.
> Why? Because how internet become centralized. Eyeball networks
> just want to reach content. E2E communication is not that much needed.
> We have games and enhusiast, but those can pay extra for public IPv4.
> Or get VPN/VPS.

Lots of possibilities were discussed, but it boiled down to the eventual
realization that there is mathematically no way to put a 128 bit
address into a 32 bit field without loss of information.

I bet any solution you can theorize ends up dying due to a variant
of the above issue.

> And end comment. I do NOT want to start some kind of flame war here.
> Yeah I know, Im biased toward IPv4. If something new popups, I want it 
> better than previous thingie (a lot) and easier or at least same level of 
> complications, but IPv6 just solves one thing and brings a lot of 
> complexity.

I have implemented IPv6 in a lot of environments and other than the complexities
around vendors doing a poor job of implementation, I haven’t encountered any
complexity that I couldn’t relate to the same problem in IPv4.

Can you elaborate on these supposed complexities and how they have actually
impacted you in real world scenarios? Perhaps the issues you’ve encountered
can be addressed in a useful way.

> The fact is, IPv6 failed. There are probably multiple reasons for it.
> Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4
> works for me for now.

Many of us have moved to IPv6 and for eyeball sites that have deployed it,
more than 50% of most traffic flows over IPv6.

I think its telling that India is at roughly 97% IPv6 deployment. By the
time internet was developing in India, APNIC was mostly out of addresses.
This coupled with the previous regulatory environment for internet services
in India severely crippled India’s access to iPv4 addresses.

I know of multiple enterprises in the US that are now deploying IPv6 at
least at their edge in order to work with developers in India.

India is a microcosm of what is to come in the developing world.

The US is at roughly 47% IPv6 eyeballs preferred today. There is going
to come a time when we start having IPv6-only eyeballs in the US and
other parts of the world. How painful or problematic that becomes will
depend on a large extent to how content providers react to this
situation over the next few years.

Owen

> 
> 
> ---------- Original message ----------
> 
> From: Grant Taylor via NANOG <nanog at nanog.org>
> To: nanog at nanog.org
> Subject: Re: IPv6 woes - RFC
> Date: Fri, 24 Sep 2021 10:17:42 -0600
> 
> On 9/24/21 3:01 AM, borg at uu3.net wrote:
>> Oh yeah, it would be very funny if this will really happen (new protocol).
>> Im not happy with IPv6, and it seems many others too.
> 
> Is your dissatisfaction with the IPv6 protocol itself or is your dissatisfaction
> with the deployment / adoption of the IPv6 protocol?
> 
> I think that it's a very critical distinction.  Much like DoH as a protocol vs
> how some companies have chosen to utilize it.  Similar to IBM's computers vs
> what they were used for in the 1940's.
> 
>> This is short list how my ideal IPv6 proto looks like:
>> - 64bit address space
>>   more is not always better
>> - loopback 0:0:0:1/48
>> - soft LL 0:0:1-ffff:0/32 (Link Local)
>> - RFC1918 address space 0:1-ffff:0:0/16
>> - keep ARPs, ND wasnt great idea after all?
>> - NAT support (because its everywhere these days)
>> - IPv6 -> IPv4 interop (oneway)
>>   we can put customers on IPv6, while keeping services dualstack
>> - correct DHCP support (SLAAC wasnt great idea after all?)
>>   I think its already in IPv6, but was an issue at the begining
> 
> I'm probably showing my ignorance, but I believe that the IPv6 that we have
> today effectively does all of those things.  At least functionality, perhaps
> with different values.
> 
>> If there are some weird requirements from others, put them into layer up.
>> L3 needs to be simple (KISS concept), so its easy to implement and less
>> prone to bugs.
> 
> How many of the hurtles to IPv6's deployment have been bugs in layer 3? It seems
> to me that most of the problems with IPv6 that I'm aware of are at other layers,
> significantly higher in, or on top of, the stack.
> 
>> And that IPv6 I would love to see and addapt right away :)
> 
> I'm of the opinion that IPv6 has worked quite well dual stack from about
> 2005-2015.  It's only been in the last 5 or so years that I'm starting to see
> more problems with IPv6.  And all of the problems that I'm seeing are companies
> making business level decisions, way above layer 7, that negatively impact IPv6.
> Reluctance to run an MX on IPv6 for business level decisions is definitely not a
> protocol, much less L3, problem.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die