Re: [v6ops] Implementation Status of PREF64

[Alexandre Petrescu <[e-mail]>]

Le 30/09/2021 à 17:23, Vasilenko Eduard a écrit :
> Hi Lorenzo,
> 
> How fast is Android refreshment time? (for example, I am still using 
> 6.2 on one device)
> 
> I mean: how much time would be needed to start adoption between your 
> decision to support DHCPv6 and old devices would be naturally 
> refreshed?

I think this question is rhetorical.

I once worked in a project during 3 days, in which we compiled and made
several DHCPv6 packages ready for submission to Store of Android apps.
But we needed 5 euros - or so - to be alowed to.  We decided to stop
short on spending that small amount of money; there are several reasons
for stopping that, not the least being that it would not be working on
3G links (our main goal) but only on WiFi; also, it would upset
Administrators of Store; last but not least it would cross our ethical
limits about how to spend money.

I think fundamentally people at owner of Android met a few technical
problems when trying to build DHCPv6 packages too; when they realized it
was not within their reach to solve them - it was within Qualcomm or
similar, reach - then they started to develop a non-DHCP religtion.  I
know other people at some operator who have a hard time negotiating with
phone manufacturer who depends on modem manufacturer; these are indeed
hard negotiations where the technical aspects are often distorted.

I think the fundamental problem lies at modem manufacturer nowadays.

The interesting thing to note is about IPR and patents.  IPv6 is known
to be relatively free of patents, whereas DHCP is not.  There is
something old about IPR and RAND conditions on DHCP(v4!) at Cisco.
There is also something old about Qualcomm and 2G (pre-GPRS) patents.
It might be that Qualcomm decided to avoid being called names because of
these DHCP IPR claims, and so decided to do IPv6 free of patents, i.e.
without DHCP.  It is laudable.

It is a personal interpretation of history.

If that is so, then one can not tell bad things about SLAAC, Qualcomm
and DHCP religion.  It is all good that way that it is, but still there
is something missing.

Alex
PS: in an interest of a full disclosure, and still be open, still be 
correct, to be fully complete, I must say also that one member of our 
discussions here recently pointed my to a hack of a modem made by 
unofficial activities but at a public URL 
https://4pda.to/forum/index.php?showtopic=678549&st=17700#entry90297458 
which seems to address the problem of a particular 3GPP modem brand 
blocking DHCPv6 in a hacking way (hacking==testing, maybe a bit 
underground, maybe a bit unreliable, whose high-level interest is 
unknown).  I will not try it myself because of these 'hacking' aspects, 
but there it is to be.


