1. 802.11ac is 5 GHz only. This “limitation” is possibly the most important development because it will bring about a shift in client device support for the cleaner band with more usable spectrum. Mobile devices should adopt quickly if they want to stay “cutting edge” on the spec sheet, and because mobile devices are consumer products, the marketing of speed-based specs carries vast importance. Pervasive client adoption of 5 GHz will improve aggregate performance across the enterprise. 2.4 GHz is a garbage band; Wi-Fi is taking the goods to 5 GHz and leaving its refuse in 2.4.
2. The IEEE has a “reach for the stars” attitude with the 802.11ac spec. Unfortunately, the marketing hype of “gigabit Wi-Fi” is way overdone. The few features that really drive the maximum data rate up are not immediately, or possibly ever, relevant to the enterprise.
• Very large channels—certainly 160 MHz, and likely 80 MHz as well—can ruin aggregate capacity, especially with high client densities and lots of 20 MHz only mobile devices. Some experts call these large channels a “gimmick.” Marketing departments love it.
• The other big data rate boost is more spatial streams (up to 8). As a reminder, today’s products incorporate only 3 (and rarely utilize them all) of the possible 4 spatial streams specified in 802.11n, so the likelihood of ever utilizing 8 is very slim. Adding more spatial streams to real-world products will take a lot of time.
• MU-MIMO promises better spectral efficiency with simultaneous transmissions to multiple users. However, this feature relies on better support (heck, let’s start with some support) of client beamforming as well as significant queuing modifications, and even then, there are still questions about achieving sufficient signal isolation between target clients. MU-MIMO doesn’t change the raw data rate, but it’s one of those marketed theoretical features that won’t be in the first, or first several, generation of products.
3. Both 802.11ac and 11ad will be hot in the consumer market, and like previous technologies, will filter into the enterprise as use cases develop. This is especially true for 11ad, which is almost exclusively focused on consumers, but may find niche uses in enterprises. 11ac will be a mainstream enterprise technology, but many of its gains are muted in the enterprise.
4. 3 out of 4 experts had reservations about the significance of “gigabit Wi-Fi.” The dissenting 1 out of 4 is optimistic. 
5. Products will not hit the market until late 2012 or early 2013, so we still have time to wait and let the many marketers beat their drums.

Hotspot 2.0 and the Next Generation Hotspot initiatives are possibly the most exciting areas of wireless progress occurring in 2012. For starters, these developments have a worldwide scope of influence. The technologies that come to market as a result of these programs will directly affect a large portion of the world’s population. If brought to market with extensibility, they could revolutionize the hotspot ease-of-use and security landscapes. These programs deserve the spotlight.

The Initiatives

Hotspot 2.0 and Next Generation Hotspot (NGH) are highly complementary initiatives, but they are different in scope. Hotspot 2.0 is the Wi-Fi Alliance’s certification program that will include a technical specification defining the Hotspot 2.0 technology. Following the Wi-Fi Alliance’s core purpose, Hotspot 2.0 will also be a device certification, based on product interoperability testing, that allows vendors to implement the protocols in a common way.

Hotspot 2.0 is designed for Wi-Fi clients and infrastructure devices to support seamless connectivity to Wi-Fi networks. The specification is still a document in progress, but as a non-Wi-Fi Alliance member, I have a little bit of insight about what we can expect. The first thing to understand about the specification is that the Wi-Fi Alliance is not attempting to define all new technologies. The Hotspot 2.0 effort is a bit more like putting together the pieces of a fragmented puzzle.

For example, the spec will draw largely (and selectively) from 802.11u, which enhances network discovery and selection by Wi-Fi clients. 802.11u provides all the protocol-level “hooks” for infrastructure vendors (the WLAN controller and APs) to interwork with backend services (like hub AAA proxy servers and operator AAA servers and user databases). Perhaps more important than the backend integration and querying, 802.11u also provides the protocols and frame components that allow the clients to learn about the backend services on the network. The client can learn what service providers or roaming partner agreements are available through the BSS, what the hotspot service model is like, and the client can even query the backend services for other information. This level of backend transparency facilitates the seamless client selection and connectivity process.

In addition to 802.11u, Hotspot 2.0 will draw on the familiar 802.1X/EAP architecture we use in Wi-Fi today. Four EAP types are in the existing spec: EAP-SIM, –AKA, –TLS, and –TTLS. Obviously, the cellular convergence focus comes in with EAP-SIM and AKA. 802.1X is also incorporated for user authentication, but the backend components will vary from one network to another. In most cases, the WLAN infrastructure (APs and/or WLC) will integrate with a “hub” AAA proxy server that interfaces directly with each operator’s AAA server. Or the WLAN may interface directly with AAA servers belonging to the network operator as well as a AAA proxy for other operators in a roaming agreement. This is where the business complexity gets interesting and also where the Wireless Broadband Alliance’s (WBA) work with Next Generation Hotspot (NGH) picks up.

