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

Michael Richardson <[email protected]> Fri, 10 Apr 2026 15:41:56 -0400

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

Philip Homburg <[email protected]> wrote:
    > I'm worried about host and application complexity. Most people writing
    > applications still live mostly in an IPv4 world. IPv6 is weird. DNS64
    > create an extra level of weirdness where IPv4 addresses are embedded in
    > IPv6 addresses.

People who wrote v4-only applications will just fail on v6only hosts.
No confusion.

People who deployed only v4 servers, will have no "confusion" between
v4-in-v6 NAT64 addresses and native v6, because they don't have native v6.
Those applications might naively do STUN/TURN anyway, which is actually what
we want.

It's only people who were v6-clueful on the application, and yet have *not*
deployed v6 servers, who will run into problems.

    > None of this is fatal. I'm sure that over time hosts and applications
    > will figure it out. But for me it is sad if this becomes an Internet
    > Standard.

I have no objection to text about STUN/TURN concerns.
Just *(@$#5324 deploy v6 already. OMG.

DNS64 might not work for you, and should not be recommended for new
application writers, but it *is* out there, and I *do* need a consistent set
of IS RFCs that can go into RFPs in order to get v6-mostly.
Not having DNS64 on that list will let some product manager remove support
for it in some router and/or DNS recursive resolver.
(Note: that could be the resolver at 127.0.0.53 used by a container)

--
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)