> 
> How long delay in Enterprise IPv6 adoption is already 
> pre-programmed?
> 
> Eduard
> 
> *From:*Vasilenko Eduard *Sent:* Thursday, September 30, 2021 1:06 PM
>  *To:* 'Lorenzo Colitti' <[e-mail]> *Cc:* David Farmer 
> <farmer=[e-mail]>; Mark Smith 
> <[e-mail]>; v6ops list <[e-mail]> *Subject:* RE: 
> [v6ops] Implementation Status of PREF64
> 
> Hi Lorenzo,
> 
> Sorry, but this URL has no reference to the product or OpenSource 
> that is capable to collect ND logs from the wide range of routers 
> (multi-vendor!), correlate them, and present them for forensic, 
> billing, or troubleshooting purposes.
> 
> No one vendor or developer of OpenSource spends resources behind
> your idea.
> 
> What you propose is just not possible to implement in production 
> now.
> 
> Why these people do not believe you?
> 
> You would not go anywhere with your idea if you would not persuade 
> them (especially Infoblox as the leader).
> 
> The first question that they would have to you may be: show me the 
> YANG model to provision boxes and show me the data model for 
> statistics that they would generate?
> 
> Ups, it is proprietary for all vendors…
> 
> IMHO: no chance that your idea would fly if it would not have any
> DDI product that supports it.
> 
> Eduard
> 
> *From:*Lorenzo Colitti [mailto:[e-mail] 
> <mailto:[e-mail]>] *Sent:* Thursday, September 30, 2021 
> 10:17 AM *To:* Vasilenko Eduard <[e-mail] 
> <mailto:[e-mail]>> *Cc:* David Farmer 
> <farmer=[e-mail] 
> <mailto:farmer=[e-mail]>>; Mark Smith 
> <[e-mail] <mailto:[e-mail]>>; v6ops list 
> <[e-mail] <mailto:[e-mail]>> *Subject:* Re: [v6ops] 
> Implementation Status of PREF64
> 
> There are already vendor solutions.
> 
> https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/
>
>  
> <https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/>
>
>
> 
On Thu, Sep 30, 2021 at 4:12 PM Vasilenko Eduard
> <[e-mail] <mailto:[e-mail]>> 
> wrote:
> 
> +1.
> 
> “Show me another solution” is a good message. Just idea or theory is
>  not enough.
> 
> David has mentioned OpenSource. I would say that vendor product is 
> needed too.
> 
> Ed/
> 
> *From:*v6ops [mailto:[e-mail] 
> <mailto:[e-mail]>] *On Behalf Of *David Farmer *Sent:* 
> Thursday, September 30, 2021 5:15 AM *To:* Mark Smith 
> <[e-mail] <mailto:[e-mail]>>; Lorenzo 
> Colitti <[e-mail] <mailto:[e-mail]>> *Cc:* v6ops 
> list <[e-mail] <mailto:[e-mail]>> *Subject:* Re: [v6ops] 
> Implementation Status of PREF64
> 
> On Wed, Sep 29, 2021 at 5:16 PM Mark Smith <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
> On Thu, 30 Sep 2021, 03:41 Nick Hilliard, <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
> Even if you had, that would be fine and you're welcome to your 
> opinions. Other people disagree because it doesn't make sense on 
> their deployments.
> 
> If they want to hobble IPv6, such that it is nothing more than a
> copy of IPv4 with bigger addresses, what is the point of going to
> the expense and effort of deploying IPv6 when most enterprises have 
> plenty of IPv4 address space via RFC1918 and 100.64/10 if they were 
> willing to abuse it a bit?
> 
> A hobbled deployment of IPv6, hobbled such that it doesn't provide 
> any useful benefit over IPv4, is just pure business expense. 
> Increased profit is an exceptionally strong disincentive to
> incurring those.
> 
> So, instead of just telling people they are doing IPv6 wrong 
> (building a hobbled network) and that DHCP doesn't provide them what 
> they think it does; How about making sure there are good open-source 
> tools to build what you think is a non-hobbled network that meets 
> their needs? In other words, how about providing some good 
> open-source ARP and ND router scraping tools?
> 
> Now you could point the finger back at me too, but then I'm not 
> saying that building networks with DHCPv6 is building a hobbled 
> network, nor am I refusing to provide a DHCPv6 client for a very 
> popular mobile and IoT platform. So, at least in my opinion, that 
> puts more onus on you than me.
> 
> So, I agree that DHCP logging (both IPv4 and IPv6) by itself isn't 
> enough, and yes you also need to scrape ARP and ND out of the 
> routers. However, ARP and ND scrapping by themselves aren't enough 
> either, DHCP logging provides much better granularity than is 
> practical from ARP and ND scrapping, at least using SNMP. Also, by 
> having both you can make some assumptions about suspicious access 
> clients that are statically configuring addresses instead of doing 
> DHCP on the access network as they should be.
> 
> I agree that limiting DHCPv6 clients to only IA-NA  and not
> providing IA-TA is a bad implementation of DHCPv6. Further, I
> recommend SLAAC, and we provide SLAAC, for general-purpose (AKA
> public) access networks with IPv6. But, we also have many networks
> where that is not appropriate, where I have regulatory and
> contractual compliance requirements, to protect non-public
> information, things like FERPA, HIPPA, PCI, and CMMC(1-4). Long-term
> we want these networks doing IPv6 too.
> 
> Android smartphones, probably belong on a general-purpose access 
> network with SLAAC for IPv6 in most cases. However, Android is also 
> on many IoT devices, things like point-of-sale terminals, credit
> card terminals, environmental monitoring sensors, etc... Many of
> those things I don't want on general-purpose access networks and some
> of those will have compliance requirements we have to meet. We think 
> DHCPv6 is perfectly appropriate for these networks, and probably for 
> server networks too.
> 
> In conclusion, while I agree with most of your arguments that DHCPv6
>  isn't necessarily the right way to do IPv6, especially for 
> general-purpose (public) access networks, that doesn’t mean I think 
> DHCPv6 doesn’t have a place in many other networks, and it would be 
> very helpful if Android provided a DHCPv6 client, even as a 
> non-default option.
> 
> Thanks
> 
> --
> 
> =============================================== David Farmer 
> Email:[e-mail] <mailto:[e-mail]> Networking & 
> Telecommunication Services Office of Information Technology 
> University of Minnesota 2218 University Ave SE        Phone: 
> 612-626-0815 Minneapolis, MN 55414-3029   Cell: 612-812-9952 
> ===============================================
> 
> 
> _______________________________________________ v6ops mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>