IETF Logo Mail Archive

IPv6 only host NAT64 requirements?

Ole Troan <otroan@employees.org> Mon, 13 November 2017 02:51 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAF7127517 for <ipv6@ietfa.amsl.com>; Sun, 12 Nov 2017 18:51:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lqsFvYU8fcP for <ipv6@ietfa.amsl.com>; Sun, 12 Nov 2017 18:51:09 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5BCE1286B2 for <ipv6@ietf.org>; Sun, 12 Nov 2017 18:51:09 -0800 (PST)
Received: from h.hanazo.no (nat64-ad.meeting.ietf.org [31.130.238.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 7A1782D5038 for <ipv6@ietf.org>; Mon, 13 Nov 2017 02:51:09 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id AAF14200BE76BA for <ipv6@ietf.org>; Mon, 13 Nov 2017 10:50:41 +0800 (+08)
From: Ole Troan <otroan@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_B97EE42B-FA32-4DE2-9858-BFFF233271F3"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: IPv6 only host NAT64 requirements?
Message-Id: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org>
Date: Mon, 13 Nov 2017 10:50:40 +0800
To: 6man WG <ipv6@ietf.org>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/MQH3sNZ9QKHSW0Ipcfvvzp943k0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Nov 2017 02:51:23 -0000

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?

Best regards,
Ole

v2.23.0 | Report a Bug | By Email