Re: IPv6 only host NAT64 requirements?

Tim Chown <> Mon, 13 November 2017 13:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AAD33129455 for <>; Mon, 13 Nov 2017 05:42:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W7PpB0CDJ35d for <>; Mon, 13 Nov 2017 05:42:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C54F127843 for <>; Mon, 13 Nov 2017 05:42:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20170213; t=1510580569; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=g2ZgtRqq2cloGTsUlMy1O/q3UmRRYy28cWZf/83j+Bc=; b=LPQf1D0ezge9oXbpPQkgVzM83oBFRkxu1GEYb6eDye3lYRJBGMJt0YwkksH/3brPAUbUyhnJU1MLYQVtCcSTcL/7B3U0kwIYf2imq+xUaRRaAWYZoJU7fHe5RVEbtR+FSsvVeU++ql+Bc84kqu7FJ7VNtOPDk87WmF59Fe1LCTk=
Received: from ( []) (Using TLS) by with ESMTP id uk-mta-60-nLfW6C7gNt2TWoNXDvQV0Q-1; Mon, 13 Nov 2017 13:42:45 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id; Mon, 13 Nov 2017 13:42:44 +0000
Received: from ([fe80::d9b7:5aa5:5084:74c2]) by ([fe80::d9b7:5aa5:5084:74c2%13]) with mapi id 15.20.0239.005; Mon, 13 Nov 2017 13:42:44 +0000
From: Tim Chown <>
To: "Rajiv Asati (rajiva)" <>
CC: Ole Troan <>, Timothy Winters <>, 6man WG <>
Subject: Re: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Date: Mon, 13 Nov 2017 13:42:44 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3445.4.7)
x-originating-ip: [2001:a88:d510:1101:e565:a751:53f4:fd9a]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 20:EbTs+2L9urINiSQiJckCyvxGkdSbSkwPNnlGQ2WBLJg09Mn1Gk0L3TD9zWNMLl3sBaX8fwR2YpPbwb0mrwpN7hi+zfdQV47ApUMCsny8dbVpTfAgs7qFMYQllORqe7vLKYNiug6ZVhOuaa5H0mqRIireA3xI4bLz/Z+ASoUmpfU=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 0e2ffcfb-d930-482a-6e7d-08d52a9c6b5a
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1137;
x-ms-traffictypediagnostic: AM3PR07MB1137:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(274715658323672)(278428928389397)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1137;
x-forefront-prvs: 0490BBA1F0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(189002)(24454002)(966005)(81156014)(53546010)(81166006)(72206003)(76176999)(36756003)(786003)(478600001)(6486002)(99286004)(7736002)(86362001)(106356001)(4326008)(82746002)(316002)(8936002)(5660300001)(83716003)(33656002)(101416001)(25786009)(105586002)(14454004)(189998001)(8676002)(50986999)(6506006)(6246003)(3660700001)(3280700002)(6436002)(2906002)(5250100002)(74482002)(2900100001)(229853002)(2950100002)(54906003)(6116002)(68736007)(102836003)(97736004)(6512007)(6306002)(305945005)(42882006)(6916009)(50226002)(53936002)(57306001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0e2ffcfb-d930-482a-6e7d-08d52a9c6b5a
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 13:42:44.6365 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137
X-MC-Unique: nLfW6C7gNt2TWoNXDvQV0Q-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
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: Mon, 13 Nov 2017 13:42:58 -0000

> On 13 Nov 2017, at 13:27, Rajiv Asati (rajiva) <> wrote:
> @Ole, I agree. Just swap the RFC#.   
>>> - Must be able to do NAT64 prefix discovery (RFC6052)
>>> - Synthesise IPv6 address from an IPv4 literal (RFC7050)
> @Tim,
>> If someone wishes to propose text in a new section 10.2 on “IPv6-only” operation, we could include that if the WG agrees.  This 
> It might be useful to have some text in section 14 (v6 router) to accommodate v4 hosts/apps in case of v6-only uplink/ WAN. 

I think the trick for 6434bis is deciding what the scope of the doc is. Such suggestions, while they certainly have merit, are a slippery slope to adding many things, as we’ve seen when Jordi started proposing transition mechanisms for RFC7084-bis.  

Steer from the WG is, as ever, very welcome.


> Cheers,
> Rajiv  
> On Nov 13, 2017, at 8:08 AM, Tim Chown <> wrote:
>> Hi,
>>> On 13 Nov 2017, at 02:50, Ole Troan <> wrote:
>>> At the hackathon there was quite a bit of testing of IPv6 only hosts with access to the IPv4 network via a NAT64.
>>> While many applications work well on a classic IPv6 only host, there are a few things required to make all applications work.
>>> - Must be able to do NAT64 prefix discovery (RFC6052)
>>> - Synthesise IPv6 address from an IPv4 literal (RFC7050)
>>> This is to be able to deal with IPv4 address literals. Which are common in protocols like SIP/ICE/STUN.
>>> These can be implemented directly in applications, or it can be implemented in the host stack (although application might still have to change).
>>> - Should do local DNS64 to support DNSSEC (RFC6147)
>>> (if you do validation).
>>> A DNS64 service in the network looks like a man in the middle attack, so to support DNSSEC, validation should happen before synthesizing, and must be done on the host itself.
>>> If this is the direction we want to go. Encourage IPv6 only host deployments (as opposed to dual stack hosts), are these requirements we'd like to add to the IPv6 node requirements document? Somewhere else?
>> draft-ietf-6man-rfc6434-bis-02 includes a (very short) Section 10 on transition, see
>> If someone wishes to propose text in a new section 10.2 on “IPv6-only” operation, we could include that if the WG agrees.  This could be something for TimW to add as a question when the draft is presented in 6man.
>> Tim
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> Administrative Requests:
>> --------------------------------------------------------------------