Re: [v6ops] Implementation of DANIR for IoT Router - DHCPv6-PD and ND
Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 30 October 2019 13:13 UTC
Return-Path: <alexandre.petrescu@gmail.com>
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 0E1C3120A1A for <v6ops@ietfa.amsl.com>; Wed, 30 Oct 2019 06:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.631
X-Spam-Level:
X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 wZPh0v7_aGxn for <v6ops@ietfa.amsl.com>; Wed, 30 Oct 2019 06:13:29 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB0712006F for <v6ops@ietf.org>; Wed, 30 Oct 2019 06:13:28 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x9UDDQpx015760 for <v6ops@ietf.org>; Wed, 30 Oct 2019 14:13:26 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C08E0206421 for <v6ops@ietf.org>; Wed, 30 Oct 2019 14:13:26 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B5BE62063EA for <v6ops@ietf.org>; Wed, 30 Oct 2019 14:13:26 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x9UDDQ3C001336 for <v6ops@ietf.org>; Wed, 30 Oct 2019 14:13:26 +0100
To: v6ops@ietf.org
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> <16e19602f4a.11692076f325242.5254263295023703726@shytyi.net> <CAGGiuEYJqZsb_BjKK_LV2iCcvs7yOpWDS=V_j5arwAH_MVGZRw@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <0e4cc304-6139-3918-b66e-4c02630dec51@gmail.com>
Date: Wed, 30 Oct 2019 14:13:26 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0
MIME-Version: 1.0
In-Reply-To: <CAGGiuEYJqZsb_BjKK_LV2iCcvs7yOpWDS=V_j5arwAH_MVGZRw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/2cSgHNOdbT82sql3ketNydLM_KE>
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: Wed, 30 Oct 2019 13:13:38 -0000
Do you mean you want to see a demo of linux VM with DANIR hosted on Windows, during the v6ops WG meeting relayed on a telco, that you will see as a remote (paying) participant? (draft-shytyi-v6ops-danir-04) Alex Le 30/10/2019 à 14:02, Li HUANG a écrit : > 20:59.hk <http://59.hk> S8 Oct. 30 2019 > > > Dear Dmytro, > > All using clients are windows, would it be mounted in linux to modify > this at webex remote from your computer at a payable way? > > > Sincerely yours > Li HUANG > > On Wed, Oct 30, 2019, 05:16 Dmytro Shytyi <ietf.dmytro@shytyi.net > <mailto:ietf.dmytro@shytyi.net>> wrote: > > __ > 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 <mailto:bleuoisou@gmail.com>>* wrote ---- > > Oct. 19 2019 21:00.hk <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 > BleuOisou@gmail.com <mailto:BleuOisou@gmail.com> > Li HUANG > > > On Fri, Oct 18, 2019, 20:30 Dmytro Shytyi > <dmytro@shytyi.net <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 <alexandre.petrescu@gmail.com > <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:12..hk <http://12.hk> > <http://12.hk> w10p m800 Sg|Rv > > Attn: > > > > Authors' Addresses > > > > Dmytro Shytyi > > SFR > > Paris area , Ile-de-France > > France > > > > Email:ietf.dmytro@shytyi.net > <mailto:ietf.dmytro@shytyi.net> > <mailto:ietf.dmytro@shytyi.net > <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:Alexandre.Petrescu@cea.fr > <mailto:Alexandre.Petrescu@cea.fr> > <mailto:Alexandre.Petrescu@cea.fr > <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 > postmaster@microsoft.com > <mailto:postmaster@microsoft.com> > > <mailto:postmaster@microsoft.com > <mailto:postmaster@microsoft.com>> none replying . > > > > > > > > > > > > Sincerely > > bleuoisou@gmail.com > <mailto:bleuoisou@gmail.com> > <mailto:bleuoisou@gmail.com > <mailto:bleuoisou@gmail.com>> > > > > On Tue, Sep 24, 2019 at 1:27 AM Alexandre > Petrescu > > <alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com> > <mailto:alexandre.petrescu@gmail.com > <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:47.hk <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 > > > <alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com> > > <mailto:alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com>> > > <mailto:alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com> > > <mailto:alexandre..petrescu@gmail.com > <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 > > postmaster@microsoft.com > <mailto:postmaster@microsoft.com> > <mailto:postmaster@microsoft.com > <mailto:postmaster@microsoft.com>> > > > <mailto:postmaster@microsoft.com > <mailto:postmaster@microsoft.com> > > <mailto:postmaster@microsoft.com > <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:39.hk <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 <bleuoisou@gmail.com > <mailto:bleuoisou@gmail.com> > > <mailto:bleuoisou@gmail.com > <mailto:bleuoisou@gmail.com>> > > > <mailto:bleuoisou@gmail.com > <mailto:bleuoisou@gmail.com> > <mailto:bleuoisou@gmail.com > <mailto:bleuoisou@gmail.com>>> > > > >> <mailto:bleuoisou@gmail.com > <mailto:bleuoisou@gmail.com> > <mailto:bleuoisou@gmail.com > <mailto:bleuoisou@gmail.com>> > > <mailto:bleuoisou@gmail.com > <mailto:bleuoisou@gmail.com> > <mailto:bleuoisou@gmail.com > <mailto:bleuoisou@gmail.com>>>>> wrote: > > > >> > > > >> 09:39.hk <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 > > > >> <alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com> > > <mailto:alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com>> > > > <mailto:alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com> > > <mailto:alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com>>> > > > <mailto:alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com> > > <mailto:alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com>> > > > <mailto:alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com> > > <mailto:alexandre.petrescu@gmail.com > <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 > > > <alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com> > > <mailto:alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com>> > > <mailto:alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com> > > <mailto:alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com>>>> > > > >> > <mailto:alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com> > > <mailto:alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com>> > > > <mailto:alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com> > > <mailto:alexandre.petrescu@gmail.com > <mailto:alexandre.petrescu@gmail.com>>>> > > > >> Pour : v6ops@ietf.org > <mailto:v6ops@ietf.org> <mailto:v6ops@ietf.org > <mailto:v6ops@ietf.org>> > > <mailto:v6ops@ietf.org > <mailto:v6ops@ietf.org> <mailto:v6ops@ietf.org > <mailto:v6ops@ietf.org>>> > > > <mailto:v6ops@ietf.org > <mailto:v6ops@ietf.org> <mailto:v6ops@ietf.org > <mailto:v6ops@ietf.org>> > > <mailto:v6ops@ietf.org > <mailto:v6ops@ietf.org> <mailto:v6ops@ietf.org > <mailto:v6ops@ietf.org>>>> > > > >> <v6ops@ietf.org > <mailto:v6ops@ietf.org> <mailto:v6ops@ietf.org > <mailto:v6ops@ietf.org>> > > <mailto:v6ops@ietf.org > <mailto:v6ops@ietf.org> <mailto:v6ops@ietf.org > <mailto:v6ops@ietf.org>>>> > > > >> <mailto:v6ops@ietf.org > <mailto:v6ops@ietf.org> <mailto:v6ops@ietf.org > <mailto:v6ops@ietf.org>> > > <mailto:v6ops@ietf.org > <mailto:v6ops@ietf.org> <mailto:v6ops@ietf.org > <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 > > > >> dhcwg@ietf.org > <mailto:dhcwg@ietf.org> <mailto:dhcwg@ietf.org > <mailto:dhcwg@ietf.org>> > > <mailto:dhcwg@ietf.org > <mailto:dhcwg@ietf.org> <mailto:dhcwg@ietf.org > <mailto:dhcwg@ietf.org>>> > > <mailto:dhcwg@ietf.org > <mailto:dhcwg@ietf.org> <mailto:dhcwg@ietf.org > <mailto:dhcwg@ietf.org>> > > > <mailto:dhcwg@ietf.org > <mailto:dhcwg@ietf.org> <mailto:dhcwg@ietf.org > <mailto:dhcwg@ietf.org>>>> > > > >> > https://www.ietf.org/mailman/listinfo/dhcwg > > > >> > > > > > > > > > _______________________________________________ > > > > dhcwg mailing list > > > > dhcwg@ietf.org > <mailto:dhcwg@ietf.org> <mailto:dhcwg@ietf.org > <mailto:dhcwg@ietf.org>> > > <mailto:dhcwg@ietf.org > <mailto:dhcwg@ietf.org> <mailto:dhcwg@ietf.org > <mailto:dhcwg@ietf.org>>> > > > > > https://www.ietf.org/mailman/listinfo/dhcwg > > > > > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org <mailto:dhcwg@ietf.org> > <mailto:dhcwg@ietf.org <mailto:dhcwg@ietf.org>> > <mailto:dhcwg@ietf.org <mailto:dhcwg@ietf.org> > > <mailto:dhcwg@ietf.org <mailto:dhcwg@ietf.org>>> > > > https://www.ietf.org/mailman/listinfo/dhcwg > > > > > > > > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >
- [v6ops] Kernel implementation of DANIR for IoT Ro… Alexandre Petrescu
- Re: [v6ops] Kernel implementation of DANIR for Io… Alexandre Petrescu
- Re: [v6ops] open source kernel implementation of … Alexandre Petrescu
- Re: [v6ops] Implementation of DANIR for IoT Route… Dmytro Shytyi
- Re: [v6ops] Implementation of DANIR for IoT Route… Li HUANG
- Re: [v6ops] Implementation of DANIR for IoT Route… Alexandre Petrescu