Hacker News Reader

Comment by paulgb | Hacker News Reader

Is there an alternative, though? Both Python3 and IPv6 both solve problems that would have been at least as painful to do incrementally, IMHO.

View on HN

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

> […] 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.

> Is there an alternative, though?

Certainly some people didn't like the changes of ND vs ARP and such, but once you're changing the address length, you have to alter the data structure on every bit of networking code, and any transition is going to be a slog.

IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+.

And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere.

But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection.

And of course as long as IPv4 works there's little inherent motivation to go to any kind of IPng.

See "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

In practice, port number is used as part of address, or, VPN, with tagging, are used. We can make convention that top 4 bits of port number are part of the host address. It will increase number of available addresses by up to 16x.

For example, we have router at 1.2.3.4/192.168.0.254, and 15 hosts behind it, then, by convention, we can access 192.168.0.1 from public internet as 1.2.3.4:32848 (port 32767+1+80), host 192.168.0.3 as 1.2.3.4:32849, and so on.

Agreed, while I recognise that both look bad, I'm skeptical as to how bad they actually are. Some comparisons against good examples of these sorts of transitions would be good.

A much simpler and compatible solution would be to assign a single IPv4 address per AS and then use IP options to pass additional address bits to identify the specific host within the AS.

That wouldn't be simple or compatible, but also... v6 basically already has what you're suggesting here, except forget every AS: every single v4 address already has a /48 of v6 space tunnelled to it.

I think that if IPv6 would just be IPv4 with bigger addresses, the rollout would be much easier. Sure, you would still need new hardware, but the basic operations would still be the same as IPv4. Currently, it is far from that.

Are there recommendations that result in IPv6 looking like something more than just IPv4 with bigger addresses? Yes.

Is there anything stopping you from effectively running IPv6 networks the same way as you run IPv4 networks, but with larger address pools? No.

You can do NAT66, you can do DHCPv6, you can run every network as a /120 (IPv6 equivalent of a /24 - 256 addresses) if you want to as well.

You can even (outside of whatever prefix is delegated to you) only use numbers for the host addressing portion if you want to, and not bother with letters.

Just because the recommendations and standards say you SHOULD do things a particular way, it doesn’t mean you MUST.

Sure, I don't have to, but everything in the stack assumes I would run it in the recommended way. I gave up trying to setup my LAN to support IPv6 after I wasted more than 2 hours on convincing my router, and devices behind it, to somehow work with the /128 address I got from my ISP. Should it be technically possible? Yes, definitely. Is there any value for me in spending a lot of time on it? No, there is not, everything is reachable on IPv4 anyway.

This would not be a problem if it would be just bigger IPv4 and there still was NAT, DHCP and everything. But that is not the way you are expected to be doing IPv6...

That's because there are good reasons for running it in the recommended way. If you're going to go out of your way to run it in bad, unpopular ways instead then it's on you to get devices that support what you're trying to do. (For example, squid on Linux would do it just fine, whereas some random consumer WiFi/switch/router combo thing is probably not going to go far outside of its basic functionality.)

Instead of giving up, I'd suggest doing it the normal way -- do DHCPv6-PD to get a routed prefix, use that on the LAN and route to the Internet. On most v6-capable routers that's the default and will happen automatically, and it would be hard to make it easier to roll out than that.

> Sure, I don't have to, but everything in the stack assumes I would run it in the recommended way.

> This would not be a problem if it would be just bigger IPv4 and there still was NAT, DHCP and everything.

Irony, I remember life before DHCP/NAT44 defaults, and having to struggle so much to do it myself. Mind, this was 1997, and IPv6 was already a defined standard, which then never got any traction because NAT44 ended up being “good enough” for most people who didn’t think about what they lost in the process.

> Should it be technically possible? Yes, definitely. Is there any value for me in spending a lot of time on it?

There was a lot of value in me spending a lot of time and effort on setting up DHCP and NAT in my home environment in the 90s. Nobody else I knew thought it was worthwhile though, and thought I was insane.

There was a lot of value in me spending a lot of time and effort on dual stacking my LAN too. I see a parallel here that’s amusing to me :-)

Reply on news.ycombinator.com