Subject: Re: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok

From: Simon Hobson <[email-masked]>
Date: Fri, 1 Dec 2017 09:08:48 +0000

Dmytro Shytyi <[email-masked]> wrote:

> v6opsers, what could be a nice motivation for such vendors as Qualcomm to change their policy regarding the DHCPv6_PD support

Someone saying something like "We want $very-large-number* of modems for our next model of $device but it needs to pass DHCPv6 traffic - if your modem can't do that we'll have to use $competitors device". Basically, they'll change the design if they think there's a commercial gain from doing it - and that means a large customer demanding the functionality.

So there's that catch-22 issue. Phone manufacturers probably aren't asking for it as they know there isn't demand because the cellular networks don't support it. Network operators probably aren't supporting it because they know there are very few devices that can use it. Modem manufacturers are blocking the traffic because $reason and no-one is demanding enough units for them to change the design.

* Where very-large-number means "many millions".

---

From: Alexandre PETRESCU <[email-masked]>
Date: Fri, 1 Dec 2017 10:26:35 +0100

Bjørn,

Le 30/11/2017 à 20:03, Bjørn Mork a écrit :
>> On Nov 30, 2017, at 11:18 AM, Alexandre Petrescu
>> <[email-masked]<mailto:[email-masked]>>
>> wrote:
>> 
>> v6opsers,
>> 
>> We succeeded in making DHCPv6 PD work natively on a cellular link. 
>> I would claim it to be a first[*]. Packet dump available upon
>> request.
>> 
>> The UE device is a Huawei E392u-12 USB dongle produced in 2011.
>> It hosts a baseband processor Qualcomm model MDM9600 (or model
>> MDM9200, or an Intel - not sure).
> 
> MDM9200.  

Noted.

I would like to ask you how do you know it's an MDM9200 in Huawei 
E392u-12 USB dongle?  Did you open the USB dongle and saw MDM9200 
printed on a IC packaging?  We could only open one cover and cant see 
the IC; further intrusion seems to risk to break it mechanically.

> Not that it matters much...

Well it does matter, because it may mean progress or counter-progress.

I am saying it's MDM9600 because Huawei announced the E392 to include a 
Qualcomm MDM9600, in year 2011:
> “We are pleased to collaborate with Qualcomm to announce the world’s
> first multi-mode LTE TDD Dongle E392 based on Qualcomm’s MDM9600,
> which is anticipated to be commercially available in the third
> quarter of 2011,” said [...] of Huawei Devices India.

On the same MDM920x product line, the MDM9207 is more recent, probably 
year 2016, whereas MDM9200 is surely year 2011.  MDM9207 does block 
DHCPv6 whereas MDM9200 does not block DHCPv6.

It would be a counter-progress if newer chipsets blocked DHCPv6 whereas 
older chipsets allowed it.

That's why I suppose the E392 to be hosting a different Qualcomm product 
line - the MDM9600.  That MDM9600 product line would supposedly support 
DHCPv6 throughout all its subsequent generations.

But I really dont know whether E392 holds a MDM9200 or a MDM9600; so I 
have to go again through this painful Qualcomm 'business case' via 
Sierra and Orange, to ask them again to unblock multicast/547.

If I knew precisely that E392 holds MDM9200 I could tell them: why 
MDM9200 allows DHCPv6 whereas MDM9207 blocks it?

Until then I can only tell them: why MDM9200-or-MDM9600 allows DHCPv6 
whereas MDM9207 blocks it?

(add to that the fact that some xda-developpers say that E392 is 
probably hosting an Intel modem, rather than Qualcomm)

>> It lets all standard DHCPv6 messaging through. The DHCPv6 client 
>> 'odhcpv6' is running on linux laptop.
> 
> Can't help being a bit curious about the Linux driver used for this 
> test? PPP?  qmi_wwan?  Something else?

For this test we used ModemManager with mmcli command line.  We did not 
use pppd.  The kernel modules were: qmi_wwan, cdc_wdm, option and 
usb_wwan.  It was first necessary to switch the dongle from "USB 
storage" mode to "modem" mode.  To achieve that it was necessary to use 
a proprietary string.  That proprietary string is found by first 
sniffing the serial line on a Windows machine.  This whole paragraph is 
publicly documented by programmers in forums.

