Re: [v6ops] Implementation Status of PREF64

[David Farmer <[e-mail]>]

On Wed, Sep 29, 2021 at 5:16 PM Mark Smith <[e-mail]> wrote:

>
> On Thu, 30 Sep 2021, 03:41 Nick Hilliard, <[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]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================