Re: [v6ops] Implementation of DANIR for IoT Router - DHCPv6-PD and ND

Dmytro Shytyi <ietf.dmytro@shytyi.net> Tue, 29 October 2019 21:16 UTC

Return-Path: <ietf.dmytro@shytyi.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6976B12006D for <v6ops@ietfa.amsl.com>; Tue, 29 Oct 2019 14:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=shytyi.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbBfUDWs_0Vn for <v6ops@ietfa.amsl.com>; Tue, 29 Oct 2019 14:16:09 -0700 (PDT)
Received: from sender11-of-o52.zoho.eu (sender11-of-o52.zoho.eu [185.20.211.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB52512001E for <v6ops@ietf.org>; Tue, 29 Oct 2019 14:16:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1572383765; cv=none; d=zohomail.eu; s=zohoarc; b=XqDXBEvZfAc4qMbyVKJi2g01+hREszACcixt3qaXp9UP3IGUQwkIp4SGyzPmf6nvr1+n5QsBVDmkmzBthRShiXBhQJEqblqYK7h9aiB+jq1DtwrwrpFNBBCEDg+fa4MWsQzJ5dD+M+xVDHBIdjStYDzTPR5fdDd2GAHpiX/GyZk=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1572383765; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=kR75sDwcJ8hfQhONlsHO2PD8/vCoO+dJzrSPrhsA4z0=; b=ME9GTtQHnAuKhmSVGQ0BGnVGFykhICvIxuV4N59cTud3wPJBFm9ZZFTpalUGM+Td6b0I5peTd54U6JP1Vo969+zoYWrUAvSItlsTzWf3ClrDO5TGksmpB1v5TgZvG/Dg2lAQAJJbZvCmymN/pHkHyxmgW+BP1abuW9kXe6IYPz0=
ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=shytyi.net; spf=pass smtp.mailfrom=ietf.dmytro@shytyi.net; dmarc=pass header.from=<ietf.dmytro@shytyi.net> header.from=<ietf.dmytro@shytyi.net>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1572383765; s=hs; d=shytyi.net; i=ietf.dmytro@shytyi.net; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=69010; bh=kR75sDwcJ8hfQhONlsHO2PD8/vCoO+dJzrSPrhsA4z0=; b=CzjDuhsdtdpcIg+DeVGyW7nIH7YbPRQUKxHf3QPkVMTr22ZW1esmVJ3a9I6rjX1w a8Dujz2jKkdwqrGnINLlXCSNn80ZRBnx9aCnB1ED5sdQ6YCEknnGYse22S/mbd47nNQ CXjkLQzHWYNPEEZy5tbCq94x9co5TwvshskMSWgI=
Received: from sender11-op-f32.zoho.eu (172.26.23.79 [172.26.23.79]) by mx.zohomail.com with SMTPS id 1572383764386901.1930180677879; Tue, 29 Oct 2019 22:16:04 +0100 (CET)
Received: from mail.zoho.eu by mx.zoho.eu with SMTP id 157238376430951.376030478771554; Tue, 29 Oct 2019 22:16:04 +0100 (CET)
Date: Tue, 29 Oct 2019 22:16:04 +0100
From: Dmytro Shytyi <ietf.dmytro@shytyi.net>
To: Li HUANG <bleuoisou@gmail.com>
Cc: v6ops <v6ops@ietf.org>
Message-Id: <16e19602f4a.11692076f325242.5254263295023703726@shytyi.net>
In-Reply-To: <CAGGiuEaTL-LMuyC7mBFL823vtnmiVrjgamHH8y7cqi==J44r9Q@mail.gmail.com>
References: <c7e54351-9096-53e7-0322-cf7d0abc58f2@gmail.com> <740671f9-6e68-70ac-8dd2-91f9d24b965d@gmail.com> <CAGGiuEbxbw67MgKUCcZcp0KsYoiewXogrynFU7b3HThOY6FD-Q@mail.gmail.com> <CAGGiuEbksPxKV6GLA06A7untZOrwpYKnb_Ycu50ibb9cvzNtxg@mail.gmail.com> <4561ca6d-4611-27e8-5cb3-16e72075fa65@gmail.com> <c32c6804-1e67-2f1d-a27f-4d925dce91df@gmail.com> <CAGGiuEYcHDs691gzRSVdW_4MK1d7LWzjDRqv7WeBGt81+LWS3w@mail.gmail.com> <ad7b5122-d1af-7629-4401-8c989ad274a7@gmail.com> <CAGGiuEaQDMyb8EMBmCbTLk9j_FMR2rGzrjwazA+4MSVaPVhSuQ@mail.gmail.com> <750e36b6-1572-2b78-953b-b0da8ae39130@gmail.com> <16dded8e702.ed9b0e42235989.4158295187609945732@shytyi.net> <CAGGiuEbHoCXaCi8nX6WA92juQx7G-+-VOagZv94HFoU8394MOw@mail.gmail.com> <16de3269bda.12447abf02199.1998508517577039185@shytyi.net> <CAGGiuEaTL-LMuyC7mBFL823vtnmiVrjgamHH8y7cqi==J44r9Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_905399_1466798737.1572383764300"
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
X-ZohoMailClient: External
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/2V5N5myRf_zKUP92U-hU-LojGjo>
Subject: Re: [v6ops] Implementation of DANIR for IoT Router - DHCPv6-PD and ND
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Oct 2019 21:16:14 -0000

Hello Li,


In the implementation it is possible to change the DUID. You need to modify the linux kernel module code and recompile it.

______________
Dmytro SHYTYI



---- On Sat, 19 Oct 2019 15:04:29 +0200 Li HUANG <bleuoisou@gmail.com> wrote ----



Oct. 19 2019  21:http://00.hk w10p m800 Sg|Rv





Thank you Dmytro and your group for sharing document on the specific dhcpv6 related topics .  You are welcome to share the dialog as well. 



Hopefully Linux/Uniz further  OS checking around  would be helped that from Dhcpv6DUID modifying unable remained to be the subnet concerning at your convenience . Which was online arrow getting to you ...





Sincerely

mailto:BleuOisou@gmail.com

Li HUANG







On Fri, Oct 18, 2019, 20:30 Dmytro Shytyi <mailto:dmytro@shytyi.net> wrote:







Hello Li, 



Don't you mind if we include in our disscussion the IETF v6ops working group?

In case you will not respond we will accept it as a permission to share our disscussion with IETF Working group. 

Thanks.



                              


Bien cordialement,

Dmytro SHYTYI






---- On Mon, 07 Oct 2019 14:32:46 +0200 Alexandre Petrescu <mailto:alexandre.petrescu@gmail.com> wrote ----



Li, 
 
Below you will find are some answers from Dmytro. 
 
I suggest we discuss this publicly on the v6ops WG email list, because 
it is on that list that others have responded (not on DHC WG email list). 
 
 
 1# 
 Router - is a node, that performs forwarding.  Router node is not a 
 final destination of forwarded packets. 
 
 Diagram : 
 ISP---Switch (4 mac found : isp x2 , modem x1 , IANA x1)---- Router 
 (WAN1,2, LAN 3 mac )---- PCs (wire, wireless , vpn mac) 
 
 && DHCPv6DUID failed to keep the modified DHCPv6DUID eth.initial.mac 
 
[Dmytro] In the implementation DHVPvyDUID type field is set to "1" that 
meanse that DUID based on the link-layer Address Plus Time is used. 
 
example from the DANIR KD6: 
 
    dhp.kd6_sol->my_client_id.duid_type = htons(1); 
 
    dhp.kd6_sol->my_client_id.hw_type = htons(1); 
 
    //DUID time convert kernel vertsion to compatible option value 
 
    ver = utsname()->version; 
 
    sscanf(ver, "%*s %*s %*s %*s %s %d %d:%d:%d %*s %d",ktime_month, 
&dh6_ktime.tm_mday, &dh6_ktime.tm_hour, &dh6_ktime.tm_min, 
&dh6_ktime.tm_sec, &dh6_ktime.tm_year); 
 
    dh6_ktime.tm_mon=GetMon(ktime_month); 
 
    //pr_info( "EP KTIME: %d,%d,%d,%d,%d,%d", dh6_ktime.tm_mon, 
dh6_ktime.tm_mday, dh6_ktime.tm_hour, dh6_ktime.tm_min, 
dh6_ktime.tm_sec, dh6_ktime.tm_year); 
 
    kernelCompilationTimeStartingFrom2000 = 
convertTimeDateToSeconds(dh6_ktime); 
 
    duid_time=htonl( kernelCompilationTimeStartingFrom2000 & 0xffffffff); 
 
    memcpy 
(&(dhp.kd6_sol->my_client_id.duid_time),&duid_time,sizeof(duid_time)); 
 
    memcpy (dhp.kd6_sol->my_client_id.my_hw_addr, d->dev->dev_addr, 48); 
 
 2# 
 DHCP-PD only can be configured by a figure not IPv6 . Term of , when 
 example 2002:: input :: would make the app grey uncontinued. 
 
 && 
 The Router Avertisement Messages carry the GUNPs 
 that are further used by the stateless autoconfiguration mechanism 
 (SLAAC) 
 
[Dmytro] RFC 4862 specifies the Router Advertisement processing process. 
 
 3# 
 Global Unique Address (GUA) - is an address that is globally 
 available and globally unique. 
 
 Diagram : 
 ISP---Switch (4 mac found : isp x2 , modem x1 , IANA x1)---- Router 
 (WAN1,2, LAN 3 mac )---- PCs (wire, wireless , vpn mac) 
 
 - GUA is DHCPv6DUID eth.mac ? 
 - which GUA to be mentioned at the draft ? 
 - Dhcpv6DUID using sub-prefix the same as the IPv4 exactly 
 working eth.mac , by ipconfig /all detected when the vista replaced its 
 motherboard and having both new and initial eth.mac shown both? 
 - "After the DHCPv6 packet leaves the cellular interface of 
 the IoT 
 Requesting Router via wireless OFDMA link, it reaches the element of 
 the access network which connects to the user equipment (UEs) - 
 eNodeB station."    likes there must be some wireless "USB.sgw.isp" 
 host or ,  Dhcpv6 must be on Cellular host ? When one of 4 mac switch 
 showing Nokia , which sometimes modem connecting arp -a shown as well? 
 That would cause the pretty much lost functions of wire.router.map 
 always via as if owning speed lower much than the wireless does have . 
 
[Dmytro] GUA is IPv6 global unique address. 
 
 4# 
 your freely downloadable kernal patch for Windows BIOS works ? 
 
[Dmytro] This is linux kernel module. Linux could be ran in the 
virtualbox in the windows environment. 
 
 5# 
 "The Hop Limit of packets that contain the DHCPv6 data MUST be 255 to 
 satisfy the properties of the cellular infrastructure.  To reach the 
 PGW from the UE the DHCPv6 packets are encapsulated by SGW into UDP/ 
 IPv4 packets; this encapsulation is for the GTP-U tunnel.  The 
 corresponding decapsulation mechanism decreases the Hop Limit; when 
 the Hop Limit reaches value 0 the packet is discarded; to avoid this 
 situation it is required to put the Hop Limit value of the DHCPv6 
 Solicit equal to 255." 
 
 - hop in switch default 64 decreased to 48 then the 
 SGW would not work--> no dhcpv6 completed ---> no ipv6 get to switch 
 then Rv after it ? 
 
 
The packet will be discarded when Hop Limit will reach 0. When Hop Limit 
 > 0 packet will not be discarded. 
 
 
Dmytro and Alex 
 
 
Le 04/10/2019 à 16:16, Li HUANG a écrit : 
> Oct. 04 2019  22:http://12.hk <http://12.hk> w10p m800 Sg|Rv 
> Attn: 
> 
> Authors' Addresses 
> 
>     Dmytro Shytyi 
>     SFR 
>     Paris area , Ile-de-France 
>     France 
> 
>     Email:mailto:ietf.dmytro@shytyi.net <mailto:mailto:ietf.dmytro@shytyi.net> 
>     URI:http://dmytro.shytyi.net 
> 
> 
> Internet-DraDHCPv6_PD, PDP and NDP Implementation in IoT Rou March 2019 
> 
> 
>     Alexandre Petrescu 
>     CEA, LIST 
>     CEA Saclay 
>     Gif-sur-Yvette , Ile-de-France   91190 
>     France 
> 
>     Phone: +33169089223 
>     Email:mailto:Alexandre.Petrescu@cea.fr <mailto:mailto:Alexandre.Petrescu@cea.fr> 
> 
> 
> Good Day Alex and Dmytro, 
> 
> 
> 
> 
> Do read through draft and thank you for your sharing . 
> 
> Some here could have not understood them well or clear , please help in 
> details off: 
> 
> 
> 1# 
> Router - is a node, that performs forwarding.  Router node is not a 
>     final destination of forwarded packets. 
> 
> Diagram : 
> ISP---Switch (4 mac found : isp x2 , modem x1 , IANA x1)---- Router 
> (WAN1,2, LAN 3 mac )---- PCs (wire, wireless , vpn mac) 
> 
> && DHCPv6DUID failed to keep the modified DHCPv6DUID eth.initial.mac 
> 
> 
> 
> 2# 
> DHCP-PD only can be configured by a figure not IPv6 . Term of , when 
> example 2002:: input :: would make the app grey uncontinued. 
> 
> && 
> The Router Avertisement Messages carry the GUNPs 
>     that are further used by the stateless autoconfiguration mechanism 
>     (SLAAC) 
> 
> 
> 
> 
> 3# 
> Global Unique Address (GUA) - is an address that is globally 
>     available and globally unique. 
> 
> Diagram : 
> ISP---Switch (4 mac found : isp x2 , modem x1 , IANA x1)---- Router 
> (WAN1,2, LAN 3 mac )---- PCs (wire, wireless , vpn mac) 
> 
>             - GUA is DHCPv6DUID eth.mac ? 
>             - which GUA to be mentioned at the draft ? 
>             - Dhcpv6DUID using sub-prefix the same as the IPv4 exactly 
> working eth.mac , by ipconfig /all detected when the vista replaced its 
> motherboard and having both new and initial eth.mac shown both? 
>             - "After the DHCPv6 packet leaves the cellular interface of 
> the IoT 
>     Requesting Router via wireless OFDMA link, it reaches the element of 
>     the access network which connects to the user equipment (UEs) - 
>     eNodeB station."    likes there must be some wireless "USB.sgw.isp" 
> host or ,  Dhcpv6 must be on Cellular host ? When one of 4 mac switch 
> showing Nokia , which sometimes modem connecting arp -a shown as well? 
> That would cause the pretty much lost functions of wire.router.map 
> always via as if owning speed lower much than the wireless does have . 
> 
> 
> 
> 
> 4# 
> your freely downloadable kernal patch for Windows BIOS works ? 
> 
> 
> 
> 
> 5# 
> "The Hop Limit of packets that contain the DHCPv6 data MUST be 255 to 
>     satisfy the properties of the cellular infrastructure.  To reach the 
>     PGW from the UE the DHCPv6 packets are encapsulated by SGW into UDP/ 
>     IPv4 packets; this encapsulation is for the GTP-U tunnel.  The 
>     corresponding decapsulation mechanism decreases the Hop Limit; when 
>     the Hop Limit reaches value 0 the packet is discarded; to avoid this 
>     situation it is required to put the Hop Limit value of the DHCPv6 
>     Solicit equal to 255." 
> 
>                   - hop in switch default 64 decreased to 48 then the 
> SGW would not work--> no dhcpv6 completed ---> no ipv6 get to switch 
> then Rv after it ? 
> 
> 
> 
> 
> 
> 6# 
> "It is possible to use IPv6-over-PPP protocol [RFC1661], with LCP, 
>     between the ARM and the modem." 
> 
>                    "ARM has added a wealth of wireless technologies to 
> its arsenal, but has no immediate plans to design a modem for mobile or 
> Internet of Things devices. 
> The company offers CPU and GPU designs that are widely used in 
> smartphones and tablets. A missing piece is a cellular modem that ARM 
> customers could license and put in mobile devices." 
> 
> 
>                - My modem is Fibre Huawai wire model, Rv, Sg all 
> wirecable devices. 
> 
> 
> 7# 
> Could not have been able to select one who would help Modify Dhcpv6DUID 
> completed , sent email to mailto:postmaster@microsoft.com 
> <mailto:mailto:postmaster@microsoft.com> none replying . 
> 
> 
> 
> 
> 
> Sincerely 
> mailto:bleuoisou@gmail.com <mailto:mailto:bleuoisou@gmail.com> 
> 
> On Tue, Sep 24, 2019 at 1:27 AM Alexandre Petrescu 
> <mailto:alexandre.petrescu@gmail.com <mailto:mailto:alexandre.petrescu@gmail.com>> wrote: 
> 
>     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 : 
>      > 08:http://47.hk <http://47.hk> <http://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 
>      > <mailto:alexandre.petrescu@gmail.com 
>     <mailto:mailto:alexandre.petrescu@gmail.com> 
>     <mailto:mailto:alexandre.petrescu@gmail.com 
>     <mailto:mailto:alexandre.petrescu@gmail.com>>> wrote: 
>      > 
>      >     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 
> mailto:postmaster@microsoft.com <mailto:mailto:postmaster@microsoft.com> 
>      >     <mailto:mailto:postmaster@microsoft.com 
>     <mailto:mailto:postmaster@microsoft.com>> 
>      >     hoping they will direct the message to people in charge? 
>      > 
>      >     Alex 
>      > 
>      >     Le 18/09/2019 à 09:45, Alexandre Petrescu a écrit : 
>      >      > 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:http://39.hk <http://39.hk> <http://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 ... 
>      >      >> 
>      >      >> 
>      >      >> 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? 
>      >      >> 
>      >      >> 
>      >      >> Microsoft is one putting on tracking, it must be forwarded to 
>      >     them about. 
>      >      >> 
>      >      >> 
>      >      >> Let have your kind advises on it please . 
>      >      >> 
>      >      >> 
>      >      >> 
>      >      >> Sincerely yours 
>      >      >> Li HUANG 
>      >      >> 
>      >      >> On Tue, Sep 17, 2019, 10:48 Li HUANG <mailto:bleuoisou@gmail.com 
>     <mailto:mailto:bleuoisou@gmail.com> 
>      >     <mailto:mailto:bleuoisou@gmail.com <mailto:mailto:bleuoisou@gmail.com>> 
>      >      >> <mailto:mailto:bleuoisou@gmail.com <mailto:mailto:bleuoisou@gmail.com> 
>     <mailto:mailto:bleuoisou@gmail.com <mailto:mailto:bleuoisou@gmail.com>>>> wrote: 
>      >      >> 
>      >      >>     09:http://39.hk <http://39.hk> <http://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 ... 
>      >      >> 
>      >      >> 
>      >      >>     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? 
>      >      >> 
>      >      >> 
>      >      >>     Microsoft is one putting on tracking, it must be 
>     forwarded 
>      >     to them 
>      >      >>     about. 
>      >      >> 
>      >      >> 
>      >      >>     Let have your kind advises on it please . 
>      >      >> 
>      >      >> 
>      >      >> 
>      >      >>     Sincerely yours 
>      >      >>     Li HUANG 
>      >      >> 
>      >      >> 
>      >      >>     On Tue, Sep 17, 2019, 00:18 Alexandre Petrescu 
>      >      >>     <mailto:alexandre.petrescu@gmail.com 
>     <mailto:mailto:alexandre.petrescu@gmail.com> 
>      >     <mailto:mailto:alexandre.petrescu@gmail.com 
>     <mailto:mailto:alexandre.petrescu@gmail.com>> 
>      >     <mailto:mailto:alexandre.petrescu@gmail.com 
>     <mailto:mailto:alexandre.petrescu@gmail.com> 
>      >     <mailto:mailto:alexandre.petrescu@gmail.com 
>     <mailto:mailto:alexandre.petrescu@gmail.com>>>> 
>      >      >>     wrote: 
>      >      >> 
>      >      >>         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 
>      >     <mailto:alexandre.petrescu@gmail.com 
>     <mailto:mailto:alexandre.petrescu@gmail.com> 
>     <mailto:mailto:alexandre.petrescu@gmail.com 
>     <mailto:mailto:alexandre.petrescu@gmail.com>>> 
>      >      >>         <mailto:mailto:alexandre.petrescu@gmail.com 
>     <mailto:mailto:alexandre.petrescu@gmail.com> 
>      >     <mailto:mailto:alexandre.petrescu@gmail.com 
>     <mailto:mailto:alexandre.petrescu@gmail.com>>> 
>      >      >>         Pour : mailto:v6ops@ietf.org <mailto:mailto:v6ops@ietf.org> 
>     <mailto:mailto:v6ops@ietf.org <mailto:mailto:v6ops@ietf.org>> 
>      >     <mailto:mailto:v6ops@ietf.org <mailto:mailto:v6ops@ietf.org> 
>     <mailto:mailto:v6ops@ietf.org <mailto:mailto:v6ops@ietf.org>>> 
>      >      >> <mailto:v6ops@ietf.org <mailto:mailto:v6ops@ietf.org> 
>     <mailto:mailto:v6ops@ietf.org <mailto:mailto:v6ops@ietf.org>>> 
>      >      >>         <mailto:mailto:v6ops@ietf.org <mailto:mailto:v6ops@ietf.org> 
>     <mailto:mailto:v6ops@ietf.org <mailto:mailto:v6ops@ietf.org>>> 
>      >      >> 
>      >      >> 
>      >      >> 
>      >      >>         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. 
>      >      >> 
>      >      >>         _______________________________________________ 
>      >      >>         dhcwg mailing list 
>      >      >> mailto:dhcwg@ietf.org <mailto:mailto:dhcwg@ietf.org> 
>     <mailto:mailto:dhcwg@ietf.org <mailto:mailto:dhcwg@ietf.org>> 
>     <mailto:mailto:dhcwg@ietf.org <mailto:mailto:dhcwg@ietf.org> 
>      >     <mailto:mailto:dhcwg@ietf.org <mailto:mailto:dhcwg@ietf.org>>> 
>      >      >> https://www.ietf.org/mailman/listinfo/dhcwg 
>      >      >> 
>      >      > 
>      >      > _______________________________________________ 
>      >      > dhcwg mailing list 
>      >      > mailto:dhcwg@ietf.org <mailto:mailto:dhcwg@ietf.org> 
>     <mailto:mailto:dhcwg@ietf.org <mailto:mailto:dhcwg@ietf.org>> 
>      >      > https://www.ietf.org/mailman/listinfo/dhcwg 
>      > 
>      >     _______________________________________________ 
>      >     dhcwg mailing list 
>      > mailto:dhcwg@ietf.org <mailto:mailto:dhcwg@ietf.org> <mailto:mailto:dhcwg@ietf.org 
>     <mailto:mailto:dhcwg@ietf.org>> 
>      > https://www.ietf.org/mailman/listinfo/dhcwg 
>      > 
>