Hacker News Reader

Comment by lxgr | Hacker News Reader

Much of this boils down to "IPv6 sucks because it's so different from IPv4", which has never been a very convincing criticism to me.

The conclusion of "It's hard to memorize or type plain IPv6 addresses" has always been "I guess I need (m)DNS" for me, not "wow, IPv6 is bad". And some years later, I'm extremely happy I don't have to memorize even local IPv4 addresses anymore – mDNS together with a proxying/caching local router works that well.

Regarding the "unnecessary" changes (i.e. everything besides just adding 96 more bits to every address):

When implementing a new IP protocol version literally touches every single device on the network (at some point), why not use that opportunity to revisit some of the historically grown cruft?

View on HN

For me IPv6 sucks because it doesn't really solve my problems in a better way, and instead seemingly introduces a lot more fragility and complexity.

I still have to mess with the firewall to open ports, not much different from doing IPv4 NAT as my router software (pfSense) automatically creates firewall rules tracking the port mapping. Except it is worse, because my firewall software don't track IPv6 changes so breaks whenever the device gets a new IP (say new prefix).

When exposing services to the internet it's even more PITA since each device needs a DynDNS client configured, whereas with IPv4 just the router needs one for my single public IP.

IPv6 on the LAN is quite a pita due to the massive "random" prefix, gone are the days of easy addresses like 10.0.0.12. Yeah I guess I could just use the local address space but what does that really bring over the IPv4 that I know?

And then there's the software that just doesn't follow the times. My router just doesn't handle getting a new prefix. Yeah OK the initial IPv6 wet dream was for an eternal prefix. But clearly that's been unrealistic for quite some time, and sadly not all software has caught up.

I will admit that some of it is probably down to me learning more. But I struggle to find the motivation. There's no "killer app", just a lot of pain so far.

When exposing services to the internet it's even more PITA since each device needs a DynDNS client configured, whereas with IPv4 just the router needs one for my single public IP.

Presumably because you configured the forwarding on the router? I mean, that should still be possible, right? Set up a name for the routers IP, and have it forward the connections statically.

IPv6 on the LAN is quite a pita due to the massive "random" prefix, gone are the days of easy addresses like 10.0.0.12.

Or just use the hostname? Sometime a couple of years ago, local names just started working, sort of on their own. My Synology is nas.local, Linux boxes are reachable using their configured hostname, even my elderly printer shows up as vigor2.local.

> Set up a name for the routers IP, and have it forward the connections statically.

If you mean NAT, then what does that buy me over what I got? If you don't mean NAT then how would that work?

> Or just use the hostname?

Right, but that requires the DNS to register the host names, and for it to respond. Or since you mention .local I guess you mean mDNS, which requires a service to run on each device and seems to be hit and miss at least for me (I just tried, several of my devices do not respond).

If you mean NAT, then what does that buy me over what I got? If you don't mean NAT then how would that work?

Nothing. But you can just keep doing what you are doing now, even with IPv6. That's what I meant.

I just tried, several of my devices do not respond

Ok. Like I said, it Just Works for me.

> But you can just keep doing what you are doing now, even with IPv6.

Do you mean keep using IPv4 or use NAT with IPv6? If the former then well, so much for that IPv6 future. If you mean the latter, the whole point of IPv6 was death to NAT no?

The whole point of IPv6 was we ran out of IPv4. NAT was a kludge necessary because "we" didn't act fast enough on that fact.

> Or just use the hostname? Sometime a couple of years ago, local names just started working, sort of on their own.

That highly depends on what router you have. For mine, the actual suffix is Speedport_W_123V_2_34_000, which is complex and/or invalid enough that a lot of software refuses to resolve it.

> each device needs a DynDNS client configured

My home router does something even better out of the box: Every device that's hostname.local or hostname.my.router locally is also globally resolvable through hostname.myusername.routervendor.com.

This is basically DnyDNS at the router level, rather than the device level (which has many downsides as you describe), and it's been a game changer for my IPv6 home use.

pfsense (the router magicalhippo is using) also supports this. Its under Services > DHCP Server (and/or DHCPv6 Server) > Dynamic DNS

That seems to require a RFC 2136 compatible DNS server on the other end, yes? So my regular dyndns ain't gonna cut it I assume.

How did we end up in this world where regular DNS updates aren't considered to be "regular dyndns" :/

Not my area, but what I can say is that the DNS provider I've used for ages (Domeneshop) does not support RFC 2136.

So I guess I either have to switch (to who?) or I set up some alias and run my own bind (another service to admin, yay). Or am I missing something?

I run my own copy of bind, and use https://dns.he.net as a slave pulling the zones from it. As a result I can actually use all DNS features.

I find it super frustrating that most dynamic DNS providers use their own custom API rather than just using the update mechanism that's in the protocol itself. That said, if they support v6 then you can probably use them by installing their update client on each machine that you want a hostname for. It just won't integrate with pfsense.

it has nothing to do with IPv6 specifically but i mostly have a haproxy instance on every "edge" for public and private services. I also do TLS there. However, everything gets its own records in DNS too. I use dynamic updates from my DHCP server to a bind9 instance for that. This all works very well for IPv4 and IPv6 simultaneously... I admit its more complicated to set all of this up properly but maybe its just the way it is ;)

