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).

> 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).

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

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

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

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.

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.

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)

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.

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.

> 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.

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...

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.

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.

> cut-and-paste repeatedly as needed

Pretty much this, though with IPv4 as I don't trust myself to remember that either.

I find myself increasingly frustrated with tools which force GUI flows or context switches that require me to do that, though. I prefer a 'edit a bunch of flat files in repos, push, magic config engine makes it happen' flow.

It's quicker for me to copy-paste than it is to type even an IPv4.

This, exactly.

I've spent way more time troubleshooting various obscure network problems that ended up being a typo in IP address/port number, than I'd be proud to admit.

Right. When I do "remember" an IPv4 it's usually that I've committed a /24 to long-term through repeated exposure, and then I really just have the 8 bits in short term memory.

You remember the prefixes (e.g. 1234:5:6:7::/48) you care most about and the hexadecimal nature of the address makes them fairly memorable and compact. You can prefix addresses with a-f to hint at usage and even spell words. Unused octets can be omitted thanks to the nature of the ::.

Yes, this is important to remember.

While automatically assigned IPv6 addresses will usually use the full 128 bits (last half is random), manually assigned addresses usually don't. So e.g. one of my servers is 2a00:1234:8::10, which is pretty easy to remember. There's going to be no way around memorizing the first two or three colon sections, which are assigned to you, but the last part is going to be as easy to remember as you make it.

2600::1, owned by sprint, which is the shortest pingable IP address I know, is exactly as long as 1.1.1.1, the shortest possible IPv4 address.

I raise you ...

$ ping 1.1 PING 1.1 (1.0.0.1) 56(84) bytes of data. 64 bytes from 1.0.0.1: icmp_seq=1 ttl=56 time=26.0 ms ...

I raise you ...

    $ ping 0
    PING 0 (127.0.0.1) 56(84) bytes of data.

Note that this may default to 0.0.0.0 instead depending on what you're running, which is technically the correct interpretation. I'm not sure who is doing the shenanigans here.

Touche!

All zeros is self, which is to say generally the same as 127.1.

Neat, I didn't know about this. If we relax the restrictions on being publicly routed, I can raise you

    $ ping ::
    PING ::(::) 56 data bytes
    64 bytes from ::1: icmp_seq=1 ttl=64 time=0.071 ms

though, shorter by one character.

People aren't having trouble remembering because they're not doing it right, they're having trouble because it wasn't designed right. And by "right", I mean designed for the average human to remember.

It's designed to go into DNS, so that computers can handle the remembering. This is the right design for the average human.

It's also designed so that the IPs themselves don't need to be particularly hard to remember. Compare 2001:db8:42:1::5 to 203.0.113.42+192.168.1.5 -- the v6 address is shorter than the pair of addresses you inevitably end up with in v4. If you're one of the tiny percentage of humans that actually do need to remember a v6 address, then pick an address like that rather than something long and hard to remember.

This is exactly how I do it. Not sure why you’re downvoted.

autoconfig, DHCP, DNS, cut & paste, and pen/paper all work fine, depending on the reason you need to move the address.

I doubt there is much discussion because there isn't really a way around it. The world is full of situations (MAC addresses, VIN numbers, software serial numbers, content hashes, UUIDs, etc, etc, etc) where a global address space doesn't fit in Human short term memory.

Computers are pretty good at remembering numbers for us, that would be my first choice.

Non-memorability is an annoying problem for IPv6.

The IP internet seems to depend on some degree of manual configuration, which requires identifying numerical IP addresses.

It's puzzling that the IETF hasn't recommended a human-memorable, word-based scheme for prefixes, something like what3words for IPv6.

Here is one project to represent them as haiku: https://gabrielbrady.com/projects/hipku/

We could also use syllabic encoding; for example, using 'bdfghjklmnprstvz' * 'aeio', we could encode 12 octet prefix

60:51:80:66:55:83:66:dc:56:fb:14:d1 as

ka-dediba-keneji-bokere-sejizi-sehohe

Which is somewhat easier to read and retype.

> Here is one project to represent them as haiku: https://gabrielbrady.com/projects/hipku/

Cute idea, although somehow in my opinion the IPv4 haikus tend to sound better than those representing IPv6 addresses.

Wow, like mnemonic encoder. Imma try something real quick...

It’s really not that bad. You remember your prefix and then manually assign in your /64. The address space is so sparse the first part is easy to remember - so really we are talking about 24-32 bits hexadecimal here.

The only hard thing to remember in ipv6 is the prefix that my ISP gives me, but it's mostly irrelevant. My DHCP6 gives out a range of ::0550:0000 to ::0550:ffff, I chose 0550 randomly, and I use a dynamic DNS updater to keep my hostnames up to date.

It's only marginally harder than ipv4.

The real problem is that they're just such big addresses.

We could totally just rerepresent v6 addresses as 4 sets of 4 octets, but that's basically remembering 4 ipv4 addresses.

