Skip to content
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

Network: DNS64 / NAT64 #68

Open
cookiengineer opened this issue May 19, 2021 · 0 comments
Open

Network: DNS64 / NAT64 #68

cookiengineer opened this issue May 19, 2021 · 0 comments
Labels
undecided Undecided on how to proceed with this issue. Needs conversation.

Comments

@cookiengineer
Copy link
Member

DNS64 and NAT64 are concepts that want to provide IPv4 access to IPv6 only clients that cannot understand legacy IPv4 networking.

As far as I can tell the RFC6052 isn't relevant for the Tholian Network concept, as all Peers have peer-to-peer SOCKS capabilities with both IPv4 and IPv6 support and could therefore relay internet traffic via connected peers that understand both networking stacks.

DNS64 as defined in RFC6147, however, might need some consideration in specific rare conditions. As an AAAA-to-A or A-to-AAAA resolver won't make sense as the resulting direct connections to the specific target hosts wouldn't be possible anyways, it might make sense to use the SOCKS proxy capabilities here, too.

If a Peer that understands both IPv4 and IPv6 can translate DNS records, it can also provide NAT64 access via a SOCKS relayed connection.

The only scenario that I can come up with right now where this could potentially fail is when Multicast DNS based Service Discovery (lookup for *.tholian.local) fails to provide local peers that can break out of an IPv6-only NAT where the connected Peers can only understand IPv4 (or the other way around inside an IPv4-only NAT with an IPv6-only Peer).

But I guess in that scenario this client can't connect to the internet by any given means except through bi-directional DNS exfiltration sockets or through PWNAT-like SNMP sockets.

This issue stays open as a reminder of that scenario, should an occasion rise in future where this scenario receives a higher priority. It might make sense - in future - to use the DNS/DNSS/MDNS stack to provide a Proxy capability so that network traffic can also be sent inside binary TXT based payload frames.

@cookiengineer cookiengineer added the undecided Undecided on how to proceed with this issue. Needs conversation. label May 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
undecided Undecided on how to proceed with this issue. Needs conversation.
Projects
None yet
Development

No branches or pull requests

1 participant