Live data from Hacker News

Why IPv6 is so complicated

github.com

331–340 of 519 posts

Re: Why IPv6 is so complicated

#331

Earlier quoted context omitted.

There's nothing stopping you from using memorable ULA prefixes on your LAN [0] and requiring the use of DHCPv6 for addressing so that each host gets a host part that is easy to remember. Hand-selecting your ULA prefix abandons the collision-resistance that you get from using The Technique to generate one, but if that's something you don't care about, then it's something you don't care about. Plus, manual address assi…

Another option for simplicity in dual stack is to assign visually similar addresses: - ipv4: 192.168.0.42 - ipv6: prefix:192:168:0:42 I only do this for static/server machines, configuring Linux with a fixed ipv4, and append the fixed ipv6 host to the Router Advertisement prefix.

If I hadn't put my long-running machines' -er- ULA-derived [0] SLAAC addresses into my local DNS ages ago, I'd either do exactly that, or slice off the "redundant" parts of the IPv4 address off, so that I could choose to assign sixteen additional bits of addresses to each host. That is:

  - ipv6: prefix:192:168:0:42
would become

  - ipv6: prefix::0:42:[0-ffff]
[0] I'm really not sure how to succinctly say "The autonomously-configured addresses on my LAN's ULA prefix".

Re: Why IPv6 is so complicated

#332

Earlier quoted context omitted.

Its not just NAT, it's also DHCP. Somehow the nerds creating IPv6 decided to not only add bytes (which is what people wanted), but also "fix" DHCP and NAT, which nobody asked for.

> Its not just NAT, it's also DHCP. I'm not sure what you mean by "fix" DHCP and NAT, but FYI: RFC 3315 was published in 2003 . As far as NAT goes, it looks like iptables added IPv6 support to the MASQUERADE, SNAT, and DNAT targets in kernel version 3.7, released in 2012. IDK when other OSs added such support.

> I'm not sure what you mean by "fix" DHCP

SLAAC was part of IPv6 since the original RFC, its a horribly over engineered stateless replacement of DHCP. Nobody asked for that.

Re: Why IPv6 is so complicated

#333

Earlier quoted context omitted.

The changes to Ethernet lookup mandate that you have a link-local address in addition to your “real” address, and this starts the ball rolling on the idea that machines have multiple IP addresses in general. Which makes privacy addresses commonplace, ULA+GUA addresses on the same machine, etc. I think this is the biggest change with IPv6: that a machine’s IP addresses is no longer its identity, and you can’t easily p…

> I think this is the biggest change with IPv6: that a machine’s IP addresses is no longer its identity, and you can’t easily predict what address will be used when connecting somewhere. Can't you unset the "Use autonomous addressing" bit and set the "Use DHCPv6 for addressing and other config" bit in your RAs, and then refuse to hand out anything other than DHCPv6 Normal Addresses? Or do OS's ignore the fact that Te…

IME nothing pays attention to when you set a flag to not do autonomous addressing. macOS and iOS don't respect it AFAICT, I don't recall what Linux does by default, but I don't remember having any success.

