On 31/07/2017 02:44, Bill Fenner wrote:
>> On Jul 30, 2017, at 9:27 AM, Ted Lemon <mellon@xxxxxxxxx> wrote:
>>
>>> On Jul 30, 2017, at 7:53 AM, Lee Howard <lee@xxxxxxxxxx> wrote:
>>> How would default-NAT64 get application developers to fix their
>>> applications?
>>
>> One of the biggest offenders historically was a Cisco VPN, so presumably having Cisco people experience that being borken would help. Similarly with Microsoft people and the Windows Update issue that was mentioned earlier. Desire to avoid public embarrassment is a useful motivating factor.
>>
>
> On the other hand, the corporate VPN I use publishes a support matrix on their public web site, and specifically says that IPv6 is not supported. I don't think they're embarrassed about it.
>
> Most people using VPNs will be in a weird state with NAT64 anyway, assuming that they use the VPN's DNS server (e.g., to access internal resources by name). A split-tunnel VPN user will lose access to v4-only sites, since it will lose dns64 translation (and will simultaneously lose the ability to detect the nat64 via the rfc7050 lookup mechanism). Does this mean "don't bother with split tunnel VPNs in a nat64 network"?
So here's the thing. All NAT breaks stuff, therefore NAT64 breaks stuff.
In fact, it breaks stuff in more complex ways than NAT44 or even NAT444.
I see no good ending to the attempt to make NAT64 work in all circumstances.
Brian