Hacker News Reader

Comment by zadikian | Hacker News Reader

I disagree that it would've been just as hard anyway. The people who say "I just wanted v4 with more bits" have a point that most of these arguments completely ignore, but this one touches on it:

  Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in [RFC3513] but deprecated by [RFC4291] because it turned out to be of no practical use for coexistence or transition.

The practical use would've been going all-in on those, making it as easy as possible for users to switch. But instead, the default way of using v6 was those new addresses, also SLAAC and no NAT, and 6to4 was bolted on in a way that never worked very well.

The thing is, their objective wasn't just to add more bits, it was to defrag the old v4 routes. If you did it the "just add more bits" way, once everyone is on v6 but with the old v4 /32s, the new address space for sale is underneath those. Maybe there'd be a way to defrag afterwards in a separate effort.

View on HN

How would this have worked in practice, in a way that the NAT464/NAT64 schemes that most mobile operators use haven’t? Would IANA have dedicated some blocks of IPv4 to be used for IPv4-compatible IPv6 addresses on the public internet?

Copy-paste the v4 blocks into v6 space under a common prefix, let's say 4::. Routers and software add ipv6 support (as they already have), but you only use 4::. Now once a user wants to switch, it looks the same. I'm still on NAT and DHCP. If I'm hitting Google.com on ipv6, I still use DNS4 and get 142.251.214.110, it actually sends to 4::142.251.214.110 takes the exact same route.

Time has to pass for all users to switch to v6. DNS6 and DHCP6 are in-place upgrades to the existing ones, not alternatives, so now they support longer fields. Once that's done, Google.com can say hey actually we're 142.251.214.110.1 now, and probably my ISP also gives me x.x.x.x.1.1 and leases x.x.x.x.2.2 to someone else.

You can also do all the above without the 4:: prefix. The point of that was to keep the possibility of offering all-new routes under the other v6 /8s, but that has its own friction.

Underneath the hood, you are talking about v4 mapped addresses:

IPv4-mapped IPv6 addresses (prefix ::ffff:0:0/96)

Network stacks do allow this today.

This already exists in two forms, and has for basically the entire history of production dual stack deployments. The first are IPv4 mapped addresses (of the form ::ffff:x.x.x.x) which instruct the local machine’s network stack to use a local IPv4 address to communicate to the server. This still requires each machine to have a routable IPv4 address (though not necessarily a public one - it can be used with a NAT44 router).

If you don’t want the local machine to have a routable IPV4 address at all (which is a common practice on mobile networks), you can do something similar with a different prefix (usually 64:ff9b::/96) called NAT46. In this case the local machine’s network stack exclusively emits IPv6 packets, and the upstream router/network detects the prefix and performs stateful NAT using its own IPv4 address(es), just like NAT44. Depending on the use-case, the local machine doesn’t even have to understand what you’re doing at all. Instead you just have the local network’s DNS server return fake AAAA records with the corresponding 64:ff9b::x.x.x.x addresses when some particular domain doesn’t have native IPv6 support.

I want something:x.x.x.x to get routed to me over v6 if I had x.x.x.x in v4, as the default and recommended way of contacting an ipv6 host, without needing additional config or middleboxes. Neither NAT64 or NAT46 do this really, and they're presented as alternatives rather than the native way.

The closest was 6to4. rfc6343 goes into why that got deprecated. You'd either have "router 6to4" which required additional setup for more parties, or "relay 6to4" which introduced nasty failure modes. Also don't think 6to4 was meant to support cases like 2002:1.2.3.4.5 down the road.

You can do this quite easily on all the major OSes by opening a single dual-stack socket. On most Linux distributions that is the default, and then mapped addresses will work fine if the machine has a v4 address or a 464XLAT configuration. This has been the case for about 20 years.

Opening a dual stack ipv4 and ipv6 does allow the service to accept both ipv4 and ipv6 connections. But I do not think that is what zadikian is getting at?

