-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Section 8.1: RFC7050 should not be applied to 127.0.0.0/8 and RFC1918 address space? #18
Comments
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. |
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:
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. |
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 hence I propose a text like
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)
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. |
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. |
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. |
Should synthesis be done to all address spaces?
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.
The text was updated successfully, but these errors were encountered: