Comment by multicast | Hacker News Reader

Comment by multicast | Hacker News Reader

It's unnecessary indeed to not use Ipv6 addresses, 2^128 addresses and the many many features it offers like unicast etc. Ipv6 makes a server as a middlemen for some applications (Ipv4 only) completely obsolete.

But a big problem is that there is still no Ipv6 auto configuration at all on a lot of devices (e.g. no default gateway or no global address configured). Especially android devices and from experience also on Windows. Linux depends on the distro. Changing routing settings on android devices from Ipv4 to Ipv6 does often not work or is not offered by the ISP strangely.

And there are other problems like routers having enabled incoming and outgoing Ipv6 connections by default, which is good, but having router advertisements blocked by default, which is bad. Since there is no way for the OS to get the prefix to construct global addresses automatically. Most users today have little to no knowledge about networking and computers in general. So auto configuration is a must.

That leads to Ipv6 only servers being not reachable and thus the buying of Ipv4 addresses makes a lot of sense at this point.

Building IPv6 autoconf into the protocol was a mistake. DHCPv6 is better.

The problem is that when you autoconf on a local network you usually want more than just a route and basic DNS. Trying to do it in the IP protocol is a bad idea since the IP protocol is intended to almost never change. It belongs in a protocol that's less tightly bound to the IP stack that can be more easily extended like DHCP.

DHCP can also integrate with things like local DNS, while this is much harder to do with IPv6 RA and SLAAC.

SLACC is something that sounded good on paper but doesn't adequately capture the entire problem domain.

IPv6 in general needs to just deprecate all the parts of the protocol that are anything but just making IP addresses larger. Everything else is "second system effect" cruft that tends to impede adoption by adding complexity or adding features in the wrong place in the stack.

> SLACC is something that sounded good on paper but doesn't adequately capture the entire problem domain.

Good news! Nothing in SLACC (sic) prevents you from using DHCPv6.

But now, since we have SLAAC as well, you get auto-magic working with simple link-layer connectivity without having to bother with extra infrastructure. If you need extra functionality, you have the option (not necessity).

The practical issues are unrelated to whether or not the two are mutually exclusive. In practice, the lack of RDNSS support from the get-go was quite the nuisance. Especially when combined with clients that refused to support the optional DHCPv6 method (e.g. Android/ChromeOS). Even with RDNSS, the feature set is quite limited compared to DHCPv6 but you may have to end up implementing both since there weren't enough incentives for all clients to go the extra mile and support it even if some of your other clients do.

Overall these days, beyond Google products, I think the ecosystem is in a healthy spot now and I think IPv6 chose the right path. It can still be a bit more hassle to manage in the enterprise space though and that's the one that needs to most convincing to migrate at this point.

Standard SLAAC only uses 64-bit prefixes. This is a problem if you want subnets and have an uncooperative ISP handing out 64-bit prefixes. Or maybe you have a /48 or /56 but want a nice readable hierarchy of subnets.

You don't even need 64 bits. IIRC with SLAAC you send NDP messages to the entire broadcast domain. So you need broadcast-domain-sized (i.e., small) device counts on every data-link-layer subnet. So why assign /64? But because some devices won't give up if SLAAC routers aren't there and and some mysteriously default to SLAAC when they shouldn't and in fact some devices only use it, now every bottom level subnet has to be /64. Blech.

This is just one of many IPv6 annoyances that don't even need to exist.

/64 is about a lot more than SLAAC, that's just one easily seen place it shows up. Even without SLAAC the /64iveness of IPv6 would still be there. End client subnets being /64 (with the exception of host routes and p2p networks) allow hardware route scaling to be roughly twice as high, allow network operators to never worry about what the client subnet size is (it's /64 and that's big enough for anything, if it's bigger it's an aggregate route, the address is always split in the half for routed part and client part), and allow various tricks like SLAAC assignment methods to work reliably. A /56 gives 256 subnets (and a /48 65,536), if a house needs more than that for hierarchy then something besides the base /64 is wonky.

Uncooperative ISPs will always exist. If the minimum size was /96 they'd hand that out instead of a /64. If there was no minimum size then they'd hand out a /124 or something equally as stupid. For all of the corporatize ISPs and well planned uses, starting at a /64 makes the rest of life easier.

It's the same logic, though often more accepted in this case, as the minimum advertiseable prefix on the internet being a /48. That also has nothing to do with how many theoretical end clients could fit in that and everything to do with what that actually means to equipment, scaling, and implementation planning.

Can you guess which of the popular OSes doesn't support stateful DHCPv6?

Answer: Android.

This makes DHCPv6 pretty much useless in practice, when 30% of the clients simply can't use it.

It's been a while since I set up an IPv6 network, what's wrong with RDNSS?

For clients, IMHO, SLAAC is fine and means I don't have to maintain and run a DHCP service anymore. One less thing that can fail, while SLAAC only fails me if the routers IPv6 link inside the given network goes down.

Servers on the other hand, I will provision with a static IP subnet on deploy, as part of the PXE install or configuration management process, depending on the environment. They will have an ephemeral address during the install, but then query for and persist their allotted address before rebooting into the installed environment as part of their post-install.

