RE: IPv6 only host NAT64 requirements?

<mohamed.boucadair@orange.com> Mon, 20 November 2017 14:47 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 0D11C129A9C for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 06:47:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 xe3TYS_DRKXT for <ipv6@ietfa.amsl.com>; Mon, 20 Nov 2017 06:47:15 -0800 (PST)
Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C85B129A90 for <ipv6@ietf.org>; Mon, 20 Nov 2017 06:47:15 -0800 (PST)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id B54E44081B; Mon, 20 Nov 2017 15:47:13 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 95A981A007F; Mon, 20 Nov 2017 15:47:13 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0361.001; Mon, 20 Nov 2017 15:47:13 +0100
From: <mohamed.boucadair@orange.com>
To: Ole Troan <otroan@employees.org>
CC: Jen Linkova <furry13@gmail.com>, 6man WG <ipv6@ietf.org>, Mark Andrews <marka@isc.org>
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTYgSm9lmKEv6P8USKvynolT4dKKMdT7Sw
Date: Mon, 20 Nov 2017 14:47:12 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A07D800@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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> <F9E3BD88-38E0-4329-A4BF-22083A023268@employees.org>
In-Reply-To: <F9E3BD88-38E0-4329-A4BF-22083A023268@employees.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4Pr2uNfTxoNTSIe7Dtiq4brGMLw>
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 14:47:17 -0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Ole Troan [mailto:otroan@employees.org]
> Envoyé : lundi 20 novembre 2017 14:37
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Jen Linkova; 6man WG; Mark Andrews
> Objet : Re: IPv6 only host NAT64 requirements?
> 
> 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.

[Med] Fully agree. 

 Applications have been forced to deal with
> NAT traversal. As in ICE/STUN/TURN.

[Med] I used to know that ICE failure rate for webrtc, for example, is high. I don't know if that situation changed since then.  

>   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?

[Med] You can consider the example of a SIP application that send keepalives even if there no ongoing media session. If that application knows the assigned lifetime, it will adjust according. 

The problem is about the default value of the keepalive message. For example, ipsec uses 20s. Other protocols are setting this value to 15s or 30s. Below an excerpt of the impact on the battery as a function of the default value:

                According to [Power], the consumption of a cellular
                device with a keep-alive interval equal to 20 seconds
                (which is the default value in [RFC3948], for example)
                is 29 mA (2G) / 34 mA (3G).  This consumption is reduced
                to 16 mA (2G) / 24 mA (3G) when the interval is
                increased to 40 seconds, to 9.1 mA (2G) / 16 mA (3G) if
                the interval is equal to 150 seconds, and to 7.3 mA (2G)
                / 14 mA (3G) if the interval is equal to 180 seconds.
                When no keep-alive is issued, the consumption would be
                5.2 mA (2G) / 6.1 mA (3G).  The impact of keepalive
                messages would be more severe if multiple applications
                are issuing those messages (e.g., SIP, IPsec, etc.).

> - 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
> 
>