Re: IPv6 only host NAT64 requirements?

[JORDI PALET MARTINEZ <[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?

[Jordi] Mark, this will not work: You need to consider that even if the phone is dual stack, there may be IPv4-only devices behind the phone (tethering), that NEED a DNS64. If the IPv4 device is validating, then is broken. If the IPv4 devices is not validating, then because the phone act as DHCP server for it, and provides the DNS, the phone acts as the DNS64 and even validator, then we are set … but phones today don’t do DNSSEC.


    
    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]
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [e-mail]
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.