Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 5 Sep 2017 17:39:06 +0200

Hi,

I want to update the list about our advancements.

We are exploring the question of why DHCPv6 Prefix Delegation is not
used on cellular links.  This lack of PD support has bad side effects:
an INFORMATIONAL RFC 64share becomes more and more used, Mobile Routers
are impossible.

Here are the unique reasons - if solely these are solved then we get PD
on cellular:
- some modems in the UE (e.g. QDSP6 and others) block standard DHCPv6
   UDP port numbers 546 and 547 and (and sometimes or) standard IP
   multicast addressing in both directions; this blocking was identified
   by comparing packet dumps on the ARM part of UE, vs on PGW;
   this blocking was further confirmed by successful Sol/Adv on unicast
   and non-std UDP ports.
   This blocking happens even though the application processor (e.g. ARM)
   does not block them.
   These ports and multicast are absolutely needed for Prefix Delegation,
   because Prefix Delegation runs as an integral part of DHCPv6.
- much less likely, it may be that some infrastructure entities like
   Base Station or SGW - again, very little probable - blocks same DHCP
   ports and multicast.
- DHCPv6 software is little parametrable or portable, even though much
   source is available openly.

Some details:
- the DHCPv6 software on Android is hampered by the need of root access.
   Android blocks that.  One needs to ask the platform manufacturer
   running that Android to "root" the platform such as to be able to run
   some of the DHCP client software (e.g. ask Huawei for a key to root
   the smartphone).  That's a real pain.  There is a risk of "bricking"
   your platform, i.e. through it out a window.
- to make an app available to everyone on Android one must pay some
   money to become a member of a store.  DHCP should not be part of that,
   as SLAAC isnt; just like SLAAC, DHCP should be builtin for free.
- the DHCPv6 server software "ISC" breaks if the port numbers are
   non-standard (not 546 nor 547) or unicast instead of multicast.
   (e.g. "Discarding Solicit from [snip]; packet sent unicast")
   This was a real pain, because we had to modify the source code
   to allow it; other software like VoIP has SIP ports this configurable
   easily with a GUI.
- Cisco parametering CLI of DHCPv6 service may have some problems in
   transforming a non-standard UDP port 546 of Solicit to a strange
   26483.  That was a real pain to one.
- various DHCPv6 client software break, or do not even start, with
   any other src and dst UDP ports than the standard (546, 547)
   and/or non-standard unicast instead of standard multicast.

Other reasons proved not to be causes of absence of DHCPv6 PD on
cellular links; they were just speculations:
- cellular operators dont provide DHCPv6 PD service (there are some who
   do under some operational conditions)
- cellular operators have a hard time making an IPv6 addressing
   architecture that delegate prefixes instead of addresses (there are
   some who do make such architecture)
- cellular operators only do '64' (it's false, some could do less,
   like 56 or even 48)
- DHCPv6 software is not available on the client (there are some, like
   on Android, and more, see quoted mails below)
- the computer that runs the DHCPv6 client is the same as the one that
   puts the Solicit on the wire: this is not true, because even in the
   smallest UE in the market there is still distinction app-vs-modem
   processors.  Often the modem part is confidential, only the binary
   is available to the public, and there are two IPs on it: Internet
   Protocol _and_ Intellectual Property.

Alex, with thanks to [Hachata], admin(s), managers, and technicals at
offices and organisations.

Le 18/08/2017 à 18:07, Alexandre Petrescu a écrit :
> I have been pointed by a helpful person that an Android app for 
> DHCPv6 exists there:
> 
> https://play.google.com/store/apps/details?id=org.daduke.realmar.dhcpv6client&hl=fr
>
>
> 
> 
> 
> It is based on the WIDE DHCPv6 client.
> 
> Further browsing leads to a discussion of DHCPv6 on Android topic: 
> https://issuetracker.google.com/issues/36949085
> 
> Alex
> 
> Le 17/07/2017 à 18:26, Alexandre Petrescu a écrit :
>> Well, this is to note that we too (Fred mentioned it too earlier) 
>> made the ISC DHCPv6 dhclient work on Android, including DHCPv6 
>> Solicit that requests Prefix Delegation.
>> 
>> (but we still dont have a response to DHCP Solicit on cellular 
>> link).
>> 
>> Alex
>> 
>> Le 06/07/2017 à 18:32, Alexandre Petrescu a écrit :
>>> Mark, noted, will try.
>>> 
>>> Just a note...
>>> 
>>> Le 06/07/2017 à 03:16, Mark Andrews a écrit :
>>>> 
>>>> In message <[email-masked]>, 
>>>> Alexandre Petrescu writes:
>>>>> Hello,
>>>>> 
>>>>> We discussed extensively about the potential use of DHCPv6 
>>>>> Prefix Delegation on cellular links.
>>>>> 
>>>>> The chicken issue is the lack of DHCPv6 PD software on 
>>>>> typical User Equipment.  For example, there is no DHCPv6-PD 
>>>>> app on Android.  The egg issue is the lack of operator 
>>>>> support of DHCPv6-PD towards the User Terminal.  For example,
>>>>> there is no cellular operator answering to DHCPv6-PD requests
>>>>> issued by the User Terminal.
>>>>> 
>>>>> To address the chicken issue, we started with an ISC DHCP 
>>>>> open software client, which does implement Prefix Delegation.
>>>>> It can be (cross)compiled on various platforms; then type
>>>>> "./dhclient -6 -P"; this sends an DHCPv6 Solicit Identity
>>>>> Associtaion for Prefix Delegation message on the interface.
>>>>> 
>>>>> However, whereas this software runs ok on interfaces such as 
>>>>> Ethernet, USBnet and WiFi interfaces, it breaks if run on the
>>>>> cellular interface of some IoT cellular platform.  The error
>>>>> can be corrected by the quick-and-dirty solution below.
>>>> 
>>>> The hack would be better as
>>>> 
>>>> #ifdef ARPHRD_XXXX case ARPHRD_XXXX: hw->hlen = 7; hw->hbuf[0]
>>>>  = HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data, 6); break; 
>>>> #endif default: log_fatal("Unsupported device type %ld for 
>>>> \"%s\"", (long int)sa->sa_family, name); break;
>>>> 
>>>> with ARPHRD_XXXX being replaced by the correct macro for 503 
>>>> from <net/if_arp.h>.  Something like that is at least 
>>>> portable.
>>> 
>>> But it means when I go to other platform will have to modify 
>>> again the ISC client source code?
>>> 
>>> In cellular terminals there are so many non-IEEE different kinds
>>>  of links.
>>> 
>>> Other clients work out of the box on this - I agree with you, 
>>> strange - "rmnet0" interface.
>>> 
>>> Alex
>>> 
>>>> 
>>>> As for the rest of it I have no idea about the presented 
>>>> hardware address of this type so I don't know it the rest of it
>>>> make sense.
>>>> 
>>>>> Alex
>>>>> 
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>> The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0."
>>>>> dhcp-4.3.5 ./common/lpf.c line number: 551
>>>>> 
>>>>> //default: //      log_fatal("Unsupported device type %ld
>>>>> for \"%s\"", //                (long int)sa->sa_family,
>>>>> name); default: hw->hlen = 7; hw->hbuf[0] = HTYPE_ETHER; 
>>>>> memcpy(&hw->hbuf[1], sa->sa_data, 6); break;
>>>>> 
>>>>> (two programmers worked this out).
>>>>> 
>>>>> Alex
>>>>> 
>>>>> _______________________________________________ v6ops
>>>>> mailing list [email-masked] 
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>>> _______________________________________________ v6ops mailing 
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> _______________________________________________ v6ops mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Sep 2017 16:06:41 +0000

