It’s a well-known fact that Wi-Fi allows for backward compatibility with previous generations. This is one reason the technology is so popular – people can upgrade their devices at their own pace, without worrying about whether their old ones will still work. But truth be told, Wi-Fi backward compatibility has long been a double-edged sword.
Believe it or not, Wi-Fi technology, also known as 802.11 WLAN technology, has been around since 1997. From 1999 – 2005, many people experienced their first Wi-Fi connection using the high-rate direct spread spectrum (HR-DSSS) technology that was defined for 802.11b Wi-Fi devices. We marveled at the ability to connect at data rates of 1, 2, 5.5, and 11 Mbps on the 2.4 GHz frequency band.
I will never forget when 802.11g was introduced with the promise of data rates of up to 54 Mbps in the 2.4 GHz band. I was teaching a Wi-Fi class in 2006, and I upgraded the classroom access point with a brand new 802.11g radio and connected some new 802.11g clients together with some older 802.11b clients. Now we all know that data rates are not the same as actual throughput. However, with the newly advertised data rate of 54 Mbps, I expected to see an aggregate TCP throughput of around 22–23 Mbps. Boy, was I disappointed because instead, we witnessed throughput closer to only 8-9 Mbps.
It was on that day that I first learned that backward compatibility often comes with an asterisk.
When 802.11g technology debuted in 2006, the 802.11 standard had to provide a way for both DSSS and OFDM technologies to coexist in the same 2.4 GHz RF environment. The technical term for 802.11g technology is Extended Rate Physical (ERP). An ERP (802.11g) radio can communicate effectively using either orthogonal frequency division multiplexing (OFDM) or HR-DSSS transmissions. However, older 802.11 or 802.11b radios only communicate using DSSS or HR-DSSS transmissions. So, a “protection mechanism” was defined so that DSSS or HR-DSSS transmissions would not happen when two 802.11g radios were communicating using OFDM. As depicted in Figure 1, the protection mechanism uses a request-to-send/clear-to-send (RTS/CTS) management frame exchange to ensure the co-existence of two different technologies with the same Wi-Fi domain.
Figure 1 – RTS/CTS protection mechanism
A good analogy would be verbal languages. Think of an 802.11g radio as speaking both English and Spanish, whereas an 802.11b radio can speak only English. An ERP protection mechanism is defined so that when Spanish is spoken between 802.11g radios, the 802.11b radios will not interrupt the conversation because the 802.11b radios speak only English. Co-existence and backward compatibility are ensured, but a painful price was paid. The overhead from all the RTS/CTS management frames lowered the potential of 22 Mbps aggregate throughput down to a real-world number of closer to 9 Mbps. Very soon, an optional protection mechanism called CTS-to-Self gained wider adoption. Due to less management overhead, the aggregate throughput in an 802.11g environment elevated to 12 Mbps, but still far short of the promised potential of maybe 22 Mbps.
Do you see where I am going with this? The existence of legacy clients in an updated Wi-Fi environment degrades the overall performance of the wireless network.
Now we have come a long way since 802.11b/g. In 2009, 802.11n (Wi-Fi 4) was introduced for both the 2.4 and 5 GHz bands. In 2013, 802.11ac (Wi-Fi 5) was introduced for the 5 GHz bands. 802.11ax (Wi-Fi 6) has now been with us for three years. With the introduction of each of these new generations of Wi-Fi, RTS/CTS protection mechanisms were needed to allow for backward compatibility. The good news is that the much higher data rates of 802.11n/ac/ax masks much of the overhead caused by RTS/CTS, but the overhead still exists.
Another deep cut caused by the double-edged sword of Wi-Fi backward compatibility is the fact that legacy clients transmit at lower data rates and consume precious Wi-Fi airtime.
Figure 2 depicts an AP communicating with multiple client stations at 6 Mbps while communicating with one lone client using a 150 Mbps data rate. When 802.11 radios transmit at very low data rates, such as 6 Mbps or even lower, they effectively cause medium contention overhead for higher data rate transmitters due to the long wait time. A radio transmitting a 1,500-byte data frame at 150 Mbps might occupy the medium for 50 microseconds. Another radio transmitting at 6 Mbps may take 1,250 microseconds to deliver the same 1,500 bytes. In other words, the same data payload consumes 2,500 percent more airtime when being delivered at the lower data rate.
Figure 2 – Data rates and airtime consumption
Once again, the existence of legacy clients degrades the overall performance of the wireless network simply because they consume more airtime.
In an 802.11 management frame, information elements are optional fields with variable lengths. One example of an information element is the robust security network (RSN) information element, which contains information about the type of authentication and encryption used within a Wi-Fi network. Whenever new Wi-Fi capabilities are introduced, so are new information elements. Although Wi-Fi technology makes provisions for backward compatibility, the opposite is often true in the real world, and client connectivity problems occur. Legacy client drivers often do not know how to handle the new fields in 802.11 information elements found in beacon and other management frames transmitted by an AP.
Bottom line, when new technology is enabled on an AP, legacy clients sometimes can no longer connect. Historically we have seen connectivity problems with some legacy clients when 802.11k, 802.11r, 802.11v, and 802.11w mechanisms were first introduced.
For example, Figure 3 depicts the two information elements found in management frames sent by an AP with 802.11r fast secure roaming mechanisms enabled. Ideally, the drivers of legacy clients that do not support 802.11r are supposed to ignore these information fields, and everything will be fine. But in the real world, the new information elements often disrupt some legacy client drivers, resulting in client connectivity problems.
Figure 3 – Information elements
What does this mean? Very often, new Wi-Fi capabilities and features must be disabled on the AP so that the legacy clients can still connect. In some cases, the client vendor may never offer a firmware upgrade that fixes the problem. The existence of legacy clients may prevent you from enabling the new generational features that your enterprise desires.
When discussing Wi-Fi security, a wide range of topics is relevant when discussing backward compatibility and the impact on your Wi-Fi network. For example, some enterprises still have not replaced ancient devices that use the long-outdated encryption methods of WEP or TKIP.
Temporal Key Integrity Protocol (TKIP) was a stop-gap security solution between 2003-2004 as the industry transitioned from WPA1 to WPA2. Very old client devices could upgrade from WEP to TKIP via a firmware update. A hardware update was required as we moved onward WPA2 using CCMP AES 128-bit encryption starting in 2004. The transition to WPA2 began. That was 18 years ago.
Starting in 2009, both WEP and TKIP were no longer supported for any of the new data rates and modulation and coding schemes (MCSs) defined for 802.11n. Meaning, TKIP only works on the DSSS data rates of 1, 2, 5.5, 11 Mbps and the OFDM rates of 6,9,12,18,36, 54 Mbps. That was 13 years ago. Both TKIP and WEP have been permanently deprecated in the IEEE 802.11-2020 standard. Also, WPA3 completely deprecates support for WEP and TKIP. But guess what? It is not uncommon to find very old wireless data collection devices that are literally two decades old in production environments in industries such as manufacturing. These devices hinder performance and pose security risks.
In August 2019, the Wi-Fi Alliance began testing APs and clients for the Wi-Fi Certified WPA3 certification. Wi-Fi Protected Access 3 (WPA3) defines enhancements to the existing WPA2 security capabilities for 802.11 radios. It supports new security methods, disallows outdated legacy protocols, and requires the use of management frame protection (MFP) to maintain the resiliency of mission-critical networks. WPA3-Personal leverages Simultaneous Authentication of Equals (SAE) to protect users against password-guessing attacks. Also, WPA3- Enterprise now offers an optional equivalent of 192-bit cryptographic strength.
However, the bulk of older Wi-Fi devices that operate in the 2.4 and 5 GHz frequency bands only support WPA2. But no worries, we can use either WPA3-Personal or WPA3-Enterprise transition modes. These transition modes enable backward compatibility for Wi-Fi security. As shown in Figure 4, WPA2-Personal clients connect to the same SSID as WPA3-Personal clients. The clients use the same passphrase; however, the WPA2 clients connect with PSK authentication, and the WPA3 clients connect with SAE authentication. In this transition mode, MFP is used by the WPA3 clients but not necessarily by the WPA2 clients. WPA2-Enterprise clients to connect to the same SSID as WPA3-Enterprise clients. 802.1X/EAP authentication remains the same. However, in this transition mode, MFP is used by the WPA3 clients but not necessarily by the WPA2 clients.
Figure 4 – WPA3 transition modes
These transition modes sound great… right? In theory, WPA2 and WPA3 clients can live harmoniously together on the same SSID. But in the real world, many enterprises have quickly discovered that legacy clients often have connectivity issues despite the promise of co-existence offered by the transition modes. For this reason, the adoption of WPA3 in the 2.4 GHz and 5 GHz frequency bands has been very slow. That’s a shame, because we should all strive to offer the best security options that are available.
Have you ever had a house guest that has overstayed their welcome? Well, because of backward compatibility, Wi-Fi clients tend to overstay their welcome in the enterprise. Depending on the vertical, Wi-Fi infrastructure upgrade cycles in the enterprise typically occur every four or five years. Enterprise customers usually upgrade their APs and WLAN infrastructure, but often fail to upgrade the client population. Legacy clients often have a 10-year life cycle and hang around way too long.
So, while Wi-Fi backward compatibility has its advantages, clearly, there are potential performance, connectivity, and security concerns when legacy clients live in your enterprise for years on end.
So, what is the solution? The best answer is to gain control over your Wi-Fi client population. First, keep the firmware and drivers current for all your corporate-owned devices. Second, do not wait 10 years to replace company laptops, tablets, scanners, and other Wi-Fi devices. Replace them with at least the most recent generation of technology as your APs. Most businesses and corporations can eliminate many of the client connectivity and performance problems by simply upgrading company-owned client devices along with the WLAN infrastructure. Sadly, the opposite is often more common, with companies spending many hundreds of thousands of dollars on technology upgrades with new access points while still deploying legacy clients. Do you still use 8-track players and VHS recorders to stream music and videos to your modern-day smart TV? I doubt it. Update your Wi-Fi clients.
The other problem is that you cannot totally control the entire client population. There is no telling what type of devices employees and guests will bring to your workplace. The best resolution is to segment your guest users and bring-your-own-device (BYOD) users on entirely separate SSIDs.
I have some great news! For the first time in 20 years, Wi-Fi does not require backward compatibility. I am talking about Wi-Fi 6E and the 6 GHz frequency band. There is no need for RTS/CTS protection mechanisms for legacy Wi-Fi devices. Older clients do not consume precious airtime while transmitting using slow data rates. WPA3 is mandated for 6 GHz, and there is no support whatsoever for WPA2 or other older security mechanisms. And why is this all possible? Why do we currently not need backward compatibility in 6 GHz? The answer is simple…. Wi-Fi is brand new to 6 GHz, and there are no legacy clients!
Countries across the globe continue to adopt the new 6 GHz superhighway that is the foundation of Wi-Fi 6E. This 1200 MHz frequency superhighway provides a reliable path for the evolution of enterprise Wi-Fi. The constant growth of cloud computing, mobile connectivity, big data, ML/AI, and IoT will continue to drive the demand for faster and more reliable enterprise Wi-Fi throughout the next decade. The advent of Wi-Fi in the 6 GHz frequency guarantees that Wi-Fi will continue to grow as the predominant solution for secure wireless connectivity and mobility in the enterprise.
Will we ever need backward compatibility in 6 GHz? I am afraid so, come talk to me in twenty years once we get to Wi-Fi 7, Wi-Fi 8, and Wi-Fi 9. In the meantime, I think we have a very long window of time to celebrate the pristine RF environment that 6 GHz provides for Wi-Fi. We are looking forward to the future and not looking back in the rear-view mirror.
