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

[Li HUANG <[e-mail]>]

20: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 <[e-mail]> 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 <[e-mail]
> <[e-mail]>>* wrote ----
>
> Oct. 19 2019  21: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
> [e-mail]
> Li HUANG
>
>
> On Fri, Oct 18, 2019, 20:30 Dmytro Shytyi <[e-mail]> 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
> <[e-mail] <[e-mail]>>* 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> w10p m800 Sg|Rv
> > Attn:
> >
> > Authors' Addresses
> >
> > Dmytro Shytyi
> > SFR
> > Paris area , Ile-de-France
> > France
> >
> > Email:[e-mail] <mailto:[e-mail]>
> > 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: [phone]
> > Email:[e-mail] <mailto:[e-mail]>
> >
> >
> > 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 [e-mail]
> > <mailto:[e-mail]> none replying .
> >
> >
> >
> >
> >
> > Sincerely
> > [e-mail] <mailto:[e-mail]>
> >
> > On Tue, Sep 24, 2019 at 1:27 AM Alexandre Petrescu
> > <[e-mail] <mailto:[e-mail]>>
> 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> 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
> > > <[e-mail]
> > <mailto:[e-mail]>
> > <mailto:[e-mail]
> > <mailto:[e-mail]>>> 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
> > [e-mail] <mailto:[e-mail]>
> > >     <mailto:[e-mail]
> > <mailto:[e-mail]>>
> > >     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/> 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 <[e-mail]
> > <mailto:[e-mail]>
> > >     <mailto:[e-mail] <mailto:[e-mail]>>
> > >      >> <mailto:[e-mail] <mailto:[e-mail]>
> > <mailto:[e-mail] <mailto:[e-mail]>>>> wrote:
> > >      >>
> > >      >>     09: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
> > >      >>     <[e-mail]
> > <mailto:[e-mail]>
> > >     <mailto:[e-mail]
> > <mailto:[e-mail]>>
> > >     <mailto:[e-mail]
> > <mailto:[e-mail]>
> > >     <mailto:[e-mail]
> > <mailto:[e-mail]>>>>
> > >      >>     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
> > >     <[e-mail]
> > <mailto:[e-mail]>
> > <mailto:[e-mail]
> > <mailto:[e-mail]>>>
> > >      >>         <mailto:[e-mail]
> > <mailto:[e-mail]>
> > >     <mailto:[e-mail]
> > <mailto:[e-mail]>>>
> > >      >>         Pour : [e-mail] <mailto:[e-mail]>
> > <mailto:[e-mail] <mailto:[e-mail]>>
> > >     <mailto:[e-mail] <mailto:[e-mail]>
> > <mailto:[e-mail] <mailto:[e-mail]>>>
> > >      >> <[e-mail] <mailto:[e-mail]>
> > <mailto:[e-mail] <mailto:[e-mail]>>>
> > >      >>         <mailto:[e-mail] <mailto:[e-mail]>
> > <mailto:[e-mail] <mailto:[e-mail]>>>
> > >      >>
> > >      >>
> > >      >>
> > >      >>         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
> > >      >> [e-mail] <mailto:[e-mail]>
> > <mailto:[e-mail] <mailto:[e-mail]>>
> > <mailto:[e-mail] <mailto:[e-mail]>
> > >     <mailto:[e-mail] <mailto:[e-mail]>>>
> > >      >> https://www.ietf.org/mailman/listinfo/dhcwg
> > >      >>
> > >      >
> > >      > _______________________________________________
> > >      > dhcwg mailing list
> > >      > [e-mail] <mailto:[e-mail]>
> > <mailto:[e-mail] <mailto:[e-mail]>>
> > >      > https://www.ietf.org/mailman/listinfo/dhcwg
> > >
> > >     _______________________________________________
> > >     dhcwg mailing list
> > > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> > <mailto:[e-mail]>>
> > > https://www.ietf.org/mailman/listinfo/dhcwg
> > >
> >
>
>
>
>
>
>
>
>