> (crossing fingers for qmi_wwan :-)

Yes :-)

Alex

> 
>> DHCPv6-PD is blocked on other baseband processors, including
>> Qualcomm and Balong versions; they are hosted by many smartphones,
>> USB cellular dongles, mobile personal WiFi hotspots and IoT
>> devices.  A sample list is available upon request.
> 
> Yes, the "smarter" these things get, the harder it is to make them
> work properly.
> 
> 
> Bjørn
> 
> _______________________________________________ dhcwg mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Bjørn Mork <[email-masked]>
Date: Fri, 01 Dec 2017 10:59:50 +0100

> the IC; further intrusion seems to risk to break it mechanically.

Mostly because the E392u-12 is a European variant and the MDM9200 is the
chipset of that generation with support for the European LTE bands.

You can also get a hint from the Qualcomm baseband revision:

root@miraculix:/tmp# qmicli -d /dev/cdc-wdm1 --dms-get-revision
[/dev/cdc-wdm1] Device revision retrieved:
        Revision: 'M9200B-SCAQDBZD-3.0.350025T  1  [Aug 11 2011 02:00:00]'

> I am saying it's MDM9600 because Huawei announced the E392 to include
> a Qualcomm MDM9600, in year 2011:

I believe there were many variants of the E392.  Some of those intended
for other markets than Europe were probably based on MDM9600. Huawei can
tell you more.

> DHCPv6 whereas MDM9200 does not block DHCPv6.

These are different chipset generations despite the similar names. The
MDM9207 is much closer related to e.g. the MDM9235 than to the MDM9200.
Marketing names means nothing.  It's just a name.

> It would be a counter-progress if newer chipsets blocked DHCPv6
> whereas older chipsets allowed it.

Well, that's progress for you :-)

I don't think they intentionally block anything, but they often mess up
when trying to add more intelligence in the firmware.  Note that these
"modems" are running Linux themselves and provide bridge or router
function between the host USB connection and the actual radio
interface. Ideally.  Most of the time it's neither a bridge nor a modem,
but something in-between.  Which is where you get into trouble...

One possible explanation could be that newer firmwares try to handle
DHCPv6 themselves, intercepting any DHCPv6 request from the host.

> That's why I suppose the E392 to be hosting a different Qualcomm
> product line - the MDM9600.  That MDM9600 product line would
> supposedly support DHCPv6 throughout all its subsequent generations.
>

MDM9200 and MDM9600 are mostly identical from a software point of view.
The MDM9207 is very different. Qualcomm can probably tell you if it is
possible to configure an MDM9207 firmware for DHCPv6 pass through.

Bjørn

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 1 Dec 2017 11:00:44 +0100

Le 01/12/2017 à 10:08, Simon Hobson a écrit :
>> v6opsers, what could be a nice motivation for such vendors as 
>> Qualcomm to change their policy regarding the DHCPv6_PD support
> 
> Someone saying something like "We want $very-large-number* of modems 
> for our next model of $device but it needs to pass DHCPv6 traffic - 
> if your modem can't do that we'll have to use $competitors device". 
> Basically, they'll change the design if they think there's a 
> commercial gain from doing it - and that means a large customer 
> demanding the functionality.
> 
> So there's that catch-22 issue. Phone manufacturers probably aren't 
> asking for it as they know there isn't demand because the cellular 
> networks don't support it. Network operators probably aren't 
> supporting it because they know there are very few devices that can 
> use it. Modem manufacturers are blocking the traffic because $reason 
> and no-one is demanding enough units for them to change the design.

Some operator does support DHCPv6-PD on PGW to UE.

Some modem and dongle do support DHCPv6-PD on UE.

Some prototypes shown it to work ok.

Further deployment needs removal of DHCPv6 blocking.

$reason would yield value :-)

Alex

> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 1 Dec 2017 11:23:53 +0100

Le 01/12/2017 à 10:59, Bjørn Mork a écrit :
> [...]. 

We will check the version as you indicated.

> when trying to add more intelligence in the firmware.

I can agree.  But adding more intelligence should not hamper existing 
features like DHCPv6-PD.

All should co-exist there.

