Hi Philip, all, I agree about your DNS64 comments.
Actually DNS operations are not impacted at all; all what this draft is about is related to transport. The draft is simply about an application that is behind a NAT64 and which uses RFC6052 to build IPv4-embeded IPv6 address to reach an upstream resolver. It is OK to document, but as I said in my review, I'm not sure there is a value in publishing this as an RFC. Cheers, Med > -----Message d'origine----- > De : v6ops <v6ops-boun...@ietf.org> De la part de Philip Homburg > Envoyé : jeudi 6 juillet 2023 15:00 > À : v6...@ietf.org > Cc : dnsop <dnsop@ietf.org>; Vasilenko Eduard > <vasilenko.eduard=40huawei....@dmarc.ietf.org> > Objet : Re: [v6ops] [DNSOP] WG call for adoption: draft-momoka- > v6ops-ipv6-only-resolver-01 > > > Hi all, The goal to > > improve DNSSEC adoption is good. The goal to improve IPv6 > adoptions > > is good too. It looks like here goals contradict (for technical > > reasons). But if you would pay attention that DNS64 is already > > massively adopted by *ALL* carriers, Then the harm for DNSSEC is > > already done and non-reversible (this battle was lost many years > ago). > > Hence, please do not harm additionally for IPv6 adoption. > > Please, adopt Momoka's draft at least somewhere (I am not sure > v6ops > > or dnsop). > > The draft is a bit confusing to me because it discusses DNS64, > though it seems that DNS64 is mostly irrelevant to this draft. > > The draft discusses how a recursive resolver could operate on a > link that has IPv6 as native transport and where IPv4 access is > provided using NAT64. > > DNS64 can be provided downstream to users of the recursive > resolver, but that seems not relevant. DNS64 can also be left out. > With no change to the upstream requirements. > > I think the draft would improve if references to DNS64 are removed > as much as possible. > > The thing I find missing in this draft is that the desired > functionality comes for free if the the host implements 464xlat. > Using 464xlat everywhere has the advantage that it is compatible > with DNSSEC and that DNS64 is not needed. > > In the context of this draft another advantage of using 464xlat is > that the recursive resolver can remain completely unaware of the > NAT64 translation prefix. The draft describes that the translation > prefix is typically configured statically because of DNS64. > However, in new installations it would be best to avoid DNS64, so > this would require recursive resolvers to dynamically find the > current translation prefix. > > In short, in my opinion a recursive resolver behind NAT64 should > use 464xlat and should not try to implement address translation > directly. > > _______________________________________________ > v6ops mailing list > v6...@ietf.org > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.ietf.org%2Fmailman%2Flistinfo%2Fv6ops&data=05%7C01%7Cmohamed.b > oucadair%40orange.com%7C3db898eb01e147db170108db7e20f10a%7C90c7a20 > af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638242452165912520%7CUnknown%7 > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL > CJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=i5PoHuXflOZ8AqGKi0thXlNKLAcDUq > sX5cCLJT3lnS0%3D&reserved=0 ____________________________________________________________________________________________________________ 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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
