Re: [DNSOP] [v6ops] DNS64/Thread RE: WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01
Hi, On Tue, Jul 11, 2023 at 10:04:38AM +1000, Mark Andrews wrote: > I think the issue is that NAT64 is being used to reach internal IPv4 addresses > (e.g. RFC 1918) so the traffic needs to go through a NAT64 that can reach > those > addresses. If you do that (which is a nice way to leverage IPv6 to work around duplicate use of private network segments, by having a NAT64 gateway for each), then you really do not want to use "arbitrary DNS64" resolvers, but maybe have the NAT64 address right in the internal DNS, for v6-enabled clients... But yes, just setting up random NAT64 and DNS64 boxes and hoping for magic to do the right thing might not work out very well. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [v6ops] DNS64/Thread RE: WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01
I think the issue is that NAT64 is being used to reach internal IPv4 addresses (e.g. RFC 1918) so the traffic needs to go through a NAT64 that can reach those addresses. > On 10 Jul 2023, at 17:32, mohamed.boucad...@orange.com wrote: > > Hi Gert, > > Please see inline. > > Cheers, > Med > >> -Message d'origine- >> De : Gert Doering >> Envoyé : lundi 10 juillet 2023 08:53 >> À : BOUCADAIR Mohamed INNOV/NET >> Cc : Ted Lemon ; v6...@ietf.org; Xipengxiao >> ; dnsop >> Objet : Re: [v6ops] DNS64/Thread RE: [DNSOP] WG call for adoption: >> draft-momoka-v6ops-ipv6-only-resolver-01 >> >> Hi, >> >> On Fri, Jul 07, 2023 at 01:19:38PM +, >> mohamed.boucad...@orange.com wrote: >>> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> data >>> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-boucadair-dnsop-prefix64- >> 02 >>> >> =05%7C01%7Cmohamed.boucadair%40orange.com%7C156480ca56e144dd3c7708 >> db81 >>> >> 125189%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63824568789974 >> 8586 >>> >> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT >> iI6I >>> >> k1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=7hwX%2Bwnur4AnRNpe9LCY >> lWNR >>> jDC5Sk%2BCnzSpTZNmqi0%3D=0 >> >> I would assume that it just does not matter if there are two NAT64 >> boxes available, with different prefixes. Depending on which >> prefix you use for the IPv6 synthesis, your packets will use one >> or the other to be translated - which is actually one of the >> brilliant aspects of NAT64, that it does not need to be in the >> "non NAT" packet flow. > > [Med] Yes, but not sure this is relevant to the point above. > >> >> Same for "having two DNS64 in sequence" - while unusual, it will >> still work. > > [Med] I'm afraid not. Failure will be observed if there are no on-path NAT64 > that uses the prefix used by these DNS64. > > The first DNS64 to see the IPv4-only reply will do >> synthesisis, the second DNS64 will see an IPv6 answer, and won't >> have to do anything except "forward". If they agree on the NAT64 >> prefix, packets will use the same NAT64 gateway in any case, if >> not, see above. >> >> Gert Doering >>-- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard, >> Michael Emmer >> Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner- >> Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [v6ops] DNS64/Thread RE: WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01
Hi Gert, Please see inline. Cheers, Med > -Message d'origine- > De : Gert Doering > Envoyé : lundi 10 juillet 2023 08:53 > À : BOUCADAIR Mohamed INNOV/NET > Cc : Ted Lemon ; v6...@ietf.org; Xipengxiao > ; dnsop > Objet : Re: [v6ops] DNS64/Thread RE: [DNSOP] WG call for adoption: > draft-momoka-v6ops-ipv6-only-resolver-01 > > Hi, > > On Fri, Jul 07, 2023 at 01:19:38PM +, > mohamed.boucad...@orange.com wrote: > > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > data > > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-boucadair-dnsop-prefix64- > 02 > > > =05%7C01%7Cmohamed.boucadair%40orange.com%7C156480ca56e144dd3c7708 > db81 > > > 125189%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63824568789974 > 8586 > > > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT > iI6I > > > k1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=7hwX%2Bwnur4AnRNpe9LCY > lWNR > > jDC5Sk%2BCnzSpTZNmqi0%3D=0 > > I would assume that it just does not matter if there are two NAT64 > boxes available, with different prefixes. Depending on which > prefix you use for the IPv6 synthesis, your packets will use one > or the other to be translated - which is actually one of the > brilliant aspects of NAT64, that it does not need to be in the > "non NAT" packet flow. [Med] Yes, but not sure this is relevant to the point above. > > Same for "having two DNS64 in sequence" - while unusual, it will > still work. [Med] I'm afraid not. Failure will be observed if there are no on-path NAT64 that uses the prefix used by these DNS64. The first DNS64 to see the IPv4-only reply will do > synthesisis, the second DNS64 will see an IPv6 answer, and won't > have to do anything except "forward". If they agree on the NAT64 > prefix, packets will use the same NAT64 gateway in any case, if > not, see above. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, > Michael Emmer > Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner- > Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 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
Re: [DNSOP] [v6ops] DNS64/Thread RE: WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01
Hi, On Fri, Jul 07, 2023 at 01:19:38PM +, mohamed.boucad...@orange.com wrote: > 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 I would assume that it just does not matter if there are two NAT64 boxes available, with different prefixes. Depending on which prefix you use for the IPv6 synthesis, your packets will use one or the other to be translated - which is actually one of the brilliant aspects of NAT64, that it does not need to be in the "non NAT" packet flow. Same for "having two DNS64 in sequence" - while unusual, it will still work. The first DNS64 to see the IPv4-only reply will do synthesisis, the second DNS64 will see an IPv6 answer, and won't have to do anything except "forward". If they agree on the NAT64 prefix, packets will use the same NAT64 gateway in any case, if not, see above. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