But it's rather not really my point... best practices for IPv6 are to not do any of this, and you probably don't want to do it, because privacy addresses are an actually-important thing for privacy (so that sites can't correlate you easily.) You can say "oh but websites use fingerprinting anyway" (which doesn't help you when it's not a web browser you're using, but any other software that's connecting places) or "but sites don't trust the trailing 64 bits" (which only helps because everyone else is using privacy addresses, which rather proves my point.) When doing IPv6, you sort of have to abandon the idea that you're going to have a fixed, known IP address that you will use for all outbound connections. Fighting this is an exercise in pain.

Re: Why IPv6 is so complicated

#334
post #283

Earlier quoted context omitted.

1. IPv6 does have NAT [1], NAT66. 2. NAT is totally orthogonal to IP and addressing. 3. NAT (as in transparent packet modification to rewrite addresses) is utterly idiotic. Ephemeral, anonymous address allocation with inbound filtering is smart, but transparently rewriting packets to do that is one of the dumbest possible ways prone to horrible compatibility and ossification issues as has been proven empirically. [1]…

Are you a network engineer?

A network engineer would know how to NAT in IPv6, and wouldn't say an untrue statement like "there is no ability to NAT with IPv6".

Re: Why IPv6 is so complicated

#335

Earlier quoted context omitted.

The changes to Ethernet lookup mandate that you have a link-local address in addition to your “real” address, and this starts the ball rolling on the idea that machines have multiple IP addresses in general. Which makes privacy addresses commonplace, ULA+GUA addresses on the same machine, etc. I think this is the biggest change with IPv6: that a machine’s IP addresses is no longer its identity, and you can’t easily p…

> I think this is the biggest change with IPv6: that a machine’s IP addresses is no longer its identity, a little over half the bytes of a typical IPv6 visitor's address is comparable in identification to what all four bytes of an IPv4 address tells you

I'm not necessarily talking about fingerprinting or tracking here, it can be something a lot more mundane. Like if I have a homelab setup and I want to see what hosts connected to something, and I look at the logs and see privacy addresses, I know I'll never know what host it was. Or if I want to set up netgroups for access control to shares or something (just a hypothetical.)

In the classic sysadmin world, the idea that an IP you see could belong to any host and you have practically zero way of knowing, is rather different from what we expect in the IPv4 world. You just have to embrace it, basically.

Re: Why IPv6 is so complicated

#337
post #322

Earlier quoted context omitted.

You are right that a 32 bit ipv4 stack can not understand a 64 bit packet format. The thing I am trying to get at is not native compatibility, it is operational compatibility via translation. I know, I know, you will probably say that is what ipv6 bridges do. But in an ipv42 type setup, you would have determnistic embedding so that every ipv4 address is represented inside the larger address space. This would allow tr…

Your proposal (translation) is addressed as point 3B in the article.

I went and re-read point 3B. I agree that some hypothetical ipv42 faces a translation problem.

But it does not follow that address design is irrelevant. The structure of the address space directly determines whether translation can be stateless and alogrithmic.

In a hypothetical ipv42 design that preserves a deterministic embedding relationship between old and new addresses, translation at the edges could be largely stateless and mechanically reversible, to reduce coordiation overhead between operators and it makes reachability more predictable.

In our world ipv6, the transition seems to require a mix of dual stack, nat64, dns64, tunneling aproaches. The mapping between ipv4 and ipv6 is not uniformly deterministic across all deployment contexts.

Also, there is just a human factor. The mental gymnastics that go on. The perception of what is the way forward? With ipv6, it feels like everyone has to go get their ipv6 stack in order. With a hypothetical ipv42, where the ISPs and backbone providers can throw in the translation layers, it feels like, to me, they would have gotten on board much more quickly. Yeah, I know, it is just a feeling.

Re: Why IPv6 is so complicated

#338

Earlier quoted context omitted.

> Its not just NAT, it's also DHCP. I'm not sure what you mean by "fix" DHCP and NAT, but FYI: RFC 3315 was published in 2003 . As far as NAT goes, it looks like iptables added IPv6 support to the MASQUERADE, SNAT, and DNAT targets in kernel version 3.7, released in 2012. IDK when other OSs added such support.

> I'm not sure what you mean by "fix" DHCP SLAAC was part of IPv6 since the original RFC, its a horribly over engineered stateless replacement of DHCP. Nobody asked for that.

> Nobody asked for that.

I wasn't around for the discussions at the time, but I would have asked for it if I was. SLAAC is IPv4LL, except that you usually get a globally-routable IP address from it. It's great. It's also quite a bit simpler than DHCP... "If the advertised prefix permits autonomous addressing, generate a host part in the non-fixed part of the prefix, run DAD on the generated address to ensure it's not in use, and start using it if it's not.".

> SLAAC was part of IPv6 since the original RFC...

An attentive reader notices that RFC 1883 and RFC 1971 are separated by nearly a year.

Post reply on HN