Hi Alex,

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Tuesday, September 05, 2017 8:39 AM
> To: [email-masked]
> Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android
> 
> Hi,
> 

You don't need to root the device to run DHCPv6 PD over a VPN: 

https://developer.android.com/reference/android/net/VpnService.html

Again, we have DHCPv6 PD working fine over a VPN.

Thanks - Fred

> [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 5 Sep 2017 21:35:10 +0200

> Again, we have DHCPv6 PD working fine over a VPN.

That is good to know.

In my setting I need DHCPv6-PD as unencapsulated as possible - just 
straight.

(on IPv6 cellular links there is already IPv6-in-GTPU encapsulation, 
which is an IPv4 protocol, that is hard to get rid of;  a 2nd 
encapsulation for VPN, or a 3rd encapsulation for Mobile IP means 
additional overhead in terms of packet headers, intelligence to maintain 
tunnels up, etc)

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 5 Sep 2017 21:47:18 +0200

For the record, we tried several other things to make PD work 
("speculations"), but none was as successful as using unicast and fake 
port numbers for DHCP Solicit/Advertise.

- Hop Limit variations in Solicit, instead of 1: this has some effect in
   keeping the packet alive on longer IP paths.
- use DHCP "Prefix Exclude" option: whether we include it or not,
   results are same.
- request plens same or longer than plen configured at server: no
   effect.
- IP dst address of Solicit: variations between ff02::1 (all-routers)
   and ff02::2:1 (all DHCP servers) has no effect; if multicast is
   blocked no form of multicast gets through.
- mapping to MAC dst multicast address: be it 33:33 formats or ff:ff
   formats, the result is the same: when multicast is blocked no form
   of mapping on MAC multicast gets through.
- some other variations.

Alex

Le 05/09/2017 à 17:39, Alexandre Petrescu a écrit :
>> I have been pointed by a helpful person that an Android app for DHCPv6 
>> exists there:
>>
>>> (but we still dont have a response to DHCP Solicit on cellular link).
>>>
>>> Alex
>>>
>>>>>> We discussed extensively about the potential use of DHCPv6 Prefix 
>>>>>> Delegation on cellular links.
>>>>>>
>>>>>> The chicken issue is the lack of DHCPv6 PD software on typical 
>>>>>> User Equipment.  For example, there is no DHCPv6-PD app on 
>>>>>> Android.  The egg issue is the lack of operator support of 
>>>>>> DHCPv6-PD towards the User Terminal.  For example,
>>>>>> To address the chicken issue, we started with an ISC DHCP open 
>>>>>> software client, which does implement Prefix Delegation.
>>>>>  = HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data, 6); break; #endif 
>>>>> default: log_fatal("Unsupported device type %ld for \"%s\"", (long 
>>>>> int)sa->sa_family, name); break;
>>>>>
>>>>> with ARPHRD_XXXX being replaced by the correct macro for 503 from 
>>>>> <net/if_arp.h>.  Something like that is at least portable.
>>>>
>>>> But it means when I go to other platform will have to modify again 
>>>> the ISC client source code?
>>>>
>>>>> As for the rest of it I have no idea about the presented hardware 
>>>>> address of this type so I don't know it the rest of it
>>>>> make sense.
>>>>>
>>>>>> Alex
>>>>>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Sep 2017 19:54:17 +0000

Hi Alex,

