Hacker News Reader

Comment by teddyh | Hacker News Reader

What is the rational reason, if any, for gripes like these? The time to have this discussion would have been in like 1993 or so. Now, IPv6 is what we have, and the standards are what they are, flaws and all.

The only reason I can think of is psychological: People don’t want to learn new things, so they find reasons to dislike the new thing to be able to pretend they don’t need to learn it.

Also, the double-click argument is crap for two reasons: Firstly, it can be fixed by configuring your local software, and secondly, IPv4 addresses also had this so-called problem.

> IPv6 is still in the early stages of adoption

It really, really isn’t. It might look that way to you, in the US, at your home endpoint, but move to the backbone or outside the US and you get a very different picture. ARIN in the US just happened to be the last of the RIRs (except AFRINIC in Africa) to run out of IPv4 addresses, so the US was able to put off switching for longer than most, and the whole of the US is now consequently behind the curve.

View on HN

> What is the rational reason, if any, for gripes like these? The time to have this discussion would have been in like 1993 or so. Now, IPv6 is what we have, and the standards are what they are, flaws and all.

The rational reason is that despite tons of "we have to adopt IPv6 or the world will end", people aren't learning it. Trying to understand the underlying reasons is worthwhile. The shittyness of the representation is one of those reasons.

(I agree with the people who say "making the parsing namespace even more complex won't help anyone" though)

It no longer matters if some people want to learn IPv6 or not. The world at large has adopted IPv6, by necessity. Those who refuse to follow with the times will, sooner or later, be replaced by those who are happy to learn new things. It’s not like the world will suddenly one day decide to give up and go back to IPv4. Adapt or die.

You seem to be confusing the difficulty of "learning" something which is trivially easy with the difficulty of using something that is designed in an obfuscated way that makes it hard to use.

This situation is the latter. That's the argument of the article.

You seem to be confusing the difficulty of "learning" something with the difficulty of "unlearning" something to learn something new.

I don't see any actual argument in the article, just narrow minded rant failing to see farther than it's own nose.

Hardly. IPv6 is straight forward for any network engineer with experience with existing networks. It's IPv4 but you get to design address space to logically suit your infrastructure and needs.

The article is rather against the use of a colon at all, and that is not obfuscation.

Everyone wants to have the larger address space that ipv6 provides. All the other stuff rolled into it and the obvious representation shortfalls etc are very unfortunate.

There isn't a clean way to solve representation of a 128-bit number. It's a big number. It'll be big to represent.

I am curious what other problems you think it has, that don't just come along with the bigger address space?

The realistic perspective here is still essentially the cost one: most people who have IPv4 hardware see little reason to move at all, until they have a problem.

They could have used base 36 and made it 16 characters. That would have made it at least feasible to remember.

I like this idea. A lot. For other readers:

https://en.wikipedia.org/wiki/Base36

I'd also want optional punctuation for formatting, for reading and data entry, just like with phone numbers. Maybe looking like this:

0123-ABCE-4567-FGHI

I'm concerned about privacy implications. Let's say that I'm a dissident somewhere. I'm using VPN services, JonDonym, Tor, etc to help obscure my identity. But then maybe WebRTC or whatever reveals the device IPv6.

I'm sure that it's possible to generate a new IPv6 for each session. But it's yet another pitfall for the unwary. For now, I just disable and firewall.

So you're behind a NAT for ipv4 for so long that you have forgotten that your computer is supposed to have a public IP address.

If you are a dissident or even a citizen concerned about privacy, you'd better be a part of the solution and not the problem as you are now by refusing to deal with ipv6.

What you're describing already exists. RFC 4941 defines a standard method for regularly "rotating" IPv6 addresses on a client machine, which is implemented by most major operating systems.

Rotating IP is nightmare for network admin: http://blog.bimajority.org/2014/09/05/the-network-nightmare-...

> UPDATE (2014-09-06): As Stéphane Bortzmeyer was the first to point out, RFC 7217 addresses all of my issues with “privacy” addresses. Let implementation come soon!

Very cool! Thanks :)

People are learning and using it just fine. Yes, it looks a bit different but that's about it. Everything works just the same except building properly routed networks is a lot easier with IPv6.

So, why not fix these problems? Go through the RFC process, if it doesn't collide with anything, it'll make it into the standard, IPv6.1 or whatever, and eventually things will support it. Sure, it might take ~10 years for all freezers and forgotten L3 switches to support it, but why not start at all?

