Re: IPv6 only host NAT64 requirements?

Ole Troan <otroan@employees.org> Mon, 13 November 2017 15:45 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 ED53C127843 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 07:45:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 Yzw87XRYVxUq for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 07:45:31 -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 2F7611200FC for <ipv6@ietf.org>; Mon, 13 Nov 2017 07:45:31 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 D5AC42D4F99; Mon, 13 Nov 2017 15:45:30 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 6ADFB200BFFAC1; Mon, 13 Nov 2017 23:45:06 +0800 (+08)
From: Ole Troan <otroan@employees.org>
Message-Id: <E5C5DFDE-DB7D-41BC-A197-7329C2FEE2F1@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_211A7385-46B6-4F4C-B1A8-5615346BA5FF"; 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 23:45:05 +0800
In-Reply-To: <CAD6AjGSzXPEN1Snu9=Acnc6xggJ3=9T4Zks1H=+pfNOyt-qaoQ@mail.gmail.com>
Cc: 6man WG <ipv6@ietf.org>, Tim Chown <Tim.Chown@jisc.ac.uk>
To: Ca By <cb.list6@gmail.com>
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk> <48E76543-3DD4-43E8-9B50-5CC4D9D76A2F@cisco.com> <7C928B66-8D07-42A0-9168-617E2978227F@jisc.ac.uk> <CAD6AjGQdenKMxQ6KBeBGzTu6fAtR9d_x7HuSPYVATcKEOdmNUQ@mail.gmail.com> <D4AB0373-B105-4E13-B4CA-94FCDACCEBA6@employees.org> <CAD6AjGSzXPEN1Snu9=Acnc6xggJ3=9T4Zks1H=+pfNOyt-qaoQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/AtVwNQfpR1U-QnwIMcthUM-INCA>
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 15:45:33 -0000

Cameron,

> 
> Yes, the first 2 are not objectionable and are already well know, documented and deployed as part of various transition solutions.
> 
> My feeling is the plane is already in flight and operators do not need any additional guidance / confusion from the ietf.
> 
> In short, this is a solved problem and the industry needs more stability and less tweaking .... especially in something fundamental like the node definition

This isn't guidance to operators, this is guidance to implementors.
As we found during the hackathon, multiple stacks do lack the first two. And as a consequence applications break.
Now you can argue if we want to put the burden of this on applications or on the host stack. If the former the node requirements document might not be the right place.

> 
> http://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/T-MobileUSA.png

I thought this deployment provided dual stack service? 464XLAT, no?
That's a different problem than what we are trying to solve here.

Cheers,
Ole