IPv6 Watch • Hacker News Board

Re: IPv6 Watch

#101

Post by citrin_ru » Thu, Jul 29, 2021, 10:29 AM UTC

adev_ wrote: post #99

citrin_ru wrote: post #68

Earlier quoted context omitted.

You still need DHCP for more than one reason: 1. Prefix delegation 2. DDNS (DHCP server can register a client IP in DNS) I've used SLAAC in my home LAN when used IPv6 ISP. Now I use IPv4-only ISP (in my area no ISP supports IPv6) and don't miss SLAAC at all. Over the years I've used DHCP in many smallish LANs (<=100 hosts) and never had any problems with it.

> You still need DHCP for more than one reason: 1) You generally do not need prefix delegation in v6: you use IPv6 like it has been designed too: routable address everywhere, /64 per default and prefix over it. 2) SLAAC is stateless and deterministic: One MAC address will always gives you the same IP. That makes DDNS mostly useless. But even if you really want to do it, it is also possible with SLAAC.

1) Precisely because you are not supposed to use NAT with IPv6 you need prefix delegation: CPE (home router) in addition to an external address (can be obtained via SLAAC) needs a network prefix (/64 or more) which it can use for LAN segment(s). DHCPv6 PD is also used in 464XLAT.

2) Address with SLAAC is deterministic but you need to know MAC address for each device to generate DNS zone. In home LAN I don't want to maintain a database of MAC address for all devices (with internet connected everything there are quite a few of them) and also at home I trust my devices not to spoof hostname in DHCP request so DHCP based DDNS works fine for me.

Re: IPv6 Watch

#102

Post by hawkice » Thu, Jul 29, 2021, 1:39 PM UTC

ATsch wrote: post #63

hawkice wrote: post #58

Just to check, I can make my website available only through IPv6 and this won't cause any issues?

That is not advisable right now as you'll cut off a lot of users. Some providers like unglei.ch do offer an IPv4->IPv6 proxy if you absolutely don't want to deal with IPv4 though.

Sort of seems like it doesn't matter who uses ipv6 on their servers, then. If ipv4 is mandatory, who cares that you COULD connect another way? Isn't the first step getting all clients able to use it?

Re: IPv6 Watch

#103

Post by remram » Thu, Jul 29, 2021, 6:30 PM UTC

junon wrote: post #96

remram wrote: post #94

Earlier quoted context omitted.

If you can reach the Steam website to buy a game and then you can't install it, because the site has IPv6 but the app doesn't, it is much worse .

Why does that make a difference? You can have both.

We should have both, that's the point, to which you replied that "the site's intent is to show the general population's ability to organically reach those sites". I disagree with you, for many of those apps having only the website's status in the dashboard is insufficient.

Re: IPv6 Watch

#104

Post by Dagger2 » Thu, Jul 29, 2021, 6:34 PM UTC

tibbon wrote: post #88

I don’t think our site supports IPv6 yet fully. If I were to go to my CTO tomorrow and try to pitch them that this is a priority, what would I tell them? How do I justify this work? Marginally cheaper addresses don’t impact our scale compared to the work cost involved. We are big enough to be mentioned front page NYT at least once a month, but this just doesn’t seem to matter (yet) for us

There are latency benefits, which translate into higher user engagement metrics. If your site sells things or has advertising, that means you get more money.

See https://pc.nanog.org/static/published/meetings/NANOG76/1991/... / https://www.youtube.com/watch?v=76XbdedSrww for a talk about that.

It shouldn't be much extra work if you roll it into your other admin tasks. Any time you're turning v4 up, turn v6 up too and you'll get there easily enough.

Re: IPv6 Watch

#105

Post by lovecg » Thu, Jul 29, 2021, 9:25 PM UTC

fulafel wrote: post #100

lovecg wrote: post #36

Earlier quoted context omitted.

I’m mostly still annoyed about the colon. Come on, ip:port is a pretty widely used convention people! The number of parsing bugs I had to fix with the migration…

On the plus side the schedule was reasonable, you had time since the 1990s :)

The flip side is job security so it’s not all bad :)

Re: IPv6 Watch

#106

Post by Dagger2 » Fri, Jul 30, 2021, 8:14 AM UTC

lovecg wrote: post #36

bejelentkezni wrote: post #12

Earlier quoted context omitted.

If I recall correctly, ipv6 addresses beginning with 0::0:ffff are mapped 1-to-1 with ipv4 addresses.

I’m mostly still annoyed about the colon. Come on, ip:port is a pretty widely used convention people! The number of parsing bugs I had to fix with the migration…

It is today, but what about at the time it was picked? Software from that era (e.g. telnet) take their hostname/service arguments as two strings (e.g. `telnet 127.1 ssh`). I believe ip:port comes from URLs, the RFC for which was published at the end of 1994, which is about the same time that v6 was being developed. So it's not clear that the fault isn't on the URL side, or on the side of software using URL conventions when they're not using URLs.

Note that staying with "." wasn't an option, due to ambiguity with DNS. (Consider something like "2001.db8.3.4.5.6.7.be": is that an IP or a hostname under .be?)

Re: IPv6 Watch

#107

Post by fulafel » Fri, Jul 30, 2021, 8:51 AM UTC

maccolgan wrote: post #84

TekMol wrote: post #23

I will start thinking about supporting IPv6 when Docker supports it out of the box. Hopefully, then I can test an individual application by running it in a container with "docker run -p [::1]:80:80 ...". I don't want to go down the rabbit hole of fiddling with the docker demon and setting up a custom network.

It's not even complicated at this point, just delegate an prefix in daemon.json and it'll all work automatically, even better if you use compose.

The problem with Docker is that assumptions of NAT and proxies are built-in quite deeply into the v4 networking functionality and defaults. With v4 it just exposes NATed rfc1918 space subnets to containers with a hardcoded prefix that's by default the same for all Docker installations in the world.

The sensible way to use it in the ipv6 world would be to give Docker its own globally routable prefix(es) acquired via eg dhcpv6 prefix delegation. The current manual prefix configuration is not how things should work in v6.