> From: Alexandre Petrescu [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2017 12:35 PM
> To: Templin, Fred L <[email-masked]>; [email-masked]

At least one freely-available VPN app I am aware of uses LZO whole
message compression, which can attenuate the extra overhead to
a considerable extent.

Plus, using the VPN may be compatible with the security policy. For
example, for a cellphone in the Internet connecting into a home
enterprise network the use of VPNs would be consistent with the
security model.

Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 5 Sep 2017 21:59:11 +0200

Hi Fred,

> message compression, which can attenuate the extra overhead to

That is the overhead of packets that could be reduced.  I agree.

But the software of maintaining that VPN tunnel up upon handover is also 
considerable, and no compression mechanism could reduce it.

> enterprise network the use of VPNs would be consistent with the

Yes, I agree with this point.
I have not given much consideration to security.

I wonder whether it can be possible to set the VPN up after the 
DHCPv6-PD exchange happened between the operator and the smartphone.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Sep 2017 20:07:18 +0000

Hi Alex,

> Sent: Tuesday, September 05, 2017 12:59 PM

Do you mean handover from one cellular base station to a second cellular
base station? From cellular to wireless? Something else? In any event the
handover is accommodated by a small exchange of control messages, but
the VPN service itself continues uninterrupted. Hence, it is a Mobile VPN.

> I have not given much consideration to security.

OK.

> DHCPv6-PD exchange happened between the operator and the smartphone.

The system I am describing first obtains an address from the operator
and next sets up the VPN using the operator's service as a link layer.

Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Sep 2017 08:03:20 +0200

Fred,,

[...]

> https://developer.android.com/reference/android/net/VpnService.html

Fred,

I can understand VPN set up runs ok without need to root the device 
running Android OS.

But, is DHCP client over that VPN needing to "root" the device?
Is that DHCP client in-house software, odhcpcd, WIDE, ISC, scapy?

If it is in-house software, I can understand you may not need to root 
it.  But then I would like to know whether that in-house software is 
parametrable so it can unicast and non-std UDP, such that it runs over 
straight interfaces too, not only VPN.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Sep 2017 08:08:13 +0200

Le 05/09/2017 à 22:07, Templin, Fred L a écrit :
[...]

>> But the software of maintaining that VPN tunnel up upon handover
>> is also considerable, and no compression mechanism could reduce
>> it.
> 
> Do you mean handover from one cellular base station to a second 
> cellular base station?

Yes.

> From cellular to wireless?

No.  Only Mobile IP can achieve it.  To run that, again, we need to root
the device.

> Something else?

Yes, something else too: handover from getting underground parking to
daylight where coverage is present.  That means losing connection and
obtaining a new prefix.

The software to achieve that is difficult to write and typically long.
Some part of it should be distributed.

> In any event the handover is accommodated by a small exchange of
> control messages, but the VPN service itself continues uninterrupted.
> Hence, it is a Mobile VPN.

Well it is an interesting VPN software.  It seems it is a VPN software 
that resists when the IP address changes on the mobile.

[...]

> and next sets up the VPN using the operator's service as a link

I see.  It is like an overlay network, and it is good many times.

Alex

> 
> Thanks - Fred
> 
>> Alex
>> 
>>> 
>>> Thanks - Fred
>>> 
>>>> Alex
>>>> 
>>>>> 
>>>>> Thanks - Fred
>>>>> 
>>>>>> - to make an app available to everyone on Android one must 
>>>>>> pay some money to become a member of a store.  DHCP should 
>>>>>> not be part of that, as SLAAC isnt; just like SLAAC, DHCP 
>>>>>> should be builtin for free. - the DHCPv6 server software 
>>>>>> "ISC" breaks if the port numbers are non-standard (not 546 
>>>>>> nor 547) or unicast instead of multicast. (e.g.
>>>>>> "Discarding Solicit from [snip]; packet sent unicast") This
>>>>>> was a real pain, because we had to modify the source code
>>>>>> to allow it; other software like VoIP has SIP ports this
>>>>>> configurable easily with a GUI. - Cisco parametering CLI of
>>>>>> DHCPv6 service may have some problems in transforming a 
>>>>>> non-standard UDP port 546 of Solicit to a strange 26483. 
>>>>>> That was a real pain to one. - various DHCPv6 client 
>>>>>> software break, or do not even start, with any other src 
>>>>>> and dst UDP ports than the standard (546, 547) and/or 
>>>>>> non-standard unicast instead of standard multicast.
>>>>>> 
>>>>>> Other reasons proved not to be causes of absence of DHCPv6 
>>>>>> PD on cellular links; they were just speculations: - 
>>>>>> cellular operators dont provide DHCPv6 PD service (there 
>>>>>> are some who do under some operational conditions) - 
>>>>>> cellular operators have a hard time making an IPv6 
>>>>>> addressing architecture that delegate prefixes instead of 
>>>>>> addresses (there are some who do make such architecture) - 
>>>>>> cellular operators only do '64' (it's false, some could do 
>>>>>> less, like 56 or even 48) - DHCPv6 software is not 
>>>>>> available on the client (there are some, like on Android, 
>>>>>> and more, see quoted mails below) - the computer that runs 
>>>>>> the DHCPv6 client is the same as the one that puts the 
>>>>>> Solicit on the wire: this is not true, because even in the
>>>>>>  smallest UE in the market there is still distinction 
>>>>>> app-vs-modem processors.  Often the modem part is 
>>>>>> confidential, only the binary is available to the public, 
>>>>>> and there are two IPs on it: Internet Protocol _and_ 
>>>>>> Intellectual Property.
>>>>>> 
>>>>>> Alex, with thanks to [Hachata], admin(s), managers, and 
>>>>>> technicals at offices and organisations.
>>>>>> 
>>>>>> 
>>>>>>> I have been pointed by a helpful person that an Android 
>>>>>>> app for DHCPv6 exists there:
>>>>>>> 
>>>>>>>> Well, this is to note that we too (Fred mentioned it 
>>>>>>>> too earlier) made the ISC DHCPv6 dhclient work on 
>>>>>>>> Android, including DHCPv6 Solicit that requests Prefix 
>>>>>>>> Delegation.
>>>>>>>> 
>>>>>>>>>> In message 
>>>>>>>>>> <[email-masked]>, 
>>>>>>>>>>> We discussed extensively about the potential use 
>>>>>>>>>>> of DHCPv6 Prefix Delegation on cellular links.
>>>>>>>>>>> 
>>>>>>>>>>> The chicken issue is the lack of DHCPv6 PD 
>>>>>>>>>>> software on typical User Equipment.  For
>>>>>>>>>>> example, there is no DHCPv6-PD app on Android.
>>>>>>>>>>> The egg issue is the lack of operator support of 
>>>>>>>>>>> DHCPv6-PD towards the User Terminal.  For 
>>>>>>>>>>> example, there is no cellular operator answering 
>>>>>>>>>>> to DHCPv6-PD requests issued by the User 
>>>>>>>>>>> Terminal.
>>>>>>>>>>> 
>>>>>>>>>>> To address the chicken issue, we started with an 
>>>>>>>>>>> ISC DHCP open software client, which does 
>>>>>>>>>>> implement Prefix Delegation. It can be 
>>>>>>>>>>> (cross)compiled on various platforms; then type 
>>>>>>>>>>> "./dhclient -6 -P"; this sends an DHCPv6 Solicit 
>>>>>>>>>>> Identity Associtaion for Prefix Delegation 
>>>>>>>>>>> message on the interface.
>>>>>>>>>>> 
>>>>>>>>>>> However, whereas this software runs ok on 
>>>>>>>>>>> interfaces such as Ethernet, USBnet and WiFi 
>>>>>>>>>>> interfaces, it breaks if run on the cellular 
>>>>>>>>>>> interface of some IoT cellular platform.  The 
>>>>>>>>>>> error can be corrected by the quick-and-dirty 
>>>>>>>>>>> solution below.
>>>>>>>>>> 
>>>>>>>>>> #ifdef ARPHRD_XXXX case ARPHRD_XXXX: hw->hlen = 7; 
>>>>>>>>>> hw->hbuf[0] = HTYPE_ETHER; memcpy(&hw->hbuf[1], 
>>>>>>>>>> sa->sa_data, 6); break; #endif default: 
>>>>>>>>>> log_fatal("Unsupported device type %ld for
>>>>>>>>>> with ARPHRD_XXXX being replaced by the correct 
>>>>>>>>>> macro for 503 from <net/if_arp.h>.  Something like 
>>>>>>>>>> that is at least portable.
>>>>>>>>> 
>>>>>>>>> But it means when I go to other platform will have
>>>>>>>>> to modify again the ISC client source code?
>>>>>>>>> 
>>>>>>>>> In cellular terminals there are so many non-IEEE 
>>>>>>>>> different kinds of links.
>>>>>>>>> 
>>>>>>>>> Other clients work out of the box on this - I agree 
>>>>>>>>> with you, strange - "rmnet0" interface.
>>>>>>>>> 
>>>>>>>>> Alex
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> As for the rest of it I have no idea about the 
>>>>>>>>>> presented hardware address of this type so I don't 
>>>>>>>>>> know it the rest of it make sense.
>>>>>>>>>> 
>>>>>>>>>>> Alex
>>>>>>>>>>> 
>>>>>>>>>>> //default: //      log_fatal("Unsupported device 
>>>>>>>>>>> type %ld for \"%s\"", //                (long 
>>>>>>>>>>> int)sa->sa_family, name); default: hw->hlen = 7; 
>>>>>>>>>>> hw->hbuf[0] = HTYPE_ETHER; memcpy(&hw->hbuf[1], 
>>>>>>>>>>> sa->sa_data, 6); break;
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________ 
>>>>>>>>>>> v6ops mailing list [email-masked] 
>>>>>>>>> _______________________________________________
>>>>>>>>> v6ops mailing list [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Sep 2017 21:10:36 +0900

> Again, we have DHCPv6 PD working fine over a VPN.

You can't bind to port 546 without rooting the device. You can certainly
encapsulate DHCPv6 packets within another protocol that you do have
permission to use (e.g., UDP or TCP on a high port), but you don't need
VpnService to do that.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Sep 2017 14:35:05 +0000

Hi Alex,

> Sent: Tuesday, September 05, 2017 11:03 PM

OK - Android provides VpnService builder for this, which is what we are using.

> But, is DHCP client over that VPN needing to "root" the device?

No.

> Is that DHCP client in-house software, odhcpcd, WIDE, ISC, scapy?

In-house software, but only a few hundred lines of code that were
easy to write.
 
> straight interfaces too, not only VPN.

It would be fine to run it over a regular interface and get back DHCPv6
information. The problem is that the goal of DHCPv6 is to first obtain
addressing information and second to assign addresses to interfaces.
But, Android does not allow apps to assign addresses to regular
interfaces. The only interfaces an app can assign addresses to are
those created by a service that gives elevated privileges like VPN.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Sep 2017 14:40:38 +0000

Hi Alex,

> Sent: Tuesday, September 05, 2017 11:08 PM

OK.

> No.  Only Mobile IP can achieve it.  To run that, again, we need to root

No, no MIPv6. I use IPv6 ND instead to accommodate address changes,
multiple interfaces, etc. IPv6 ND provides a great mobility service over
tunnel virtual interfaces.

> daylight where coverage is present.  That means losing connection and

With VPN, you get to keep the same prefix even though the underlying
interface address changes.

> that resists when the IP address changes on the mobile.

It is a VPN software with an IPv6 prefix that persists (not "resistis" :^} )
when the IP address of the mobile changes.

