Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

IPv6 provided some features people needed (larger addresses), made some changes born from experience (removing IP-level header checksums in favor of packet checksums like those in UDP and TCP, removing fragmentation), and then bundled in a pile of mandatory added complexity (DAD, SLAAC and router advertisements rather than DHCP, initially mandatory IPsec).

If IPv6 had left out the mandatory added complexity, and just focused on the larger addresses and cleanups, it would have been easier to adopt. The other changes could have happened via other standards, rather than bundling them all into "IPv6".

View on HN

> […] and then bundled in a pile of mandatory added complexity (DAD, SLAAC and router advertisements rather than DHCP, initially mandatory IPsec).

SLAAC and RA reduce complexity as you no longer need 'extra' infrastructure (DHCP) to get going: plug in and the router sends the information and you're done.

You also get rid of the complexity of STUN/ICE/etc as you no longer need NAT, so you just need hole punching for SPI firewall (also needed with NAT for port forwarding, so no change there).

Except you still need all that complexity as you need to support IPv4 as well.

There is NAT64 for that https://en.wikipedia.org/wiki/NAT64 Many mobile operators use that, in USA that is Sprint/T-mobile, Bell in Canada. All modern OSes support that pretty well.

Once you add up the real world factor of half-assed implementations and bad business/tech decisions, you end up with DHCP and NAT (or its IPv6 cousin, NPT) to solve issues.

> plug in and the router sends the information and you're done.

If you want the network to come up in a timely fashion, the new system needs to poke the network to get information proactively sent to it as soon as possible, at which point you have about the same level of complexity as poking a DHCP server. (With added bonus "this could happen asynchronously at any time and you never reliably know when your network is actually done being configured".)

If those standards are so valuable, they should have stood on their own, as optional things people could have adopted if they wanted to do things completely differently from IPv4. Meanwhile, people already have DHCP servers, and could have just told those DHCP servers to start giving out IPv6 addresses too.

The reaction I have every time I interact with IPv6 is that it seems incredibly hard to make a system just use the configuration you tell it to use and never ever listen to any configuration from the network.

> If you want the network to come up in a timely fashion, the new system needs to poke the network to get information proactively sent to it as soon as possible, at which point you have about the same level of complexity as poking a DHCP server.

I've had to fight with ip-helper issues and DHCP scopes enough times to not wish to have to deal with it if possible.

I have to configure the router (or the VLAN on a Layer 3 switch) anyway, so a few extra lines for /64 scopes that are sent out via RAs on the same device I have to touch anyway is easier.

> The reaction I have every time I interact with IPv6 is that it seems incredibly hard to make a system just use the configuration you tell it to use and never ever listen to any configuration from the network.

On Debian with interfaces(5):

    auto eth0
    iface eth0 inet6 static
        address 2001:db8:aaa:bbbb:cccc::dead:beef
        netmask 64
        gateway 2001:db8:aaa:bbbb:cccc::1
        accept_ra 0

For Netplan-based stuff, this looks similar:

* https://github.com/canonical/netplan/blob/main/examples/dire...

I recently had to switch ISPs to one that doesn't do IPv6 for FTTH (but their smart offerings are (AFAICT) IPv6-only), but my previous IPv6 did, and activating it for my home network was a couple clicks on my Asus router: all my devices (including a networked printer) picked it up without issue.

You also need to turn off DAD because if the computer comes up without a link, DAD will fail with a timeout and ifup will leave IPv6 unconfigured.

So:

    dad-attempts 0

* https://manpages.debian.org/stable/ifupdown/interfaces.5.en....

The complexity is already paid for since you aren't going to be able, or even want to, wholly rip and replace IPv4 since it gains very little and risks a lot. IPv6 would have been great if it didn't have to work in a brownfield environment. Unfortunately, nobody is going to change because it's conceptually purer to not have those ancillary protocols. This is what the creators of v6 failed to consider: IPv4 was entrenched, it's not 1982 with ARPANET connecting a handful of systems all managed by people who knew each other.

And DHCP does a bunch of stuff that's irritatingly dumb to do with IPv6, to the extent that v6 ended up shoving partial compromises _anyway_ like RDNSS.

It's classic second-system effect and design by people without production experience or skin in the game.

> The complexity is already paid for since you aren't going to be able, or even want to, wholly rip and replace IPv4 since it gains very little and risks a lot.

You should tell that to Microsoft:

* https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...

Veronika McKillop is now President of the UK IPv6 Council:

* https://www.youtube.com/@ukipv6council468/videos

* https://fr.linkedin.com/in/veronika-mckillop-ipv6

> It's classic second-system effect and design by people without production experience or skin in the game.

Begin with "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" for part of the discussion from back in the day (1993):

* https://datatracker.ietf.org/doc/html/rfc1347

The author of that document attended the first IETF meeting in 1986; interview:

> He’s now a Distinguished Engineer at Juniper Networks, author of 14 RFCs, and chair of the MPLS Working Group at IETF.

* https://www.internetsociety.org/blog/2016/02/interview-ross-...

* https://www.linkedin.com/in/ross-callon-b8383695

He co-edited the MPLS architectural document:

* https://datatracker.ietf.org/doc/html/rfc3031

But sure: "without production experience or skin in the game".

Those are the very things that makes IPv6 anti-privacy. We lose all control at the router level. Users are served up like lambs to the privacy slaughter.

Uh... what.

You don't lose control at the router level. v6 isn't anti-privacy and there's no privacy slaughter in it. RAs have no privacy impact and SLAAC makes no meaningful difference.

Indeed. IPv6 is something very different from IPv4.

And due to the large number of significant changes it's still a work in progress as a standard, with important RFCs coming out "as we speak"[1].

[1]: https://packetpushers.net/podcast/ipv6-buzz-134-revisiting-u...

Yes but you've left out the biggest and most disruptive change in v6: all pre-existing v4 addresses and routing are not carried over to it. This alone makes it a conceptually separate network from ipv4.

Reply on news.ycombinator.com