It does not address the network level identity and reachability. There is no default, globally routable mapping where owning a ipv4 automatically gives you an equivalent identity in ipv6 that others can reach without translation infrastructure. The transition mechanisms are not uniform or canonical, and that increases complexity.

6to4 was an attempt at that kind of embedding and I do not think it succeeded?

The original specification of ipv6 did not directly address a translation mechanism? It seemed to rely on, well, everyone will go dual stack and we will shut down the old ipv4 stack. I think it should have addressed that in the beginning and provided the one canonical way of doing it, perhaps with guides on timelines to get the ISP and backbone providers to get on board.

Yeah we're talking about the same thing. So my v4 is 70.94.201.31. My ISP didn't also give me 2002:70.94.201.31 or whatever.

They're allowed to do that if they want to. Most find there's no practical reason to ensure the addresses are related. It wouldn't help them support v6 faster.

Do they own such an address, as in, a packet sent by someone on another ISP to that address will actually reach my ISP's router over v6? Not talking about translations that use v4. If they do, I've never seen them actually give it to me.

Yes, they can just put your 32-bit IPv4 address after their 32-bit prefix, and that gives you a /64 as is standard. If they want to. But what's the advantage?

> My ISP didn't also give me 2002:70.94.201.31 or whatever.

Traffic to 2002:70.94.201.31/48 is tunnelled via 70.94.201.31 with-in an IPv4 packet (encapsulation):

* https://en.wikipedia.org/wiki/6to4

I mentioned 6to4 in the original comment. It doesn't fulfill this use case, it still relies on v4 packets.

I’m not clear on who is supposed to do the translating that isn’t doing it today, or why the mapped IPv4 addresses don’t qualify. Virtually all ISPs either give you an IPv4 address or do the translation for you, and the software you write doesn’t have to care exactly how it’s set up for the most part (there’s some subtlety about stuff like MTUs, but if you’re just doing unencapsulated TCP it usually doesn’t matter). It can just use whatever comes back from DNS (including using the official mapped addresses if only an IPv4 record exists) and expect the network stack to figure it out.

None of this stuff works perfectly, but it’s powering almost every mobile internet connection in the world so I don’t understand what is missing.

If you look at the reasons GitHub for instance doesn't support ipv6, it's a different set of problems from what cell carriers had to deal with.

You wrote "I don't understand what is missing"

ipv6 was standardized in 1995 6to4 was standardized in 2001

6to4 is not used in any meaningful way today.

What was missing was ipv6 should have had 6to4 (but better) in it, in 1995.

Now, I could go on about what is wrong with 6to4, but every new topic is just another surface area for ipv6 proponents to launch another question (I sometimes suspect in bad faith).

How would this work if your upstream router doesn't support v6? All other networks send packets towards you, but your ISP ignores them because they are invalid packets. Then what?

It requires the router to support v6. If you want, could do an approach kinda like "happy eyeballs" where you try both.

If the whole path supports ipv6 what is the purpose of the compatibility trick?

If you want to start using v6 before you're sure that every host supports it. But this isn't strictly needed, could just rely on something in DNS telling you the host supports it (I'm not saying AAAA records cause idk if you'd use them in this scheme).

> I want something:x.x.x.x to get routed to me over v6 if I had x.x.x.x in v4, as the default and recommended way of contacting an ipv6 host, without needing additional config or middleboxes.

Anyone with an IPv4 automatically got a 'free' IPv6 allocation:

> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.

> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.

* https://en.wikipedia.org/wiki/6to4

"Connection of IPv6 Domains via IPv4 Clouds", etc:

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

Owning 192.0.2.4 in v4 didn't really give you 2002:192.0.2.4 in v6, as in v6 packets can't reach you that way. If someone sent a v6 packet there, some router on their side would intercept it and relay as v4. Aside from this still relying on v4, it was very unreliable in practice because of uncertainty around what v6 route is taken to the relay. There's an RFC somewhere that looked at this in hindsight.

