Subject: Re: [v6ops] DHCPv6 PD client on cellular on some IoT platform

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Jul 2017 18:10:57 +0200

Hi Fred,

But what we want is DHCPv6 PD on a real cellular interface (not tunnel).

Alex

Le 24/05/2017 à 23:21, Templin, Fred L a écrit :
> Hi Alex,
> 
> We have been doing DHCPv6 PD on Androids for a long time. DHCPv6 messaging
> is via a tunnel over the cellular and WiFi links. The DHCPv6 client app was easy to
> implement and requires just a small amount of code and a few DHCPv6 messages.
> The DHCPv6 server we are using is from ISC.
> 
> Thanks - Fred
> 
>> -----Original Message-----
>> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
>> Sent: Wednesday, May 24, 2017 10:06 AM
>> To: [email-masked]
>> Subject: [v6ops] DHCPv6 PD client on cellular on some IoT platform
>>
>> 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.
>>
>> 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
> 
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 5 Jul 2017 18:08:13 +0000

Hi Alex,

OK, but hen how would you expect to handle multiple interfaces (cellular + WiFi) ?

Thanks - Fred

> From: Alexandre Petrescu [mailto:[email-masked]]
> Sent: Wednesday, July 05, 2017 9:11 AM
> To: Templin, Fred L <[email-masked]>; [email-masked]
> Subject: Re: [v6ops] DHCPv6 PD client on cellular on some IoT platform
> 
> Hi Fred,
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 5 Jul 2017 17:54:36 -0600

> The DHCPv6 server we are using is from ISC.

Point of Clarification:

In that, you aren't going across the backbone to a server in ISC, are you? I would expect you are running one of ISC's open source packages  (ISC-DHCP or KEA) on a server inside Boeing. Hence, not across a tunnel.

Correct?

---

From: Mark Andrews <[email-masked]>
Date: Thu, 06 Jul 2017 11:16:05 +1000

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

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.

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Jul 2017 18:32:36 +0200

Mark, noted, will try.

Just a note...

> 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

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 17 Jul 2017 18:26:24 +0200

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 :
>>> 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 \"%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?
> 
> Other clients work out of the box on this - I agree with you, strange
> - "rmnet0" interface.
> 
> Alex
> 
>> 
>>> 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;
>>> 
>>> _______________________________________________ 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: Ted Lemon <[email-masked]>
Date: Mon, 17 Jul 2017 20:07:07 +0200

Understood.   The issue here is that the ISC client is using bpf (or lpf)
to send packets rather than using the Linux stack.   Try compiling it with
#define USE_SOCKETS and see if the behavior changes.

On Mon, Jul 17, 2017 at 6:26 PM, Alexandre Petrescu <
[email-masked]> wrote:

>>>> \"%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;
>>>>

---

From: Francis Dupont <[email-masked]>
Date: Tue, 18 Jul 2017 10:35:13 +0200

>  #define USE_SOCKETS and see if the behavior changes.

=> in fact it uses BPF/LPF/... for DHCPv4 but as you can't disable
DHCPv4 yet you should recompile with the socket only option.
 This can break direct DHCPv4 on some systems but it doesn't matter as
you want only DHCPv6. Note if (when?) this will become a common case
you can ask for a feature request so it will be handled directly
at the configuration phase.

Regards

[email-masked] (and also [email-masked])

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jul 2017 10:55:10 +0200

I think you can do DHCPv4 on linux without using LPF.   Also possibly on
various modern BSDs.   The advanced socket API appears to support this.

---

From: [email-masked]
Date: Tue, 18 Jul 2017 11:19:47 +0200 (CEST)

> at the configuration phase.

The problem, at least on some systems, is being able to receive DHCP
*broadcast* packets (e.g. the first Discover packet in a DHCPv4
transaction).

I run ISC DHCP on FreeBSD, compiled without BPF, and with all DHCP
traffic via relay agents. No problems.

Steinar Haug, AS2116

---

From: Francis Dupont <[email-masked]>
Date: Tue, 18 Jul 2017 11:25:11 +0200

>  various modern BSDs.   The advanced socket API appears to support this.

=> this is why I added "on some systems". Note it is harder on the client
side, and on the server side with a relay BPF/LBF/... is never required.
Of course this applies only to DHCPv4.

Regards

[email-masked]

---

From: Mark Smith <[email-masked]>
Date: Tue, 18 Jul 2017 20:39:40 +1000

> Of course this applies only to DHCPv4.

You're right, I'm miss-attributing these sort of client issues to a server.

I'm pretty sure under Linux all interfaces are IPv4 enabled by
default, which I think would mean that even if the interface doesn't
have an address, it will still receive and process IPv4 broadcasts.
IPv6 is the same, although there is a disable_ipv6 knob to disable all
IPv6 packet processing on an interface. So in the OPs case, even
though the host is an "IPv6 only" host, it could still receive and
process some IPv4 packets.

Filtering them or not running a DHCPv4 process is probably the only option.

Regards,
Mark.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 18 Jul 2017 12:39:02 +0200

>  *broadcast* packets (e.g. the first Discover packet in a DHCPv4

=> or worse to send it without an IP address assigned to the interface...

>  traffic via relay agents. No problems.

=> yes, this case is known always to work. Kea offers the UDP socket
(vs BPF/LPF) in its configuretion file so you don't need to recompile
(i.e., Kea learnt from ISC DHCP :-).

Regards

PS: to summary: the hack used to make the DHCP client to work an Adroid
is not a real hack and is perfectly safe for its goal (DHCPv6 prefix
delagation).

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Jul 2017 15:37:34 +0000

I have been running my own little DHCPv6 PD client on Android for a long time.
Works great with the kea server, and probably with other DHCPv6 servers that
I haven't had time to try yet.

Thanks - Fred

> From: v6ops [mailto:[email-masked]] On Behalf Of Francis Dupont
> Sent: Tuesday, July 18, 2017 2:25 AM
> To: Ted Lemon <[email-masked]>
> Cc: IPv6 Ops WG <[email-masked]>
> Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android
>