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

[Dan Wing <[e-mail]>]

On May 15, 2019, at 8:04 PM, Gábor Lencse <[e-mail]> wrote:
> On 5/16/2019 08:29, Dan Wing wrote:
> 
> [...]
>> 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.
> 
> I agree that NAT64 should finally diminish, but I don't think that its diminishing would be imminent. On the contrary, I expect that it will be used for at least a decade or even more.
> 
> My student has just finished her BSc final project thesis about examining the transition to IPv6 on the basis of available statistics. Her conclusion is that the IPv6 transition technologies will remain with us for a long time. Some technologies that aimed to help the early adoption of IPv6 (such as 6to4 or 6rd) are diminishing and give their place to the IPv4aaS technologies, where also DNS64 and NAT64 belong to.
> 
> Therefore, I think it is worth dealing with this draft, which could be a useful update to RFC 7050.

Any feedback on my other comments?  As an example, today, we don't have a way for client systems to chose outgoing IPv4 gateways (routers) or outgoing IPv4 NATs.  Well, we don't have a way that works.  The NAT64-SRV document assumes some sort of unstated relationship between IPv4 routing and DNS names, but I couldn't understand the assumed relatinoship (e.g., is all of example.com's IPv4 space always accessible behind a specific NAT64, and if it isn't, how is that expressed.  A concrete example is Apple's 17.0.0.0/8 allocation which has a couple of subnets publicly routable, and I struggle how a NAT64 operated within Apple's network with NAT64-SRV would be configured with SRV records and how the client does all the stuff it needs to do.  Naturally, not all clients will support NAT64-SRV so I guess the answer is NAT64-SRV-aware clients "work better", but all clients will work (somewhat worse, I presume with less-performant paths).

-d