[DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147 ) to Internet Standard

Michael Richardson <[email protected]> Fri, 10 Apr 2026 13:24:34 -0400

Newsgroups	gmane.ietf.dnsop,gmane.ietf.v6ops
Message-ID	<[email protected]>

Philip Homburg <[email protected]> wrote:
    > It limitations like this (and the lack of support for IPv4 literals,
    > issues with applications using public DNS resolvers (with or with out
    > DoT or DoH) that mean that DNS64 should have a very reduced scope.

    > One thing that I don't understand, is how (in the context of DNS64)
    > applications handle NAT traversal.

Do you mean, for things like SIP that use a TURN server to learn of things?

    > As far as I know, for NAT traversal you have to know if an address is IPv4
    > or IPv6. But DNS64 hides that difference. Is there an RFC where this is
    > spelled out?

Since all the addresses are IPv6, the application might think it does not
need to do TURN.  If the service is sane, then it has v4 and v6 addresses,
and the DNS64 will not synthesize AAAA, and the application will fail to
connect to the v4, and just use the v6.
If the application communicates IP literals in-band (I think teams.* does
this), and supplies v4 and v6, then the v4 just fail.
*If* there is also a local CLAT, then the v4 "work", and the application uses
TURN to figure out what the outer IPv4 from the 464 is.

The place where I think we get into trouble is when, as you suggest, a name
is used to refer to the additional resource, there are no v6, and DNS64
synthesis occurs, and TURN would have been needed.  In 2019 thru 2022-ish,
many of us experienced exactly that with teams.*, where it did not do TURN
properly, unless it was RFC1918.
v4-public and v6 addresses on the host *did not work*.
I "solved" the problem by making sure to route the RTC end-point IPs via a NAT44.
(Yes, like for IETF107 online in April 2020, where we used Webex for the
virtual meetings, a bunch of the services would just fail.)

--
Michael Richardson <[email protected]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

**       My working hours and your working hours may be different.         **
** Please do not feel obligated to reply outside your normal working hours **

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

signature.asc (application/pgp-signature, 487 B)