Re: IPv6 only host NAT64 requirements?

[Mark Andrews <[e-mail]>]

Is there any reason to run DNS64 at all these days?  ipv4only.arpa can be a preconfigured
zone which allows CLAT to get its mapping.  All the phones have CLAT support.  Can we just
make DNS64 historic and let the phones run all IPv4 connections through CLAT rather than
having to stuff up DNSSEC and have IPv6 connections terminate in IPv4 servers without
the application knowing?

Mark

> On 14 Nov 2017, at 4:11 am, Philip Homburg <[e-mail]> wrote:
> 
>>> (c) Every ICMPv6 error message (type < 128) MUST include as much of
>>>   the IPv6 offending (invoking) packet (the packet that caused the
>>>   error) as possible without making the error message packet exceed
>>>   the minimum IPv6 MTU
>> 
>> Right. But when is that an actual issue for applications?
> 
> First, I naively put this in my TCP implementation. Technically that's
> not an application, though user land TCP does occur.
> 
> It also breaks my traceroute implementation.
> 
>> Then we are stuck with dual stack.
>> What Randy and Jen set out to try in the IETF experiment was to figure 
>> out if it would be possible to do IPv6 only + NAT64. Identify what was 
>> broken and then get that fixed. If we're stuck with dual stack (or IPv4 
>> only), then we're not moving towards the end-goal, are we?
> 
>> From a host point of view, I very much want to be dual stack. No magic.
> What goes over the wire is what the application sees. IPv6 is complex enough
> on its own. Adding DNS64/NAT64 make it less likely that people can actually
> understand what is going on. 
> 
> Hosts being dual stack doesn't say anything about backbone networks. You
> can do 464xlat on access routers or any other kind of IPv4 tunneling
> technology. By tunneling on access routers you can even preserve a 1500 octet
> MTU for IPv4.
> 
> In my view, the way we move to the end goal is when some networks really don't
> have any IPv4 anymore. 
> 
> When IPv6-only eyeball networks appear that don't offer any kind of IPv4
> connectivity, content providers either add support for IPv6 or they lose that
> group of potential customers.
> 
> After a while, cheap consumer networks just drop IPv4 because it too expensive
> to maintain. 
> 
> That's when IPv4 becomes truly legacy: you may have IPv4 connectivity at work,
> but possible not at home. Not at a random place that offers wifi, not in
> your hotel.
> 
> In corporate environments, assuming that all legacy applications can get
> rewritten to support IPv6, the next step is to install proxies that offer
> access to the few essential external services that are still IPv4 only.
> Though possibly, those services start installing reverse proxies to offer
> IPv6.
> 
> The only thing offering NAT64 to hosts does is making access networks IPv6-only
> while introducing a lot of complexity without increasing end-to-end IPv6
> connectivity.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]