Re: [v6ops] draft-ietf-v6ops-nat64-srv

[Dan Wing <[e-mail]>]

On May 14, 2019, at 6:08 PM, Erik Kline <[e-mail]> wrote:
> From: Mikael Abrahamsson <[e-mail]>
> Date: Mon, 13 May 2019 at 10:04
> To: Ron Bonica
> Cc: [e-mail]
> 
> On Mon, 13 May 2019, Ron Bonica wrote:
> 
> > This week, please review and comment on draft-ietf-v6ops-nat64-sr .
> 
> I'm generally sympathetic to the problem space this draft tries to solve.
> 
> Really?  I don't see it yet..  I don't foresee any client implementing this level of complexity -- it doesn't actually buy them anything.

The part of the I-D that seems useful is the ability to use a centralized DNS server (e.g., 1.1.1.1, 8.8.8.8, some might say "DoH") which is not participating in the DNS64/NAT64 infrastructure (and thus doesn't do the normal DNS64 synthesis) and having the client synthesize AAAA.  But RFC7050 already anticipated that need for client synthesis of AAAA with its existing support for client-side DNSSEC.  Perhaps a a document that described how to elicit an RFC7050 response (that is, elicit a synthesized address) and have the client use that information when communicating to a centralized DNS server could be helpful.  A careful read of RFC7050 should be sufficient to implement that, at least that was our intent when we wrote RFC7050 that it would be clear enough how the client can do its own synthesis.

I agree with Erik that the NAT64 balancing seems a lot of effort for the client with little gain for the client. NAT64 as a technology will diminish as native IPv6 overcomes the IPv4 inertia so engineering fancy NAT64 solutions is not "where the hockey puck is going", as they say.

-d