> I see.  It is like an overlay network, and it is good many times.

Overlay network yes. Good many times, also yes.

Thanks - Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Sep 2017 14:57:14 +0000

Hi Lorenzo,

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Wednesday, September 06, 2017 5:11 AM
To: Templin, Fred L <[email-masked]>
Cc: Alexandre Petrescu <[email-masked]>; [email-masked]
Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android

On Wed, Sep 6, 2017 at 1:06 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
You don't need to root the device to run DHCPv6 PD over a VPN:

You can't bind to port 546 without rooting the device. You can certainly encapsulate DHCPv6 packets within another protocol that you do have permission to use (e.g., UDP or TCP on a high port), but you don't need VpnService to do that.

Ø    Yes, I understand the point about being able to run DHCPv6 over a different port number

Ø    The problem is that once the DHCPv6 client gets back addressing information, it cannot

Ø    assign addresses to interfaces on the Android platform without having the device

Ø    rooted. VpnService skirts around this issue by asking the user “is it OK if this app

Ø    modifies the network settings?” and if the user answers yes then the service allows

Ø    the app to assign addresses on the VPN interface without having to root the device.

Ø
Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Sep 2017 18:11:11 +0200

Fred,

Le 06/09/2017 à 16:35, Templin, Fred L a écrit :
[...]
> The problem is that the goal of DHCPv6 is to first obtain

Let's clarify this.

We dont want DHCP to assign addresses on interfaces.  We want it to 
obtain a prefix from the network (DHCPv6 Prefix Delegation).  Right?

> interfaces.

If so, it seems like a problem of Android.

It's hard to accept buying an expensive smartphone with its data plan 
yet be forbidden to set an address on it on the command line.  I should 
be allowed to freely set not one, but as many addresses that I want.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Sep 2017 18:21:18 +0200

Fred,

Le 06/09/2017 à 16:40, Templin, Fred L a écrit :
[...]

>> Yes, something else too: handover from getting underground parking
>> to daylight where coverage is present.  That means losing
>> connection and obtaining a new prefix.
> 

Yes, you keep the same prefix despite changes in IP address of
underlying interface; for that to work, among other things, one needs a
VPN server in the infrastructure to maintain that prefix.

A VPN server may be costly to maintain, in some cases.

It would be advantageous, in some cases, to not need a VPN server. In
these cases we want the DHCPv6 Prefix Delegation to work straight on a
cellular interface.

In these cases, instead of relying on a VPN server to maintain that
prefix, we rely on the cellular network operator to maintain it.  The 
prefix may change upon handover - yes, but for many
applications that's not ultra-important (they dont break).

We think that the ability to rely most of the time on connectivity for 
cellular network  (instead of additional VPN server) is worth 
sacrificing the few times when the apps care about session continuity.

It's on this direction that we propose the use of DHCPv6 Prefix 
Delegation on cellular links.

We propose that as Prefix Delegation (not IA_NA address).

Alex

