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.
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
TXTbased payload frames.