The Wi-Fi Alliance’s Hotspot 2.0 is primarily focused on Wi-Fi device interoperability and testing (i.e. clients and APs), but the WBA’s mission is targeted at the whole scope of functionality and interoperability, including interoperability between network operators and service providers on the backend. In 2011, the WBA conducted NGH trials, which are real-world functionality tests using equipment from the participating vendors. Wi-Fi client and infrastructure participants were required to first pass the Wi-Fi Alliance’s Hotspot 2.0 test events. In the NGH trials, the approved Hotspot 2.0 devices were tested with the various backend systems and architectures. NGH trials included testing for different authentication setups, including direct authentication with the owner operator (e.g. AT&T SIM on an AT&T network), authentication through third-party hubs (e.g. using Syniverse or others as a AAA proxy to an operator’s servers), and through visited network operators (e.g. AT&T SIM on an Orange network).

Based on the results of the NGH trials, the WBA is creating recommendations to bring these operator and service provider technologies to market in a consistent and interoperable way.

In a typical client connection to a wired Ethernet port, the client will be a member of a VLAN based on the switch port configuration. When the client connects, it does the usual DHCP exchange by sending a broadcast DHCP discovery frame to find a DHCP server. If there’s a DHCP server on the local Layer 2 domain, it will reply and everyone will be happy. However, if the DHCP server is not on the local subnet, a router must be configured to forward the DHCP discovery. Typically, this is accomplished by configuring an IP Helper Address on the router, which is just a way of telling the router to relay certain broadcast UDP frames (like DHCP) to a specific IP destination. In the case of DHCP, the router will forward the DHCP discovery and request as unicast frames to one or more pre-configured DHCP servers.

However, the router does something interesting. Remember that the original client doesn’t yet have an IP address, so there is no source IP address in the DHCP discovery. When a router forwards the frame across the IP network, the router must include a relay IP address so that the DHCP server can send the DHCP offer back to the proper relay device. For this, the router uses the interface (or subinterface) IP address that matches the client’s VLAN.

For wireless clients, when you understand the above process, DHCP is not terribly complex. There are a few more potential gotchas on the wireless segment, though. A few reasons why Wi-Fi DHCP is a little different follow:

1. An AP’s radio interface performs different functions than an access (non-trunked) port on a switch
   1. A single radio interface is expected to allow multiple clients at the same time
   2. The radio interface may support multiple service sets with different parameters and functions
   3. Clients associated to an interface may be in different VLANs
2. The AP may be connected to its uplink switch via a trunk (with multiple VLANs) or an access port (with only a single VLAN) and may forward data directly to its source or tunnel the data to a WLAN controller for forwarding
3. Clients move

So the first goal for the infrastructure is to determine which VLAN a wireless client belongs in. The most common method is to statically map an SSID with a VLAN. Once the client associates to the SSID, it is automatically placed in that SSID’s VLAN. The other method—more flexible, but less common— is to implement 802.1X user-based policies in which the client is assigned to a VLAN dynamically based on RADIUS attributes sent during 802.1X authentication. Regardless of the method, after the authentication is complete, the infrastructure (WLAN controller and/or AP) can map the client with a VLAN and IP subnet. Of course, the client doesn’t know which subnet it belongs in.

When the client initiates a DHCP exchange, the WLAN infrastructure can handle it in a few ways.

DHCP Bridging

DHCP bridging is somewhat self-explanatory in that the WLAN infrastructure simply “bridges” the DHCP frames to the wired network without modifying them. Neither the WLAN controller nor AP changes the DHCP frames in any way. In this configuration, the upstream wired network remains responsible for handling DHCP exchanges, as described previously for wired clients. This is the expected behavior for a WLAN infrastructure that does not support the proxy or relay DHCP features described later

Below is an overly simplified network diagram in which the DHCP server is in a different IP subnet than the client.

With DHCP bridging, the client’s DHCP discovery and request frames would be passed to the upstream network, in this case, the first router (connected via a red link for illustration). The router would then act as a DHCP relay agent, forwarding/routing the DHCP discovery and request to the DHCP server. A frame decode of this is shown below, captured from the red link prior to the router’s modification.

DHCP Relay

At the beginning of this article, we described the DHCP exchange for a wired client. When a DHCP discovery or request hits an IP subnet boundary, a router must be configured with an IP Helper address pointing to a DHCP server. Wi-Fi segments can accomplish the same basic task by turning the AP or WLAN controller into the relay agent.

