Hi Mark,
1. 464XLAT is indeed an alternative, but a bad one: it means that the client should have a local IPv4 subnet. The DNS resolver should prepare the packet in IPv4 format, then fetch it to the CLAT engine where it would be translated to IPv6. It is not an IPv6-only network. You have to have an IPv4 stack on the DNS resolver anyway. Such a solution does not have too much sense for IPv6 progress – we already have DualStack. Well, OK. IPv4 (and CLAT) would be only inside hosts, not on network links and routers. It is not nice anyway – software guys would probably be in strong opposition. 2. An outdated statistic that I have seen for Mobile was: · 75% of traffic is native IPv6, · 24% is NAT64 whereas DNS64 is faking IPv6 address for IPv4-only resources, · 1% and declining is CLAT (then NAT64/PLAT). Hence, disabling DNS64 is to move 24% to CLAT. It is possible but would be strong opposition to an additional translation on the traffic path (including some IPv6 WG members). A reminder that in both cases traffic is coming through PLAT/NAT64 which is expensive. CLAT is almost 0$ cost (a little for support). I am personally in favor of canceling DNS64 and moving ¼ of Telco traffic through CLAT (in smartphone or CPE) – additional CLAT is not a problem – DNSSEC is a good reason for it. But I am sure that Carrier already implemented all of these and would not listen to us. Do not touch anything that works on a massive scale (or have a very-very strong reason that everybody is probably suffering already). Carriers are not suffering from DNSSEC adoption. Sorry. 3. MAP is not supported by any Mobile OS. You could just ignore it like it does not exist – no difference. Fixed Broadband has a choice, but historically MAP was absent in CPEs (RFC 8585 is from May 2019). And it has a problem with the huge IPv4 address space requirement – not many carriers are so rich on the legacy address space. Hence, the average person has enough fingers to count MAP installations worldwide. Disclaimer: I believe that MAP technically is the best. But the train has passed. I feel the pain from DNSSEC progress. I agree that DNSSEC is something VERY important. Just blocking this small feature would not help to resurrect DNSSEC – the battle was lost at different times (5-10 years ago) and for different reasons (avoid additional NAT/CLAT translation). Hence, help to move IPv6 forward to cancel DNS64 – it would not be needed in an IPv6-only world (fingers crossed). Albeit, the feature is small that would not greatly speed up IPv6 adoption. It is positive anyway. Effectively, this is the request for an additional 0.000001% of hosts to use DNS64 to billions that already support it. Eduard -----Original Message----- From: Mark Andrews [mailto:ma...@isc.org] Sent: Thursday, July 6, 2023 5:39 PM To: Vasilenko Eduard <vasilenko.edu...@huawei.com> Cc: Ted Lemon <mel...@fugue.com>; dnsop <dnsop@ietf.org>; list <v6...@ietf.org> Subject: Re: [v6ops] [DNSOP] WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01 > On 6 Jul 2023, at 21:09, Vasilenko Eduard > <vasilenko.edu...@huawei.com<mailto:vasilenko.edu...@huawei.com>> wrote: > > 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, The carriers could turn off DNS64 today and just serve an appropriately populated ipv4only.arpa zone and 99.9% of customers wouldn’t notice the difference. All the phones shipping today support 464XLAT. The vast majority of the existing phones also support 464XLAT. When you get away from carriers to wireline ISPs DS-Lite, MAP-* are also in use. They don’t actually break access to the IPv4 internet like DNS64 does. Even then just having the CPE support DS-Lite, MAP-*, 464XLAT is enough for ISPs to turn off IPv4 and go IPv6 only in the access network. The applications running in this environment also require IPv4 literal support more than phones do. There is lots more custom code here in this space that has never been made IPv6 aware. DNS64 is actually a BAD fit. This is also where you do find name servers in use. > Then the harm for DNSSEC is already done and non-reversible (this battle was > lost many years ago). No, it isn’t irreversible. Just about every cell phone that is shipping supports 464XLAT and that DOES NOT require DNS64. It just requires being able to get the PREF64. > Hence, please do not harm additionally for IPv6 adoption. The use of DNS64 is actually doing harm for IPv6 adaption as it DOES NOT WORK FOR ALL APPLICATIONS. There are plenty of IPv4AAS that do work FOR ALL APPLICATIONS and they can actually be deployed in parallel. All this draft is doing is demonstrating why DNS64 is a bad solution. If it had worked this wouldn’t be being proposed. It is making all the same assumptions that where made initially for DNS64 and guess what? The world decided that DNS64 WAS NOT ENOUGH. We have 464XLAT support on just about every cell phone. We have 464XLAT support in modern desktop boxes. If the box you want to run the DNS64 nameserver on doesn’t support 464XLAT install one that does. Mark > Please, adopt Momoka's draft at least somewhere (I am not sure v6ops or > dnsop). > Eduard > -----Original Message----- > From: v6ops [mailto:v6ops-boun...@ietf.org] On Behalf Of Mark Andrews > Sent: Thursday, July 6, 2023 7:48 AM > To: Ted Lemon <mel...@fugue.com<mailto:mel...@fugue.com>>; dnsop > <dnsop@ietf.org<mailto:dnsop@ietf.org>>; list > <v6...@ietf.org<mailto:v6...@ietf.org>> > Subject: Re: [v6ops] [DNSOP] WG call for adoption: > draft-momoka-v6ops-ipv6-only-resolver-01 > > > >> On 6 Jul 2023, at 12:32, Ted Lemon >> <mel...@fugue.com<mailto:mel...@fugue.com>> wrote: >> >> It’s not a problem to validate before translating if you’re a full service >> resolver. > > Ted you are missing the point. It is impossible to *reliably* run a > validating client behind a DNS64 server. DNS64 uses CD in a manner that is > *incompatible* with DNSSEC. > Sure as long as the DNS64 server *always* gets good answers you can “get away > with it” > but once you don’t things break. > > In DNSSEC > CD=1 is for when the recursive validating resolver has bad time / > trust anchors > CD=0 is ensures the cache returns answers that can validate as secure (the > server is supposed to try multiple sources as it is required to “treat as > never having arrived” > responses that don’t validate) > > “Always send CD=1” is stupid advice. I tried to prevent it being published > in the first place. > > If the DNS64 server happens to lock onto a bad source of data or is losing > the race with spoofed responses the client will never get anything that > validates as secure as: > CD=1 the bad data is passed through or returned from the cache. > CD=0 the DNS64 server produces responses that don’t validate. > > Anything that further promotes the use of a BROKEN protocol should not be > published. > > Mark > >> Op wo 5 jul 2023 om 21:10 schreef Mark Andrews >> <ma...@isc.org<mailto:ma...@isc.org>> I’ll >> repeat that it is a bad idea to make this an RFC. I’m saying this >> despite adding this to named. >> >> It is perpetuating DNS64 which does not work with DNSSEC. It sends >> the wrong signal that DNS64 is a good protocol to deploy when we know that >> it breaks lots of things. >> >> The better solution would be to improve the automatic installation of >> 464XLAT (RFC6877) support in nodes. There is already a RA PREF64 >> option (RFC8781) to signal that NAT64 is available on the network and >> that works for all applications on the node, not just the nameserver. >> >> Similarly for DS-Lite. >> >> Linux has https://github.com/toreanderson/clatd >> FreeBSD has 464XLAT support built in since FreeBSD 11.3 >> >> While CLAT is not everywhere there yet it is definitely on the way. >> https://blog.apnic.net/2022/11/21/deploying-ipv6-mostly-access-networ >> k >> s/ >> >> I really don’t know why we are just not saying if you want to run a >> DNS64 server behind a IPv6 only link install CLAT support if it is not >> already available. >> >> >>> On 6 Jul 2023, at 01:12, Tim Wicinski >>> <tjw.i...@gmail.com<mailto:tjw.i...@gmail.com>> wrote: >>> >>> Momoka >>> >>> Thanks for making DNSOP aware of this. We encourage anyone with comments >>> on the document adoption to reach out. >>> >>> Everything I've heard and read on this work (wearing no hats) is that this >>> is good work and should be adopted. >>> >>> thanks >>> tim >>> >>> >>> >>> On Tue, Jul 4, 2023 at 5:15 AM Momoka Yamamoto >>> <momoka....@gmail.com<mailto:momoka....@gmail.com>> wrote: >>> Dear dnsop wg >>> cc:v6ops wg >>> >>> My name is Momoka, the author of the draft-momoka-v6ops-ipv6-only-resolver. >>> This draft, which has already been introduced to the V6OPS Working Group, >>> aims to address a pertinent operational issue: facilitating the transport >>> of query packets from an IPv6-only iterative resolver to an IPv4-only >>> authoritative DNS server. >>> >>> In light of some suggestions in V6OPS and considering the overlapping >>> interests, I am introducing this draft to the DNSOP Working Group. Its core >>> proposition lies in the mechanics of transporting query packets rather than >>> the alteration of the DNS protocol behavior, but the operational context >>> undoubtedly makes this draft relevant to both groups. >>> >>> Here are links to the draft and the ongoing discussions in V6OPS: >>> >>> 1. Draft: >>> https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolv >>> er/ 2. V6OPS Thread: >>> https://mailarchive.ietf.org/arch/msg/v6ops/uNrPNbeUtA_D0xzqLfq5dNQ8 >>> 5OY/ >>> >>> >>> Currently, there is an adoption call in V6OPS for this draft set to end on >>> July 10, 2023. Your opinion, input, and suggestions will be highly valued >>> as we explore and progress this topic. I look forward to fruitful and >>> enlightening discussions. >>> >>> Best regards, >>> >>> Momoka Yamamoto >>> momoka....@gmail.com<mailto:momoka....@gmail.com> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org<mailto:DNSOP@ietf.org> >>> https://www.ietf.org/mailman/listinfo/dnsop >>> _______________________________________________ >>> v6ops mailing list >>> v6...@ietf.org<mailto: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<mailto:ma...@isc.org> >> >> _______________________________________________ >> v6ops mailing list >> v6...@ietf.org<mailto: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<mailto:ma...@isc.org> > > _______________________________________________ > v6ops mailing list > v6...@ietf.org<mailto: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<mailto:ma...@isc.org>
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
