Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

464XLAT should work fine with ipv4 literals, no? At least on macOS, this will get routed to a local 192.0.0.2 interface, which does the CLAT, translates it to an ipv6 64:ff9b::<ipv4> address, and relays it to your nat64 server. The ipv4-only software doesn't know any different, and the only traffic going on your LAN is ipv6.

I'm not sure if windows works the same way though...

(Edit: Looks like windows can do this, but it only configures it for WWAN interfaces, go figure: https://techcommunity.microsoft.com/t5/windows-os-platform/c...)



Discord calls on Windows was the only exception I ran into, because as you found yourself, it functionally had to fallback on DNS64. In general, some peer-to-peer situations are the likely one of the few cases where it will end up falling back onto DNS64 for resolution. This isn’t something I entirely realized myself — I’m apparently far from the only person to discover this behavior (Discord embedding IPv4 literals for its relay servers). Discord has had tickets open about it for years so far.

I appreciate my son being patient on that one, but he appreciated how seriously I dug into everything. Again, we have IPv4 enabled again as fallback, but the family agreed for an IPv6-only weekend as a test, and that was the only thing (outside of one website) that failed.

Everything else worked perfectly, including tons of legacy devices and software, some of which had no concept of IPv6.

For 464XLAT on clients, phones are actually the leaders here. It’s worked perfectly on at least iOS (and I assume Android) for a LONG time because of its built-in automatic tunneling. Mac OS had some recent improvements in Ventura to make things easier. Windows absolutely has some quirks, the biggest being IPv6 literals in UNC paths ending up using a domain Microsoft doesn’t actually own - a potential huge future attack vector.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: