Subject: [dhcwg] Fwd: Kernel implementation of DANIR for IoT Router - DHCPv6-PD and ND

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 16 Sep 2019 09:25:41 +0200

Hello to participants in DHC WG,

One might be interested in this kernel implementation of DHCPv6-PD parts.

Yours,

Alex and Dmytro

-------- Message transféré --------
Sujet : 	Kernel implementation of DANIR for IoT Router - DHCPv6-PD and ND
Date : 	Mon, 16 Sep 2019 09:21:46 +0200
De : 	Alexandre Petrescu <[email-masked]>
Pour : 	[email-masked] <[email-masked]>

Hi,

The kernel implementation of DANIR for IoT Router was finally working a 
few weeks ago.

It is an implementation of draft-shytyi-v6ops-danir-03.txt.  This is the 
right thing to do, instead of '64share' RFC7278.

In this video one can see the kernel in the IoT Router issues a DHCPv6 
PD request on its egress and obtains a /56; it then makes several /64s 
out of it and subsequently sends RAs with these on the ingress interfaces.

The DHCPv6 server is took off-the-shelf.  The PDP part is not present in 
the IoT Router, but we expect it to work ok on a ptp link on a cellular 
network to a smartphone.

The video recorded the virtual machines output on the IoT Router 
(featured below), the Client device behind it, and the DHCPv6-PD server.

https://youtu.be/DymVQY7bCUM

Yours,

Alexandre PETRESCU and Dmytro SHYTYI

PS: we will soon post the source code on github.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 17 Sep 2019 11:18:46 +0200

Hi Li,
Thank you for the message.

Le 17/09/2019 à 03:48, Li HUANG a écrit :
> 09:39.hk <http://39.hk> S8 Sept 17th 2019
> 
> 
> Thank you dhcwg returning on this,
> 
> 
> 
> IoT either PTP to dhcpv6 pd server sounds very like the running 
> preferially to wireless, or phone networks instead of apt windows that 
> blocked wwan, wlan services of it ...

Indeed.  An IoT Router is a device of class IoT, but has several IP 
interfaces, hence it is a router.

An IoT Router uses the wireless egress interface (either wlan, or 
cellular) to send DHCPv6-PD request.

> To the kernel apart, OEM user would principle following its offered 
> updates of system, in case dhcpv6 required update, how would clients 
> obey protocol rcf 3315, 8415, 6260 whilst OEM warranty contract to get 
> all none conflicts?

Please separate the phrases into sentences, by using terminating dots. 
If you do, I will understand you better.  Did you mean this:

"About the kernel part: OEM user would in principle follow the system 
updates.  The updates could be performed by using an IP address obtained 
by dhcpv6.  But how would clients obey protocol rfc3315, 8415, 6260? 
They need to maintain warranty and avoid conflicts".

Let me try to answer.

In an IoT router there is indeed a modem of an OEM.  For example a 
Huawei or a Qualcomm modem.  This modem often updates its software, in 
order to move from 4G+ to 4G++, for example.  Typically it updates by 
using over-the-air software update technology.  It needs an IP address 
for itself.  This IP address is just one of multiple addresses of an IoT 
router.   Multiple addresses make for a prefix.  To obtain a prefix one 
uses DHCPv6-PD, not just SLAAC.

So, the OEM user needs to run DHCPv6-PD.  It must do so in accordance 
with RFC3315 and then RFC8415.  It needs to update its software from 
RFC3315 to RFC8415.

> Microsoft is one putting on tracking, it must be forwarded to them about.

A Microsoft computer, like a Windows 10 tablet, also uses a 4G modem. 
Windows does implement DHCPv6.

Do you know whether Windows 10 implements DHCPv6-PD?

> Let have your kind advises on it please .

I would like to learn whether I can put this open source DHCPv6-PD plus 
ND linux kernel implementation into the Windows kernel?

https://github.com/dmytroshytyi/KD6-DHCPv6-PD-DANIR

Or maybe in a BSD OS?

Or maybe run this linux kernel software as a virtual machine on windows 
and link its virtual interface to the real interface?

Alex

> 
> 
> 
> Sincerely yours
> Li HUANG
> 
> 
> On Tue, Sep 17, 2019, 00:18 Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     <mailto:[email-masked]>
>     Pour : 	[email-masked] <mailto:[email-masked]> <[email-masked]>
>     <mailto:[email-masked]>
> 
> 
> 
>     Hi,
> 
>     The kernel implementation of DANIR for IoT Router was finally
>     working a few weeks ago.
> 
>     It is an implementation of draft-shytyi-v6ops-danir-03.txt.  This is
>     the right thing to do, instead of '64share' RFC7278.
> 
>     In this video one can see the kernel in the IoT Router issues a
>     DHCPv6 PD request on its egress and obtains a /56; it then makes
>     several /64s out of it and subsequently sends RAs with these on the
>     ingress interfaces.
> 
>     The DHCPv6 server is took off-the-shelf.  The PDP part is not
>     present in the IoT Router, but we expect it to work ok on a ptp link
>     on a cellular network to a smartphone.
> 
>     _______________________________________________
>     dhcwg mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Li HUANG <[email-masked]>
Date: Wed, 18 Sep 2019 14:39:41 +0900

