Hi Ted, (Changed the subject for convenience)
I was told that PCP was required in Matter/Thread(?). Do you know if the discovery of the prefix is based on RFC7225? Thanks. For your last point: problems may arise if a distinct pref64 is used by the upstream DNS64 than the one used locally. Unless I’m mistaken, we currently don’t have a solution to detect mismatches between what is used by a local NAT64 and an upstream DNS64 let alone whether an upstream resolver is also performing DNS64. I used to have a proposal for this: https://datatracker.ietf.org/doc/html/draft-boucadair-dnsop-prefix64-02 For DNSSEC, as your rightfully mentioned if the host sets CD/DO bits then the upstream DNS64 must not synthesize answers. This assumes that the host issues both A/AAAA queries. Cheers, Med De : Ted Lemon <mel...@fugue.com> Envoyé : vendredi 7 juillet 2023 14:06 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> Cc : Philip Homburg <pch-v6ops...@u-1.phicoh.com>; v6...@ietf.org; Xipengxiao <xipengxiao=40huawei....@dmarc.ietf.org>; dnsop <dnsop@ietf.org> Objet : Re: [v6ops] [DNSOP] WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01 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<mailto: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<http://192.0.2.1/>, ftp://192.0.2.1<ftp://192.0.2.1/>, imap://192.0.2.1<http://192.0.2.1/>, ipp://192.0.2.1<http://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<mailto:dnsop-boun...@ietf.org>> De la part > de Philip Homburg > Envoyé : vendredi 7 juillet 2023 12:18 > À : v6...@ietf.org<mailto:v6...@ietf.org> > Cc : Xipengxiao > <xipengxiao=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>>; > dnsop > <dnsop@ietf.org<mailto: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<mailto:v6...@ietf.org> https://www.ietf.org/mailman/listinfo/v6ops ____________________________________________________________________________________________________________ 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
