FWIW the approach we took for Thread was to require that devices do DNS64 locally, which is consistent with what you are saying, Med. So Thread BRs do not do DNS64: they provide a NAT64 prefix that hosts on the Thread mesh can use to synthesize IPv6 addresses after the resolver has discovered them.
In this scenario, a DNS resolver would in fact do NAT64 to query an IPv4 name server. But it would never do DNS64 other than in the way Med is suggesting: if it discovers that there is no AAAA record for a particular authoritative server, it would use an A record to synthesize the IPv6 address directly. It was my understanding that that is what this document recommends, but perhaps I am wrong? It's definitely a problem, BTW, if the upstream resolver from the Thread host does DNS64. We can't really prevent that, though, and it will work as long as DNSSEC isn't being done, but if DNSSEC is being done, we expect to get answers that aren't synthesized. So part of the reason I'm engaging in this conversation is that if we think that will work, but it won't, I'd like to know more. On Fri, Jul 7, 2023 at 6:32 AM <mohamed.boucad...@orange.com> wrote: > Hi all, > > > So instead of creating documents for every possible protocol that > > uses IPv4 literals, why not create one document that describes how > > to deal with IPv4 literals in existing protocols in the context of > > NAT64? > > > > We do already have rfc7051 + many pref64 discovery RFCs out there. RFC7051 > says: > > Below is (an incomplete) list of various > use cases where it is beneficial for a host or an application to know > the presence of a NAT64 and the NSP/WKP: > > o .. > > o Protocols that use IPv4 literals. In IPv6-only access, native > IPv4 connections cannot be created. If a network has NAT64, it is > possible to synthesize an IPv6 address by combining the IPv4 > literal and the IPv6 prefix used by NAT64. The synthesized IPv6 > address can then be used to create an IPv6 connection. > > o ... > > o URI schemes with host IPv4 address literals rather than domain > names (e.g., http://192.0.2.1, ftp://192.0.2.1, imap://192.0.2.1, > ipp://192.0.2.1). A host can synthesize an IPv6 address out of > the literal in the URI and use IPv6 to create a connection through > NAT64. > > Cheers, > Med > > > -----Message d'origine----- > > De : DNSOP <dnsop-boun...@ietf.org> De la part de Philip Homburg > > Envoyé : vendredi 7 juillet 2023 12:18 > > À : v6...@ietf.org > > Cc : Xipengxiao <xipengxiao=40huawei....@dmarc.ietf.org>; dnsop > > <dnsop@ietf.org> > > Objet : Re: [DNSOP] [v6ops] WG call for adoption: draft-momoka- > > v6ops-ipv6-only-resolver-01 > > > > > I agree with you that 464XLAT is a better solution and the world > > > should use it as much as possible. > > > > > > But for those already deployed DNS64 and can't move to 464XLAT > > soon > > > (possibly due to lack of CLAT support, e.g. in some residential > > > gateways), wouldn't Momoka's draft help? If Momoka adds > > statements in > > > a new version telling people to consider 464XLAT first, will it > > be > > > acceptable to you? Thanks. > > > > NAT64 without 464xlat is a rather broken way of providing access > > to the IPv4 internet because it cannot deal with IPv4 literals. > > > > So instead of creating documents for every possible protocol that > > uses IPv4 literals, why not create one document that describes how > > to deal with IPv4 literals in existing protocols in the context of > > NAT64? > > > > > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
