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

[JORDI PALET MARTINEZ <[e-mail]>]

Unless I got it wrong, Apple started some years ago to make their own chipsets for "everything", including the cellular interface.

I know ARM is not a "modem" manufacturer, but many vendors are using their designs as part of the CPUs and SoC they make, including Apple and Broadcom, for example and ARM is aware of those developments, because it requires a specific license with each customer, I believe.

Regarding Qualcomm, I can't believe they are "blocking" with no-way-back specific UDP or TCP ports. This may break many other things. I could understand that their default SDK or implementation, or whatever is doing that, but not that you can't re-configure it for your own purpose. It will be a very bad design, as it closes yourself the doors for other purposes.

About Android and DHCPv6, we all know. But I don't know if it is true for a DHCPv6-PD client. I guess Android is being used also in some (mobile and broadband) CPEs, which need that feature.

We need to understand *in detail* why cellular vendors aren't using DHCPv6-PD, even if it is in the 3GPP specs.

Regards,
Jordi
@jordipalet
 
 

El 9/11/20 0:05, "ipv6 en nombre de Alexandre Petrescu" <[e-mail] en nombre de [e-mail]> escribió:



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

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