Re: IPv6 only host NAT64 requirements?

JORDI PALET MARTINEZ <> Wed, 15 November 2017 08:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD24C1270A0 for <>; Wed, 15 Nov 2017 00:06:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vTf3i2jrCmvH for <>; Wed, 15 Nov 2017 00:06:27 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F078124BE8 for <>; Wed, 15 Nov 2017 00:06:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; s=MDaemon; t=1510733184; x=1511337984; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=/okV2CCz8mSYo9v97boKPVQf3 KpKoswzwKAb4T5DVFA=; b=N/Ba0SsQ/knmAxNkqz4b4A1t6B9dHlB8uSdJpNHhI ajs1RojL4FYfAQCtXI1hgUc/h9QVxa0nywxP6rKSUPEFtJRbToH8low9PEflrcVP Aev6XzND+ExxsLKcynHG1yICnyf8N+PdLXuNb2VSYGGR4Tu1VsdF2z8LJyPzJwjl cI=
DomainKey-Signature: a=rsa-sha1; s=MDaemon;; c=simple; q=dns; h=from:message-id; b=bq3PXjGMW21SLmGmP10XUQKu3Wi9VI9E9CToU5VepKuuCdrbHHS8aeuhjUu4 120xGRDIdM8awiOl6v7MUG+qxRIUM1eZVy9t8vhvc47kSc51DSMkLM0Z8 s57e6DkhPVqlkBdxeinK67ZDcYbgpHE8+BgNdKF0tuJb8BDYbjydyg=;
X-MDAV-Processed:, Wed, 15 Nov 2017 09:06:24 +0100
X-Spam-Processed:, Wed, 15 Nov 2017 09:06:23 +0100
Received: from [] by (MDaemon PRO v11.0.3) with ESMTP id md50005624254.msg for <>; Wed, 15 Nov 2017 09:06:22 +0100
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-HashCash: 1:20:171115:md50005624254::P9XojiyqWCh7IaTm:00003DNz
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Wed, 15 Nov 2017 16:06:06 +0800
Subject: Re: IPv6 only host NAT64 requirements?
To: <>
Message-ID: <>
Thread-Topic: IPv6 only host NAT64 requirements?
References: <> <> <> <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Nov 2017 08:06:29 -0000

Is there any reason to run DNS64 at all these days? 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.

    > On 14 Nov 2017, at 4:11 am, Philip Homburg <> 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
    > Administrative Requests:
    > --------------------------------------------------------------------
    Mark Andrews, ISC
    1 Seymour St., Dundas Valley, NSW 2117, Australia
    PHONE: +61 2 9871 4742              INTERNET:
    IETF IPv6 working group mailing list
    Administrative Requests:

IPv4 is over
Are you ready for the new Internet ?
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.