Re: IPv6 only host NAT64 requirements?

JORDI PALET MARTINEZ <> Wed, 15 November 2017 07:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDE45129549 for <>; Tue, 14 Nov 2017 23:57:45 -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 pc8FFE4_6ZHF for <>; Tue, 14 Nov 2017 23:57:44 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 67628124BE8 for <>; Tue, 14 Nov 2017 23:57:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; s=MDaemon; t=1510732658; x=1511337458; 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=2cVCyh2n1rHBmqxWC2yo9qZ6F pnBlv/XqwKHx0ot//E=; b=OXvrW0gAVr3VC3qXdNiagejZPa/cP5YkbaUkSG5CW hjdN8exGDe84Fx0juJ1kzQ6NaTQDq7OvHJmN2VjfGpCPsp6G+rGaIBfEsinnvmxC /S5CB8HCByocjpvzyQfJhjsXKIxMyfS6vn2x5UPYWF864p16SGQdSu4cDJ10PZbV io=
DomainKey-Signature: a=rsa-sha1; s=MDaemon;; c=simple; q=dns; h=from:message-id; b=Lub6NvMw8+fohVnWbcQeNo7ctk2Il5XNNr2fvGO0M2Fv8tyqDqNeiqSrR0na Nt+SOmq6fbrhs9wCE/pay5zXA6sj0dXVLinYkVIsuRhEQCHGHMTh9UYU9 q+oZkY8eECo8fjTPqbrZETb6jleybmY2NHtI1s9G0TljfLHnrZRtco=;
X-MDAV-Processed:, Wed, 15 Nov 2017 08:57:38 +0100
X-Spam-Processed:, Wed, 15 Nov 2017 08:57:37 +0100
Received: from [] by (MDaemon PRO v11.0.3) with ESMTP id md50005624248.msg for <>; Wed, 15 Nov 2017 08:57:37 +0100
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-HashCash: 1:20:171115:md50005624248::auo8iYYvSpkaLDMP:00003cia
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Wed, 15 Nov 2017 15:57:27 +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: 7bit
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 07:57:46 -0000

That tunneling technology is 464XLAT, depending on how you deploy it:


-----Mensaje original-----
De: ipv6 <> en nombre de Philip Homburg <>
Responder a: <>
Fecha: martes, 14 de noviembre de 2017, 6:11
Para: <>
Asunto: Re: IPv6 only host NAT64 requirements?

    >I am not optimistic on the demand / need / value of dnssec in any scenario
    >....let alone an ipv6-only host validating an ipv4-only dns name. If the
    >folks operating this service cared, they could operate the server with
    >signed v6 names.  It is more reasonable in todays internet to asked the
    >server (lets assume most signed name scenarios are servers) to be setup
    >right (with v6). There is not a compelling reason why having v6 is
    >unattainable today for named nodes.
    DNSSEC is something that works today. Opinions are divided on what security
    it offers. Some people like it way more than the traditional CA system. 
    Other people believe that we should continue making random changes to the CA
    system in the hope that one day it will be secure.
    The problem for people who do local DNSSEC validation is that if neither the
    NAT64/DNS64 operator nor the operator of the target server cares about 
    DNSSEC/IPv6 then it just breaks.
    If all server operators cared, then there would be no need for NAT64/DNS64
    so the problem would not exist in the first place.
    If the NAT64/DNS64 operator cared, then they would offer be dual stack IPv4
    or a tunneling based transition technology that doesn't break DNSSEC.
    I guess the good news is that at least one group of people writing a local
    DNSSEC validating resolver (getdns) are aware of this issue and are adding
    code to handle this situation.
    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.