Hacker News Reader

Comment by clhodapp | Hacker News Reader

Perhaps the impulse is cruel but for me, the fact that humans can't remember IPv6 addresses is a selling point. It forces people into what I believe are better practices (indirection through dns, using tagging in firewalls and load balancers, auto-assigning IPs, copy-pasting addresses in the cases where they're actually needed).

View on HN

> It forces people into ... better practices

I've got no beef with IPv6; it seems pretty great there being enough addresses that everybody gets one.

That said, being unmemorable is not a feature. Doing nothing is an alternative to doing things 'the right way' and people will choose it. The situation will backslide a little bit - with IPv4 people would do things, with IPv6 some people won't. Unless the goal is to configure IPv6 systems for their own sake, this is an unfortunate and unwanted side effect.

Do you know the IP addresses of your servers? You shouldn't know them. That reveals a lack of automation at a pretty low level of your infrastructure.

IP addresses change all the time in cloud environments and container orchestration systems. Even if they didn't change, you get better systems if you pretend they might. It doesn't matter if you use containers or not -- if you assume IP addresses could change at any time, you end up with infrastructure that is tied to your service graph rather than your hardware.

What about when the host is your domains dns server, and you need to ssh to it to fix a broken dns configuration. But because dns is broken the hostname you would use isn’t resolving anymore.

If a public domain, there needs to be NS records pointing at it from the registry, and they need to either have glue records giving the IP and/or at least one ought to be on a domain your name server itself is not the authoritative dns for.

If a private domain and/or the server is only reachable from private IPs, then its IP should be in an asset management system somewhere (it should be if it is public too); be that a full blown orchestration system, if cloud servers or containers, or some form of asset register - even if only a spreadsheet - if it is physical servers in your own data centers.

If properly automated, that asset register should drive configuration deployment - you shouldn't ssh to it to fix a broken dns configuration, you should run your deployment with a fixed config.

I get that this is an idealized setup and that a lot of the time things intervenes and it's quicker and easier to do things manually then and there. Been there, done that, but in the long run it pays to invest the time in then cleaning that up (up to and including wiping clean setups that have been manually updated to verify that the automated setups are correct and complete).

Almost every single web service in existence works or would work fine on a single server. We don't all need the cloud.

We are not going into the cloud for this reason.

We go into the cloud because the cloud provided you infrastructure as a service which is a huge benefit for small and big companies.

dude I'm not setting a DNS to access my NAS or my raspberry pi

Then pick a memorable address, something like <prefix>::3 rather than <prefix>:ec47:87af:c904:98d7:de0b.

If you refuse to pick a memorable address and refuse to use the tool which is designed to let you handle unmemorable addresses, then you don't get to complain about how hard your addresses are to remember.

This. If you look at my domain name (no nasty things, please):

    $ drill AAAA mayeul.net
    ;; ANSWER SECTION:
    mayeul.net. 900 IN AAAA 2a01:cb14:cce:1200::11

This isn't really hard to remember: I have the same prefix on the other computers on that network. Then 2a01:c000::/19 is my ISP's prefix [1]. The only part I picked was the :11, which is similar to the local IPv4 address I use on the same machine (10.12.186.11). I don't know the prefix by heart, but then I also get the v4 one wrong. I can get back the prefix from a DNS query most of the time, though. And I could create dummy subdomains to remember more address prefixes, if ever needed.

If you need an IP address in multiple places on the same host, it would be better to use /etc/hosts anyways, or use a DNS server, as it makes changing configuration way easier.

I've been playing around with the idea of giving each of my services a dedicated IPv6, so that I can seamlessly switch them from one machine to another.

