Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt

[Alexandre Petrescu <[e-mail]>]

Le 08/11/2020 à 23:06, JORDI PALET MARTINEZ a écrit :
[...]
> I'm sure we have in the list folks from Apple, Broadcom, Qualcomm, 
> maybe ARM, or somebody in the list can reach them, to ensure if this 
> is a chipset problem, which I don't think is the case.

Apple and ARM are not modem manufacturers.  They make processors.
Actually, in a smartphone, working on the ARM or on the Apple processors
is very good.  There is some form of access, and ability to modify, to
port source code, etc.

To be clear and not to name, I meant Qualcomm in particular.  There are
other modems from China such as Balong (if I remember correctly the name).

We were in close contact with Qualcomm.  The people from Qualcomm at
IETF were very friendly and helpful, and brought us to the humans
at design and implementation.  It is there that all blocks.

None of Qualcomm of Balong modems let DHCPv6 through.  Some block UDP
port number of DHCP, others block multicast.  I specifically say 'block'
because trying other port numbers or trying unicast does let DHCPv6-PD
through.  But these other port numbers or unicast are not standard
because other RFCs.  So operator does not want to allow it.  Which I
think it is right.

There are other modem manufacturers that you did not list above, but
most of them copy the behaviours of the ones we talk about.

There is something else in implementation that we could talk about but
that you do not mention.  In Android there is no DHCPv6-PD client by
default.  Google somehow (religiously?) opposes DHCP.  (PRobably because
of the same apparently religious reasons that Qualcomm believes IPv6
design is SLAAC and not DHCP.)  But we did port a DHCPv6-PD client in
Android on ARM because we were allowed to (open source, etc.)  Of
course, we might dream about requesting Google themselves to port a
DHCPv6-PD client on ARM on Android, but I think we already tried
and we did not succeed, here at IETF.  Alternatively, we might try to
inject a DHCPv6-PD client in the kernel, and so - maybe - Android will
inherit it some time.  We have a draft for that implementation in v6ops
WG, and an implementation freely available.

But even then, because of all the reasons I tried to explain earlier, I
still think DHCPv6-PD is not the point of our discussion here.

Alex

> 
> It looks to me it is more a problem of the rest of the mobile
> network equipment, just not implementing it by default.
> 
> 
> El 8/11/20 22:44, "ipv6 en nombre de Brian E Carpenter" 
> <[e-mail] en nombre de [e-mail]> 
> escribió:
> 
> On 09-Nov-20 09:14, JORDI PALET MARTINEZ wrote:
>> This is wrong. As one of the authors of that document, I can
>> ensure that it covers both aspects, size and persistence and it
>> also covers mobile. See:
>> 
>> 
>> 
>> 4.2.4. Considerations for Cellular Operators
>> 
>> There is a clear exception to the rule described above when 
>> assigning prefixes in a cellular network. In this case, a /64 will 
>> need to be provided for each PDP context for cellular phones, 
>> whereas for LTE modems/routers, i.e. in the case of broadband by 
>> means of cellular access, it will still be necessary to choose a 
>> /48 or /56 in accordance with the aforementioned considerations.
>> 
> 
> Can you be more explicit? Are you saying that this problem is in
> fact solved for 5G modems? If so, and 4G is soon to be legacy, why
> are we even having this discussion?
> 
> Regards Brian
> 
> 
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [e-mail] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
> 
> 
> 
> ********************************************** IPv4 is over Are you 
> ready for the new Internet ? http://www.theipv6company.com The IPv6 
> Company
> 
> This electronic message contains information which may be privileged 
> or confidential. The information is intended to be for the exclusive 
> use of the individual(s) named above and further non-explicilty 
> authorized disclosure, copying, distribution or use of the contents 
> of this information, even if partially, including attached files, is 
> strictly prohibited and will be considered a criminal offense. If you
> are not the intended recipient be aware that any disclosure, copying,
> distribution or use of the contents of this information, even if
> partially, including attached files, is strictly prohibited, will be
> considered a criminal offense, so you must reply to the original
> sender to inform about this communication and delete it.
> 
> 
> 
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [e-mail] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>