Interesting approach, thanks.

There is a huge hole in functionality of IPv6 in most common networking equipment. I have a Mikrotik and the IPv6 functionality is signifiantly worse than the IPv4 one:

- There's no caching DNS and I can't set static DNS entries for IPv6

- There's no way to use DHCPv6 to give out addresses.

- Because of lack of DHCPv6, there's not way to give out static addresses to devices on LAN and manage them centrally.

- Because of lack of DHCPv6 and static addressing, it's really annoying to configure firewall to allow outside access to services on LAN devices (on IPv4 you either have static entries or NAT-PMP).

- There's no fasttrack functionality so IPv6 traffic will max out CPU and prevent me from fully using my Gbit fiber line.

- There's no UI way of announcing DNS to clients via DHCPv6 - you can set some option amanually but it's far from setting a nice UI entry like for DNS.

And yes, those are all holes in my routers Firmware, but it's been YEARS and they're still lacking. Other SOHO routers aren't faring any better, I haven't seen these features configurable on any of them.

I have a LAN which has a PiHole and a Synology NAS at home + some entertainment devices. Configuring IPv6 to allow access to same services as IPv4 from WAN via public DNS has been practically impossible, undocumented and huge pain. For pretty much no gain and loss of bandwidth.

That sounds more like a Mikrotik problem than an IPv6 problem. OpenWRT does most or all of that, for instance.

I would never recommend <Foo>WRT to anyone.

It's a shiny toy to play with. However, it has so many weird bugs that never get addressed that it's just not worth the grief.

Why can't the wired ping the wireless but the wireless can ping the wired? Why can I connect every device except my Samsung phone? Why is my throughput so much worse than the manufacturer firmware? Why are the LED's doing weird things that correspond to nothing useful?

I've never even tried IPv6 on a <Foo>WRT because it's handling of basic IPv4 stuff is so dreadful.

(Please don't read this is as dig on the <Foo>WRT developers--they're doing their best. However, the sheer variety of platforms, the lack of documentation, and the small number of developers simply creates an impossible situation.)

I can't say I've had those problems, other than throughput being worse (which is a result of proprietary acceleration chips with no published specs to write OSS drivers with). v6 works great on OpenWRT for me -- but then again, so does v4.