AIUI, you encapsulate anything to 2002:192.0.2.4/48 into an IPv4 packet with "41" in the protocol field (as opposed to 6 (TCP) or 17 (UDP)) and send it to 192.0.2.4. 192.0.2.4 would then work as the relay and extract the IPv6 traffic and handle it.

* https://en.wikipedia.org/wiki/IPv4#Protocol

* https://simple.wikipedia.org/wiki/Protocol_41

This exists already. But how does the ipv6 packet that says 4::1.2.3.4 get through all the ipv4 routers that have no idea how to read that, to the ipv4-only endpoint that doesn't know how to read it, and even if it did know, has no way to send a packet back to the sender's ipv6 source address?

We have it already with a translator box. It's called NAT64 and almost every cellular ISP in the whole wide world uses it.

> But instead, the default way of using v6 was those new addresses, also SLAAC and no NAT...

Well, the good news is that we've had DHCPv6 and IPv6 NAT for at least like 25 years. It's true that these weren't standardized in 1995, but I always wonder how long things need to be fully supported [0] before people stop acting like they don't exist.

It took something like a decade for IPv4 to get DHCP, and I don't know how long for it to get NAT, and yet I don't hear people saying that IPv4 has no default mechanism for address autoconfiguration or network address translation.

[0] ...by everyone except Android, of course...

The defaults determine what like 95% of users end up actually using, even if they have their own preference. Like you said, even if I wanted to use DHCP6, Android won't use it. My router also doesn't support it.

> My router also doesn't support it.

I'm sorry your router sucks. If -for example- my router intermittently fucked up its IPv4 NAT and sent NATted packets into the Internet Bitbucket, it would be incorrect for me to claim that IPv4 NAT sucks or isn't supported by default. The correct claim would be that my router's NAT implementation sucks.

A router messing up IPv4 NAT would make it unusable for v4. My router still works with v6, just doesn't support an optional extension of it. (Idk if the v6 spec actually says DHCP is optional, but it de facto is because slaac isn't, likewise NAT isn't even part of v4 spec but a home router will need it.)

And it's not exactly a bad thing that most routers have only one right way to do v6 addressing. One thing that's explicitly optional in v6 is default-deny firewall, which is where those "v6 is insecure" "no you're just using it wrong" fights come from:

  REC-49: Internet gateways with IPv6 simple security capabilities MUST
   provide an easily selected configuration option that permits a
   "transparent mode" of operation that forwards all unsolicited flows
   regardless of forwarding direction, i.e., not to use the IPv6 simple
   security capabilities of the gateway.  The transparent mode of
   operation MAY be the default configuration.

You could say well the user is dumb for not changing this setting, but there's a point where you should blame the design instead of the user if it's not generating the desired outcome across many users. This also goes if you actually want the router to leave your inbound alone and let the devices do firewalling, cause your device isn't going to be reachable when you're on someone's default-deny network.

they have no point. some random aesthetic aspect of a standard is not why it does or does not get adopted. it's an evolutionary standard that offers no direct incentives for adoption.

the real obstacle was enterprise sales, that is, someone had to pay Microsoft, Google, Amazon, etc. as a major customer of theirs to implement correct IPv6, which takes time. the people at Microsoft working on ipv6 for customers, they're only going to implement the parts that customers need, they're not going to proactively discover all the bugs and fix everything. this is true about everything, i'm not saying anything that unorthodox, except...

the reason we're talking about ipv6 now is, in a post LLM world, it is now possible to take a well written and thoughtful spec like ipv6 and Just Do It. you don't have to wait for a customer relationship to do it.

Despite the lack of incentive for some, it's gotten pretty far. Pretty much every network device and host supports it in a minimal way. It's just that people/corps don't want to switch because it introduces a lot of risk and changes in unexpected areas. Like you can fully understand the spec without knowing what the routes and reputation will look like.

Going all-in in what way?

The only thing I can think of is making it easier to run your local network v6-only. But if you're translating at the router like that, you don't need any particular mappings.

I've clarified under another comment what I meant by that

Want to add, it's not too late to do this on top of the ipv6 we have today.

Reply on news.ycombinator.com