The hex approach used today is a pretty good compromise, but people haven't really regularly operated with hexadecimal digits as a daily representation for a couple decades. Between hex and a direct binary representation there aren't really a lot of standard representations. Even say 16 ASCII characters won't work since there are quite a few whitespace and nondisplayable characters in the set.

I was curious if anyone had tried encoding them in e.g. base64 and found this: https://tools.ietf.org/html/rfc1924

base85. Still 20 digits...Not much easier to remember. They are truly huge.

As bad of an idea as memorizing addresses is, they're only so big if you use all of the bits. If you manually assign addresses, most of the bits will be zeroes or low numbers, which means you can just collapse them.

E.g. if you had a /32 and two dns servers, the second one might be reachable at 2400:123:d::2, which is exactly as long as say 143.239.132.2. And because you only get at most one octet to play with on v4, you can't easily make your addresses more memorable either.

When I work with v6 addresses, often only the last two bytes change from one address to the next, so I copy&paste the common prefix, and just work on the last two bytes.

If that's not the case, always copy&paste.

No one has yet mentioned but some people have built special keypads for inputting hexadecimal addresses. I remember seeing a patent a number of years ago for an "IPv6 keyboard". Not sure if he ever tried to mass produce it. A web search shows one website is selling something called an "IPv6 Buddy". Perhaps it is the same person, but I doubt it.

Absolutely agree! Also I think many of us have so many systems that either can't / won't support IPV6 that it is just way too much hassle vs private addreses & a NAT gateway!

In Xfce there is a clip-manager plugin. So, when dealing with dozens of IPv6, all are magically on this easy to get to panel. And I only focus on the last four chairs. I never type them.

We autoscale our stuff. I need a /28 for one kubernetes cluster of 1-300 nodes and 1-4 ils for ingress.

The ipv4 shortige definitely had a huge impact on those designs.

Get a utility for cut/paste that allows multiple choices? For windows, they are called "clipboard managers".

> What do people do with v6?

I write them down.

We use DNS... Its been around about as long as IPv4

This isn't a great solution. Every IT person knows "its always DNS," and you have to set up IP stuff to bring up DNS in general. DNS is brittle and doesn't deal well with multiple network domains or debugging if the network is down, and those are precisely the situations where one finds oneself typing IPs.

I really think the size of the IPs is a major cause of slow V6 uptake.

Size in which regard though? They're hexadecimals. If they were numbers or letters (0-9, a-z instead of 0-0, a-f) the number of bits would be still high, but with lower amount of characters. You might loose something beautiful as autoconfig but who needs a /64 for one device anyway? Plus, it does not work well for anonymity. You might as well randomize it.

DNS doesn’t help when you’re having to manually enter an IP into a config, which is what the OP implied.

My experience is contrary:

Put the “interesting” addresses in DNS immediately upon acquiring/configuring them.

When you need a literal - lookup DNS name, copy-paste from one terminal into the other. I do this for both Ipv4 and Ipv6 addresses.

Turns out the human brain sometimes does also have difficulty figuring the differences between 192.168.129.1 and 192.186.130.1 when one of them is mistyped....

You still need to put that ip address manually into a few places to have that setup (dns, static ip settings, possibly router settings, etc.)

If an application supports IPv6, it should support DNS. If it doesn’t support DNS, that feels like a bug.

The only configuration item that should require manual entry of an IPv6 address is a NIC. Even that has other mechanisms. Everything else should support DNS.

Edit: doh, the second place is the dns zone file

Again, to me the OP is talking explicitly about places where you have to enter it in. What are the other mechanisms? Let’s forget about situations where you can copy/paste or use DHCP.

My answer would be to use my phone to take a photo of the address (if not easily accessible via web browser), and then use that to manually enter it. Probably not a situation where you can rely on memory, unfortunately.

Outside of the NIC and DNS, where else do you need to enter in an IP literal?

Firewalls, for example. We have huge files containing risk levels for various IP addresses. Most of it is automated, but sometimes we have to tweak something manually. These aren't IP addresses that we control, so DNS isn't helpful. Often we're dealing with ranges as well, for which DNS is also unhelpful.

Technically, you could claim you're authoritative, just hope the assignments don't leak ;-)

Connecting to things on your local network

Dns resolver Internal IPs

So you gotta log into your registrar and copy paste your IPv6 address and wait god knows how long for it to propagate...

DNS doesn't actually "propagate", all you're waiting for is the caches to expire, and you can control that by keeping a low TTL on the record.

Or you can host your own dns. Or you can get a decent dns host. It doesn’t need to be your domain registrar, much like you don’t need your website or email hosted with your domain registrar.

Yeah, but what about ephemeral DNS for your LAN? Zeroconf and NetBIOS work but can be harder to set up than IPv4 (especially if your install media doesn't have it set up by default).