Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments

You are arguing to make DNS64 historic. I think that case is mutually exclusive.
What I mean is, I don't see that v6ops/IETF should stop trying to make DNS64 workable/compatible until the point it is retired. So it is not an argument against draft-byrne-v6ops-dnssecaaaa.

-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Andrews
Sent: 04 July 2018 03:46
To: Ca By <cb.list6@gmail.com>
Cc: v6ops@ietf.org WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments

While it will mitigate things it is a case of the tail wagging the dog and really the correct solution is to make DNS64 historic.  DNS64 has always been a case of tail-wagging-dog.

Accounting could have been fixed by “if next hop is IPv4 do accounting on the that layer”.  That should have been a quick fix for the telcos.

It was claimed "This will be a short term hack”.  Yeh, really?

It was claimed “Hosts won’t need to be upgraded” yet all those hosts (cell
phones) supported personal hotspots with IPv4 clients.  Almost all cell phones have some mechanism to support IPv4 clients today.

It was claimed “Than DNS64 was the only way that would let one know when it was safe to turn off IPv4 as a service as nothing else would move the traffic to IPv6”.  Yet we see traffic prefering IPv6 instead of IPv4 when DNS64 is not in use.

It was claimed that DNS64/NAT64 was better than tunnels yet it has basically all the same problems.  You have a smaller PMTU for translated packets.  Bring with it PMTUD problems, mss re-writing in the NAT64 mitigates some of the for TCP but the problem still exists.

It was argued at the time DNSSEC problems were not properly addressed and that has been demonstrated to be true.

The IETF process itself doesn’t lead to got solutions because if you have argued in the working group against something you get ignored at IETF last call with “you argued that in the W-G and lost”.

There is NO REASON to keep DNS64.  The current crop of phones will work without it.  464XLAT doesn’t need DNS64, it just need ipv4only.arpa configured on the recursive servers.  For wireline / fixed wireless / personal hotspot there are
IPv4 only clients that have to be handled so DNS64/NAT64 was never enough.

Put DNS64 out of its misery.

> On 4 Jul 2018, at 5:37 am, Ca By <cb.list6@gmail.com> wrote:
> 
> 
> 
> On Tue, Jul 3, 2018 at 10:11 AM Fred Baker <fredbaker.ietf@gmail.com> wrote:
> A general note. I have wondered aloud about interest in several new drafts, and managed to miss Cameron's:
> 
> https://datatracker.ietf.org/doc/draft-byrne-v6ops-dnssecaaaa
> https://tools.ietf.org/html/draft-byrne-v6ops-dnssecaaaa
>   "DNSSEC Resource Record Should Include AAAA", Cameron Byrne, 
> 2018-07-01,
> 
> If you want it on the agenda in two weeks, now would be the time to say so.
> 
> No, i will not be present. 
> 
> But  i am interested in folks sending feedback on if this is useful.  The goal of this I-D is to harmonize dns64 and dnssec deployment with an ideal solution, as opposed to falling into a worst case where folks pick one or the other.
> 
> 
> 
> > Begin forwarded message:
> > 
> > From: Ca By <cb.list6@gmail.com>
> > Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments
> > Date: July 2, 2018 at 2:55:09 PM PDT
> > To: Fred Baker <fredbaker.ietf@gmail.com>
> > Cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, 
> > "v6ops@ietf.org list" <v6ops@ietf.org>
> > 
> > 
> > 
> > On Mon, Jul 2, 2018 at 1:41 PM Fred Baker <fredbaker.ietf@gmail.com> wrote:
> > 
> > 
> > > On Jul 2, 2018, at 1:17 PM, JORDI PALET MARTINEZ <jordi.palet@consulintel..es> wrote:
> > >
> > > DNSSEC is *only* broken if the dual-stack host is doing DNSSEC validation over the synthetized AAAA.
> > 
> > So you're worried about DNSSEC validation working through NAT64 in the case that the host is using the DNS service in the IPv4 network through the NAT64 device.
> > 
> > That doesn't have anything to do with DNS64; an a 464XLAT network, if we believe RFC 6877, the issue you raise happens in the absence of DNS64.
> > 
> > A good postion for the IETF to take is that one should only produce 
> > a signed A if they can also produce a signed AAAA, which is not a 
> > tall order these says
> > 
> > https://tools.ietf.org/html/draft-byrne-v6ops-dnssecaaaa-00
> > 
> > 
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@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: marka@isc.org

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops