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

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

Hello Owen

I believe you’re confused between LPWAN which is as you describe and 6LoWPAN (now 6lo). Please look at the introduction of RFC 6282, or any of the charters of 6TiSCH ROLL, 6lo, or obviously 6LoWPAN itself. The IoT side of the IETF has been very aware of memory, CPU, and battery- related constraints.

6LoWPAN runs easy on the platforms you mention. Just Google, you’ll find the research papers. There’s a full implementation of 6TiSCH on cc2358 too, including 6LoWPAN and RPL.

Stateful ND is less state in the end host than classical ND because it always operates in not onlink mode, so the only neighbors known are the routers and information is not cached. Many radios and power line networks are non transitive so redirect is discouraged in general.

It is also less code; no DAD, no lookup and no NUD (beyond RSing the routers). No asynchronous multicast to handle but possibly RAs though in general these are unicast. No cache management. And as I said no redirect.

Plain here’s my address(es), here’s how long I need it (renewable) here’s a sequence counter (because I move) and optionally a proof of ownership (crypto based on autoconf’ed keypair). Router says yes or no, eg because it’s duplicate.

It is what the most minimalist implementations of IPv6 do. It is actually hard to prove that you need much more though it is easy to prove that you can get a lot less with more code, more state, and more bandwidth, e.g., SLAAC.

A lot of good people working hard in the early times of 6LoWPAN tried to evolve classical ND to fit in the constrained node (including bandwidth I admit) and failed. Ultimately the group went for stateful, for some people because they liked it, for other because they found no other way.

This does not change the RA much; it is recommended to add the 6CIO to expose capabilities, there’s compression related options if you compress IP, and the address of the equivalent of the DHCP server for use by routers in NBMA networks.

Ole’s work is orthogonal but I believe it’s a modern way for the future. Just like RIFT using Thrift. Please consider that as separate from stateful ND, though.

Keep safe,

Pascal

Le 1 oct. 2021 à 02:24, Owen DeLong <owen=[e-mail]> a écrit :



On Sep 30, 2021, at 13:55 , Pascal Thubert (pthubert) <pthubert=[e-mail]<mailto:pthubert=[e-mail]>> wrote:

Hello Owen



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



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

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?

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 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?

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?

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).

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.

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

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.

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 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.

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.

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).

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. That’s the only ND that was feasible for them.

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 America.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

All valid criticisms and I’d personally like to see those features added to DHCP.

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.

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

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.

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.

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>)

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.

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.

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.


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 is part of the negotiation. Seems complicated but really is not.

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 address and then push the address to DHCP from the router on behalf of the host.

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.

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.

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