I guess we agree that we need a single source of truth, what physical device has what IP (range) in their possession at any time. DNS is a classic way to do that, but there are other solutions, from ITIL-style CMDBs to simple config management git repos. And of course the latter doesn't mean that we don't also update DNS based on IP-assignement, DHCP is not the only tool that can be made to interface with a DNS service.

As long as ISPs are unwilling to actually work on the problem on letting their customers use ipv6, applications/services will continue to be uninterested in exposing ipv6 for usage.

Some countries are doing better than others (https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...), but still, ISPs are really dragging their feet...

The worst foot-draggers are major sites like Github and cloud infrastructure. Google only got IPv6 in GKE this year in most regions.

The other big foot-draggers are corporate networks. Even if the ISP supports V6 many corporate networks do not because two generations of IT professionals learned how to do networking entirely through the lens of NAT as a requirement and don't understand how to do things without it. I've seen many IT peoples' brains just melt at the idea of things just having one address. In reality it simplifies things dramatically but sometimes getting people to grasp a simpler solution is actually harder than getting them to grasp a complex one.

I live in the USA and have had IPv6 at home for over a decade (and have used three different ISPs in that time). Many mobile networks are IPv6-first.

NAT is a hack and it going away will be good.

That being said, you can do NAT on IPv6 if you really want to, and maybe it will be needed to help soothe those with those emotional attachment to certain numbers. [fc00::192:168:1:0]/120 or [fc00::10:44:0:0]/96, for example.

Even with NAT IPv6 is better because the NAT can do 1:1 mapping for every IP inside and does not need to remap ports. There is no port exhaustion and P2P always works.

V6 NAT is unnecessary and dumb but it works better than V4 NAT.

All major ISPs have had native ipv6 for customers in the US for at least 5 years. Not some funky bastardized implementation but native full ipv6.

Ipv6 is overly complicated and has been riddled with bugs for 30 years now. As long as ipv4 is an option many are going to choose to completely disable it. Some of the security concerns cannot be effectively filtered at all. There are numerous examples of these vulnerabilities from even just the last few years.

It’s hard for teams of engineers to secure properly much less a home user.

I completely disable ipv6 even with a deep understanding of it.

> All major ISPs have had native ipv6 for customers in the US for at least 5 years. Not some funky bastardized implementation but native full ipv6.

CenturyLink (or Lumen or whatever they want to call themselves today) only has 6rd, at least in my neck of the PNW. And it's best if you don't use it, as their CPE tends to do bad things if you do; my initial CPE would reboot if a fragmented 6rd packet came in over the WAN interface. The current CPE doesn't reboot, but v6 packets sometimes take about 1 second to transit the CPE, so I gave in and run the CPE as a bridge and do PPPoE on my own equipment.

Here in Boise I have two choices for internet, Sparklight or CenturyLink. CenturyLink will only deliver 80Mbps to my house and Sparklight does not support IPv6.

In my opinion, that should be a legal issue.

Nowadays, you shouldn't be allowed to advertise "internet access" if ipv6 isn't supported.

Ipv6 is the current protocol. And some sites don't have ipv4. (Amazon charging an extra for ipv4 is another sign that ipv4 should be a protocol for particular use cases, not for "the internet")

And it should be the same for software and connected hardware. No ipv6 ? That's not a product that works over the internet.

On a personal side, what I host is only working on ipv6, as my ISP has stable ipv6 but not ipv4, and for the convenience of configuration.

And even cheapo internet plans on mobile and landline support ipv6 by default nowadays. (The government pushed for it)

> Ipv6 is the current protocol

It's A protocol

> And some sites don't have ipv4

Yet there are far more sites that don't have ipv6 access.

What's the ipv6 address for hacker news?

> On a personal side, what I host is only working on ipv6, as my ISP has stable ipv6 but not ipv4, and for the convenience of configuration.

For me it's the other way around - I disable IPv6 on all my servers and only host anything on IPv4. I know it's frowned upon in networking circles, but IPv4 "just works" for me, and I want to reduce attack scope and maintenance burden (I had some problems with IPv6 messing things up, or my ipv6 firewall misconfigurations).

Exacly that! I do the same. Accessing of internal resources hosted on LAN? No problem, just make overlay VPN network.

Need to host something via HTTP? mod_proxy to the rescue.

IPv6 is junk protocol, overengineered. I hope IPv6 will be used for all those internet consumers and IPv4 will stay where its place to be, interesting R&D projects :)

The sad part about all this is that Ipv6 was already standardized in the 90s and supported by most network interfaces in the early 2000s.

>Ipv6 makes a server as a middlemen for some applications (Ipv4 only) completely obsolete.

Not really, proxying also provides user privacy, and enables DDoS protection (this is especially an issue in the video game world).

Absolutely, a very good point indeed. But I meant more specific applications like end-to-end messaging. Surely 'obsolete' is a bit of an overstatement. At the end it depends how one looks at and want things to be done.

Reply on news.ycombinator.com