Subject: [v6ops] Enterprise policies: :WAS Implementation Status of PREF64

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Sep 2021 17:22:27 +0000

Hello Owen

We cannot stay too vague here. Maybe there are things where we can progress. Can we elaborate on which policies you have in mind?

There are a number of policies that can still be enforced even with AAC, like the number of addresses per device. Some of us hate that it happens, but in some environments there’s an infrastructure cost to each address (like an auth flow, a TCAM entry, whatever) so there are cases where it is bounded by policy, want it or not, and already today. Say that number is 1, and say that ND pushes that information to the DHCP server to feed the existing tools, does that solve your use case? Or is it like the policy interested in defining a specific (semantic) IID for each node?

Notes:

I’m not calling people names, they are my customers. I’m trying (very hard) to make their life simpler, and I’m not trying to influence their policies. It is their job to decide what the best tool is for their case.  I see a hammer and a plier in the 25-years old  toolbox, and I can see many shapes of screws invented since for modern networks. You can manage something with both tools but that’s far from ideal, and not an incentive to go v6.

I’m not saying that I’m happy with the lack of DHCPv6 in Android. I think DHCP was the natural starting point in the evolution towards IPv6 in enterprise and I buy the argument that it is probably an impediment to the adoption of IPv6 in that space. I just think that ultimately it should phase out and be replaced by Ole’s universal RA and Stateful ND. Because that can bring more control and visibility –  screwdrivers in the tool box.

Note that it’s not DHCP or stateful ND. The node must register an address that was obtained from DHCP in stateful ND, like it must do DAD for it today. Just that you do not waste one second in the process, and do not broadcast over the whole enterprise Wi-Fi domain. The cool thing is  that the host can also unregister it when it ceases to use the address and free network resources.

Stateful AAC provides full visibility and protection, a lot more than what we have today, even with DHCP. E.g.,  DHCP can only be snooped by the on path switches, the other just learn indirect information from ND multicast. There is little to no control over the DHCP state and possibly a lot of stale state, think about the impact to MAC rotation for instance. There is no notion of having more than one address with different roles, privacy requirements, and life cycles. DHCP does not help distinguish mobility vs. duplication / attack. It does not pub/sub the binding to external services like proxy, routing, or LISP.

Think about the things we can do with stateful ND AAC:

