Re: IPv6 only host NAT64 requirements?

Ole Troan <otroan@employees.org> Mon, 20 November 2017 23:53 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 6BFA712EAF1 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 15:53:31 -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 V8wqZGhv90KD for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 15:53:29 -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 D7E6B12EAF0 for <ipv6@ietf.org>; Mon, 20 Nov 2017 15:53:29 -0800 (PST)
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (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 F0B7A2D5120; Mon, 20 Nov 2017 23:53:28 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 491C8200CDCCBE; Tue, 21 Nov 2017 00:53:27 +0100 (CET)
From: Ole Troan <otroan@employees.org>
Message-Id: <C9CDCB26-CDE6-4892-87D2-0934EEC5CE23@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_A2D2AAFC-C763-47ED-9C97-751230222F39"; 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: Tue, 21 Nov 2017 00:53:26 +0100
In-Reply-To: <a77addfd-a53c-bb3a-5417-e3b18a03d8e9@gmail.com>
Cc: Lee Howard <lee@asgard.org>, "Manfredi, Albert E" <albert.e.manfredi@boeing.com>, 6man WG <ipv6@ietf.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <CAFU7BARoXgodiTJfTGc1dUfQ8-ER_r8UOE1c3h-+G0KTeCgBew@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <F9E3BD88-38E0-4329-A4BF-22083A023268@employees.org> <f673d6c7-570e-b2b8-e8aa-15d73ea8ba3f@gmail.com> <e697e64116f245f0b462a1a2277c704b@XCH15-06-11.nw.nos.boeing.com> <D638AAD2.8C6F2%lee@asgard.org> <3a20ce57-2a61-bca3-9e25-6d4c38c12888@gmail.com> <200AD734-6AEC-4CE9-A921-B9555821B646@employees.org> <a77addfd-a53c-bb3a-5417-e3b18a03d8e9@gmail.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/zkXNIrjg7YkFjsL4Cv7-NCgV-oo>
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, 20 Nov 2017 23:53:31 -0000

Brian,

>>> One thing that we demonstrated very convincingly last week
>>> is that there are enough legacy devices and applications in
>>> existing user hosts that the co-existence plan is still needed.
>>> (And, BTW, we demonstated it for user hosts belonging to
>>> relatively sophisticated users.)
>> 
>> Huh?
>> Data please.
> 
> Well, I assume that Jen et al will produce a summary report, but
> the number of tickets at https://tickets.meeting.ietf.org/wiki/nat64
> tells me that ietf-nat64 did not provide a smooth co-existence
> experience for everybody. Imagine that each of those tickets equates
> to one support call per week, multiplied by the number of hotels
> in the world.

The purpose of the experiment was to get some real data.
Before jumping to conclusions let's get the report. No-one thought this would work without a single flaw.
And this experiment is not about providing IPv6 only service to hotels, it is about providing IPv6 only + NAT64 to the IETF network.

32 tickets. Where people were encouraged to report anything. You cannot just assume those are real issues without looking at them.
E.g. you can discount 1151, 1175, 1185, 1160, 1174, 1172, 1159 straight away.
Some tickets may contain multiple issues and so on.

Looks like we're left with a handful of applications and some OS issues. We're not talking rocket science to get those fixed.

Ole