>    Note that these

Could be.  To that, the answer is that modem that intercepts DHCPv6 
request and generates new ones is harmful.

Not only it theoretically violates layering but may lead to situations 
where software version after version leads to effective blocking of 
DHCPv6-PD.

The initial intention was good (support DHCP) and the end result is 
blocking DHCP.

What should be done in modems is to let everything IP through; modem is 
at layer2, not layer3.

> possible to configure an MDM9207 firmware for DHCPv6 pass through.

I will ask again.

They can tell indeed whether it is possible.  What they seem to _not_ 
want to do is to do it themselves.  It's not clear though whether they'd 
allow me (or a programmer with me)  to modify the firmware to let DHCPv6 
pass through.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 1 Dec 2017 11:50:03 +0100

Our USB dongle Huawei E392u-12 yields:
> [/dev/cdc-wdm0] Device revision retrieved: Revision:
> 'M9200B-SCAQWBZD-3.3.330160T  1  [Sep 07 2012 04:00:00]'

It says "M9200B"; I suppose that means the baseband processor is
"MDM9200".  I will use that in my conversations, thank you very much.

Alex

---

From: Alexandre PETRESCU <[email-masked]>
Date: Fri, 1 Dec 2017 14:03:42 +0100

For the DHCPv6-PD successful working, the address used in forming the 
Solicit of 'odhcpv6' on laptop is the same address as in the Solicit 
that PGW receives.

So there is no address translation, like a NAT would do.

I did not bother to compare the each field of the contents of DHCPv6 
messages, but the packet dumps at laptop and at PGW are available.

Because of this I dont think there is any proxying or translation 
between the CPU that executes 'odhcpv6' and the PGW.  That looks good.

Le 01/12/2017 à 10:59, Bjørn Mork a écrit :
> [...]

In RFC terms this is very much about a "Host-IMP" interface.   Host is 
the Host as we know it, and IMP stands for "Interface Message Processor".

This intermediary proxying entities is indeed what can create problems.

To clarify it, it would be advantageous to use common terminology.

These publicly available block schémas show what you call firmware, 
modem, bridge, router, radio interface.

Many call them "Baseband Processor",  "Baseband signal processing", for 
what I call modem, then "Radio frequency module", "PMIC" for what I 
never call, and finally  "Application system", "ARM", "Application 
processor", or laptop, for the entity that executes the DHCP client.  
Some also use the term 'chipset' but that's really unclear.

3GPP uses the term "User Equipment", UE.

Some other SDO uses the term "Mobile Terminal", MT.

For example:

Alex

---

From: Fernando Gont <[email-masked]>
Date: Sat, 2 Dec 2017 21:40:36 +0800

On 12/01/2017 12:18 AM, Alexandre Petrescu wrote:
> I would claim it to be a first[*].
> Packet dump available upon request.
> 
> The UE device is a Huawei E392u-12 USB dongle produced in 2011.  It
> hosts a baseband processor Qualcomm model MDM9600 (or model MDM9200, or
> an Intel - not sure).  It lets all standard DHCPv6 messaging through.
> The DHCPv6 client 'odhcpv6' is running on linux laptop.
> 
> The mobile operator's PGW assigns a /56 and sets proper forwarding for
> it.  The PGW runs on a big Cisco platform.
> 
> After the successful DHCP exchange the laptop is able to ping google
> with a src address which is manually derived out of the /56 delegated
> prefix.

Please send all the "available upong request" that -- either on-list, or
off-list. This stuff is always good to have handy.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 3 Dec 2017 14:29:21 +0100

> off-list. This stuff is always good to have handy.

The topology was the following:

    laptop --- USBdongle ---- SGW --- PGW ---- Internet ---- google.com

The pcap captures are captured on laptop (not on USB dongle).
The txt captures are on PGW.

The pcap and txt captures are simulatenous, but serve distinct purposes. 
  The pcaps served to identify DHCPv6-PD works, that ping google works, 
that there is Release, which 'modem' works, etc.  On txt captures 
operator needed to identify DHCPv6-PD works, but also other things like 
48req-56reply problem, ClientID-00 syntax error absence, prefix-exclude 
for double state avoidance, etc.

I sent you dumps off-list.

Alex