Re: IPv6 only host NAT64 requirements?

Ole Troan <otroan@employees.org> Mon, 20 November 2017 13:37 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 3A0411298BA for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 05:37:02 -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 SAfsrtlZmFJB for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 05:37:00 -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 52B101267BB for <ipv6@ietf.org>; Mon, 20 Nov 2017 05:37:00 -0800 (PST)
Received: from h.hanazo.no (unknown [173.38.220.35]) (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 AA9A12D5038; Mon, 20 Nov 2017 13:36:59 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 4B957200CAD856; Mon, 20 Nov 2017 14:36:54 +0100 (CET)
From: Ole Troan <otroan@employees.org>
Message-Id: <F9E3BD88-38E0-4329-A4BF-22083A023268@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_162733EB-6FCA-4157-9AC3-509305E430E3"; 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, 20 Nov 2017 14:36:53 +0100
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Cc: Jen Linkova <furry13@gmail.com>, 6man WG <ipv6@ietf.org>, Mark Andrews <marka@isc.org>
To: Mohamed Boucadair <mohamed.boucadair@orange.com>
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <D43E103C-27B8-48CF-B801-ACCF9B42533E@employees.org> <m1eEHPS-0000FyC@stereo.hq.phicoh.net> <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org> <m1eEIGX-0000FjC@stereo.hq.phicoh.net> <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org> <CAKD1Yr1aFwF_qZVp5HbRbKzcOGqn==MRe_ewaA8Qc8t3+CVu_Q@mail.gmail.com> <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org> <D42D8D7A-6D19-4862-9BB3-4913058A83B6@employees.org> <CAFU7BARCLq9eznccEtkdnKPAtKNT7Mf1bW0uZByPvxtiSrv6EQ@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <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>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/lxGQLnS2C4bc73o8xmitQOuG0_Y>
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 13:37:02 -0000

Med,

>>>>> [Med] As you are mentioning "IETF" explicitly, NAT64 may not be the
>>>> appropriate "IPv4 service continuity" solution here.
>>>> 
>>>> Why not?
>>> 
>>> [Med] Because dual-stack can do the job without any extra effort.
>> 
>> That's not a valid answer, when the question to be explored is "Is it
>> possible to run IPv6 only hosts?".
> 
> [Med] You should admit that there are questions that don't make sense if not contextualized.

Freely admitted. Although I thought that was made clear both earlier in thread and by subject. ;)

>> The arguments against dual stack:
>> - expensive to operate
>> - little progress towards the end goal of IPv6 only
> 
> [Med] These are generic statements, Ole. We are talking about the IETF case.
> * The IETF has no control on the hosts that connect to the IETF network,
> * IETF attendees who are using corporate devices, have no control on these hosts
> 
> So, how forcing devices to use "IPv6+nat64" will help here?

Eat own dogfood. Many IETF people are developers or work for companies having applications not working.
As I said there were a minimum of applications that didn't work. Corporate VPNs largely did. Jen has the final numbers.

[...]

>>> Advanced features have been also specified, e.g.,
>>> - if you want to allow for incoming connections: e.g., access a video
>> server
>>> - if you want to avoid overloading NAT64 with all sorts of ALGs
>>> - if you want to avoid draining the battery of your mobile because of
>> the keepalive messages
>> 
>> Yep, but I think the cat is largely out of the bag here, and an
>> application must work in the "smallest common denominator" network.
> 
> [Med] More concretely?

- ALGs do more harm than gain. Applications have been forced to deal with NAT traversal. As in ICE/STUN/TURN.
  Applications must work with any NAT also those without ALGs. ALGs are dead.
- For the applications that need the keepalive wouldn't they send traffic anyway, so that it wouldn't be an additional battery drain.
  Example of application that doesn't?
- Incoming connections? Didn't think we did that on the Internet anymore? :-(
  That's static configuration in one case, and for the other symmetric hole punching (as in the ICE/STUN case).

Would PCP have helped, yes, possibly, but given that applications must work without it anyway...

Cheers,
Ole