The very nice part is that I get more IP addresses than I will ever need. Probably. Unless I am into nanobots. I could take an IP address and reroute it over a tunnel, or even assign an address block the size of the whole IPv4 internet and make my server tunnel that to the right target. Waste IP addresses ranges just to get a convenient prefix (::f00d:7ea ::f00d:cafe for the teapot & coffee machine, for instance, or ::1:???? for pro stuff and ::6666:??? for personal things. I don't know). There are so many possibilities, I'm barely scratching the surface.

Now, a couple minor complains I have:

- I don't have IPv6 at work

- My ISP doesn't have IPv6-enabled DNS

- My ISP-provided router sometimes reset IPv6 firewall rules, which is annoying.

[1]: https://www.ultratools.com/tools/ipv6InfoResult?ipAddress=2a...

> This isn't really hard to remember:

cmon, how many bits of information are there in your example vs remembering the last three digits of 192.168.1.xxx.

Like, ~4 bits? It's the last two digits in 2a01:cb14:cce:1200::xx.

Compare these two:

  2a01:cb14:cce:1200::xx
  203.0.113.42+192.168.1.xxx

Which is shorter? It's not the pair of v4 addresses.

where does this comparison come from ? currently I only have to know 192.168.1.xxx

It's the full addressing of the host... but you're right, I guess it was a bit of a non-sequitor. The only parts you have to actually know are the xx/xxx, which is roughly the same amount of bits. They could even both be, say, "42", so you're remembering the same thing for both.

If I were not to use a DNS, I would have to know by heart my IPv4 address (32 bits) to SSH on the router, then hop on the right host (32 bits local address). I guess you could shorten that to 32+8 if you were to use a super common prefix, but I tend not to do that to facilitate routing when bridging networks with a VPN, so it is more like +32 or +24 (10.x.x.x instead of 192.168.x.x).

The full address I wrote above is 72 to 80 bits, depending on how you count (if the ::11 counts as 8 or 16). So that's more, but not much. And The common part is always 32 bit more than the common ipv4 part.

An easier alternative to hoping on the router would be to assign a port to each computer behind the NAT. That makes 32bit for the IPv4, and 16 for the port. Contrast 64+16 in my IPv6 case (I actually have a /56, but that's no help for remembering it). 1 computer on the network means that you have to know 66% more bits with IPv6. Bump that to 10, and it's just 16%. This is because there is always a common part, and that common part is two times the length with IPv6, so that makes it a constant offset.

When configuring a network, I typically do not know the prefix by heart, so I make sure to have that written on a paper sheet that I take with me.

Plot twist: I do not know my IPv4 by heart. I actually know the IPv6 one better, as I have a dynamic IPv4 at home. And I intensively use DNS/mdns. IPv6 actually makes it easier to use DNS for local network machines, I think, as I feel it is more worth it to fill the DNS entries with it, in case I want to later open some ports in the firewall for the www to access.

If a computer's host name is "giggidy", then when it requests a DHCP lease, it sends that name to the DHCP server. If your DHCP server is hooked up to a mini DNS server, then the DNS server will resolve "giggidy" or "giggidy.whatever" to the IP it was assigned. This is how dnsmasq works, and a lot of consumer internet routers, too.

The router's IP and a nameserver IP are the only ones you should have to remember in the event of problems, and both of those can be short and simple.

I don't see anything in my network that responds to ping $hostname or ping $hostname.whatever

Why not? I've been running internal DNS for almost 25 years. Setting up BIND, even in 1995, wasn't rocket science. If it's too complex, try dnsmasq.

but I don't want to run anything, just look on my modem's page (and have something simple enough that I won't need to look it up every time)

Yeah, but to set up an AAAA record, you still need the IP address. The usability still leaves something to be desired. At least we should never run out of IPv6 addresses.

If you're setting up a AAAA once, you can deal with the copy paste. If you're updating them a lot, or a lot all at once, you should probably use a dynamic DNS updater.

> At least we should never run out of IPv6 addresses.

This is true in terms of the raw total number of IPv6 addresses.

Everything I've seen discussing them assumes they'll be assigned hierarchically, though, which is a great way to ensure most of them are never used. Block assignments through a hierarchy can chew through any number of addresses no matter how big the space is.

Heirarchical assignment allows route summarisation. Imagine how much TCAM you'd need for unsummarized IPv6.

Yes, you're correct.

But at the same time hierarchical assignment allows organization, including route summarization, it undermines the argument that there are too many addresses to exhaust. Addresses can easily be (in fact, are guaranteed to be) exhausted by the organizational system without ever being in use. The goals are in conflict.

They are being used -- for the purpose of allowing the internet to scale.

But yes, we do need to be careful not to assign blocks that are too large. We're doing a good job of this (see any /8s being assigned?). We're also doing allocations only from 2000::/3, and there are five more completely untouched /3s available, so if we do somehow run out of space in 2000::/3 then we can start over with tighter allocation polices... five times over.

As said by others, you need hierarchy to avoid routing tables becoming excessively large-- that's the real limit.

Since an IPv6 subnet can hold effectively any number of hosts, and it's easier to give bigger chunks of networks, the chances that a given org needs multiple assignments is much lower. In turn we use that real limit (routing table size) more responsibly.

If routing tables can be much bigger in the future, we also have a whole lot more room to grow / allocate it differently. The chunk from which allocation is occurring (2000/3, plus the multicast and link local blocks, etc) is less than 1/4th the space; furthermore, more than half of the space within this is reserved.

https://www.iana.org/assignments/ipv6-unicast-address-assign...

Reply on news.ycombinator.com