09:39.hk S8 Sept 17th 2019

IoT either PTP to dhcpv6 pd server sounds very like the running preferially
to wireless, or phone networks instead of apt windows that blocked wwan,
wlan services of it ...

To the kernel apart, OEM user would principle following its offered updates
of system, in case dhcpv6 required update, how would clients obey protocol
rcf 3315, 8415, 6260 whilst OEM warranty contract to get all none conflicts?

Sincerely yours
Li HUANG

On Tue, Sep 17, 2019, 10:48 Li HUANG <[email-masked]> wrote:

> 09:39.hk S8 Sept 17th 2019
>
>
> updates of system, in case dhcpv6 required update, how would clients obey
> protocol rcf 3315, 8415, 6260 whilst OEM warranty contract to get all none
> conflicts?
>
>
> On Tue, Sep 17, 2019, 00:18 Alexandre Petrescu <
> [email-masked]> wrote:
>
>> <[email-masked]>
>> Pour : [email-masked] <[email-masked]> <[email-masked]>
>>
>> Hi,
>>
>> In this video one can see the kernel in the IoT Router issues a DHCPv6 PD
>> request on its egress and obtains a /56; it then makes several /64s out of
>> it and subsequently sends RAs with these on the ingress interfaces.
>>
>> [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 Sep 2019 09:45:09 +0200

Dear Li,

Please help me understand:

What do you mean by 'apt windows'?

Alex

Le 18/09/2019 à 07:39, Li HUANG a écrit :
> 09:39.hk <http://39.hk/> S8 Sept 17th 2019
> 
> 
> On Tue, Sep 17, 2019, 10:48 Li HUANG <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     preferially to wireless, or phone networks instead of apt windows
>     that blocked wwan, wlan services of it ...
> 
> 
>     obey protocol rcf 3315, 8415, 6260 whilst OEM warranty contract to
>     get all none conflicts?
> 
> 
>         It is an implementation of draft-shytyi-v6ops-danir-03.txt. 
>         This is the right thing to do, instead of '64share' RFC7278.
> 
>         several /64s out of it and subsequently sends RAs with these on
>         the ingress interfaces.
> 
>         present in the IoT Router, but we expect it to work ok on a ptp
>         link on a cellular network to a smartphone.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 Sep 2019 14:05:01 +0200

Dear Li,

Thank you for the partial clarification you sent in private about 'apt 
windows'.  I understand that by 'apt windows' you mean 'apart from 
windows', which means 'with the exception of Windows'.

So, I think you mean that we in our draft have a preference to run 
DHCPv6-PD over the wireless interface, like with a phone.  You also mean 
that is ok.  You also mean that only Windows runs DHCPv6 on a wired 
interface; because Windows blocked DHCPv6 on wwan and wlan interface.

I think you are saying that this Windows blocking DHCPv6-PD on the 
wireless interfaces caused you a lot of trouble, even after system updates.

Because of that I think you are asking that we make and forward to 
Microsoft, a request to make DHCPv6-PD on the wireless interface.

I may be wrong though.

I would like to ask you: do you know somebody at Microsoft who cares 
about DHCPv6?  Or should I write simply to [email-masked] 
hoping they will direct the message to people in charge?

Alex

---

From: Li HUANG <[email-masked]>
Date: Fri, 20 Sep 2019 08:55:30 +0900

08:47.hk S8 Sept 20 2019

continued...,

Thank you rephrasing our diagonose for assuring the points.

Wireless advance for dhcpv6 is imagined to experienced network maps. Which
none wireless devices and plan isp at all decades.

Microsoft who is handing rcf3315 according modified failures,  to changed
board OEM machine, has reached wall to resolve it inside microsoft.

Looking for some where who would enter the juridical like IEFT...etc., in
order to edge out what responsibility taken by who, if in such compromising
rcf rules obeying  in conditions.

Sincerely yours
Li HUANG

On Wed, Sep 18, 2019, 21:05 Alexandre Petrescu <[email-masked]>
wrote:

> >>     <[email-masked] <mailto:[email-masked]
> >>
> >>     wrote:
> >>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 20 Sep 2019 10:08:56 +0200

Hi Li,

 From your message, I think I understand some things, but I am not sure.
The reason of doubt is that the English expression is not clear.

I suppose that you are using an automatic translator, from Chinese to
English, whose output is not good for me.

I suggest a better way: please write the Chinese text that you type,
instead of the translation.

I will then convert it myself with my preferred converter, which is
translate.google.fr.

In this way, we may communicate better, and concentrate on the technical
aspects.

Alex

你好，

从你的消息，我想我理解一些事情，但我不确定。
怀疑的原因是英语表达不清楚。

我想你使用的是自动翻译器，从中文到
英语，输出不好。

我建议一个更好的方法：请写下你输入的中文文本，
而不是翻译。

然后我将使用我喜欢的转换器自行转换它
translate.google.fr。

通过这种方式，我们可以更好地沟通，并专注于技术
方面。

亚历克斯

Le 20/09/2019 à 01:55, Li HUANG a écrit :
> 08:47.hk <http://47.hk> S8 Sept 20 2019
> 
> 
> continued...,
> 
> 
> Wireless advance for dhcpv6 is imagined to experienced network maps.
>  Which none wireless devices and plan isp at all decades.
> 
> 
> Microsoft who is handing rcf3315 according modified failures,  to 
> changed board OEM machine, has reached wall to resolve it inside
> microsoft.
> 
> 
> Looking for some where who would enter the juridical like
> IEFT...etc., in order to edge out what responsibility taken by who,
> if in such compromising rcf rules obeying  in conditions.
> 
> 
> 
> Sincerely yours Li HUANG
> 
> 
> 
> 
> 
> 
> On Wed, Sep 18, 2019, 21:05 Alexandre Petrescu 
> Thank you for the partial clarification you sent in private about
> 'apt windows'.  I understand that by 'apt windows' you mean 'apart
> from windows', which means 'with the exception of Windows'.
> 
> DHCPv6-PD over the wireless interface, like with a phone.  You also 
> mean that is ok.  You also mean that only Windows runs DHCPv6 on a
> wired interface; because Windows blocked DHCPv6 on wwan and wlan
> interface.
> 
> <mailto:[email-masked]> hoping they will direct the message
> to people in charge?
> 
> Alex
> 
>>> 09:39.hk <http://39.hk> <http://39.hk/> S8 Sept 17th 2019
>>> 
>>> 
>>> To the kernel apart, OEM user would principle following its
>>> offered updates of system, in case dhcpv6 required update, how
>>> would
> clients
>>> Sincerely yours Li HUANG
> <mailto:[email-masked]>
>>> <mailto:[email-masked] <mailto:[email-masked]>>>
>>> wrote:
>>> 
>>> 09:39.hk <http://39.hk> <http://39.hk> S8 Sept 17th 2019
>>> 
>>> 
>>> Microsoft is one putting on tracking, it must be forwarded
> to them
>>> about.
>>> 
>>> 
>>> Sincerely yours Li HUANG
>>> <[email-masked]
> <mailto:[email-masked] 
> <mailto:[email-masked]>>>
>>> wrote:
>>> 
>>> -------- Message transféré -------- Sujet :     Kernel
>>> implementation of DANIR for IoT Router - DHCPv6-PD and ND Date :
>>> Mon, 16 Sep 2019 09:21:46 +0200 De :     Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>>
>>> <mailto:[email-masked]
> <mailto:[email-masked]>>
>>> Pour : [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>
>>> <[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
>>> <mailto:[email-masked]>>
>>> 
>>> 
>>> 
>>> Hi,
>>> 
>>> It is an implementation of draft-shytyi-v6ops-danir-03.txt. This
>>> is the right thing to do, instead of '64share' RFC7278.
>>> 
>>> (featured below), the Client device behind it, and the
> DHCPv6-PD
>>> server.
>>> 
>>> _______________________________________________ dhcwg mailing
>>> list [email-masked] <mailto:[email-masked]>
>>> <mailto:[email-masked]
> <mailto:[email-masked]>>
>> _______________________________________________ dhcwg mailing list 
> _______________________________________________ dhcwg mailing list

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 23 Sep 2019 19:27:13 +0200

Hi Li,

IETF is not police of protocols: IETF can not force organisations to 
implement protocols or to fix bugs.  But we can discuss about protocols 
at IETF.

If Microsoft Windows does not implement DHCPv6-PD on wireless links 
(like on cellular), then I have two things to say.

One thing is to say that Microsoft programmers should not worry.  They 
are not the only ones who do not implement DHCPv6-PD on wireless links. 
There is also Qualcomm who refuses to.  It may, or it may not be a 
problem.  But it is not only Microsoft.  An it is a good topic to work on.

The other thing is to say that it is possible to run a linux virtual 
machine on a Microsoft Windows real machine.  In that linux machine, one 
can run DHCPv6-PD, on the wireless interface of the real Microsoft 
Windows machine.  We propose open source to achieve this.  It is 
available at 
https://dmytro.shytyi.net/kd6-danir-lite-kernel-dhcpv6-pd-and-ndp-implementation/

(we have tried to upload it to github, but we hit a 2Gb upload limit; 
this limit is a thing to complain to github, together with its lack of 
IPv6 access; and github is now a Microsoft organisation :-)

Alex and Dmytro

Le 20/09/2019 à 01:55, Li HUANG a écrit :
> changed board OEM machine, has reached wall to resolve it inside microsoft.
> 
> 
> Looking for some where who would enter the juridical like IEFT...etc., 
> in order to edge out what responsibility taken by who, if in such 
> compromising rcf rules obeying  in conditions.
> 
> 
> 
> Sincerely yours
> Li HUANG
> 
> 
> 
> 
> 
> 
>     mean
>     <mailto:[email-masked]>
>      >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >>
>     offered
>      >>         De :     Alexandre Petrescu
>      >> <[email-masked] <mailto:[email-masked]>>
>      >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>