Re: [v6ops] "Getting IPv6 Private Addressing Right" AusNOG presentation

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 18 September 2019 07:39 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD3F1208F9 for <v6ops@ietfa.amsl.com>; Wed, 18 Sep 2019 00:39:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.631
X-Spam-Level:
X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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 i2E_I53AWaEz for <v6ops@ietfa.amsl.com>; Wed, 18 Sep 2019 00:39:45 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 4F9E7120098 for <v6ops@ietf.org>; Wed, 18 Sep 2019 00:39:45 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x8I7dg0Q116598; Wed, 18 Sep 2019 09:39:42 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 92FFD200C1D; Wed, 18 Sep 2019 09:39:42 +0200 (CEST)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 83047200B4F; Wed, 18 Sep 2019 09:39:42 +0200 (CEST)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x8I7dgHp018617; Wed, 18 Sep 2019 09:39:42 +0200
To: Ca By <cb.list6@gmail.com>, Mark Smith <markzzzsmith@gmail.com>
Cc: v6ops list <v6ops@ietf.org>
References: <CAO42Z2yJWgswT6+RYqunqYX70tg4BY3s3rsBGscvNfi-+uFqcQ@mail.gmail.com> <1a8cd6c2-7c5a-3260-7027-fd84a89945bd@gmail.com> <20190917115032.GM55186@Space.Net> <30fe8da2-bd72-1be4-fbb6-5ebdeb451771@gmail.com> <20190917125542.GQ55186@Space.Net> <6ba597e9-b622-6c22-7e3b-40d11f4270a4@gmail.com> <20190917133033.GR55186@Space.Net> <1f5b2b0e-ca2b-7883-5967-2b32eb94ae10@gmail.com> <CAO42Z2w2eH3jk9k_Yb2FfuC15gfKZo8op8Mgk9OunT=3ayH0sA@mail.gmail.com> <CAD6AjGQS_1EtwQXwj5BkKBS6Zs2hEabpSSDbXGig7+m2SqL7KA@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <86b1d529-7adf-1a25-8bc5-aa9dbd1130f1@gmail.com>
Date: Wed, 18 Sep 2019 09:39:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAD6AjGQS_1EtwQXwj5BkKBS6Zs2hEabpSSDbXGig7+m2SqL7KA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/qh6QGA9_4tB6huH53yp_FmgVHKE>
Subject: Re: [v6ops] "Getting IPv6 Private Addressing Right" AusNOG presentation
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Sep 2019 07:39:48 -0000


Le 18/09/2019 à 03:23, Ca By a écrit :
[...]
> Eh. It may be time to update that perspective as 64share is simply how 
> tethering is done on millions of Android and Apple devices.  I think it 
> is now fair to say, for mobile, DHCPv6 a solution to a problem users / 
> providers /  the market does not have ha e

I will not argue, even though it is a topic important to me.

We will write down in the draft a perspective in which 64share is 
deployed on many smartphones; we will write down that some opinions 
consider DHCPv6 to be a solution to a problem users/providers/markets 
does not have.

I let you know here that I do have the problem of running 64share and 
464xlat in cars.

Thank you for the comments.

Alex

> 
> 
>     DHCPv6-PD is the proper solution, however the real issue is caused
>     by how 3GPP do entire device version number snapshots.
> 
>      From the RFC Intro:
> 
>     "3GPP mobile cellular networks such as Global System for Mobile
>         Communications (GSM), Universal Mobile Telecommunications System
>         (UMTS), and Long Term Evolution (LTE) have architectural support for
>         IPv6 [RFC6459], but only 3GPP Release-10 and onwards of the 3GPP
>         specification [TS.23401] supports DHCPv6 Prefix Delegation [RFC3633]
>         for delegating IPv6 prefixes to a single LAN link."
> 
> 
>     On a normal computer, if you want DHCPv6-PD support, you just
>     install it and try to use it. It generally works or it doesn't.
> 
> 
>     On a 3GPP "Smartphone", which is actually just a computer too with a
>     specific type of link-layer interface, you can't install new
>     software to give it a new network capability, because then it
>     doesn't comply with the 3GPP spec. it is supposed to.
> 
>     The versioning model of 3GPP is whole of device, where as the IETF
>     model is per protocol. That means having to come up with non-IETF
>     spec compliant work arounds like 64share when there is a conflict in
>     these models.
> 
>     It would be better if 3GPP started to think of smartphones as
>     portable personal computers that happen to be able to make phone
>     calls, and allowed them to follow the more discrete and incremental
>     protocol version model.
> 
>     As that industry has more than a century of think of devices in
>     end-users hands as voice devices first, and anything else as an add
>     on (like running non-voice apps), I'm not sure we'll ever see them
>     change from this versioning model.
> 
> 
> Apple and the other OEMs do what they want and do not follow 3gpp 
> blindly. 64share and 464xlat never appeared in a 3gpp doc, yet both are 
> deployed in many 3gpp networks n
> 
> 
>     Regards,
>     Mark.
> 
> 
>         Alex
> 
>         _______________________________________________
>         v6ops mailing list
>         v6ops@ietf.org <mailto:v6ops@ietf.org>
>         https://www.ietf.org/mailman/listinfo/v6ops
> 
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org <mailto:v6ops@ietf.org>
>     https://www.ietf.org/mailman/listinfo/v6ops
>