Re: IPv6 only host NAT64 requirements?

[Ole Troan <[e-mail]>]

Hi Med,

>> 
>> For the IETF NAT64 IMHO
> 
> [Med] As you are mentioning "IETF" explicitly, NAT64 may not be the appropriate "IPv4 service continuity" solution here.

Why not?
Interesting to hear your views here, especially since it "almost" worked at IETF100.

> I need:
>> - No dependency on DNS64. Want to use recursive resolver I trust plus
>> local validating resolver.
>> - Not depend on the success of PCP for NAT64 prefix discovery
>> - If the host couldn't learn the NAT64 prefix any other way, I suppose it
>> could throw an ICMP echo towards
>>   64:ff9b::127.0.0.1 (or perhaps just 64:ff9b::)
>> 
> 
> [Med] Fair. That is another "add my favorite solution" to the list.
> 
>> But I also see there being different deployment options here.
>> Btw, for multiple NSPs, couldn't you partly solve that by injecting more
>> specifics into routing?
> 
> [Med] It is not only about forwarding/routing, but also how a host can pick the appropriate prefix64 for address synthesis. Things may be obvious if you can consider the example of RFC7050:
> 
> 
>                      NAT64 "A" ----- IPv4-only servers in a data center
>                     /
>   IPv6-only node---<
>                     \
>                      NAT64 "B" ----- IPv4 Internet

Firstly this seems like it is over engineered. Has anyone actually deployed NAT64 this way?
(Given that this is quite rare even in IPv6 only or IPv4 only scenarios. Look at implementation status of RIO for example).

Secondly, RFC7050 says:

   The heuristic discovery method described herein does not support
   learning of the possible rules used by a DNS64 server for mapping
   specific IPv4 address ranges to separate Pref64::/n prefixes.
   Therefore, nodes will use the same discovered Pref64::/n to
   synthesize IPv6 addresses from any IPv4 address.  This can cause
   issues for routing and connectivity establishment procedures.  The
   operator of the NAT64 and the DNS64 ought to take this into account
   in the network design.

Which to me reads, this just doesn't work.

If we think NAT64 is a fundamental piece of technology to make progress on the transition, then I think we should focus on making it as simple and deployable as possible.

Cheers,
Ole