Re: DHCPv6-PD is fine

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 10 November 2020 16:28 UTC

Return-Path: <alexandre.petrescu@gmail.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 EBD983A0A00 for <ipv6@ietfa.amsl.com>; Tue, 10 Nov 2020 08:28:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.67
X-Spam-Level:
X-Spam-Status: No, score=0.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 LpKkMndDHxJp for <ipv6@ietfa.amsl.com>; Tue, 10 Nov 2020 08:28:00 -0800 (PST)
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 09AAF3A09C5 for <ipv6@ietf.org>; Tue, 10 Nov 2020 08:27:59 -0800 (PST)
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 0AAGRgZ4002672; Tue, 10 Nov 2020 17:27:42 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C808A20A44B; Tue, 10 Nov 2020 17:27:42 +0100 (CET)
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 B96CE2054DF; Tue, 10 Nov 2020 17:27:42 +0100 (CET)
Received: from [10.11.242.43] ([10.11.242.43]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AAGRgHY011730; Tue, 10 Nov 2020 17:27:42 +0100
Subject: Re: DHCPv6-PD is fine
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>, "ipv6@ietf.org" <ipv6@ietf.org>
References: <350919b2-fe50-a3b8-3f15-4ce32124d495@gmail.com> <3377F3AE-BDFE-4AAC-ACA3-0F3D1A4D8854@thehobsons.co.uk> <SN6PR02MB4512DE7BF31D8758BE15D899C3EA0@SN6PR02MB4512.namprd02.prod.outlook.com> <20201109.220035.1460667476695106090.he@uninett.no> <06002E16-10CF-4C39-80A7-4EF2B1DFF4CA@fugue.com> <92f3c592-ac15-1e9a-640b-86f5e090e57a@gmail.com> <672a97ad31c443f9964f5a8a5a497226@huawei.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <5e22ec2c-ca4a-75e1-8bc0-010ae198f082@gmail.com>
Date: Tue, 10 Nov 2020 17:27:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.1
MIME-Version: 1.0
In-Reply-To: <672a97ad31c443f9964f5a8a5a497226@huawei.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/ipv6/6nQETSIBe80w3Mq4qKR7gsQLNK4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 10 Nov 2020 16:28:02 -0000


Le 10/11/2020 à 13:16, Vasilenko Eduard a écrit :
> The less tethering - the more additional SIMs and Modems to sell. 
> Blocking DHCP PD is the revenue generating technology. Is it by 
> coincidence?

One might be tempted to think along these lines yes.  But.

> If you would split /64 on /66 - would it resolve the root cause? Are
>  you trying to undermine additional revenue stream?

I am not sure the question is asked rhetorically?

Anyways, there are many new ways in which to generate new revenue
streams for cellular networks.  6G is one if I had to mention but one.

The mobile WiFi hotspots sold by cellular operators are other examples:
that single SIM accomodating multiple WiFi devices is generating
additional revenue streams from selling a device which is an additional
SIM card for an owner who already owns a SIM card in a personal smartphone.

The Tesla cars whose cellular plans are pre-paid entirely to mobile
operators all over the world are another example of new revenue streams
which still use one SIM card per a group of devices in the car.
Moreover, many drivers plug their SIM-enabled smartphones on these new
car's dashboards, effectively bringing in multiple SIM cards and
computers in the car.

Overall, I dont think there is any reduction in revenue stream provoked
by extending the network. The value of the network might grow with its
size, is said, and I agree.

Alex

> Ed/
>> -----Original Message----- From: ipv6 
>> [mailto:ipv6-bounces@ietf.org] On Behalf Of Alexandre Petrescu 
>> Sent: 10 ноября 2020 г. 13:21 To: ipv6@ietf.org Subject: Re: 
>> DHCPv6-PD is fine
>> 
>> This is a personal point of view, I am not employed at manufacturer
>> or operator.
>> 
>> Le 09/11/2020 à 22:23, Ted Lemon a écrit :
>>> On Nov 9, 2020, at 4:00 PM, Havard Eidnes 
>>> <he=40uninett.no@dmarc.ietf.org 
>>> <mailto:he=40uninett.no@dmarc.ietf.org>> wrote:
>>>>>> From what I've been reading in this thread, in the mobile 
>>>>>> world the problem isn't DHCPv6-PD, but the cellular world 
>>>>>> having not adopted it, or even blocked it (ref discussion 
>>>>>> of mobile modems blocking DHCP packets).
>>>> 
>>>> Is this lack of flexibility for all intents and purposes 
>>>> imprinted into silicon?  That would ... be an extremely 
>>>> effective road-block for practical deployment if one wanted to
>>>>  make a change where DHCP should additionally be used.
>>> 
>>> I’m having trouble envisioning how this would even be possible. 
>>> Is there an IP stack on the chip that has a firewall in it that 
>>> blocks DHCP?
>> 
>> Yes.
>> 
>>> This woud be surprising.
>> 
>> YEs to me too it was surprising to see how many things these modems
>> do.
>> 
>> I was surprised first when my laptop sent a DHCP request, received
>>  an answer, but the operator told me they did not receive such a 
>> request and they did not generate an answer either.  It's because 
>> there was a DHCP proxy in between that I could not see.  It's on 
>> the modem.
>> 
>> There is a whole operating system running in modern modems of 
>> smartphones. They have their own IP addresses inside.  Some times 
>> they even run DHCP servers inside.
>> 
>> Looking at the open source efforts to make an OS for these modems 
>> it is possible to get a hint of how advanced they are.  IIRC one is
>> called Hexagon MiniVM.
>> 
>>> Why would they go to that effort?
>> 
>> In order to protect (some humans at some computers at some) 
>> operator.
>> 
>> The legislation requests that the owner of a smartphone has access
>>  to that smartphone, i.e. to log in and install whatever s/he 
>> wishes; as a side note this is different than CPEs where the 
>> legislation only requests the GPLed source codes of CPE to be made
>>  available upon request.
>> 
>> On these smartphones, a malicious user might install malicious 
>> software that could attack the (~) operator.  Other than outright 
>> vicious attacks some programmers might want to play with a home 
>> made DHCP client on the ARM part of the smartphone (not the modem).
>> That client would disrupt functioning of the already exisitng DHCP
>> server running in the modem.  I suspect that is why smartphone
>> manufacturer, under guidance of modem manufacturer and in agreement
>> with (~) operator, effectively block UDP port numbers of DHCPv6.
>> They block other people's DHCP and let only their own 
>> non-documented variant of DHCP proxy through.
>> 
>> That is my supposition, or rather a speculation.  It means that I 
>> might be wrong. But that does not improve the situation of absence
>>  of DHCPv6-PD in smartphones.
>> 
>> Alex
>> 
>>> 
>>> --------------------------------------------------------------------
>>>
>>>
>>>
>>> 
IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
>>> --------------------------------------------------------------------
>>>
>>
>>
>>>
>>>
>>> 
--------------------------------------------------------------------
>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative 
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
>> --------------------------------------------------------------------