Hi, > On 13. Aug 2025, at 00:25, Mark Andrews <[email protected]> wrote: > > > >> On 11 Aug 2025, at 20:06, Tobias Fiebig <[email protected]> wrote: >> >> Moin, >> >> On Mon, 2025-08-11 at 19:55 +1000, Mark Andrews wrote: >>> Which only “works” with trivial configurations. >>> >>> What happens if 2.0.0/24 is reachable out interface A and interface B >>> is IPv6 only with a PREF64? >> >> Then I'd say that it is covered by the point being made >> <bcp14>SHOULD</bcp14> and not <bcp14>MUST</bcp14>. > > SHOULD is a cop out. What we are designing SHOULD work everywhere WITHOUT > manual intervention.
Turning on NAT64 address synthesis should only ever happen if you know that there is no IPv4 connectivity. Apple takes a similar approach in their local resolver library and it saves CPU calyces and makes debugging much easier. One big advantage of doing address synthesis over using a CLAT is that we can correctly set socket options like IPV6_USE_MIN_MTU=1 for the way before we hit NAT64. The bigger one ist that we don’t need to configure CLAT, for which we btw. have production-grade implementation on Linux. If the machine has not IPv4 connectivity, enabling address synthesis is much less error prone than setting up CLAT. That’s the reason why I would do address synthesis in my IPv6-only Kubernetes Clusters. > Translating IP addresses in a DNS server is unnecessary work. It is also > a security flaw as you are potentially redirecting DNS queries to places > other than where they are intended to go according to the routing table. If there are no IPv4 routes, there are no security issues. If there are (but no default route) maybe disabling address synthesis and setting up CLAT is easier, but for wich use-cases? - Recursors on Laptops with split-VPN? - My chaotic VyOS VPN router at home? >> The ways to configure one's own network are endless. What if there are >> two interfaces each with their own PREF64? What if the second Interface >> only offers reachability for RFC1918? What if the operator has been >> squatting non-RFC1918 space and the 2.0.0.0/24 reachable via Interface >> B is _not_ the one they want to use for DNS resolution? > > All the more reason to NOT do this. It’s not something that can be done > safely. It is perfectly safe if you have no IPv4 connectivity and much less error-prone than integrating CLAT. The only drawback of doing address synthesis instead of CLAT is that DNS server vendors get additional bug reports for broken network setups that should not have enabled address synthesis in the first place. >> I think that all of that is sufficiently covered by >> <bcp14>SHOULD</bcp14>. >> >> However, to make this more clear, we could add text along the lines of: >> >> "Specific operational scenarios may differ. As such, it is >> <bcp14>RECOMMENDED</bcp14> that implementations offer configuration >> options that allow an operator fine-grained control of prefixes to >> exclude from PREF64 based address synthesis." >> >> The general point, though, was brought forward to me by multiple >> operators, who are struggling with the current situation, and would >> appreciate the currently sketched solution. >> >> With best regards, >> Tobias >> -- >> Dr.-Ing. Tobias Fiebig >> T +31 616 80 98 99 >> M [email protected] >> Pronouns: he/him/his > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [email protected] > <mailto:[email protected]> > > _______________________________________________ > DNSOP mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> AVE! Philipp S. Tiesel -- Philipp S. Tiesel https://philipp.tiesel.net/
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