We can chance these things easier than our visual pattern matching engine. (Not that we can't train it to perform better, but that just means we'll still make more mistakes and will be less efficient than with this small change.)

Fixed width fonts and indentation are good things, the majority of programmers use it for some reason, why not go for sane ergonomics in network related stuff?

> Sure, it might take ~10 years for all freezers and forgotten L3 switches to support it, but why not start at all?

I seriously doubt that any change in notation would be beneficial enough to be worth the 10 years of work, incompatibilities and bugs.

You don’t see people making this kind of fuss about MAC addresses; that’s because people know that they aren’t supposed to memorize them, and we treat them accordingly. That’s the thing about IPv6 - you have to realize that you have to let go of the notion of memorizing IP addresses, just as it would never occur to you to know your MAC address by heart. Use the DNS; eliminating the need to memorize IP addresses is what the DNS is meant for.

MAC addresses are actually worse, some software displays uses colons to separate, and some uses dashes. IPv6 addresses are ungainly, and have two forms (canonical short, and canonical full), but you can usually put either form wherever you need an address, and there's good library support. I guess that's a benefit of a multiple decades adoption; by the time I get to use it, everything works already. :)

> So, why not fix these problems?

They're individual preferences not problems. We can't realistically have a bunch of different notation standards to make everyone happy.

True, so why not make a good notational standard so that everyone is at least not unhappy?

I'm a network engineer and I work with IPv6 often these days. I think it's a good notational standard. I don't care about the difference between dots and colons. That's much more of a programmers fetish type of thing. As a general rule I think network engineers, who actually have to work with this stuff, just want consistency. If IPv8 wants to replace colons with middle finger emojis sure OK. Whatever I don't care. Just let me know. I'll figure it out.

Most IT operations people within corporate networks use ips instead of names. And unix admins only trust ips in their host firewalls. So many things rely on the ip address that people get to know that 10.1.0.0 is headquarters and 10.1.3.0 is marketing and 10.4.0.0 is Seattle .. etc etc.

I'm not saying that is a good thing or not, I'm just saying it IS.

It would be a pain to use ipv6 internally.

> It would be a pain to use ipv6 internally.

So.. Have you ever actually used ipv6?

With ipv6 your organization gets a prefix assigned, usually a /32 or a /48

So you would get assigned a prefix like 2626:32:400::/48

With ipv4 where if you were lucky you had a /16 that had 65,536 addresses - with "simple" /24 subnetting for 256 subnets of 256 hosts each.

With ipv6 you minimally have a /48 that has 65,536 subnets.

So you can just start subnetting things like 2626:32:400:0/64 is headquarters, 2626:32:400:1/64 is marketing. And you never have to worry about running out of address space on each subnet, since each subnet has room for 18,446,744,073,709,551,616 addresses.

And since there is room for 65,536 subnets, you can easily do things like immediately carve that up into blocks of 512 subnets for every geographical location and project... once. And not end up with "10.1.3.0 is marketing, but also 10.1.58.0 because we ran out of room"

So really, if you can type 192.168.x.y, you can type 2626:32:400:x:y.

In fact it's even easier. In the IP address you can embed an identifier for which office/datacenter, which department, which VLAN, etc. This makes it much more powerful and expressive.

I know that some network configurations will still have to use actual IPv6 addresses but for the most part you could save yourself a lot of pain by just using DNS and hostnames.

When I speak to our network guys to get a firewall entry they don't want to hear about names. Their network diagrams don't have names. Using names to them is unnecessary cognitive load.

What would happen if your current ISP got problems and you had to switch to a different ISP with a new range of addresses (assuming you don't have operator independent addresses and not using BGP)?

They'd NAT. And they're probably already NATed, so it would just be a few changes on the outside of the firewall.

Good luck NATing v6

That's already done. If you're big enough that renumbering is a concern, but small enough that you don't have your own assigned prefix, you use unique local addresses (fc00::/7) and NAT them to your providers space. (Which works better than it sounds - because you have enough space to nat one-to-one, the translation mechanism doesn't need to keep state. Simply replace one prefix with another, whack a new checksum in and send it along)

There's nothing about NAT that makes it IPv4 specific. In fact, it implemented in netfilter (Linux)/PF (OpenBSD). For IPv6, there's also NPT (Network Prefix Translation), though I'm not sure how widespread it is.

Now, the fact that you can NAT IPv6, doesn't mean that you should. Specifically, if you NAT your IPv6 prefix because that's what you do with your IPv4 block, then you're doing something wrong.

I would hope that the firewall guys are using a layer of abstraction in their rules rather than just putting the IPs in each rule individually. Network and protocol objects are fantastic, because you can assign names to network resources and then write rules that refer to hosts and networks by human names.

As an added bonus, if a resource changes addresses you just update the object and all of your rules are updated.

Such IT operations people and “unix admins” have chosen not to adopt the new thing slowly when they had the chance, so instead, they will now have the pain of adopting it quickly. This is entirely on them. Having that attitude towards IP addresses is not a practical attitude with IPv6 - you can do it, but it’s impractical. It is the attitude itself, not IPv6, which is the problem. This was going to be a problem whatever notation was used - there are simply too many bits in an address for it to be practical to deal with and memorize lots of raw IP addresses anymore.

The majority of people will use IPv6 transparently through DNS. I'm not sure why typing an address into a browser or even a terminal seems like the more common use case.

Hear, hear.

The fact that IPv6 addresses are so unruly is a blessing in disguise. Use DNS, /etc/hosts, bonjour, .ssh/config, whatever. Use names, stop using addresses directly, even with IPv4.

With IPv4, if DNS isn't working, it is very useful to be able to enter an IP address directly to check if the problem is with DNS or with the network.

(But then again, that is no reason not to adopt IPv6! Some things are going to get harder, but so many, many things are going to get easier that it is easily worth the tradeoff.)

And for those few times, you can still enter an IP directly. :)

For those who like to memorise IP addresses, my favorite ping in ipv4 is 8.8.8.8, but in IPv6 I like using 2600::1. Shorter, and more fun! (2600 as in the Hacker Quarterly/Hope.net or the old 2600 mHz hack, although the netblock is owned by Sprint, but I guess that is à propos..).

Yes, you can. But it is hard to deny that if there is a specific server/host you are trying to access, its address is likely to be a lot harder to memorize than that.

(And like I said, that should not be considered a reason to avoid adopting IPv6. The only thing I currently dislike about IPv6 is that my ISP does not give me a static network address.)

That's odd. What ISP is it? This goes against RFC recommendations (ex: https://tools.ietf.org/html/rfc6177 - assign between /64 to /48)

My ISP (DSL with teksavvy.com in Canada) offers a dynamic-ish /64 with SLAAC, then a static /56 subnet over DHCPv6. I know some people who had issues with their /56 subnet resetting, but that was usually solved by contacting tech support.

Hmm, realized this after posting: my comment on /64 to /48 is rather off-topic, and the reason why the ISP allocates dynamically might be that they are using 6rd [1].

From what little I understand of it, 6rd calculates an IPv6 subnet by using the IPv4 address. So unless your v4 adress is static, your v6 subnet will be dynamic. Some cable providers are using this in Canada (Videotron). I hope they get rid of it soon, because it's really clunky!

[1] https://en.wikipedia.org/wiki/IPv6_rapid_deployment

Seems Google have been able to snag some easy to use IPv6 addresses for their DNS servers as well.

    2001:4860:4860::8888
    2001:4860:4860::8844

Sprint.net has the IPv6 address 2600::, which responds to ping. It's super helpful for testing v6 connectivity, as well as being an awesome reference.

Sadly, it's a lot easier to have my router always always assign my NAS 192.168.0.2 than it is to configure DNS

Make a homelab and setup local DNS. It's not that complicated if you don't want to get fancy. You can also team it up with DHCP using tools like dnsmasq which is lightweight and works on everything from raspberry pis and routers with flashed firmware to a whole computer or VM on a larger host.

You can do it. You should do it. Why haven't you done it yet?

Not saying what I'm doing is right, but giving my NAS a static IP works on any device connected to the network. My router doesn't support manual DNS entries and I don't want to go through the trouble of flashing OpenWRT just to do something.

You can name off tools that make it easier all you want, but how is the average user supposed to know that? When I set up my NAS, I wanted it to be accessible from the same address no matter what. I knew (at the time) about static IPs and manual DNS entries. So I went to my router's configuration and it didn't support manual DNS entries. So I opted for a static IP, and it worked. Sure, it's a kludge and not future proof, but I don't care. That's the problem. The "solutions" only work if you both know about them and care enough to do it the right (instead of the easy) way

Because it is work, and then it will require administration. Which is more work. Computers are smart enough to handle this, why can't everything on a subnet just have (for example) zeroconf?

We have a Macs so I just use zeroconf/Bonjour names. Never had to configure anything.

From personal experience, most home routers today take the computer name and add that to a .local DNS entry only valid for the local network (meaning that .local is a reserved TLD).

