hairyplanter's comments

I use tayga.

This does not contradict what I said. Every Debian release is (and will be) an LTS release.

I have fully implemented IPv6 in my home network.

I have even implemented an IPv6-Only network. It fully works, including accessing IPv4 only websites like github.com via DNS64 and NAT64 at my router.

The only practically useful thing about my IPv6 enabled network is that I can run globally routable services on my lan, without NAT port mapping. Of course, only if the client is also IPv6.

Other than this one use case, IPv6 does nothing for me.

It doesn't work from most hotels, nor from my work lan, nor many other places because most "managed" networks are IPv4 only. It works better at Cafes because they are "unmanaged" and IPv6 is enabled by the most common ISPs, like ATT and Comcast and their provided routers.

Based on this experience, I think IPv6 is less valuable than us HN audience thinks it is. Private networks, NAT, Carrier Grade NAT are good enough, and internet really doesn't care about being completely peer-to-peer.

I think the adoption rate reflects this--it's a linear growth curve over the last 25 years. It should have been exponential.

I think cost of IPv4 reflects this--it is now below the peak, and has leveled off.

As surprising as it seems, IPv4 exhaustion has not been a serious problem. Internet marches on. IPv6 is still a solution looking for a problem, and IPv4 exhaustion wasn't one of them.

Debian doesn't have LTS and non-LTS.

Debian has Stable. That's it.

This is interesting. If you only had IPv4, you’d block a ddos by filtering ip ranges. If some of those ranges were CGNat, you’d be cutting access to possibly millions of innocent addresses or even entire countries.

As IPv4 addresses become more scarce and more people get on IPv6, so more people end up behind IPv4 gateways to reach your IPv4 only service, the greater the chance that they’d be cut off for someone else’s bad behavior.

“640KB ought to be enough for anyone”

I wrote one: https://news.ycombinator.com/item?id=40603777

EUI-64 uses the NIC MAC to derive an address. Linux by default uses it, and it's fine for servers.

There are other more privacy sensitive ways to generate obfuscated addresses.

But none of these matter, because RFC 4941 says a new random address is used for each request. If you surf the web on a server with a static address, it'll create hundreds of temporary, random addresses to make requests from. The server is reachable by the static address, but outgoing requests come from a random address.

I know, weird, right? Concept 2: IPv6 uses multiple addresses.

Yes, if you replace the NIC, the address will change. Different OS won't, if it uses EUI-64.

Step 2 answer: To set up ULA, just assign ULA you want to your LAN interface. Default radvd.conf will now advertise that ULA prefix to the lan, and your hosts will auto configure. Are they static? Yes, in the sense that they don't change. Are they dynamic? Yes in the sense that you didn't have to configure the host manually, it just did slaac.

Once a host picks a ULA (prefix + id), you can get that from the host. It's the same as getting a mac address of a machine, but instead you get the ULA, and add it to your firewall rules.

Step 3 answer: I run unbounded on the router.

RA message can specify a DNS server.

Mine specifies the router's ULA, which is effectively static, and it runs unbounded.

I haven’t seen one. Openwrt seems to do the right thing out of the box, but that’s not that helpful in setting up your own and learning on the way.

Maybe I will write one this weekend and make a hn post.

My experience is the opposite!

ULA is still the right solution here.

ULA would let you maintain your internal lan with custom subnets and DNS even if you switch carriers or use multiple carriers. No need to update your internal DNS servers for ULA.

If you're running a server on your dynamic residential service, you must be using dyndns for ipv4. So do the same with ipv6.

Residential random prefixes is the nature of residential networks, as ISPs don't want to preserve state. With a business grade service, you'd get a static prefix, much like static ipv4. Then the only time you need to update anything is when you switch your ISP and need to update global DNS addresses for your servers.

As browsers don't like link local addresses in the address bar, ULA is still better.

> or just bite the bullet and use ULA.

This is the proper ipv6 solution.

With ipv6, one ethernet interface is _supposed_ to have multiple addresses. You wouldn't want your lan routing to stop working when your ISP goes down, right? So configure your internal DNS with ULA (which should be stable for each machine for a given prefix, even with SLAAC) and be done with it, much like internal DNS using private addresses in ipv4.

For externally visible servers, do the normal thing, that is, those servers dynamically update global dns, much the same way with ipv4 dyndns.

Another learning curve for ipv6 is that people get frustrated by dynamic prefixes, but it's the nature of residential networks: the ISPs want a stateless solution, so customers get a dynamic prefix. Maintaining the same prefix across power outages needs a stateful solution, so only business plans offer them for an extra fee, much like static ipv4 addresses.

And we've had dyndns for decades now for exactly that use case. Just keep using that.

I was thinking “hey, I bet it would be pretty easy to write something like this in Go”. And of course it’s written in Go!

In your playground example, if you print the capacity and the length before and after “re-extension”, it becomes clear what happened. In fact, accessing item 5 after reduction gives a size panic, where as accessing item 6 after re-extension gives you a capacity panic.

Understanding rsc’s “Go Slices” blog is very helpful here. Coming from Java or something, this exposure of underlying storage could be jarring, but coming from C, Go slices are basically built in fat arrays, and this behavior doesn’t surprise me. Maybe it was a design mistake to expose so much of the underlying machinery. Ymmv.