Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The world in which IPv6 was a good design (2017)

apenwarr.ca

Post reply on HN
Print view View original

141–150 of 318 posts

Re: The world in which IPv6 was a good design (2017)

#141

Post by drewg123 »

cyberax wrote: post #17
themerone wrote: post #8

The myth that it would have been easier to switch to a protocol that is just ip4 with more bits needs to die. The companies too cheap or lazy to adopt ipv6 would still be clinging to classic ipv4 with NAT.

Is it such a myth, though? IPv6 still causes troubles in deployment. For example, Android phones (still!!!) don't support stateful DHCPv6. Moreover, DHCPv6 was designed by idiots and out of many options for DUIDs it doesn't allow the most logical one: a user-specified host name. PMTU in IPv6 is even _more_ broken than in V4 because extension headers just plain don't work in the wide Internet.

Thank you for mentioning extension headers. IMHO, they are the worst mistake in IPv6, because they are unbounded. If you design your hardware to handle extension headers, there are all kinds of edge cases to worry about, and regression testing the different combination of headers is nearly impossible. So lots of hardware vendors just don't handle them (or handle just one), which means they might as well not exist.

Re: The world in which IPv6 was a good design (2017)

#142

Post by fulafel »

mort96 wrote: post #89
fulafel wrote: post #65

Earlier quoted context omitted.

It's looking more like a slow victory than a failure: https://www.google.com/intl/en/ipv6/statistics.html People like to complain a lot about the new features in v6, but they don't make it any worse as a v4 replacement.

I'm worried about the long tail. IPv6 won't actually be useful until more or less everything supports v6; as long as there are enough clients which don't support v6 servers need v4, and as long as there are enough servers which don't support v6 clients need v4. And until we can start disabling v4, v6 gives no advantage and only causes significant added complexity. I'm worried that the time when we can start removing…

Most networked things are not end user facing. It's plenty useful now.

End user facing apps also use it in gradual way when available, eg with WebRTC it lowers service ops costs and gives better latency.

Re: The world in which IPv6 was a good design (2017)

#144

Post by [deleted] »

lproven wrote: post #96

I have several times cited it as a key article, more insightful than almost anything else I've ever read about IPv6, but I concede it is overlong and unclear and needs more illustrations. (Which, as a technical writer myself, I generally regard as a crutch.) I think the core argument can be summarised as this: 1. IPv6 is flawed because it has 2 main layers, but it needed 3. 2. It understands physical addresses, and i…

[deleted]

Re: The world in which IPv6 was a good design (2017)

#145

Post by FuriouslyAdrift »

lproven wrote: post #96

I have several times cited it as a key article, more insightful than almost anything else I've ever read about IPv6, but I concede it is overlong and unclear and needs more illustrations. (Which, as a technical writer myself, I generally regard as a crutch.) I think the core argument can be summarised as this: 1. IPv6 is flawed because it has 2 main layers, but it needed 3. 2. It understands physical addresses, and i…

The single biggest mistake IPv6 made was not encompassing the entire IPv4 space within it to ease transition.

As it is, I am seeing a transition to either non-IP or LISP/HIP based methodologies due to security and attestation concerns.

Re: The world in which IPv6 was a good design (2017)

#146

Post by throwaway154 »

cyberax wrote: post #51
kccqzy wrote: post #41

Earlier quoted context omitted.

> Use 72-bit addresses. 56 bits for the network address, 16 bits for the end-user networks. 16 bits is just way too small. The article clearly states that network operators just love to bridge together larger and larger networks due to the mobile IP problem. In the IPv4 world they can even have 24 bits (10.0.0.0/8) why should IPv6 have only 16 bits? It's definitely not enough.

8 bits for the home network feels cramped even now, my home network is at 56 devices. But 16 bits are fine for end-user networks. And once you go over 16 bits, you really need to start dealing with routing. > In the IPv4 world they can even have 24 bits (10.0.0.0/8) why should IPv6 have only 16 bits? It's definitely not enough. This is not a fair comparison. You won't have a 10.0.0.0/8 network in IPv4 that has 16 mil…

16 bits is fine if thinking about discrete devices in the home.

But what about thinking about the next step, neurons in the home. 65k's on the low side for home neuron count.

Re: The world in which IPv6 was a good design (2017)

#147

Post by systems_glitch »

Helmut10001 wrote: post #77

About a year ago I started the IPv6 migration for my home network (2 Remote sites, connected via IPSEC, with 10 VLANs (subnets) and about 70 devices, 10 people). - I started on one side of the IPSEC, where I have an OPNsense - there were like 5 updates of OPNsense in the last year where different IPv6 issues were fixed (and others have been introduced). - my ISP only hands out /64-Prefixes, and these are also dynamic…

I really really don't get ISPs' difficulties in deploying IPv6. The only conclusion I can reach that actually makes sense is that they don't have the in-house talent to deploy it and refuse to hire someone who does. I guess there's just not enough pain in staying IPv4-only or halfway implementing IPv6 to make them get up and do something about it?

Re: The world in which IPv6 was a good design (2017)

#148

Post by systems_glitch »

Helmut10001 wrote: post #84
Faaak wrote: post #82

Earlier quoted context omitted.

You're comparing two remote sites linked by IPv4 NAT to distributing IPv6 from a /64 (which was never meant to be subdivided) which is dynamic..

Yes, I know - but as the article mentions, it is not possible to "deprecate" IPv4 yet. I need both. And during this "migration phase", both IPv4+IPv6 must work alongside each other, which frankly speaking, I haven't yet managed to accomplish.

Just grab yourself a Hurricane Electric tunnel and be done with it. It's so irritating to work with dynamic IPv6 assignments when you're not Just Some User. Best case, your ISP has really long lease times and you can fake it being "static." Usual case is you get everything working but there are often 5-minute periods where IPv6 is down because some dynamic changes happened at the wrong time.

Re: The world in which IPv6 was a good design (2017)

#149

Post by systems_glitch »

Anyone else mostly fine with IPv6 like it is?

Biggest complaint here is that I wish I had a way to correlate SLAAC addresses with hostnames somewhere other than the host. But I don't so when it matters I run a DDNS client on the host, which is probably the "more correct" answer anyway because the host always keeps DNS updated with its current address.

Re: The world in which IPv6 was a good design (2017)

#150

Post by throw0101b »

mike_d wrote: post #133
Faaak wrote: post #90

Earlier quoted context omitted.

Well, tbh dual-stack is enabled in 70% of France's customers for example. If you start with a solid base (having a fixed IPv6 /56 delegation for example), or at least a dynamic allocation with IPv6-PD, then you'll see that it's way easier than IPv4 in the long end

Advocates often drag out the [large number]% of IPv6 in some case or another. It is only thanks to "happy eyeball" algorithms in the browser which prefer v4 when v6 is broken or non-performant that mitigate end user complaints to the point that people can just kind of turn it on in some state of broken and forget about it.

> It is only thanks to "happy eyeball" algorithms in the browser which prefer v4 when v6 is broken or non-performant that mitigate end user complaints to the point that people can just kind of turn it on in some state of broken and forget about it.

There are entire ISPs that are IPv6-only at the CPE and have to deal with brain-dead software that can't handle it and so have to spend enormous amounts on CG-NAT:

* https://community.roku.com/t5/Features-settings-updates/It-s...

* https://news.ycombinator.com/item?id=35047624

Post reply on HN