Re: [v6ops] DNS64/Thread RE: WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01

Mark Andrews <[email protected]>
Newsgroups gmane.ietf.dnsop,gmane.ietf.v6ops
Message-ID <[email protected]>
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, [email protected] wrote:
> 
> Hi Gert,
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Gert Doering <[email protected]>
>> Envoyé : lundi 10 juillet 2023 08:53
>> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>
>> Cc : Ted Lemon <[email protected]>; [email protected]; Xipengxiao
>> <[email protected]>; dnsop <[email protected]>
>> 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 +0000,
>> [email protected] 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&data
>>> 
>> =05%7C01%7Cmohamed.boucadair%40orange.com%7C156480ca56e144dd3c7708
>> db81
>>> 
>> 125189%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63824568789974
>> 8586
>>> 
>> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
>> iI6I
>>> 
>> k1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7hwX%2Bwnur4AnRNpe9LCY
>> lWNR
>>> jDC5Sk%2BCnzSpTZNmqi0%3D&reserved=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 14        Aufsichtsratsvors.: 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/v6ops


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email protected]

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.