Re: [v6ops] Implementation Status of PREF64

[Kevin Myers <[e-mail]>]

You’re not alone Nick.  I’ve been reading this over the last week and thinking the same thing – this is absolutely an impediment to IPv6 adoption. As an advocate for IPv6 that implements it every day in ASNs for operators (both SP and Enterprise), the disregard for operator choice is disheartening and frustrating.

Many of the slack groups I’m in have been reading this thread and echoing the same comments. None of the publicly traded companies I consult for want anything to do with SLAAC in enterprise environments and have said they’ll keep running IPv4 until DHCPv6 is more universally available on all mobile platforms. The peers I collaborate with that also consult for the Fortune 500 crowd have said the same thing.

Lack of choice for operators does nothing to improve IPv6 adoption. The assumption that operators are making inferior technical choices is just plain wrong.  Many of the world’s largest companies are bound by regulatory environments that spent 20+ years in a DHCP world and won’t shift quickly – if ever. Technical merit will yield to organizational requirements every day of the week.

It's not just mainstream enterprise, the lack of operator choice affects other sectors we build networks in like energy, manufacturing, education and government – all with their own regulatory issues.

If the goal of dying on the hill of technical superiority was to ensure we prevent anyone other than webscale companies or cloud operators to easily deploy IPv6 in the next 10 years, I think we got there.

The last 10 years have shown that holding out for IPv4 exhaustion to force IPv6 and rigid implementation guidelines without flexibility for operators is a failed strategy and it needs to get easier or we’ll have this debate in another 10 years.

From: v6ops <[e-mail]> On Behalf Of Nick Buraglio
Sent: Thursday, September 30, 2021 9:38 AM
To: Gert Doering <[e-mail]>
Cc: V6 Ops List <[e-mail]>; JORDI PALET MARTINEZ <jordi.palet=[e-mail]>
Subject: Re: [v6ops] Implementation Status of PREF64



On Tue, Sep 28, 2021 at 1:40 PM Gert Doering <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

On Tue, Sep 28, 2021 at 06:24:57PM +0200, JORDI PALET MARTINEZ wrote:
> I don???t think I can agree with your comments about recommending not deploying in enterprise (and thus government) networks.
>
> In fact, I think it is key for advancing the IPv6 deployment that governments require it in any administration network including any acquisitions (hardware, software, services, links, etc.). That encourages the ecosystem to move on to IPv6, including enterprises that want to participate in government tenders.

As a matter of fact, I know of at least one deployment in a "fortune 500"
company that was seriously impaired due to lack of DHCPv6 support in
Android.  They want control over address assignment, tracking of address
assignments, and DHCP is the machinery they use for it (plus NAC, making
sure that only assigned IPv6 addresses can be used).


With an operational hat on, I have been watching this dilema play out for quite some time, hoping for some level of agreement or compromise. I know I am not alone in the thinking that this is a significant impediment to IPv6 deployment, which is already a hard sell for many more conservitive organizations. I agree with Gert, there are plenty of easy "no" answers for "should I deploy IPv6", but this one is often cited as a technical limitation for a reasonable number of required devices - especially since more and more IoT-style devices are being built using Android.

From the point of view of an operational or. planning engineer, this kind of disagreement doesn’t matter much because of lack of support for things that are expected - regardless of the *actual* usefulness or technical correctness, it serves as an easy door to close which in turn results in a significant impediment to deployment.

I have literally heard - in the last 30 days - the argument that v6 cannot be deployed because it lacks DHCP client support for certain devices, the largest contingency of which are Android,

which makes it inconsistent with how this facility does their host address management.

It does not matter how the mechanics work, but they need to be consistent at some level (and in the cases I have seen that comes down to using a centralized management platform to dole out addressing. Tracking is a "nice to have", but having a dual stack network that uses different allocation mechanisms creates a prickly experience for those that need to sell the option of using IPv6.



An absolutely *critical* piece of IPv6 deployment is management buy-in, and telling non-technical management level folks that “we manage this one way and that another way” is akin to saying “this is operationally more expensive, which is a cost center, not a cost saver”, and as pointed out in another part of this thread, a business case is *really* useful in proposing IPv6 deployment.

I am not advocating for anything, but consistency lends itself to lower overhead and that will get IPv6 in more places than “it works the same on everything except this”, which clearly hasn’t been working for quite some time.



nb

But they want to support Android devices.

So, still no IPv6 today...

Gert Doering
        -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: [phone]         USt-IdNr.: DE813185279

_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops
ᐧ