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

["Pascal Thubert (pthubert)" <[e-mail]>]

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=[e-mail]>
Sent: jeudi 30 septembre 2021 17:59
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: Lorenzo Colitti <[e-mail]>; v6ops list <[e-mail]>
Subject: Re: [v6ops] Implementation Status of PREF64




On Sep 30, 2021, at 03:14 , Pascal Thubert (pthubert) <pthubert=[e-mail]<mailto:pthubert=[e-mail]>> 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