Re: IPv6 only host NAT64 requirements?

Ole Troan <otroan@employees.org> Mon, 13 November 2017 05:50 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 70C6712949D for <ipv6@ietfa.amsl.com>; Sun, 12 Nov 2017 21:50: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 3A0OgJRO9rGY for <ipv6@ietfa.amsl.com>; Sun, 12 Nov 2017 21:50:21 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BB4128B4E for <ipv6@ietf.org>; Sun, 12 Nov 2017 21:50:15 -0800 (PST)
Received: from h.hanazo.no (nat64-4f.meeting.ietf.org [31.130.238.79]) (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 46B862D50CE; Mon, 13 Nov 2017 05:50:15 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 7340D200BF03D0; Mon, 13 Nov 2017 13:49:48 +0800 (+08)
From: Ole Troan <otroan@employees.org>
Message-Id: <BEC4C879-5657-49A5-9E71-ACD4214D3B07@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_8C7E207F-D256-40D8-8694-57F9F34FDFE1"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Mon, 13 Nov 2017 13:49:47 +0800
In-Reply-To: <B84A189C-AC6A-407B-B1E3-B5EACA4F66FB@consulintel.es>
Cc: 6man WG <ipv6@ietf.org>
To: Jordi Palet Martinez <jordi.palet@consulintel.es>
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <B84A189C-AC6A-407B-B1E3-B5EACA4F66FB@consulintel.es>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/XxBykkZcx3_ujlMSj6W9Q_iA1AQ>
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 05:50:23 -0000

Jordi,

> I was also thinking on this yesterday after the hackathon and I thing from that talk it is obvious that I will support that.

Thanks.

> 
> Also thought about this:
> 
> Could the “IPv6 node requirements document” include also a consideration for the same you mention here, in case there is IPv4-only in a dual-stack LAN with IPv6-only access?

Not sure I understand what dual stack LAN with IPv6 only access means.
If it is dual-stack, I'd assume you also have IPV4 routing.

> I’m almost sure that this is out of the scope of the 6man charter, but I also feel that this is somehow our job … alternatively what is the correct place to do that? May be a new sunset4 document? Or int-area? The point here is an IPv4-only host being used in a network using IPv6-only for the access ...

If you are talking about the reverse problem, an IPv4 only host requiring access to the IPv6 Internet.
Or an isolated IPv4 only host in an IPv6 only network... I'd think that would be better suited for sunset4.

Cheers,
Ole