Vendors usually call this DHCP Relay. Either the AP or the WLAN controller (depending on the data forwarding plane) receives the DHCP discovery/request and forwards the frame to the DHCP server(s), adding its own IP address as the relay.

The key configuration requirement for DHCP Relay is that the WLAN controller or AP must have an interface with a corresponding IP address in each of its clients VLANs—and potential clients’ VLANs. The WLAN infrastructure uses the corresponding interface and IP address as the relay agent IP address for the DHCP discovery and request frames. By using the client’s VLAN/subnet as the relay agent IP, the DHCP server knows to provide an IP address in the correct client subnet.

A frame decode of DHCP Relay is shown below. This frame was also captured from the red link between the wireless infrastructure and the router. The WLC/AP has changed the destination from broadcast to unicast (the DHCP server’s IP address) and has placed its own client-side IP address as the relay agent IP address.

DHCP Proxy

DHCP Proxy is similar to DHCP Relay in its basic function, but it goes a step further. Instead of merely forwarding the frames back and forth, the DHCP Proxy takes a more active role by inserting itself as a DHCP server to the client device. When the client sends the DHCP discovery and request frames, the WLAN infrastructure alters (or rebuilds) the frames and unicasts them to the DHCP server. After receiving the offer from the DHCP server, the WLAN infrastructure sends a DHCP offer to the client, presenting itself as the DHCP server. The WLAN infrastructure maintains a table of client MAC to IP mappings, drawing on this information to add security and performance functionality to the WLAN (I’ll explain in a minute).

If we were to look at a frame trace of DHCP proxy on the wired side as we did in the previous DHCP bridging and DHCP relay traces, DHCP proxy would look the same as DHCP relay. Below is a frame trace of DHCP proxy on the Wi-Fi interface. This frame is the DHCP offer sent to the Wi-Fi client. The WLAN infrastructure offers the IP address to the client, using its own IP address as the DHCP server. For this, the WLAN infrastructure is configured with a virtual IP address (it was common practice to use 1.1.1.1 in Cisco WLANs, but now recommended that an unused private address be used instead), which is the “DHCP server” IP address shown to the client. You’ll see here that the client is offered 10.10.50.4/24 from 1.1.1.1.

There are three primary benefits to DHCP Proxy:

1. By converting a broadcast frame to unicast at the frame’s entry point on the wired network (other than in a tunnel to the WLAN controller, which is also unicast), the DHCP relay and proxy features both eliminate wireless broadcast DHCP traffic on the LAN.
2. We mentioned earlier that the WLAN infrastructure maintains a client MAC/IP table, and this table enables the infrastructure to apply security policies between the wired and wireless segments. Specifically, participation in the DHCP process prevents unauthorized DHCP traffic between wireless and wired segments, it allows the WLAN to prevent IP and ARP spoofing as well as rogue DHCP servers, and it protects against other DoS attacks.
3. DHCP proxy also improves roaming performance. When a client roams between Layer 3 boundaries, it recognizes the need to request a new IP address. By sharing the virtual IP address (e.g. 1.1.1.1) across a mobility domain (i.e. in Cisco speak), the WLAN infrastructure can easily and efficiently renew the client’s IP address without the back-and-forth with the real DHCP server. The added efficiency and IP renewal may prevent a disruption to applications that require a continuous session.

Impact of the Data Plane

When it comes to WLAN architectures with DHCP features, the device that relays or proxies the DHCP frames will either be the AP or the WLAN controller. Regardless of the forwarding model, the device(s) that is responsible for DHCP relay or proxy features must be configured with interfaces on each client VLAN/subnet. If data is forwarded through the WLAN controller (i.e. centralized), it makes sense that the WLAN controller would be handling DHCP features. In distributed forwarding models, network design plans should account for more IP address consumption because each AP will need an IP address for each supported client subnet. When large numbers of APs serve each client VLAN, IP address consumption becomes excessive and the DHCP Bridging model is a better design choice than DHCP proxy/relay. To date, only one vendor supports DHCP relay in a distributed fashion.

Final Comments and Suggestions (FCS)

DHCP is not always  first on the list of hot topics for wireless design priorities. No less, poor DHCP planning for your network could have a significant impact on WLAN service availability. For that reason, and for troubleshooting problems that will inevitably arise, any WLAN engineer should know the three primary ways to manage DHCP in a WLAN: bridging, relay, and proxy. We spend a lot of time and energy improving our RF environments; it would be a real shame to let DHCP ruin client connectivity.

Reposted with permission from CWNP.com