>>> control messages, but the VPN service itself continues
>>> uninterrupted. Hence, it is a Mobile VPN.
>> 
>> Well it is an interesting VPN software.  It seems it is a VPN
>> software that resists when the IP address changes on the mobile.
> 
> It is a VPN software with an IPv6 prefix that persists (not
> "resistis" :^} ) when the IP address of the mobile changes.
> 
>> [...]
>> 
>>>> I wonder whether it can be possible to set the VPN up after
>>>> the DHCPv6-PD exchange happened between the operator and the 
>>>> smartphone.
>>> 
>>> The system I am describing first obtains an address from the
>>> operator and next sets up the VPN using the operator's service as
>>> a link layer.
>> 
> Thanks - Fred [email-masked]
> 
>> Alex
>> 
>>> 
>>> Thanks - Fred
>>> 
>>>> Alex
>>>> 
>>>>> 
>>>>> Thanks - Fred
>>>>> 
>>>>>> Alex
>>>>>> 
>>>>>>> 
>>>>>>> Thanks - Fred
>>>>>>> 
>>>>>>>> - to make an app available to everyone on Android one
>>>>>>>> must pay some money to become a member of a store.
>>>>>>>> DHCP should not be part of that, as SLAAC isnt; just
>>>>>>>> like SLAAC, DHCP should be builtin for free. - the
>>>>>>>> DHCPv6 server software "ISC" breaks if the port numbers
>>>>>>>> are non-standard (not 546 nor 547) or unicast instead
>>>>>>>> of multicast. (e.g. "Discarding Solicit from [snip];
>>>>>>>> packet sent unicast") This was a real pain, because we
>>>>>>>> had to modify the source code to allow it; other
>>>>>>>> software like VoIP has SIP ports this configurable
>>>>>>>> easily with a GUI. - Cisco parametering CLI of DHCPv6
>>>>>>>> service may have some problems in transforming a 
>>>>>>>> non-standard UDP port 546 of Solicit to a strange
>>>>>>>> 26483. That was a real pain to one. - various DHCPv6
>>>>>>>> client software break, or do not even start, with any
>>>>>>>> other src and dst UDP ports than the standard (546,
>>>>>>>> 547) and/or non-standard unicast instead of standard
>>>>>>>> multicast.
>>>>>>>> 
>>>>>>>> Other reasons proved not to be causes of absence of
>>>>>>>> DHCPv6 PD on cellular links; they were just
>>>>>>>> speculations: - cellular operators dont provide DHCPv6
>>>>>>>> PD service (there are some who do under some
>>>>>>>> operational conditions) - cellular operators have a
>>>>>>>> hard time making an IPv6 addressing architecture that
>>>>>>>> delegate prefixes instead of addresses (there are some
>>>>>>>> who do make such architecture) - cellular operators
>>>>>>>> only do '64' (it's false, some could do less, like 56
>>>>>>>> or even 48) - DHCPv6 software is not available on the
>>>>>>>> client (there are some, like on Android, and more, see
>>>>>>>> quoted mails below) - the computer that runs the DHCPv6
>>>>>>>> client is the same as the one that puts the Solicit on
>>>>>>>> the wire: this is not true, because even in the 
>>>>>>>> confidential, only the binary is available to the
>>>>>>>> public, and there are two IPs on it: Internet Protocol
>>>>>>>> _and_ Intellectual Property.
>>>>>>>> 
>>>>>>>> Alex, with thanks to [Hachata], admin(s), managers,
>>>>>>>> and technicals at offices and organisations.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> I have been pointed by a helpful person that an
>>>>>>>>> Android app for DHCPv6 exists there:
>>>>>>>>> 
>>>>>>>>>> Well, this is to note that we too (Fred mentioned
>>>>>>>>>> it too earlier) made the ISC DHCPv6 dhclient work
>>>>>>>>>> on Android, including DHCPv6 Solicit that requests
>>>>>>>>>> Prefix Delegation.
>>>>>>>>>> 
Alexandre Petrescu writes:
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> We discussed extensively about the potential
>>>>>>>>>>>>> use of DHCPv6 Prefix Delegation on cellular
>>>>>>>>>>>>> links.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> example, there is no DHCPv6-PD app on
>>>>>>>>>>>>> Android. The egg issue is the lack of
>>>>>>>>>>>>> operator support of DHCPv6-PD towards the
>>>>>>>>>>>>> User Terminal.  For example, there is no
>>>>>>>>>>>>> cellular operator answering to DHCPv6-PD
>>>>>>>>>>>>> requests issued by the User Terminal.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> To address the chicken issue, we started with
>>>>>>>>>>>>> an ISC DHCP open software client, which does 
>>>>>>>>>>>>> (cross)compiled on various platforms; then
>>>>>>>>>>>>> type "./dhclient -6 -P"; this sends an DHCPv6
>>>>>>>>>>>>> Solicit Identity Associtaion for Prefix
>>>>>>>>>>>>> Delegation message on the interface.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> interface of some IoT cellular platform.
>>>>>>>>>>>>> The error can be corrected by the
>>>>>>>>>>>>> quick-and-dirty solution below.
>>>>>>>>>>>> 
>>>>>>>>>>>> #ifdef ARPHRD_XXXX case ARPHRD_XXXX: hw->hlen =
>>>>>>>>>>>> 7; hw->hbuf[0] = HTYPE_ETHER;
>>>>>>>>>>>> #endif default: log_fatal("Unsupported device
>>>>>>>>>>>> type %ld for \"%s\"", (long int)sa->sa_family,
>>>>>>>>>>>> name); break;
>>>>>>>>>>>> 
>>>>>>>>>>>> macro for 503 from <net/if_arp.h>.  Something
>>>>>>>>>>>> like that is at least portable.
>>>>>>>>>>> 
>>>>>>>>>>> But it means when I go to other platform will
>>>>>>>>>>> have to modify again the ISC client source code?
>>>>>>>>>>> 
>>>>>>>>>>> Other clients work out of the box on this - I
>>>>>>>>>>> agree with you, strange - "rmnet0" interface.
>>>>>>>>>>> 
>>>>>>>>>>> Alex
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> presented hardware address of this type so I
>>>>>>>>>>>> don't know it the rest of it make sense.
>>>>>>>>>>>> 
>>>>>>>>>>>>> Alex
>>>>>>>>>>>>> 
>>>>>>>>>>>>> //default: //      log_fatal("Unsupported
>>>>>>>>>>>>> device type %ld for \"%s\"", //
>>>>>>>>>>>>> (long int)sa->sa_family, name); default:
>>>>>>>>>>>>> hw->hlen = 7; hw->hbuf[0] = HTYPE_ETHER;

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Sep 2017 16:40:08 +0000

Hi Alex,

> Sent: Wednesday, September 06, 2017 9:11 AM

Obtain a prefix, yes. But, presumably, the Android node will want to use
the prefix in some fashion. It can either act as a router (which is prohibited
by Android without rooting the device) or it can act as a host and try to
assign addresses from the delegated prefix to an interface (which is also
prohibited by Android w/o rooting the device). 

> If so, it seems like a problem of Android.

AFAICT, Android tries to protect users from shooting themselves in
the foot. Rooting the device is the user's way of saying: "I know what
I am doing and accept the consequences of my actions" but it voids
any warranties.

> be allowed to freely set not one, but as many addresses that I want.

You can try bringing up a terminal window app on the Android and
type: "ip -6 addr add 2001:db8::1 dev X" but it will not let you do it.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Sep 2017 16:50:14 +0000

Hi Alex,

> Sent: Wednesday, September 06, 2017 9:21 AM

Yes, a VPN server is necessary but not necessarily costly to maintain. For
example, OpenVPN server runs well even on lightweight virtual machines.

> these cases we want the DHCPv6 Prefix Delegation to work straight on a

But, if the node gets a PD from a first network attachment point and then
moves to a second network attachment point, it will need to scrap the first
PD and get a new one. The result is a messy renumbering event and loss
of continuity for any sessions in progress.

> applications that's not ultra-important (they dont break).

Renumbering on-the-fly is hard, and applications that rely on a constant
IP address will break.
 
> We propose that as Prefix Delegation (not IA_NA address).

