Re: IPv6 only host NAT64 requirements?

Brian E Carpenter <> Tue, 14 November 2017 00:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6ADA1288A9 for <>; Mon, 13 Nov 2017 16:11:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CL6htUWGFEMl for <>; Mon, 13 Nov 2017 16:11:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 625791200CF for <>; Mon, 13 Nov 2017 16:11:49 -0800 (PST)
Received: by with SMTP id 207so11150774pgc.12 for <>; Mon, 13 Nov 2017 16:11:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fXy04IJNCjnId6U3LGCUzBg2aPnpO9v+8PRBqGUS/6k=; b=ZW5/qwMTyOr/YAmy3gCXjI1VGl18KAaYtpoyjht7UWkblu+nn+r6f4Kkfd3krqnlLl nris06NDgUzqAKlRKUU2cou3n3uI/GRPLURA+t/4xq2HDGa1byYLoXV04hrAnrAFYG+L BN5uRldfpzGS7OEq5XFMrVtPsP3RKltQqzFOx1WX5rqZPYMR/vnRoZuYlGcuZ+jsKwi/ aPvu1joF8bu+HbVhaxToJwq27O/Eq+07dqffsg9gropkNEok+mUsTnx3LexpgVfcE+23 z1rOEXTINZNse9yzfT9DhoY100gGREIDq6tHwL6/j182sYaWSk3es4wa4CcbtVWl7LDg dSwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=fXy04IJNCjnId6U3LGCUzBg2aPnpO9v+8PRBqGUS/6k=; b=hvpIsFX7SEgj1YYMTZ60vbzgrAVuqCoV07/p/cpsfDbXesksfb0e6wcXIerN56qkeE lqbTsxMM5W+9ZOQvkZCrXZgztwBY3vbiRvILk3I/MgF6AYRAaWySVgPeFHLuZwBE3WXZ vFzVd0dHxnZD+Ybvj36crWNOgOI1HvrBTedKb/DBTwGg18FAoYChNawywwM3WF+F2W4b Ar6joPNHHn86nL9EKTP1PwVUp/LAUxSEuB/pT9HKKHByvx0rbWan9wdLdNcc0ywirVHA 6FWzJ0c1IPxoBrveS9CRXq+ZO7VXOLdRIzMYxn+zvRC2TKPvc0ODn1nkCdkqkUg4W7kl Ma2w==
X-Gm-Message-State: AJaThX635MERi6ff5fn2E32dEeP44ft/E+koeKfprusH1YhNdO4cKjJx 2kaDtjv5volBs5EkoRkJK/Oz5g==
X-Google-Smtp-Source: AGs4zMYtO8quRYTyKVa2g9QgVtgD5PglG65yCcVNv/By9Cb+Aoadwld0g/WNvlytK/eKR7zqrTSQfQ==
X-Received: by with SMTP id g3mr10779554pld.400.1510618308709; Mon, 13 Nov 2017 16:11:48 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id t2sm38242691pfk.90.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 16:11:47 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Philip Homburg <>,
References: <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Tue, 14 Nov 2017 13:11:46 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
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: Tue, 14 Nov 2017 00:11:50 -0000

On 14/11/2017 05:16, Philip Homburg wrote:
> But for host software there is a lot more incentive to support dual stack then
> to do the extra step for NAT64.
> The big problem I see for NAT64 is that for old IPv4-only applications you 
> have to make two fundamental changes to the application. The first to 
> make sure that the application handles IPv6 in every possible way. And a
> second pass that makes sure that every place where an IPv4 address literal 
> is handled, works with NAT64. 
> For an application writer it is better to try to avoid doing the second pass.

I think there is a missing document, and it may well belong in v6ops not
6man: "IPv4 Applications on an IPv6-only Host". 

Your text above is probably a good summary of what the document needs
to cover. (I also suspect that if this document existed, we wouldn't need
Jordi's draft attempting to define "IPv6-only".)