Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and GUA

[Alexandre Petrescu <[e-mail]>]

Hi,

Sorry it is just now that I see the email.

Since we last discussed I had some revelations, and I must correct myself.

Le 17/07/2017 à 09:17, [e-mail] a écrit :
> See below with[HM]
> 
> Holger
> 
> -----Ursprüngliche Nachricht----- Von: v6ops 
> [mailto:[e-mail]] Im Auftrag von Alexandre Petrescu 
> Gesendet: Freitag, 14. Juli 2017 21:02 An: [e-mail] Betreff: 
> Re: [v6ops] RFC6459 "IPv6 in 3GPP" - the IID in the LL address and 
> GUA
> 
>> [HM] WWAN Modem Chipsets perform some kind of translation of 
>> packets,
> 
> This seems like a generalisation.  I do not understand what do you 
> mean by WWAN Modem Chipsets - can you give an example of a WWAN Modem
> Chipset?
> 
> In my particular case there is no separated Modem Chipset from an 
> Application Chipset, or App Processor vs. Broadband Processor, or 
> something like that that one can find in many smartphones.  Or like 
> Host-IMP distinciton of early RFCs.
> 
> In my case it is an IoT device.  It is called an "integrated module"
>  and it runs linux.  It is from Sierra, format CF3, series WP8.
> 
> [HM] Look into their datasheets, they call it "Telecom core" there, 
> and it seems to be a Qualcomm Hexagon based chipset.

I agree.

What I tested for these experiments is a Sierra module; it includes in
the same circuit one ARM Cortex A5 running a yocto-based OS (a linux
distribution for lightweight platforms) and two Qualcomm QDSP6s Hexagon
cores.  It includes further electronic radio circuits that have less
relevance to SLAAC/DHCP (transceivers, amplifiers, etc).  It seems some
parts of this are called "Snapdragon".

The yocto OS provides all its source code including SLAAC/DHCP; yet the
part running on the QDSP6 is binary, confidential proprietary of Qualcomm.

The code running on QDSP6 seems to be running as a virtual machine as a
layer of the yocto OS.  Alternative to that proprietary virtual machine
is a Hexagon MiniVM.

This proprietary virtual machine seems to implement matters related to
DHCPv6 and to SLAAC, including some '64' magic numbers; it is indeed
something like a black box between what yocto does (RS/RA/NS/NA, DHCPv6
client) and what the cellular network offers.  The indicators that tell
that this black box implements DHCPv6/SLAAC are confidential indicators.

Because of proprietary confidential aspects of Qualcomm it is hard to
understand what SLAAC/DHCPv6 on QDSP6 does, and even less to talk
publicly about it.

> There is only one module running both linux and the cellular 
> interface.
> 
> [HM] And this module has two processors, one for the application, and
> one for the telecom side (usually called "the modem").

YEs, actually three in this particular case: one for yocto, and two for
"modem".

>> especially ICMPv6 packets, between the interface to the computer 
>> and the interface towards the provider network. The reason is that
>>  the computer wants to see an Ethernet broadcast interface, but
>> the provider interface is point-to-point. For example, the computer
>>  needs Neighbor Discovery but this is not available on the
>> provider interface. The provider's network device doesn't have a
>> MAC address either, so the modem chipset emulates this missing MAC
>> to the computer.
> 
> Do you think it is a linux kernel module that performs that 
> emulation, or is it completely another OS (like ThreadX)?
> 
> [HM] No, it is a separate processor (actually a DSP).

YEs, in this Sierra module, there are two QDSP6s, in addition to the yocto.

> That emulation must be standardised.
> 
> [HM] Well, obviously nobody saw the need for it until now, it is 
> actually implementation specific. It would be a good idea indeed to 
> specify this.

I agree with you.

There is a strong need to have clear specification of whatever any
intermediary box does, especially when it gets in the way.

Otherwise it's impossible to continue.

> Most of these translation layers drop all DHCPv6 traffic so no
> chance to get Prefix Delegation working if it is initiated by the
> host.

This is indeed a risk.  This is something explored as we speak.

It would be great to get Qualcomm involved in this.  Because I think
they sit in the middle, yet a better understanding of SLAAC/DHCP can
bring more value.

> There is a need for such translation otherwise Ipv6 won't work.

Well, I tend to disagree, but discussion may change my point of view.

Currently I think the ideal is if that QDSP6 does not do anything - let
everything through.  For a start.

> Ipv4 neither - Ipv4 address assignment on the carrier side does not 
> use DHCPv4 which the mobile host usually speaks. This is the downside
> of presenting an Ethernet interface to the Operating system. The
> upside is the there is no need to change OS specific handling of a
> WWAN interface since it can be handled like any other Ethernet 
> interface. Otherwise, each OS would have to implement an interface 
> driver complying to 3GPP's view of the wireless network 
> connectivity.

Noted.

>> So what you capture on WWAN0 (or however your computer interface
>> is named) is not what actually goes over the air.
> 
> If you think that something else goes over the air, can you tell me 
> how, or what capturing tool, did you find out that there is something
> else over the air?
> 
> [HM] I traced within the operator's network, looking at the GTP 
> traffic just in front of the GGSN/PGW.
> 
> My operator asks me the same thing - what goes over the air - and I 
> dont know what to answer. [HM] Tell them to trace your GTP traffic 
> right in front of their GGSN/PGW (e.g. Gn interface).

Thank you for the advice.  This is what we currently do with the help of
the operator.  We identified some issues.

On the mobile side, Qualcomm offers a diagnostic tool (private
confidential).

This is a matter of Host-IMP interface, RFC 7!

Alex