Hacker News new | ask | show | jobs
by throw0101d 15 days ago
> You don't actually own the IPv4-mapped-V6 address, as in packets don't get routed to you, they go to a relay that was notoriously flaky.

6to4 is exactly ownership:

> 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

The relaying is a necessity:

              OLD    DUAL   NEW     
            ----------------------
        OLD |  32  |  32  |  XX  |      
            |------|------|------|
       DUAL |  32  |  64  |  64  |
            |------|------|------|
        NEW |  XX  |  64  |  64  |
            ----------------------
* https://github.com/becarpenter/book6/blob/main/01.%20Introdu...

There's no way around it: a non-IPng-having node will have to go through a translation box of some kind.

2 comments

> There's no way around it: a non-IPng-having node will have to go through a translation box of some kind.

Yes. Note that it doesn't need to be someone else's relay; anyone with IPv4 connectivity could easily route 2002::/16 into IPv4-land (without having to announce it in BGP for others to use). You could even announce 2002:aabb:ccdd::/48 as a more-specific in BGP if you wanted, although this was more exotic.

If I have 1.2.3.4 in ipv4 world, I want 1.2.3.4 in ipv6 world instead of a random new address. I want another ipv6 host to be able to send dst=1.2.3.4 and have it go directly to my ipv6 host. 6to4 isn't comparable to that, it's for translation to/from v4 like you said.
> If I have 1.2.3.4 in ipv4 world, I want 1.2.3.4 in ipv6 world instead of a random new address.

::ffff:1.2.3.4

* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...

By having 1.2.3.4 you also got 2002:1.2.3.4::/48 'for free' (per 6to4). So if you want to send things to 1.2.3.4 / ::ffff:1.2.3.4, you tell your router that it's available via 2002:1.2.3.4::/48.

Any idea that you think is clever and to 'just' do X and/or Y for IPng, and would work, has probably already been thought of and attempted in the last 20-30.

Having 1.2.3.4 in v4 doesn't make ::ffff:1.2.3.4 or 2002:1.2.3.4 route to me in v6. It would route to a relay that translates/resends to v4 1.2.3.4, then it reaches my router over v4. Nobody can use that address over pure v6.

There's no one clever trick to make the transition easy, the idea is to preserve the v4 address blocks in v6. That cascades down to a bunch of different decisions, some of which include keeping NAT around. They've most likely thought of that too, and turned it down because they wanted to start with a clean slate and maybe also had some other vision of pure P2P apps.

> Having 1.2.3.4 in v4 doesn't make ::ffff:1.2.3.4 or 2002:1.2.3.4 route to me in v6. It would route to a relay that translates/resends to v4 1.2.3.4, then it reaches my router over v4. Nobody can use that address over pure v6.*

Sure they could: if your ISP owns 1.2.0.0/16, it could advertise 2002:1.2::/24 via BGP. So if someone on the other side of the planet wants to send something to 2002:1.2.3.4::/48 they would know where to send it.

And just like how something sent to 1.2.0.0/16 globally is then handled internally via IS-IS/OSPF/etc so your ISP knows how to send something for 1.2.3.4 to your CPE, your ISP would know how to handle 2002:1.2.3.4::/48 to get it to your CPE.

Routers are told to map traffic for (::ffff:)a.b.c.d to 2002:a.b.c.d::/48. If you're sending from w.x.y.z, you can put the source address as from something in 2002:w.x.y.z::/48.

It has nothing to do with "clean slate" or not. There are two immovable facts:

"""

IPv4 implementations, in 1994 and still today, have the 32-bit address format built into their code. Whether you expand the address size to 33, 64 or 128 bits, all IPv4 implementations will discard the packets. So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means two things immediately:

1. You have to change the version number.

2. You have to add new code to handle the new version.

""

* https://github.com/becarpenter/book6/blob/main/01.%20Introdu...

And this also includes 'accessory protocols': DNS A records are fixed at 32-bits, so if you want to use hostname with IPng you needed to upgrade the DNS infrastructure, including APIs to say "give me A and Ang", and then you perhaps need fallback mechanisms, in which case you're at:

* https://en.wikipedia.org/wiki/Happy_Eyeballs

Any IPng protocol, including 'just' adding bits, regardless of how you want to hand wave it as being 'just' an extension of IPv4 will be in same situation because you can't fit >32-bits in the 32-bits of the original code. You're rolling out new code in a rolling fashion, just like had to be done with IPv6.

Well yeah if you made your router use 2002:1.2.3.4, your ISP advertised 2002:1.2:: on BGP, and the other ISPs agreed your ISP owns that, that would work. They didn't do that, and the spec didn't say to. They did 6to4 instead.

I understand the limitation that you can never put a 128-bit address in a 32-bit field, and one way or another two hosts and everything in between have to understand the new packet format. That didn't force them to make ipv6 its whole separate network from v4 where almost no state is shared with v4. Having separate DHCP6 vs DHCP4 was a choice, likewise with DNS, NAT, and even the routing tables. It makes the difference for service operators who would be fine adopting ipv6 but don't want it to be a big project.