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

[Alexandre Petrescu <[e-mail]>]

Hi Fred,

Le 05/09/2017 à 21:54, Templin, Fred L a écrit :
> Hi Alex,
> 
>> -----Original Message-----
>> From: Alexandre Petrescu [mailto:[e-mail]]
>> Sent: Tuesday, September 05, 2017 12:35 PM
>> To: Templin, Fred L <[e-mail]>; [e-mail]
>> Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android
>>
>>
>>
>> Le 05/09/2017 à 18:06, Templin, Fred L a écrit :
>>> Hi Alex,
>>>
>>>> -----Original Message-----
>>>> From: v6ops [mailto:[e-mail]] On Behalf Of Alexandre Petrescu
>>>> Sent: Tuesday, September 05, 2017 8:39 AM
>>>> To: [e-mail]
>>>> Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android
>>>>
>>>> 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.
>>>
>>> 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.
>>
>> 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)
> 
> 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.

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.

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

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

> 
> 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.
>>>>
>>>>
>>>> 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 <[e-mail]>,
>>>>>>>> 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 [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>>>>
>>>>>>> _______________________________________________ v6ops mailing
>>>>>>> list [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>>>>>
>>>>>> _______________________________________________ v6ops mailing list
>>>>>> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>>>>
>>>>> _______________________________________________ v6ops mailing list
>>>>> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>