Maintaining a constant and unchanging address is beneficial for maintaining
application sessions, for avoiding renumbering events and (for mobile
enterprise device users) for maintaining a reachable set of addresses that
can always be used to locate the device.

Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Sep 2017 19:10:32 +0200

Fred,

Le 06/09/2017 à 18:40, Templin, Fred L a écrit :
[...]
>> We dont want DHCP to assign addresses on interfaces.  We want it
>> to obtain a prefix from the network (DHCPv6 Prefix Delegation). 
>> Right?
> 
> Obtain a prefix, yes. But, presumably, the Android node will want to
>  use the prefix in some fashion.

Yes, first, we want our in-house software to form an address out of the
delegated prefix and assign it on the WiFi interface.

We want to do that without having to root the smartphone.

64share already does that in some sort.

I dont understand why the 64share INFORMATIONAL RFC does address
assignment by default, yet if I want to do it with the Prefix Delegation
Stds Track RFC I have to risk the platform by trying to root it.

> It can either act as a router (which is prohibited by Android without
> rooting the device)

Transforming a Host into a Router by toggling ipv6_forwarding should not
need to root the device either.

> or it can act as a host and try to assign addresses from the 
> delegated prefix to an interface (which is also prohibited by Android
> w/o rooting the device).

Prohibition wrong, must open.

> the foot.

Good initiative, but wrong results.

Even if Android has not offered the means, others have offered more or
less official means to root, like Huawei.  At the end of the day one is
still capable to shoot in the foot.

Imagine that I had to root a smartphone in order to run IPv6 on it - is
that acceptable?

Is a user irresponsible if s/he  wants to use IPv6?

> Rooting the device is the user's way of saying: "I know what I am 
> doing and accept the consequences of my actions" but it voids any 
> warranties.

I agree.  Many people know what they are doing, but its inacceptable for
someone to claim knowing better without proof.

>> It's hard to accept buying an expensive smartphone with its data 
>> plan yet be forbidden to set an address on it on the command line.
>>  I should be allowed to freely set not one, but as many addresses 
>> that I want.
> 

That should change.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 6 Sep 2017 19:19:04 +0200 (CEST)

> Stds Track RFC I have to risk the platform by trying to root it.

That's because you're trying to install something on it by yourself, when 
the vendor has decided this is not something they want their users to do.

So proper procedure is to go to vendor and ask for feature.

I've been out of the loop for a long time now, but I still haven't heard 
of any mobile core vendor who implemented DHCPv6-PD. That's the right 
thing to get done (and for instance on some WWAN router to have DHCPv6-PD 
client), then after that you can grow the rest of the ecosystem by doing 
feature requests.

There is no standards action to be had here, the problem isn't with 
standards. It's with getting running code into all components needed to 
make this happen. There is nothing fundamental in 3GPP architecture that 
makes DHCPv6-PD hard to do, it's just that... nobody does it, so nobody 
tests against it.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Sep 2017 19:21:17 +0200

I wanted to clarify one thing.

> Here are the unique reasons - if solely these are solved then we get
> PD on cellular: - some modems in the UE (e.g. QDSP6 and others) block
> standard DHCPv6 UDP port numbers 546 and 547 and (and sometimes or)
> standard IP multicast addressing in both directions;

I mentioned above modem "QDSP6" which is a Qalcomm product in Sierra
module; but there are other modems in other platforms.

In our Android smartphone the brand is Huawei Mate 8, the processor is
produced by HiSilicon, the model is HiSilicom Kirin 950 and the modem
integrated in the processor is Balong Integrated UE [User Equipment]
Cat. 6E.

It is highly likely that the Balong Integrated UE blocks IPv6 multicast
packets; these packets are of utmost importance to the execution of
DHCPv6 Prefix Delegation.

(it is very little probable that the Base Station, nor SGW, nor PGW
block this multicast addressing).

I have been asked whether the Android linux (instead of the Balong modem
software) blocks these multicast packets necessary to DHCPv6 Prefix
Delegation.  I think no, but I am not a specialist of Android.

Anybody knows?  Is Android on Huawei smartphone blocking the multicast
addressed packets of DHCPv6 Prefix Delegation?

Alex

  this blocking was identified
