Hi Dmitry,

> 1. Is this a realistic recommendation for data center operators to create
> signed records for thousands of synthesized addresses of IPv4 only hosts?
> E.g., are there tools which allow to do that easily and easily update in case of
> network renumbering or new hosts being deployed dynamically?

Why the operator who creates thousands of (signed) A records for those IPv4 only hosts couldn't create also (signed) AAAA records for the said hosts? Or are those hosts such that they all update their own DNS records? 

> 2. I agree with you that a scenario with 2 NAT64 and shared IPv6 prefix can be
> solved by routing based on prefix which includes the IPv4 ranges bits. But my
> original question was somewhat different - what if there are NAT64 and they
> serve different IPv4 address ranges, mapped to *different* Pref64/n.

If the network does not provide the routing assistance, does not provide AAAA DNS records for those hosts, then I suppose the packets do not go to the right destination.

Maybe the operator who has that kind of limitations should not introduce IPv6-only pockets to their network at the first place:-)

> I don't yet see how routing alone helps there. Perhaps I'm missing something,
> so let me give an example - let's say the mappings table is A4_1 -> Pref64_1/n
> (for NAT64_1, path to Internet), A4_2 -> Pref64_2/n (for NAT64_2, path to
> datacenter), and heuristic for a packet destined to A4_1 incorrectly formed
> Pref64_2:A4_1 as IPv6 destination address.

The DNS64 of the network would give Pref64_1 as the prefix for ipv4only.arpa, so wouldn't the incorrectly formed address be instead Pref61:2:A4_2? (This is detail, I got the idea).

> If the IPv6 network has only Pref64_1/n and Pref64_2/n routes, then such
> packet Pref64_2:A4_1 will be routed to NAT64_2, which either will drop the
> packet (if it verifies that IPv4 is in the allowed range for the used IPv6 prefix),
> or will translate it to A4_1, and send packet destined to Internet into
> datacenter network, that may not go anywhere.

Yes, that's why we proposed the router to choose the right NAT64 based on the IPv4 address, or to avoid IPv4 literals that provide these kinds of mines. Special use IPv4 literals have serious issues already in the traditional IPv4-only setups.

> If the network has also Pref64_2:A4_1 -> NAT64_1 route, to compensate for
> heuristic lack of support of mappings, such route will bring the packet to
> NAT64_1, but again, unless NAT64_1 has a configuration for route Pref64_2,
> NAT64_1 will not know how to translate Pref64_2:A4_1 -> A4_1 and may
> drop the packet.

Right, the datacenter NAT64s would need to be configured to accept packets for translation that come with Internet NAT64's Pref64::/n. 

Now that I think of this more, maybe the bigger problem would be actually in the return direction, as the datacenter's NAT64 would need to be clever on what is the Pref64::/n it needs to use for a packet going back to the host - the NAT64 could not use it's "default" Pref64_2, but would have to use Pref64_1 the IPv6-only host chosen to use. This likely creates additional state.

> So is the assumption/suggestion that in addition to routing which include IPv4
> ranges bits, all NAT64s are configured with shared configuration, so that they
> know about each other prefixes? 

This was the assumption in the range-support proposal, yes.

>Or the assumption is that one would never
> want to have Pref64_2 != Pref64_1, and just one shared Pref64 is sufficient
> always?

Maybe that is needed with the heuristics-based approach, for addresses that are delivered as IPv4 literals to hosts. I try to clarify these restrictions of the heuristic-tool to the draft. 

> 3. If the heuristic is a documented kludge - what are the reasons it is put on
> the standards track instead of informational/experimental?

What is the DNS64/NAT64 framework but a documented kludge? The stds track was agreed on the chartering phase and I think it is justified as we need e.g. globally hosted IPv4-only name, ipv4only.arpa.

Best regards,

	Teemu