Hacker News Reader

Comment by TekMol | Hacker News Reader

As a user, I have IPv6 disabled at my router. It is just easier for me to see xxx.xxx.xxx.xxx style IPs everywhere and avoid the cognitive load of IPv6.

As a tech entrepreneur, I run multiple popular websites that have hundreds of thousands of users. I get emails from users daily. With congratulations, feature requests etc. So far, nobody ever requested IPv6 support.

I have no idea what would happen if I enable IPv6 on my servers. Probably some desaster would strike because some of the code expects xxx.xxx.xxx.xxx style IPs.

What would be the steps to test this? Run the application locally in a Docker container and somehow make the requests to the container go over IPv6?

View on HN

If you enable IPv6, and test it yourself (you can use an IPv6 tunnel if your ISP does not support it), then you should be able to quickly go over the main features of your site and see if you have any issues (IP logging, for example).

It would be rather unusual to run a web stack that assumes strictly IPv4. Maybe if you have an SQL field that logs IPs, and a developer was very clever and optimized for IPv4, but that's pretty rare.

I am a strong advocate of IPv6 and early adopter, but would never bother emailing a website about it. Even GitHub. For a long time, AWS didn't have any IPv6 support (I'm sure it's part of their business plan too, to charge extra for IPv4 eventually).

As a hosting provider, the main benefit of IPv6 is that I can have unique IP addresses for my users. Nowadays, most people on mobile and more and more ISPs use a very small IP pool (CG-NAT), not to mention offices behind NAT (ignoring very large offices who use proxies).

Well, it is not like I do regression testing by manually trying "the main features" of my applications. I have many hundreds of automated tests.

But since my dev environment runs in Docker, how would I test IPv6? I did some googling now and it seems that would not be an easy feat.

give it a v6 address in the same way you give it a v4 address?

You mean something like this:

docker run -p 127.0.0.1:80:80 ...

But with an IPv6 address? Which address would I use?

If I recall correctly, you can do "docker run -p [::1]:80:80 .." (::1 is the equivalent to 127.0.0.1).

Although I don't know at what point that will test your application. I guess it will at least make sure that it can handle IPs such as "::1".

    docker run -p [::1]:80:80 ..

And then how do I send a request to the container? I tried like this:

    wget 'http://[::1]:80'

But that gives me "connection refused".

that would suggest your app isn't listening on the v6 address

so you are already testing it :)

I don't think so.

I get the same result when I run "ncat -6 -lp 80" inside the container and try to wget from the outside.

When I do the wget inside the container, I get "Connecting to [::1]:80... failed: Cannot assign requested address.".

As I said, reading around the net about "docker ipv6", it seems Docker is not IPv6 ready out of the box.

That is correct - please first enable ipv6 and assign it a subnet in your /etc/docker/daemon.json, then restart the service. Details at: https://docs.docker.com/config/daemon/ipv6/

I used to type ::1:9092 to connect to my Kafka brokers on my laptop. Best shortcut ever.

You can assign a Unique Local Address [1] subnet to Docker. Unique Local Addresses are the IPv6 equivalent of 192.168/16, 10/8, ...

Docker's documentation explains how to assign an IPv6 subnet to Docker: https://docs.docker.com/config/daemon/ipv6/ and https://docs.docker.com/network/bridge/#use-ipv6

You then can lookup a container's IPv6 address using 'docker inspect' and then directly connect to it from your host.

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

    Docker's documentation

Yes, I looked at it and that is what I referred to with "No easy feat".

Start by enabling IPv6 on your docker daemon: https://docs.docker.com/config/daemon/ipv6/

I assume your scenario is that you don't currently use IPv6, so you probably can't assign a subnet of your /48 block of IPv6 range to be routed to your docker host. You can probably use a subnet from a reserved range in that case, for example from: https://en.wikipedia.org/wiki/Unique_local_address

With that new subnet set up, you would at least be able to test the services running inside containers from that host itself.

In my own experience I never encountered services that don't work with IPv6 at all, but as others mentioned the most common issues are with truncated addresses in a db column designed for IPv4 or log parsers that refuse to match on IPv6. Worst case I found was a log based rate limiter that ignored IPv6 addresses and therefore let all requests using that stack pass.

Abuse rate limiting often relies on the scarcity of IPv4 addresses.

If, for example, you limit a user to one concurrently used account per IP (which some gaming sites do to discourage cheating/griefing by one person playing multiple players at the same time), this breaks.

This can also be revenue relevant if e.g. the ability to have multiple accounts per IP is a paid feature.

Out of curiosity - did you get any users feature-requesting HTTP/2 or HTTP/3? SameSite cookie attributes? jquery library version upgrade? Anything low-level like that...

They would "request" low level things if something breaks because of those. That certainly happened in the past. But it is very rare. So rare that no example comes to mind right now.

You don't have to enable v6 internally, you can just put v6 addresses on your public endpoints. Create a little testing environment and access it exclusively via v6 to test for bugs.

> So far, nobody ever requested IPv6 support

I have actually put in feature requests for v6 support before (probably not your stuff, since I have no idea what you work on).

You don't have to use really long IPv6 addresses. If you get a /48, you can leave all the rest of the bits zeroed out, and they'll be shown as "::" in the notation; then your whole address is just a triplet like X:Y:Z::, where each individual X might be between 1 and 4 characters long.

If you run your own ASN, you'll probably get a /32 IPv6, then the shortest possible address is even shorter than with a /24 IPv4:

xxxx:xxxx::

is shorter than

xxx.xxx.xxx.x

Of course, for privacy, you're supposed to get a randomly-generated 64bits, but you can disable that setting in your favourite address, and use static addressing.

> and avoid the cognitive load of IPv6

That’s the same reason i gave up and disabled ipv6… i think i might be too old to wrap my head around it. Ipv6 seems really complicated to setup compared to ipv4.

It is not complicated. It is using different conventions.

You can say that ZFS/BTRFS are more complicated than XFS/EXT4 + device mapper, but while it may be slightly more complicated, the more important thing is that they are different.

It took me a while for IPv6 to "click". I still don't like a couple of RA/NDP related settings, but it works and is much much easier not to deal with NAT.

> It is not complicated.

Personally I find it a lot more complicated, and not just because it is different. Part of it is inherent complexity, part of it is that it's still evolving as a specification, part of it is ISP's not following best practices, part of it is lacking software support.

I'm trying to keep IPv6 enabled. But every few months I hit some issue where IPv6 is the reason stuff stops working or I can't get something to work, and it's just oh-so-tempting to switch off IPv6.

For example:

"You will find that on the LAN host, their default route and gateway point to the Link-Local address of the machine acting as the IPv6 gateway/router. This is entirely normal and expected."

Reply on news.ycombinator.com