> by comparing packet dumps on the ARM part of UE, vs on PGW; this
> blocking was further confirmed by successful Sol/Adv on unicast and
> non-std UDP ports. This blocking happens even though the application
> processor (e.g. ARM) does not block them. These ports and multicast
> are absolutely needed for Prefix Delegation, because Prefix
> Delegation runs as an integral part of DHCPv6. - much less likely, it
> may be that some infrastructure entities like Base Station or SGW -
> again, very little probable - blocks same DHCP ports and multicast. -
> DHCPv6 software is little parametrable or portable, even though much 
> Some details: - the DHCPv6 software on Android is hampered by the
> need of root access. Android blocks that.  One needs to ask the
> platform manufacturer running that Android to "root" the platform
> such as to be able to run some of the DHCP client software (e.g. ask
> Huawei for a key to root the smartphone).  That's a real pain.  There
> is a risk of "bricking" your platform, i.e. through it out a window. 
> money to become a member of a store.  DHCP should not be part of
> that, as SLAAC isnt; just like SLAAC, DHCP should be builtin for
> free. - the DHCPv6 server software "ISC" breaks if the port numbers
> are non-standard (not 546 nor 547) or unicast instead of multicast. 
> (e.g. "Discarding Solicit from [snip]; packet sent unicast") This was
> a real pain, because we had to modify the source code to allow it;
> other software like VoIP has SIP ports this configurable easily with
> a GUI. - Cisco parametering CLI of DHCPv6 service may have some
> problems in transforming a non-standard UDP port 546 of Solicit to a
> strange 26483.  That was a real pain to one. - various DHCPv6 client
> software break, or do not even start, with any other src and dst UDP
> ports than the standard (546, 547) and/or non-standard unicast
> instead of standard multicast.
> 
> cellular links; they were just speculations: - cellular operators
> dont provide DHCPv6 PD service (there are some who do under some
> operational conditions) - cellular operators have a hard time making
> an IPv6 addressing architecture that delegate prefixes instead of
> addresses (there are some who do make such architecture) - cellular
> operators only do '64' (it's false, some could do less, like 56 or
> even 48) - DHCPv6 software is not available on the client (there are
> some, like on Android, and more, see quoted mails below) - the
> computer that runs the DHCPv6 client is the same as the one that puts
> the Solicit on the wire: this is not true, because even in the 
> processors.  Often the modem part is confidential, only the binary is
> available to the public, and there are two IPs on it: Internet 
> Alex, with thanks to [Hachata], admin(s), managers, and technicals
> at offices and organisations.
> 
> 
>>>>>> support of DHCPv6-PD towards the User Terminal.  For
>>>>>> example, there is no cellular operator answering to
>>>>>> DHCPv6-PD requests issued by the User Terminal.
>>>>>> 
>>>>>> open software client, which does implement Prefix
>>>>>> Delegation. It can be (cross)compiled on various platforms;
>>>>>> then type "./dhclient -6 -P"; this sends an DHCPv6 Solicit
>>>>>> Identity Associtaion for Prefix Delegation message on the
>>>>>> interface.
>>>>>> 
>>>>>> However, whereas this software runs ok on interfaces such
>>>>>> as Ethernet, USBnet and WiFi interfaces, it breaks if run
>>>>>> on the cellular interface of some IoT cellular platform.
>>>>>> The error can be corrected by the quick-and-dirty solution
>>>>>> below.
>>>>> 
>>>>> hw->hbuf[0] = HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data,
>>>>> 6); break; #endif default: log_fatal("Unsupported device type
>>>>> %ld for \"%s\"", (long int)sa->sa_family, name); break;
>>>>> 
>>>> In cellular terminals there are so many non-IEEE different
>>>> kinds of links.
>>>> 
>>>>> hardware address of this type so I don't know it the rest of
>>>>> it make sense.
>>>>> 
>>>>>> Alex
>>>>>> 
>>>> list [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Sep 2017 19:53:42 +0200

Le 06/09/2017 à 19:19, Mikael Abrahamsson a écrit :
>> assignment by default, yet if I want to do it with the Prefix 
>> Delegation Stds Track RFC I have to risk the platform by trying to 
>> root it.
> 
> That's because you're trying to install something on it by yourself, 
> when the vendor has decided this is not something they want their 
> users to do.

What users want must be standard, and vice-versa.

We have a problem in that the standard is not what the users want.

Or maybe the problem lies in the vendor interpretation of what users want.

> So proper procedure is to go to vendor and ask for feature.

For Android there is a feature request to get DHCPv6 working on Android
https://issuetracker.google.com/issues/36949085

The discussion runs since 2012 until now.

Maybe with a specialised DHCPv6 Prefix Delegation request (rather than
just DHCPv6) it could go further?

> I've been out of the loop for a long time now, but I still haven't 
> heard of any mobile core vendor who implemented DHCPv6-PD.

Cisco does that.  On AS5500 they have DHCPv6 Prefix Delegation service.
  Some cellular operators have AS5500 on PGW.

Or I dont understand what do you mean by 'mobile core vendor'?

> That's the right thing to get done

Some feature requests are ongoing at hardware manufacturers, operators,
vendors; but do you have one particular feature request in mind that I
could file?

> (and for instance on some WWAN router to have DHCPv6-PD client),

I dont understand this.

Among many dimensions, there is one in which two distinct models propose
DHCPv6 Prefix Delegation in a cellular network.  A good sketch of it
(it misses many details like Host-IMP interfaces in the UE) is in
Figures 2 and 3 of RFC6653 "Prefix Delegation on LTE".

Is it model of Figure 2 you talk about?  Or Figure 3?

> then after that you can grow the rest of the ecosystem by doing 
> feature requests.

Which feature request would one think of?

> standards. It's with getting running code into all components needed 
> to make this happen. There is nothing fundamental in 3GPP 
> architecture that makes DHCPv6-PD hard to do, it's just that... 
> nobody does it, so nobody tests against it.

Others and us by rooting the device were able to successfully test it.

There is no more question of whether it works or not - it works,
provided some conditions are satisfied.

To make it work some put it on a VPN, others use non-standard unicast or
non-standard UDP port numbers.  We dont want to go that way, we want to
use standards.

The 3GPP specs must says this: the UE (e.g. QDSP6, Balong) MUST NOT run
DHCPv6 software, proxies, clients or relays; it MUST NOT filter IPv6
packets port 546 and 547, nor IPv6 multicast address ff02::2:1
(all-DHCP-servers).  It is the application processor (e.g. ARM) that
MUST run DHCPv6 software.

3GPP should also understand the fine distinction between
DHCPv6-for-addresses (IA_NA, we dont want on smartphone) and DHCPv6
Prefix Delegation (IA_PD, we want on smartphone).

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 6 Sep 2017 20:03:25 +0200 (CEST)

On Wed, 6 Sep 2017, Alexandre Petrescu wrote:

>> I've been out of the loop for a long time now, but I still haven't heard of 
>> any mobile core vendor who implemented DHCPv6-PD.
>

Yes, I mean PGW and the rest of the 3GPP core nodes.

> vendors; but do you have one particular feature request in mind that I 

No, "create everything needed for DHCPv6-PD server in PGW".

>> (and for instance on some WWAN router to have DHCPv6-PD client),

The natural case for DHCPv6-PD is a router with 4G uplink and multiple LAN 
interfaces.

> Prefix Delegation (IA_PD, we want on smartphone).

When we discussed this a few years back and i looked at the 2012 specs, 
this was already that way.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Sep 2017 18:14:27 +0000

Hi Alex,

In general, my understanding is that Android is like a mini linux system in
your pocket. As you know, linux prohibits general users from setting
network configurations (e.g., adding an address to an interface) without
first elevating their privileges. And, in android, the only way for a general
user to gain elevated privileges is to root the device.

To Mikael's point, system processes that are capable of managing
network configuration settings are placed there by the manufacturer
and have elevated privileges for the specific task they were designed
to perform. But, a general user cannot create an app with elevated
privileges, so unless the manufacturer supports it the app cannot
mess around with network configuration settings.

Apps that use VpnService are an example of an app that can work
around this limitation. Do you know of others?

Thanks - Fred

> Sent: Wednesday, September 06, 2017 10:11 AM
> Subject: Re: [v6ops] Android must allow root access
> 
> Fred,
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Sep 2017 21:15:25 +0200

Mikael,

Le 06/09/2017 à 20:03, Mikael Abrahamsson a écrit :
>> Some feature requests are ongoing at hardware manufacturers, 
>> operators, vendors; but do you have one particular feature request 
>> in mind that I could file?
> 

I see, I agree.  It sounds like an excellent feature request.

We did something along these lines that and we got answers: (1) the
Cisco CLI has a problem in setting other UDP listening port number than
the standard 547.  When they set it to 546 the GUI shows 26483 and (2)
they dont want to listen to any unicast address because the DHCPv6
_multicast_ address is the standard.

It's also little appreciated to ask Cisco for a feature request that is
a Balong problem (multicast is standard and Balong does unicast).

I wonder whether Balong has a webpage to receive feature requests?  I
could ask them to allow IPv6 multicast through, because DHCPv6 PD needs it.

Or should one rather ask the DHC WG to for a DHCPv6 server to listen
to unicast to become a standard too?  And maybe listen to a
dynamically-defined UDP port number, rather than the fixed 547?

Which way?

One should consider that an update to Balong may be a hardware upgrade,
which may be rolled in into future smartphones, but old smartphones
would still not work.  I would like a solution for both present and
future smartphones to run DHCPv6 Prefix Delegation, because some of the
users I am concerned with will carry their old smartphones and some cars
will carry new 4G modems.

> The natural case for DHCPv6-PD is a router with 4G uplink and 
> multiple LAN interfaces.

I agree, and Sierra built what may be the smallest such natural router
on the market (4g uplink, Ethernet downlink1, WiFi downlink2 on
7cmx7cm).  Yet it can't be called "smallest IPv6 WWAN router" because of
this lack of PD.

>> DHCPv6-for-addresses (IA_NA, we dont want on smartphone) and
>> DHCPv6 Prefix Delegation (IA_PD, we want on smartphone).
> 
> When we discussed this a few years back and i looked at the 2012 
> specs, this was already that way.

In this case, I believe there may be misunderstanding.  Either spec
writers dont understand the implementers, or vice-versa.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 6 Sep 2017 21:37:09 +0200 (CEST)

> dynamically-defined UDP port number, rather than the fixed 547?

What unicast address would you send this packet to?

> Which way?

Fix the defective 3GPP baseband thingie that drops multicast is the proper 
solution.

> writers dont understand the implementers, or vice-versa.

... or the implementers do the wrong thing because they don't know better. 
Perhaps they tried to save energy so they decided to put in filters for 
multicast traffic.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Sep 2017 22:11:55 +0200

> What unicast address would you send this packet to?

An unicast address communicated out-of-band.

>> Which way?
> 
> Fix the defective 3GPP baseband thingie that drops multicast is the 
> proper solution.

That may mean new hardware.

But old hardware would continue to block DHCPv6-PD.

> ... or the implementers do the wrong thing because they don't know 
> better. Perhaps they tried to save energy so they decided to put in 
> filters for multicast traffic.

Could be.

Alex

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Sep 2017 12:02:00 +1000

In message <[email-masked]>, "T
emplin, Fred L" writes:
> Hi Alex,
>
> In general, my understanding is that Android is like a mini linux system
> in your pocket. As you know, linux prohibits general users from setting
> first elevating their privileges. And, in android, the only way for a
> general user to gain elevated privileges is to root the device.

Can anyone tell me why we bother with reserved ports anymore on
single user machines?  No one uses r* commands anymore and they are
the only thing that really depended on ports being restricted.

The only thing else they do is allow the operator to bring up a
service after startup without having to worry has some "user" grabbed
the port.

> mess around with network configuration settings.

Reserved ports are orthogonal to changing network settings.  I can
configure FreeBSD so all ports are available to all users but only
root can change the systems IP addresses.

> > From: Alexandre Petrescu mailto:[email-masked]
> > Subject: Re: v6ops Android must allow root access
> >
> > Fred,
> >
> > Le 06/09/2017  18:40, Templin, Fred L a crit :
> > ...

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Sep 2017 11:22:06 +0900

On 7 Sep 2017 11:02, "Mark Andrews" <[email-masked]> wrote:

That seems like a good enough reason to me, particularly if you think of a
non-network-savvy user that could potentially be running an app that's
misbehaving or even malicious.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Sep 2017 12:40:18 +1000

In message <CAKD1Yr06gR0+G60987US=[email-masked]>
> misbehaving or even malicious.

And what servers are there on a phone for them to bring up?  DHCP
servers when tethered.  Anything else?  Sshd - No.  Telnetd - No.
Httpd - No.  Httpds - No.  A much saner approach would be to have
a reserved list for the ACTUAL ports the phone may use not the
complete range.

That allows apps to provide services that phone doesn't provide
itself.  You could even disable a port if you want a app to replace
the system one and restart the phone.

Mark

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Sep 2017 11:47:16 +0900

> the system one and restart the phone.

I think a better way to do that is to have the app request a port from a
privileged process that can do arbitration.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 6 Sep 2017 19:54:52 -0700

> On Sep 6, 2017, at 7:02 PM, Mark Andrews <[email-masked]> wrote:
> 

FTP proxies, maybe?

> service after startup without having to worry has some "user" grabbed

That seems unlikely, these days.  Any "system" services will (or at least should) get launched before any general user access is allowed, so the system bits will have glommed on to the respective network ports by then.

But the idea that ports <= 1024 are "magic" died the day that BSD/OS was released to the wild blue Internet.

--lyndon

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 7 Sep 2017 05:43:46 +0200 (CEST)

> That may mean new hardware.

No, it most likely means updated software in the baseband module. This 
however is also not something YOU can fix, it has to be fixed by whoever 
bought it and incorporated it into its device (which you then bought).

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Sep 2017 08:45:20 +0200

Le 07/09/2017 à 05:43, Mikael Abrahamsson a écrit :
> No, it most likely means updated software in the baseband module.

YEs in principle, but no in some case.

Some modem manufacturer does not want to update software on baseband
module that manufacturer considers to be too old.  That modem
manufacturer recommends to the bigger system integrator to move first to
the new 'baseband' module before updating the software to support DHCPv6.

(it is the case with some support at Qualcomm considering MDM8215
'baseband' being too old - they dont support it anymore despite being
present in some devices; they recommend replacing old with a new
'baseband' MDM9207 including a new version of QDSP6 modem; without that
some Qualcomm support will not allow some Sierra engineer to update the
software of the old modem QDSP6 - simply put they dont provide the
source code of the old modem to some customer).

(maybe I dont understand the term 'baseband' term very well, but it is
sometimes used to designate just the "modem" running miniVM, other times
to designate the processor that runs the tcpdump; in this second
interpretation it includes both an ARM Cortex and the 'modem'; it's the
'modem' part of the 'baseband' that poses problems, not the ARM part of
the 'baseband' processor.)

> This however is also not something YOU can fix, it has to be fixed by
> whoever bought it and incorporated it into its device (which you then
> bought).

I really would like to, but the end result of a case described above is
that I am forced into getting new hardware if I want that
546-port-blocked problem fixed in the modem thingie, and thus DHCPv6
Prefix Delegation to run.

Users of old devices wont be able to use DHCPv6 PD.

When one thinks about 'old' modems one has to have in mind smartphones
but also cars.  There are still many cars in the market that have
2011-year Sierra modules and these wont ever be able to connect to IPv6
  Internet.

This is not a happy situation to be in.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 7 Sep 2017 09:53:36 +0200 (CEST)

> This is not a happy situation to be in.

Sure. But I don't see any standards-action here. You can write operational 
document how to get around the problem of hardware/software not 
implementing support for existing standards (which typically means 
tunneling).

But I doubt you're going to see anyone interested in standardizing unicast 
DHCPv6-in-3GPP with out-of-band address for DHCP communication. That seems 
more like a 3GPP profile than anything else.