Hacker News Reader

Comment by mgbmtl | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com