I addressed that - OpenWRT is a 3rd party firmware you need to reflash on your router (if you're lucky). It also doesn't install on an equipment I need.

I've never seen this features out of the box on SOHO equipment like ASUS routers, TP-Links, FritzBoxes, Apple routers and other equipment that actually ends up in peoples homes. And again, we're YEARS after the standard and there still doesn't seem to be feature parity between the two stadards on even basic home equipment.

One of my routers came with OpenWRT, so it's certainly possible to get routers that use it as 1st party firmware.

As for routers with random vendor firmware, I'm not familiar enough with all of the vendors out there to give an authoritative answer but I've seen or helped with plenty of routers that support many of the things on your list.

My off-the-shelf home router (sub-100€, very popular brand in Germany) supports all of that. I don't doubt that this will vary across vendors, but it definitely does exist.

> whenever the device gets a new IP (say new prefix)

Prefixes shouldn't change, that's the whole point. And you can use fixed addresses for IPv6 just as you had for IPv4.

> each device needs a DynDNS client configured, whereas with IPv4 just the router needs one for my single public IP.

Sure, but if you're doing that at an industrial size, you should consider buying/renting a fixed IP (range). You don't do production at home now, do you?

> IPv6 on the LAN is quite a pita due to the massive "random" prefix

You probably mean suffix? Anyway, your systems can be configured to either not have that random suffix, and they can also be configured to still reply on their fixed address (the one that's not random). Maybe try using the fe80:: address if your prefix does change.

> Prefixes shouldn't change, that's the whole point.

Well that's not the world I live in. And even if they didn't by default, I might want to change my prefix from a privacy point of view.

> You don't do production at home now, do you?

Not for paying customers, but I have plenty of services that I would like myself, my gf, my buddy etc to be able to access from the internet.

> You probably mean suffix?

No I meant the prefix, see above.

> Prefixes shouldn't change, that's the whole point.

Tell that to my residential ISP!

>Prefixes shouldn't change, that's the whole point.

They shouldn't, but they change all the time. I gave up on Ipv6 in my last house because of this reason: my prefixes were changing every few weeks. In my new household, my ISP doesn't even off IPv6.

You shouldn't get a new prefix - it should be static from your ISP, and your IP shouldn't be changing, so you don't need DynDNS per-client and can just add a static entry to a hosted DNS zone file somewhere that shouldn't change.

You use the word "shouldn't" like ISPs give a rats ass.

No ISP here hands out static prefixes for residential clients

I get a new prefix every 24 hour (around 3am).

This is intentional. In order to make renumbering possible at all, it needs to be done regularly. If the equipment didn’t handle DHCP-PD regularly the code would rot and other devices and people would assume that address prefixes would never change. That, in turn, would cause lots of things to break when prefixes were forced to change (new ISP, merger, change in upstream architecture, etc).

I get that, and personally I've thought the same that it would be better to change it often than not. Similar to Let's Encrypt.

If only the software worked with it, which it doesn't for me.

> Much of this boils down to "IPv6 sucks because it's so different from IPv4"

In fact, "IPv6 sucks because it's not broken in the same ways as IPv4". NAT, for example, was only ever a hack to get around limited address space, and the fact that it 'hid' your internal network was an accidental side effect. People started architecting their networks around that, and now are annoyed that IPv6 isn't broken in the exact same way.

Saying that IPv4 gave you network privacy for free is like claiming that old-school single-line home phones were an advantage over personal cell phones because they gave you some amount of extra privacy 'for free'.

The article makes a lot of points and all of them are pretty weak and stem entirely from ipv4 being the "established" protocol. In every case if you had an ipv6 config that worked and you wanted to switch to the ipv4 way of doing thing the result would be just plain worse.

> The conclusion of "It's hard to memorize or type plain IPv6 addresses" has always been "I guess I need (m)DNS" for me, not "wow, IPv6 is bad".

DHCP servers like dnsmasq can already serve lan hostnames even for ipv4.

This whole thing reminds me python 2 vs python 3.

"IPv4 is great as it is, I don't want to change"

Python tried to add things to the language to entice developers over. The only thing that worked was finally ending python 2 support.

They tried to do the same thing with IPv6, and nobody wanted to move over to it until the warning "We're running out of IPv4 addresses".

Users actually wanted to use IPv6, organizations were somewhat neutral. The ones that were standing in a way of adoption are ISPs.

Also IPv6 was almost entirely unavailable until a few years ago. There's no point in learning how to use ipv6 if your ISP does not support it.

HE.net and SixXS have been providing IPv6 tunnels for at least a decade.

SixXS no longer does and I never was able to use them. For some reason one person assumed that information I provided were fake and I never was able to get an account with them until they ceased their activity.

HE.net works and was relatively nice experience to learn how IPv6 work, although both SixXS and HE you still had the disadvantages of tunneling like low speeds, outages etc.

It's nice to test if your application can work on IPv6, but you still won't get benefits of natively using it.

I’ve been using HE.net for years and I get full speed, equivalent of my IPv4 bandwidth. You may want to look at it again.

I guess it is just my bias against tunnels. BTW: what is your bandwidth?

Their tunnels work surprisingly well! It is only 100 megabits down, 20 up.

Thanks, that's quite good.

Well, change has high costs, that's why. So the benefits need to be big as well. I think the issue for Python 3 is the benefits weren't that large compared to the costs, and for IPv6 it's the same, albeit people know that the cost/benefit ratio changes over time as IPv4 gets more and more overloaded.

> "IPv6 sucks because it's so different from IPv4"

Interestingly, this is the primary reason it hasn't been adopted universally.

And weirdly, it's not even very different to v4. Most parts of v6 work exactly the same as they do in v4. Most other L3 protocols we've used have been far more different than these two are.

Can you recommend any good resources for setting up mDNS? It sounds like you managed to get it working across routers (networks?), which would be quite useful to have documented.

I'm not really using mDNS across networks, but rather just my home router's DNS functionality: Every device requesting an IP via DHCP automatically is made available as clientid.some.privatetld on the local DNS server.

This works for both IPv4 and IPv6.

As far as I remember, OpenWRT's default setup (probably using dnsmasq?) provides something very similar.

Which is better then mdns for practical reasons. Android still doesn't support mdns unfortunately.

Are you sure about that?

It definitely supports at least the "client" side of it, i.e. resolving host names and discovering services (Chromecast is based on this, after all), and it looks like broadcasting services is supported as well: https://developer.android.com/training/connect-devices-wirel...

IPv6 is OK, but end user experience is horrible.

> "It's hard to memorize or type plain IPv6 addresses"

We should create a system to translate IPv6 address to a phrase in English or user language, which is easy to memorize and type. E.g. "hoards of sleepy beefs" is much easier to remember, dictate over phone, or type (maybe even with autocompletion), than raw IPv6 address.

IPv6 is designed for computers. Humans need an adapter.

You can imagine similar arguments against IPv4 back in the day: "I used to only have to know what interface to send stuff to, and now I need this long complicated number?! What the hell is wrong with /etc/hosts?"

That adapter is called DNS

You don't understand - we've had DNS for a couple decades now, but I often have to deal with IP addresses directly still. Even if just to check where a given DNS record points to.

The problem is that an ipv6 address is not something you can pronounce, recognize at a glance, or remember. All of these are unfortunately still things one has to do, despite there being name servers. The (proposed) solution is to have a 1:1 algorithm that translates an ipv6 address into a value that a human can work with.

If I'm troubleshooting an issue on an ipv6 network, and my colleague asks me for the IP of a machine, I have no choice but to either text it to him, or painfully, tediously and error-pronely spell it out.

>"I guess I need (m)DNS"

But I don't want mDNS

Reply on news.ycombinator.com