Re: IPv6 only host NAT64 requirements?

Mark Andrews <marka@isc.org> Tue, 21 November 2017 01:15 UTC

Return-Path: <marka@isc.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 2D3591205F0 for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 17:15:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 wZAEELxLuswh for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 17:15:35 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64E09120454 for <ipv6@ietf.org>; Mon, 20 Nov 2017 17:15:35 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id C459A3AC64E; Tue, 21 Nov 2017 01:15:32 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8DFE0160082; Tue, 21 Nov 2017 01:15:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7E99916006A; Tue, 21 Nov 2017 01:15:32 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4AjfIqb_ZVKG; Tue, 21 Nov 2017 01:15:32 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 99EF8160054; Tue, 21 Nov 2017 01:15:31 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements?
From: Mark Andrews <marka@isc.org>
In-Reply-To: <16d4277c-5ea7-1615-fecb-355436e1fcfc@gmail.com>
Date: Tue, 21 Nov 2017 12:15:29 +1100
Cc: Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C1C841F-2443-4E24-8BC8-1863A8D063E6@isc.org>
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <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> <C9CDCB26-CDE6-4892-87D2-0934EEC5CE23@employees.org> <16d4277c-5ea7-1615-fecb-355436e1fcfc@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/wa3lY3cgjr_J5j9SIRRgcn1YfME>
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: Tue, 21 Nov 2017 01:15:37 -0000

> On 21 Nov 2017, at 12:01 pm, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 21/11/2017 12:53, Ole Troan wrote:
>> 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.
> 
> Sure, and we should try. But we can't fix legacy hosts in the hands of the general public.

But we can send feed back to the vendors of the products they are using that the product they are shipping does not work in this environment for this reason.  More and more of their clients will be behind some sort of IPv6 as a service and there products should work in that environment.  Eventually the fixed will get deployed.

I also think it is a myth that we tell ourselves that hosts won’t get updated.  They get updated all the time provided the vendor of the product puts out a fix.  Its getting the vendor to publish the fix that is the hard part.

Mark

>   Brian
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org