Re: [IPv6] Thoughts on draft-thubert-6man-ipv6-over-wireless-15

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

Many thanks for reading the draft, Joe.

About the concept of the BBR / AP collocation, yes, it looks like a layer violation, but it is also a conscious requirement by IEEE std 802.11.

The IEEE 802.11 standard demands (and has demanded for a number of iterations) that the AP has an "arp proxy" function. In their parlance "arp proxy" is for both IPv4 and IPv6. And the intent is to keep a state about the IP addresses in the associated nodes in order to tame L3-induced broadcasts. They want a L3 equivalent of the secure proactive address registration process that they call "association". Everyone know the term but is not necessarily clear on what it really does. It creates a BSS, which is a domain where the ethernet broadcast can be emulated - at a cost - for protocols that existed before Wi-Fi and were not sensitive to broadcast. At the same time, the association tames the broadcasts induced by learning bridges operations.

Till RFC 8929 and the specification of the BBR, there was no IETF spec to match the .11 requirement.

Now, the RFC 8505 registrar that you mention is very abstract. It can be "replicated" in all the BBRs (https://datatracker.ietf.org/doc/draft-thubert-bess-secure-evpn-mac-signaling/), "centralized" (think LISP, meaning that does not have to be a SPoF), or "distributed" with each BBR maintaining the state for its registered addresses only. RFC 8929 specifies  a "distributed" variation that uses IPv6 ND to reactively discover the other addresses over the backbone. This way, RFC 8929 provides a standard for the arp proxy that IEEE 802.11 is after, and allows to cancel the undesirable broadcasts over the wireless access.

But, caveat, it can only suppress the undesirable broadcasts when *all* its associated wireless nodes implement RFC 8505. Which is why a focus was initially given to wireless, still showing in the title of the draft.

On a different note, but probably of interest for ops, RFC 8929 provides both a routing and a bridging proxy variation. In routing proxy, the BBR answers NSs on behalf of the registered nodes with its own link layer address, and it installs a /128 route towards the registering node. IOW it routes the packets . This is required when the node is, say, on an IEEE 802.15.4 link that has non-bridgeable MACs. But that could be very cool for ops as well as the wireless MACs do not need to show on the backbone, at least for IPv6 operations. Conversely, the bridging proxy lets the registering node answer the NAs (unless the BBR is a sleep proxy of sorts),  meaning that the data packets are bridged by the AP as usual. The broadcasts NS are turned to unicast on the wireless hop, which makes it both faster and reliable, so there's a clean win there.

The bridging proxy operation is probably the one that the .11 people had in mind but in the end, it is up to the ops people to use either one. The RAs can still be generated by the real routers though the RS could be turn to unicast by the 6BBR, or at least not copied on the wireless side. I hope this helps alleviate the concerns about layer violations. They are limited, required (by .11), and better understood now that we made them a standard vs the art of existing but proprietary variations.

All the best,

Pascal
From: ipv6 <[e-mail]> On Behalf Of Joe Clarke (jclarke)
Sent: Wednesday, August 2, 2023 8:10 PM
To: [e-mail]
Subject: [IPv6] Thoughts on draft-thubert-6man-ipv6-over-wireless-15

I had a chance to read through this draft with the hat of an IETF NOC member.  Given the number of wireless (and IPv6 wireless) issues we've seen over the years, Sections 2.1 and 2.2 really speaks to me.  We have seen issues with failing stateful proxies, incomplete learning of IPv6 addresses, and snooping holes.  These have led to extended onboarding time for IPv6-only clients and times when certain clients can pass traffic.  Things have gotten better, but it's still a moving target.  This is a real problem, and I'm glad focus is being given to it.

While not IPv6-specific, the IETF conference network currently uses public IPv4 addresses without a firewall (to provide an "Open Internet(tm)"), and this leads to other operational challenges that have required us to use ARP proxies to tamp down the broadcast onslaught.  Not having standards means to do some of these functions has been challenging.

Therefore, I support the spirit of this draft in that a more proactive approach to address registration and use of standardized means to do so and query the registrar would aid in overall network operation..

The concern I have is turning the AP into a BBR.  I can already hear some of the conversations in the NOC about this "layer violation".  That said, I can imagine a case where AP suppresses the multicast over the air and redirects RS or NS requests directly to the registrar (e.g., campus router).  As you mention, the true wired side of the network is not as susceptible to the shortcomings of NBMA, so pushing this traffic out onto the wire is not such a bad thing, plus it gives less "Magick" for the AP to handle.

Joe