Section 8.1: RFC7050 should not be applied to 127.0.0.0/8 and RFC1918 address space?

[momoka0122y]

Should synthesis be done to all address spaces?

If client applications or users wish to connect to IPv4 address
literals, the Happy Eyeballs engine will need to perform NAT64
address synthesis for them.

I wonder if this has been discussed for RFC7050 but should this algorithm
be applied to 127.0.0.0/8 and RFC1918 address space? Maybe we should
discuss if these address spaces should NOT be translated.

For the loopback address range (127.0.0.0/8), it should not be translated
as the client in question should have a route to the loopback network
resulting in the synthesis not being needed.

For addresses within the RFC1918 space, the translated address could be
misrouted to an unintended host, diverging from the user's original
intention. Nonetheless, it is worth noting that nothing stops the inclusion
of RFC1918 addresses in DNS records. As a result, translated IPv6 addresses
originating from RFC1918 space can still be acquired via DNS64. Given this,
it may be counterintuitive to impose restrictions on such addresses in the
Happy Eyeballs algorithm.

[nidhijaju]

We should add an editorial note about this, but make sure not to restrict anything because loopback and RFC1918 addresses can technically need to be synthesized.

[DavidSchinazi]

We discussed this issue from a security perspective in the CONNECT-UDP RFC. There we recommend against proxying loopback, link-local, multicast, etc.

Ideally RFC 6146 should have warned implementers of NAT64 about this. Unfortunately it didn't.

That said, I think it makes sense to synthesize RFC 1918 space via 7050. 1918 space is not globally routeable, but 7050 has no such requirement.

128.0.0.1/8 however is specific to this host, so synthesizing doesn't make sense when the NAT64 is on another device.

Looking at the Special-Use IPv4 Addresses Registry, I suspect we might want to restrict the following:

• 0/8
• 127/8
• 169.254/16
• 255.255.255.255/32

Another solution - which is what Apple implements - is to perform a route check for the target address and if there is a route then don't synthesize. For example, there's always a route to 127.0.0.1 over the loopback interface.

[momoka0122y]

That said, I think it makes sense to synthesize RFC 1918 space via 7050. 1918 space is not globally routeable, but 7050 has no such requirement.

I don't think there should be a text that restricts synthesising the address space but I think there should be an warning of how it can be routed to an undesired place.

hence I propose a text like

IPv4 addresses in the {{!RFC1918}} space may be routed unintendedly when doing NAT64 address synthesis depending on the network configuration of the NAT64 gateway.

I am thinking of a situation like below. The client A is not connected to 192.168.1.1 via IPv4. Depending on where the NAT64 box is at, the client can reach a host with a 1918 space address in a completely different network. (ex. different AS)
THe client may think that the 192.168.1.1 it is reaching is a totally different host.

+--------+        IPv6 Network    +-------+      IPv4 Network     +-------------+
| ClientA |---------------------->| NAT64 |---------------------->| 192.168.1.1 |
+--------+   64:ff9b::192.168.1.1 +-------+       192.168.1.1     +-------------+

This shouldn't be restricted but I think it would be nice if there is a caution that it may send packets to a client that it is not connected to which normally does not happen in 1918 space.

[momoka0122y]

Another solution - which is what Apple implements - is to perform a route check for the target address and if there is a route then don't synthesize. For example, there's always a route to 127.0.0.1 over the loopback interface.

This is also what chrome does (at least last time I checked) but I think as a document it is nice to have the actual IPv4 address spaces written down rather than how it should be implemented.

[DavidSchinazi]

The target audience for this document is implementers of HEv3. I'm not seeing how the caution about 1918 is useful for that audience, because there's nothing an HEv3 implementation can or should do about 1918

[momoka0122y]

The target audience for this document is implementers of HEv3. I'm not seeing how the caution about 1918 is useful for that audience, because there's nothing an HEv3 implementation can or should do about 1918

I was actually thinking of chrome and apple devises that implements this.