- provide full visibility to the network administrator
- secure the address ownership with RFC 8928
- rotate MAC and IP for privacy with no stale state and/or silent node
- synchronize a state in the L3switch/AP/router for ND proxy (RFC 8929) and routing (RFC 9010, RIFT<https://datatracker.ietf.org/doc/html/draft-ietf-rift-rift>, eVPN<https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling>)

Keep safe;

Pascal

From: Owen DeLong <owen=[email-masked]>
Sent: jeudi 30 septembre 2021 17:59
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Lorenzo Colitti <[email-masked]>; v6ops list <[email-masked]>
Subject: Re: [v6ops] Implementation Status of PREF64

On Sep 30, 2021, at 03:14 , Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>> wrote:

I have the same perception of that thread and the IPv6 woes one on NANOG as you do. For one thing we cannot extract DHCPv6 brutally as a rotten tooth.
We need to understand what it’s used for and provide a better replacement that will slowly take over. SLAAC cannot be that. The problem of SLAAC is not the AAC piece, it’s the SL. SL lacks observability, and that’s what prevent it from being a replacement to the database that the operators and network managers need, e.g., for forensics.

It’s both, actually. The AAC side interferes with certain aspects of policy enforcement that are important in some environments.

I think there’s a golden path where DHCP is pushed deeper in the infra so that at first it is no more visible to the end device but still available to the operations that require it, and then we move on to the point where it becomes fully redundant and ceases to exist, by the user’s own decision, on his own agenda.

This is the problem, right here… There are networks where the administrators do NOT WANT this to be up to the user. They want control over certain policy aspects on their network. You are free to call them whatever names you want, but their networks are part of the target audience for IPv6 and they aren’t going to deploy it unless they have at least equivalent policy enforcement tools to what they have in IPv4 and they’re going to have to be implemented in a way that provides at least some familiarity or clear roadmap of the transition.

Today, that’s IA_NA combined with other enforcement mechanisms such as NAC providing dynamic switch port ACLs. Yes, 802.1x is an L2 protocol, but contrary to earlier statements, the NAC server can pull data from multiple sources and push an ACL onto the switch port that will limit the client(s) attached to that port to the addresses and capabilities permitted by the NAC policy configured (including limiting the L3 addresses that can be forwarded to the one(s) assigned by the DHCPv6 server, if desired).

If you’ve got a better idea for enterprise-level policy enforcement than IA_NA and IA_PD (where permitted), by all means, present it.

If not, then yeah, support for IA_NA is essential to forward progress in the enterprise.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Sep 2021 11:01:06 -0700

> On Sep 30, 2021, at 10:22 , Pascal Thubert (pthubert) <pthubert=[email-masked]> wrote:
> 
> Hello Owen
>  

I’m not the enterprises that have the policies, and you’re not going to like some of them, but examples of things clients have told me:

1.	There shall be no address assignment on the LAN except by our DHCP server.
2.	The switch shall not pass any packet into the network with a source address that does not correspond to the DHCP address(es)
	issued to the host on that port and correlated with its authenticated MAC address in the 802.1x authentication process.
3.	Any host on the network must only use addresses which we can correlate with a particular user through the DHCP and 802.1x logs.
4.	Hosts cannot just choose addresses, they must be assigned by the DHCP server.

etc.
 
> There are a number of policies that can still be enforced even with AAC, like the number of addresses per device. Some of us hate that it happens, but in some environments there’s an infrastructure…

Most of the clients I’ve encountered that are truly resistant fall more towards the latter. However, there have been some cases where the former might be a workable solution if hosts could be reliably prevented from using addresses not associated with the authenticated {user, host} that made it through the 802.1x process and any other NAC in question.

> I’m not calling people names, they are my customers. I’m trying (very hard) to make their life simpler, and I’m not trying to influence their policies. It is their job to decide what the best tool…

The name calling comment was more oriented towards some of the other participants in this thread.
 
> I’m not saying that I’m happy with the lack of DHCPv6 in Android. I think DHCP was the natural starting point in the evolution towards IPv6 in enterprise and I buy the argument that it is probably…

I’m not 100% convinced of this, but I”m open to being won over. Part of it is that I am very resistant to complicating RA and SLAAC because there are devices that are resource and memory constrained that don’t need to fit into these policy-constrained networks and don’t need all the code to handle every option ever invented plus those that weren’t invented at the time the device was deployed. This constraint doesn’t apply to android, but squeezing v6 into an AT328P or even an ESP12F, for example, is hard enough as it is, without making RA gain all the complexities of DHCPv6.

The nice thing about having SLAAC and DHCPv6 available is that SLAAC (as is) is a really good option for most networks and most devices and it’s extremely lightweight and relatively easy to implement, while DHCPv6 through the M+O flags in RA can provide a more robust more managed configuration environment for more full-featured hosts that can support it readily.

The problem (which is almost uniquely android) here is that we have a vendor of full-featured hosts that doesn’t want to play nice i the sandbox and wants to act like a resource-constrained node that can’t do DHCPv6  _AND_ put these devices in general purpose networks with users on the devices facing full featured UIs without these additional configuration constraints, information, etc.
> Note that it’s not DHCP or stateful ND. The node must register an address that was obtained from DHCP in stateful ND, like it must do DAD for it today. Just that you do not waste one second in the…

As I said, I’m not opposed to this being an additional tool administrators can choose from, but I thin it is somewhat orthogonal to whether or not IA_NA is a requirement for enterprise deployment that just can’t be obviated, at least not today. The only drawback that concerns me with it is the added complexity to SLALAC for resource constrained hosts.
 
> Stateful AAC provides full visibility and protection, a lot more than what we have today, even with DHCP. E.g.,  DHCP can only be snooped by the on path switches, the other just learn indirect info…

All valid criticisms and I’d personally like to see those features added to DHCP.
 
> - synchronize a state in the L3switch/AP/router for ND proxy (RFC 8929) and routing (RFC 9010, RIFT <https://datatracker.ietf.org/doc/html/draft-ietf-rift-rift>, eVPN <https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling>)

All of these come at a cost of complexity in the ND process which I’m not convinced is a benefit. SLAAC/DHCP separation was intentional in order to provide both a low-cost light-weight auto configuration protocol that could be used by resource constrained hosts that were not on policy-sensitive networks _AND_ a full-featured dynamic host configuration capability that was heavier and better suited to such policy-sensitive environments.

Unfortunately, M-bit enforcement is a gaping hole here since it depends on voluntary compliance by host developers, thus can’t be depended on for enforcement.

Further, we have a device manufacturer that is unrepentantly determined to produce general purpose devices that (currently) need to he able to be used on policy-sensitive networks and only support the required policy regime and configuration options in IPv4. They have refused to implement the necessary capabilities in IPv6.

Owen

>  
> Keep safe;
>  
> Pascal
>  
> From: Owen DeLong <owen=[email-masked] <mailto:owen=[email-masked]>> 
> To: Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>>
> Cc: Lorenzo Colitti <[email-masked] <mailto:[email-masked]>>; v6ops list <[email-masked] <mailto:[email-masked]>>
> On Sep 30, 2021, at 03:14 , Pascal Thubert (pthubert) <pthubert=[email-masked] <mailto:pthubert=[email-masked]>> wrote:
>  
> _______________________________________________
> v6ops mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Sep 2021 20:55:53 +0000

Hello Owen

Le 30 sept. 2021 à 20:05, Owen DeLong <owen=[email-masked]> a écrit :

On Sep 30, 2021, at 10:22 , Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>> wrote:

Hello Owen

etc.

Most of the clients I’ve encountered that are truly resistant fall more towards the latter.

Do I read that they forge the IID for the node by policy?

However, there have been some cases where the former might be a workable solution if hosts could be reliably prevented from using addresses not associated with the authenticated {user, host} that made it through the 802.1x process and any other NAC in question.

Sure. We do that in FHS. The trouble is that snooping is not reliable enough, mostly in the case of SLAAC. This is why stateful AAC is the only viable way in enterprise and for the lack of it the policy becomes DHCP only.

Notes:

Our main disagreement. Look at where stateful ND comes from. 6LoWPAN. Because SLAAC was too complicated (cache management) and too resource consuming (broadcast and asynchronous operations that keep the end device awake at night).

The first standard to adopt RFC 9010 is Wi-Sun. For the LFNs, those devices that are so tiny that they sleep more than cats and live on a coin battery for years. Those devices implement RFC 8505. That’s the only ND that was feasible for them.

 Bottom line is that Stateful ND is in fact much simpler to implement than SLAAC. Your power meter at home may actually implement it and you don’t know. They are deployed by millions in North America.

The reason for not adding the screwdriver in the tool box is not complexity, it’s ignorance (what’s that strange tool for?).

That was the binary truth of Y2K when networks where of either of 2 colors. This does not apply to IoT or cloud networks.

Said otherwise: An enterprise that decided for DHCP must keep IPv4 alive for Android users. This means that they cannot go IPv6 only. And I’ve read on the NANOG woes thread that dual stack is the worst possible outcome for OPEX.  Conclusion?

I see that from the other end. Real constrained devices cannot do SLAAC. But they can do DHCP.  And they prefer stateful ND, that’s a lot more bang for the buck (e..g., RFC9010 or RFC 8929).

Not me.

I’d rather have a modern ND that can do pub sub of what it sees to all interested protocols with a simple and agnostic interface to the host.  See it as a Kafka.

RFC 8505 gives you address assignment, DAD, and BCE in one round trip and no multicast. It is stimulated by the host which can go back to sleep with the knowledge that it’s address will not be stolen or impersonated. Bang for the buck.

I m not saying that the current stacks should not implement DHCP. I’m saying that it should move to the back end out of sight as it is replaced by a more valuable interface.

All of these come at a cost of complexity in the ND process which I’m not convinced is a benefit.

The biggest operational complexity is probably to deal with broadcast, which places a high constraint on how a subnet can be assembled.

Not everyone is a CCIE, and I’ve seen people in industrial plants suffering trial and failures deploying simple IPv4 and discovering the impact of broadcast over 100 nodes per broadcast domain. The sort of failure that you observe when the network injects jitter in control loop operations. Ugly. They now have explicit rule of thumb and network designs to prevent that.

They should never have had to worry about that. It’s entirely our fault.

It’s all due to the reactive behavior of ARP. ND is worse because it’s not only lookup, it’s also DAD, times N addresses. Not really an incentive to let SLAAC on in the enterprise is it?

With stateful ND we deploy subnets with thousands of nodes on linkspeeds expressed in Kbps, and there’s no CCIE involved in the deployment. They are live. Now.

SLAAC/DHCP separation was intentional in order to provide both a low-cost light-weight auto configuration protocol that could be used by resource constrained hosts that were not on policy-sensitive networks _AND_ a full-featured dynamic host configuration capability that was heavier and better suited to such policy-sensitive environments.

It can be enforced at the first hop (snooping) switch. But having to snoop and destroy protocol elements in a middle box is the clear indication that the protocol is not doing its job.

There should be an explicit contract between the host and the network that this host can use this address in association with this MAC, that the network will guarantee the ownership for a duration that is part of the negotiation. Seems complicated but really is not.

 I’m aware of customers with policy similar to what you suggested. But the ones I know do not care what the IID is. I believe that their policy would be satisfied if we do 1x and AAC for one address and then push the address to DHCP from the router on behalf of the host.

The situation with Android is related but not exactly the subject of my question. Please assume that I regret this situation and that you do not need to convince me.

 I wish to understand if we can envision to push DHCP out of sight of the end device in your use cases, not now but if / when stateful ND gets in mainstream stacks.

If so we may have a path to resolve the situation. Convincing people to take that path is another story…

Keep safe;

Pascal

Owen

Keep safe;

Pascal

From: Owen DeLong <owen=[email-masked]<mailto:owen=[email-masked]>>
Sent: jeudi 30 septembre 2021 17:59
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>; v6ops list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] Implementation Status of PREF64

Owen

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Sep 2021 17:23:59 -0700

> On Sep 30, 2021, at 13:55 , Pascal Thubert (pthubert) <pthubert=[email-masked]> wrote:
> 
> Hello Owen 
> 
> 
> 
>>> On Sep 30, 2021, at 10:22 , Pascal Thubert (pthubert) <pthubert=[email-masked] <mailto:pthubert=[email-masked]>> wrote:
>>> 
>>> Hello Owen
>>>  

Forge is a strong term. Let’s be clear what we mean by IID here. I’m not talking about DUID or MAC address, I’m talking about the host-portion of the IPv[46] address(es).

> Sure. We do that in FHS. The trouble is that snooping is not reliable enough, mostly in the case of SLAAC. This is why stateful AAC is the only viable way in enterprise and for the lack of it the p…

Yeah, sounds about right, though I’m not sure that stateful SLAAC with complex RAs is a better solution.

> Our main disagreement. Look at where stateful ND comes from. 6LoWPAN. Because SLAAC was too complicated (cache management) and too resource consuming (broadcast and asynchronous operations that kee…

That’s a different kind of resource constraint… You’re now focused on power-constrained devices. I’m talking about devices that may well have mains power or a DC wall-wart, but which have only a few K-bytes of memory for IP stack, application, etc.

6LoWPAN is about power-constrained devices, but most of them are fairly resource-rich when it comes to memory, cpu, etc.

> The first standard to adopt RFC 9010 is Wi-Sun. For the LFNs, those devices that are so tiny that they sleep more than cats and live on a coin battery for years. Those devices implement RFC 8505. T…

Again, a low-power solution for a more full-featured set of hardware devices.

>  Bottom line is that Stateful ND is in fact much simpler to implement than SLAAC. Your power meter at home may actually implement it and you don’t know. They are deployed by millions in North Ameri…

Not convinced of this. I am convinced that it takes a lot less power than SLAAC, but I’m not yet convinced that the memory/CPU footprint is necessarily smaller overall.

> The reason for not adding the screwdriver in the tool box is not complexity, it’s ignorance (what’s that strange tool for?).

I’m all for putting all the screwdrivers in the toolbox and letting the administrator pick the right one for each job.

What I don’t want to do is keep adding crap to RAs until it becomes impossible to parse them with anything short of a machine with 2G RAM and an ARM M7 or better processor at 1GHz or better.

I want to have something that can run at least on an ESP12-F and preferably on an AT-328P.

> That was the binary truth of Y2K when networks where of either of 2 colors. This does not apply to IoT or cloud networks. 

That doesn’t change the fact that there are resource-constrained (CPU, RAM, FLASH, not necessarily power) devices out there that should still be able to be IPv6 enabled.

> Said otherwise: An enterprise that decided for DHCP must keep IPv4 alive for Android users. This means that they cannot go IPv6 only. And I’ve read on the NANOG woes thread that dual stack is the w…

If it were my enterprise, I’d have an SSID for androids alone that was badly NAT v4 only and move everyone else forward to IPv6.

I’d send out a memo explaining the deficiency in the android operating system and how android has failed to provide the basic building blocks necessary for them to participate in our IPv6 network and so they are consigned to this legacy support SSID on a best-effort basis.

I’d probably also provide some form of subsidy for employees choosing to abandon their android devices in favor of something with DHCPv6 support.

Fortunately, in the closest thing I have to an enterprise environment where I make policy, I don’t have to support android at all.

> I see that from the other end. Real constrained devices cannot do SLAAC. But they can do DHCP.  And they prefer stateful ND, that’s a lot more bang for the buck (e..g., RFC9010 or RFC 8929).

From what your saying, it sounds like you equate “real constrained” with “low power, and/or battery operated”. I’m not talking about power constrained devices, I’m talking about devices with limited RAM and CPU capabilities.

> I’d rather have a modern ND that can do pub sub of what it sees to all interested protocols with a simple and agnostic interface to the host.  See it as a Kafka.

I can foresee a number of problems with that model from a security and privacy perspective.

> I m not saying that the current stacks should not implement DHCP. I’m saying that it should move to the back end out of sight as it is replaced by a more valuable interface. 

I’m not convinced that stateful ND is all things to all people. I’m also convinced that when you start adding the kitchen sink to NS/NA/RA/RS packets, you risk exploding the memory and CPU footprint on hosts that can’t cope well with that.

It might be great in some (possibly even most) enterprise environments, but if you’re going to mess with RA/RS and/or NA/NS, you’re going to need to do so very carefully.
 
> With stateful ND we deploy subnets with thousands of nodes on linkspeeds expressed in Kbps, and there’s no CCIE involved in the deployment. They are live. Now.

OK, that’s great for a bandwidth starved network, mesh networking, low power devices, etc.

Not convinced it’s necessarily a better solution for enterprise-level networks.

Further not convinced it’s necessarily better for devices which are {memory, cpu} constrained.

> It can be enforced at the first hop (snooping) switch. But having to snoop and destroy protocol elements in a middle box is the clear indication that the protocol is not doing its job. 

It’s also a fragile and perilous way to do things. I wouldn’t trust it as part of a security architecture which is what we’re talking about here.

> There should be an explicit contract between the host and the network that this host can use this address in association with this MAC, that the network will guarantee the ownership for a duration…

That doesn’t seem complicated at all, but it does require more RAM and a bit more CPU.

>  I’m aware of customers with policy similar to what you suggested. But the ones I know do not care what the IID is. I believe that their policy would be satisfied if we do 1x and AAC for one addres…

In a lot of cases, this is more tribal than technical. The folks that want control over host behavior are not friends with the folks that control the routers. That’s a common enterprise reality.

You can argue that the organization is broken in such cases, but guess what… Most organizations are broken in various ways and this is one of the more common ones.

It’s reality. We have to deal with it.

> The situation with Android is related but not exactly the subject of my question. Please assume that I regret this situation and that you do not need to convince me.

Fair enough. The situation with android is the one I care more about at the moment. Looks like we agree that what you’re on about is orthogonal to that.
The situation with android is the one currently stalling IPv6 deployment in the enterprise (at least to some extent). Yours is more of an optimization for some
particular users of the network that are unlikely to choose IPv4 over IPv6 even in the current state of both protocols.

>  I wish to understand if we can envision to push DHCP out of sight of the end device in your use cases, not now but if / when stateful ND gets in mainstream stacks.

As I have said, maybe in some cases, but almost certainly not in all.

> If so we may have a path to resolve the situation. Convincing people to take that path is another story…

It sounds to me like Lorenzo is at least as resistant to stateful ND as he is to DHCPv6, so I don’t see it helping with the current situation that I am concerned about, but I appreciate your efforts.

I do know that pushing one boulder up one hill is hard enough. Trying to push two boulders up different hills at the same time will usually get you crushed while the hills both laugh at you.

Owen