Re: IPv6 only host NAT64 requirements?

"Rajiv Asati (rajiva)" <> Mon, 13 November 2017 13:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8D80129445 for <>; Mon, 13 Nov 2017 05:27:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 YdJz_MJRVl51 for <>; Mon, 13 Nov 2017 05:27:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A86ED1243F3 for <>; Mon, 13 Nov 2017 05:27:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=10023; q=dns/txt; s=iport; t=1510579632; x=1511789232; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pgzNiH8LwYoNdFYIjF8LpE6Fqpdl/uqW6BqsiAkjz0Q=; b=en7owTnSk8eWkUixAfbMj43fRGrSiLmJwrzDaIMKg/QhArXBYIhYzfB8 AuaJJ917lSOXhkf2C3Hm63u5D4bavbaAfcpTeWErvmJhfx5QqZqZG7acg rnO/ebFF/WLrKapH8M9bIRvg1O/Wz6jtFlSM2qkHyrxvYFpX7H2zdY11t 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.44,389,1505779200"; d="scan'208,217";a="323597088"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Nov 2017 13:27:11 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id vADDRBfK024364 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Nov 2017 13:27:11 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 13 Nov 2017 07:27:11 -0600
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Mon, 13 Nov 2017 07:27:11 -0600
From: "Rajiv Asati (rajiva)" <>
To: Tim Chown <>
CC: Ole Troan <>, Timothy Winters <>, 6man WG <>
Subject: Re: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTXCpRAMcG+a5XKUyB+nmCuhf8DKMSrSsA//+guII=
Date: Mon, 13 Nov 2017 13:27:10 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_48E765433DD443E89B505CC4D9D76A2Fciscocom_"
MIME-Version: 1.0
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:27:15 -0000

@Ole, I agree. Just swap the RFC#.

- Must be able to do NAT64 prefix discovery (RFC6052)
- Synthesise IPv6 address from an IPv4 literal (RFC7050)


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.


On Nov 13, 2017, at 8:08 AM, Tim Chown <<>> wrote:


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.

IETF IPv6 working group mailing list<>
Administrative Requests: