IPv6 support

[mid-kid]

IPv6 support is interesting, because eventually the internet will move to that, and there's different ways to make it work. I'm here to propose one:

Games generally don't actually care what IP a server has. They always return exactly the IP that the DNS query command returns. We can use this fact to our advantage. Each time the DNS Query command is called, try fetching both the IPv4 and IPv6 address. Save these in a table, and return a fictional address, that can be later looked up in this table. This table should hold at least as many entries as simultaneous connections can be made. When connecting to one of these, try connecting to both the IPv4 and the IPv6 address, since we don't know exactly what protocols are talked through the user's connection.

To allow games to connect straight to IPv4 addresses, such as addresses in the local network, any address that doesn't start with 0.0.0.xxx (0.0.0.0/24 in IP talk) will still connect straight to the address.

[ariscop]

127.0.0.0/24 might be a better range to use

[leo60228]

This is a very similar concept to the long-deprecated NAT-PT. RFC 4966 presents a number of reasons for its deprecation, but most of them might not apply to this usecase, and you could make an argument that using an IPv6 transition technology from 2000 would be period-accurate....

[kabili207]

127.0.0.0/24 might be a better range to use

I would be extremely hesitant to use anything in the 127.0.0.0/8 range of IPs. The entire block is explicitly defined for loopback addresses, and we have no guarantee that a game won't act up if it sees an address that's supposed to mean "this device".

0.0.0.0/8 is a bit of a weird one too, since it means "this network," and could be problematic for the same reasons.

There are three ranges for documentation purposes (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) as well as a range designated for benchmarking purposes (198.18.0.0/15) that we could probably use safely.

[leo60228]

What about the CGNAT block (100.64.0.0/10)?

[kabili207]

The CGNAT block is heavily used by mobile carriers around the world. We can't use that range for the same reason we can't use the private ranges: there's a non-zero chance that we could steal an IP used by an ISP's critical network infrastructure.

[leo60228]

That's not actually a problem, though, is it? The Game Boy should never actually be trying to communicate with an ISP's CGNAT addresses. Since the CGNAT addresses are just being used as stand-ins for IPv6 addresses, there won't be any conflicts (and per RFC 6598 "Shared Address Space can be used as additional non-globally routable space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces" which I think more or less applies here).

[mid-kid]

The point was to use an address range that would otherwise mean nothing, or be invalid as per the IP spec, since the adapter itself doesn't impose such restrictions. Whether that be the loopback addresses or other addresses assigned to special use, doesn't really matter. The point is mostly that they can't normally be used otherwise.

I like the idea of following an old RFC, though. I wonder if there's other RFCs that specify similar v4 to v6 translation mechanisms.

[leo60228]

To my knowledge, the only addresses that are completely unused are the 240.0.0.0/4 block (excluding 255.255.255.255). However, trying to take advantage of something that's currently unused seems like a bad idea considering that there have been repeated proposals to open up 0.0.0.0/8 and 240.0.0.0/4 as new unicast space. On top of this, multiple ISPs use 240.0.0.0/4 internally in violation of its reserved status, so it might not be safe even today.

I think 100.64.0.0/10 is the safest option, especially since if you squint it's basically intended for this usecase (doing a form of NAT where the address is an implementation detail to the user).