/etc/hosts and .ssh/config scale very, very poorly, whereas the raison d'etre of ip6 is that it is there to scale very, very well.

Those are for "home use", for other stuff you use DNS. DNS is what they call "internet scale".

Interestingly, perhaps ironically in this context, is that the original HOSTS.TXT was the "internet scale" solute of the time in that it powered names for the entire network: https://en.m.wikipedia.org/wiki/Hosts_(file)

The majority never see IPs at all, in which case this is a non-issue. This is an issue for network people and developers.

All the alternatives are either unreliable and slow (bonjour/mDNS) or require manual setup prior to use. Given that machines, networks, routes, etc. are all becoming increasingly ephemeral in the end all you end up with is a DNS, .ssh/config, or hosts file with hundreds or thousands of stale entries for things that existed for five minutes. In some environments there are nice systems for naming things and IP address management but these are hard to set up and maintain and aren't feasible in really heterogenous settings.

I guess Martin Fowler was right: there are two hard things in CS, cache invalidation and naming things. This is naming things.

“All the alternatives are either unreliable and slow (bonjour/mDNS)”

I’ll agree with you on that, in certain cases. In my experience, OS X-to-OS X always works seamlessly, but Windows-to-OS X is much more annoying. It works around 70% of the time.

Say the hostname of the Mac on the local network is lorems-mac-mini.local. Then say I want to connect to this Mac over various services from my Windows computer (file sharing via Windows Explorer, vnc via TightVNC, nx via NoMachine, etc.). 70% of the time, providing lorems-mac-mini.local as the hostname works. The other 30% of the time, the same programs which worked just fine with the hostname as lorems-mac-mini.local all of a sudden won’t be able to find it on the network anymore unless the same hostname is entered without the .local part. Then, sometimes, neither solution works and the Windows computer can’t find the Mac at all unless I enter its IP address, which magically works.

Frankly, it became annoying enough that I now just enter the IP addresses of devices on my local network that I want to connect to now instead of their hostnames, since I know it’ll always work.

…in that sense, I guess I have to agree with your overall sentiment.

> This is an issue for network people and developers.

So, the problems mentioned in the post essentially were...

    * ambiguity specifying ports

    * software not recognizing addresses

    * length to type (3-32+7 characters)

Looking past DNS, the first is only really an issue in web browsers, which I would doubt most people will actually use. The second is arguably a software issue, not a format issue. The third genuinely seems marginally debatable. Still, it seems like the amount of code needed to translate from one format to another would be trivial. In the amount of time it took to write the post, someone could probably have just written the code instead. There are tons of plugin mechanisms for stuff (shell, editor, browser, etc...)..

> Given that machines, networks, routes, etc. are all becoming increasingly ephemeral

MPTCP addresses some of these issues.

In theory, a change to the text representation would be significantly easier to deploy than IPv6 itself, because it doesn't require a change to the wire format.

An end user could tweak the text representation for their own tools, while continuing to exchange packets with the rest of the Internet.

>> IPv6 is still in the early stages of adoption > It really, really isn’t. It might look that way to you, in the US, at your home endpoint, but move to the backbone or outside the US and you get a very different picture. ARIN in the US just happened to be the last of the RIRs (except AFRINIC in Africa) to run out of IPv4 addresses, so the US was able to put off switching for longer than most, and the whole of the US is now consequently behind the curve.

The US may have been slow to start, but is probably ahead of the curve now. AT&T (6rd, but still) and Comcast have a large amount of residential users that are IPv6 enabled; T-Mobile, Verizon, AT&T and Sprint all support it on wireless too (subject to apns and access technology).

I suspect it's more about mind share in the IT profession rather than IPv6 support by ISPs, as they started to roll out when all new equipment had IPv6 support by default and a subset of customers were asking for it.

In Europe for example, the IT profession has been bombarded with news on how IPv4 was running out, then it ran out, and then all problems because it ran out. Network courses have been teaching IPv6 for a long time, government has issued mandates to use it (and governments are not known to be fast on those issues...), and IT conferences used to talk about it to the point where it's such old news that it is no longer worth talking about.

If user access to Google via IPv6 is considered a good tool of measurement, then The US actually has the highest rate of IPv6 adoption. https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...

Globally (again using user access to google as measurement) the adoption rate is still less than 10%, One could argue this could be considered still early stages of adoption.

> then The US actually has the highest rate of IPv6 adoption.

actually, according to these statistics, the adoption rate in belgium is much higher: 40.39%

Reply on news.ycombinator.com