Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion

[Andrew Sullivan <[e-mail]>]

Hi,

On Sun, May 13, 2018 at 07:07:18PM -0700, Fred Baker wrote:
> Considering https://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00, discussed at IETF 101 using the slides at https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-nat64-deployment-guidelines-in-operator-and-enterprise-networks-00. I'd like to invite discussion on the list. What thoughts do folks have on this draft?
> 

Thanks for asking.

I have read the draft.

In section 2, I find this claim bizarre:

   If a device connected to an IPv6-only WAN queries for a domain name
   in a signed zone, by means of a recursive name server that supports
   DNS64, and the result is a synthesized AAAA record, and the recursive
   name server is configured to perform DNSSEC validation and has a
   valid chain of trust to the zone in question, it will
   cryptographically validate the negative response from the
   authoritative name server.  So, the recursive name server actually
   lie to the client device,

Of course they are "lying" to the client: that's literally the
feature.  What the DNS64 mechanism does is give you answers for a AAAA
record when you otherwise wouldn't get one.  And indeed, a validating
DNS64 resolver can give you that synthetic AAAA with greater
confidence, having validated that the AAAA really for sure doesn't
exist.

Similarly,

   If the client device performs DNSSEC validation on the AAAA record,
   it will fail as it is a synthesized record.

This is only true if the "client device" is NAT64-oblivious.  That
point is made at some length in RFC 6147, in sections 3, 5.5, and 6.2.
It isn't like we didn't think about this.  Essentially all of section
2 is covered at length in RFC 6147; and the "obvious solution"
contained in this section is rather non-obvious to me, given that such
a requirement is both beyond the means of the person who has the
problem and also, in fact, the very problem NAT64/DNS64 is trying to
mitigate.  Indeed, if the solution were just, "Everyone should deploy
IPv6," we wouldn't need NAT64/DNS64 at all.

When we wrote DNS64, we made the assumption (which I think we made
clear in RFC 6147) that it was sufficiently early in the
validator-deployment curve that it would be ok to break certain DNSSEC
assumptions for people who were really stuck in a NAT64/DNS64-needing
world.  Validators could come to know about NAT64, could perform the
necessary discovery, and could do their own synthesis.  This is why we
overloaded the CD bit.  (I am aware that Mark Andrews hated that
decision, but it was the only one on offer unless we wanted to do
multiple round trips for every one of these cases -- something I still
think would have been a bad idea.  And it was the WG consensus; Mark
was in the rough.)

In section 3, there are some arguments for deployment scenarios that
are explicitly ruled out by NAT64/DNS64.  In particular, if 3.a. is
true then the validating resolvers need to be DNS64-aware too (as RFC
6147 pointed out); if not, then they can't validate.  3.b. was always
a known issue with NAT64/DNS64, and my position then (and now) was
that we weren't trying to make this perfect, we were trying to
mitigate pain.  I have been pleasantly surprised by the success of RFC
6877, which seems to me to be a partial answer to the limitations of
NAT64/DNS64.  But I did not believe then, and I do not believe now,
that we should make the transition services perfect.  We need to make
them just good enough that most things mostly work, and rely on
commercial pressure (particularly from lousy performance) to ensure
that people who are IPv4 only get the message.

Section 3.1 describes a case that simply doesn't work: the whole point
of publishing NAT64 and DNS64 together was to make complementary
things that worked together.  I am struggling to imagine what
conceivable value this would be (or in what world random authoritative
servers on the Internet are going to configure synthetic records for
everyone else).

In general, I find the use cases to be improbable.  Anyone who is
willing to go to the effort of deploying NAT64 or 464XLAT is going to
be able to deploy DNS64 too.  Virtually nobody is doing DNSSEC
validation in endpoints even today, and virtually everyone who is has
the capacity to do synthesis themselves as well.

So, I don't really understand what the document is trying to do.  I
think it would be useful to tell people, "If you're going to deploy
NAT64, you need DNS64, and here are some limitations."  This document
seems instead to pretend that there are some sorts of mitigations for
most of these issues, some of which appear to involve getting other
people on the Internet to do things.  I don't see how it helps any
transition, and I don't see how it helps people trying to deploy
NAT64+DNS64 to cloud the water with a bunch of scenarios that won't
work and were never expected to work.

Best regards,

A

-- 
Andrew Sullivan
[e-mail]