Roaming & OperationsL3

Network Protocols (Advanced)

Roaming Reference

EasyMesh, IPv6 over Wi-Fi, PMKSA/ERP deep dive | Wi-Fi Alliance Multi-AP Spec v4.0, RFC 6105, RFC 66965 rows#

Topic	Standard	Description	Key Messages / Protocol Flow	Engineering Notes
EasyMesh - Architecture	Wi-Fi Alliance Multi-AP Spec v4.0 IEEE 1905.1	EasyMesh defines a standardized multi-vendor mesh Wi-Fi architecture: • Controller: single logical entity managing the whole mesh. Usually on the root AP (connected to WAN). • Agent: each AP in mesh is an agent. Agents report topology, stations, metrics to Controller. • 1905.1 AL-MAC: Abstraction Layer MAC - device-independent addressing for multi-technology (Wi-Fi + Ethernet) backhaul. • Backhaul: wired Ethernet or wireless (802.11 WDS-like but standardized). Dual-band agents can use one radio for backhaul, one for clients.	CMDU (Control Message Data Unit) - EasyMesh protocol messages over 1905.1: • AP Autoconfiguration: new agent discovers controller, exchanges WSC (Wi-Fi Simple Config) M1/M2 for credential provisioning • Topology Discovery: agents report neighbor BSSID, BSS info, STA associations • Channel Selection: Controller sends Channel Selection Request, Agents respond • Client Steering: BSS Transition Management (802.11v) to steer STAs between agents • Backhaul Steering: move backhaul link between channels/bands	EasyMesh vs 802.11s (mesh): • 802.11s: standardized L2 mesh (HWMP routing), no controller concept, IEEE standard • EasyMesh: controller-based management over 802.11 + Ethernet, Wi-Fi Alliance cert • WDS: vendor-proprietary, not interoperable • EasyMesh preferred for multi-vendor managed deployments (ISP, enterprise home)
EasyMesh - Channel Selection (CSBC)	Wi-Fi Alliance Multi-AP Spec v4.0 §17	Channel Selection Based on Centralized control (CSBC): Controller coordinates channel assignment across all agents to minimize CCI. Algorithm: 1. Agent reports: available channels, channel utilization (802.11k neighbor report), noise floor 2. Controller computes non-overlapping channel plan 3. Controller sends Channel Selection Request to each agent 4. Agent responds with Channel Selection Response (accept/decline + reason) 5. Agent performs CAC if DFS channel selected, then switches	Channel Selection Request TLV: Operating Class + Channel + Reason Code Channel Selection Response TLV: Accept/Decline (reason: DFS required, not supported, busy) CAC completion report: CAC_COMPLETION_REPORT TLV with result (success/radar detected) Metrics reporting: Channel Scan Report includes noise, utilization, neighbor list per channel	CSBC coordination prevents the 'AP island' problem where adjacent APs independently select the same channel. In 3-agent mesh: root=ch36, hop1=ch100, hop2=ch149 = no co-channel backhaul.
EasyMesh - BSS Steering	Wi-Fi Alliance Multi-AP Spec v4.0 §14	BSS Steering: Controller directs Agent to steer a STA from current BSS to a target BSS. Methods: • Mandate steering: Agent sends 802.11v BTM Request to STA (Mandate bit set). STA should comply. • Opportunity steering: Agent asks STA to roam (STA may decline). • Force disassociation: if STA refuses BTM, Agent can disassociate STA (last resort). Controller uses STA capabilities, RSSI reports, link quality metrics to decide when/where to steer.	Steering messages: • Client Steering Request (Controller→Agent): STA MAC, Target BSSID list, disassoc imminent, BTM request • Client Steering BTM Report (Agent→Controller): STA response (accept/decline), target BSSID • Steering Completed (Agent→Controller): confirms STA associated to target Steering metrics used: • RSSI of STA on current BSS < threshold (e.g. -70 dBm = trigger) • RSSI on target BSS > threshold (e.g. -65 dBm = candidate) • Link quality (frame error rate, retry count) from 802.11k metrics	Steering guard timer: prevent oscillation. Default: 300s hold after failed steer. 802.11v BTM Request: Disassoc Timer field (if mandatory, AP disassocs after N beacon intervals if STA stays).
IPv6 over Wi-Fi - RA Guard	RFC 6105 (RA Guard) RFC 8021 (RA Guard bypass) IEEE 802.11-2020	Router Advertisement (RA) Guard: AP/switch blocks rogue RA messages from STAs. RAs carry IPv6 default route - a rogue RA (from compromised STA or attacker) can redirect all IPv6 traffic. RA Guard policy: only designated router ports (uplink) allowed to send RA messages. All STA ports: RA from STA → dropped. RA Guard bypass: RFC 8021 documents RA Guard bypass via IPv6 extension header manipulation. Fragmented RA or oversize extension headers may evade some implementations.	RA Guard implementation in AP: • Inspect ICMPv6 type=134 (Router Advertisement) in all frames from STAs • If RA from STA port → drop + log • If RA from uplink → forward to all STAs Additional: DHCPv6 snooping - track IPv6 address assignments per STA MAC. IPv6 ND Proxy: AP answers Neighbor Solicitation (NS) on behalf of STAs. Prevents NS flooding. 6LoWPAN (RFC 4944): IPv6 over IEEE 802.15.4. Relevant to 802.11ah IoT - compression headers reduce 40-byte IPv6 header to 2-6 bytes over low-bandwidth sub-1GHz links.	Key RA Guard checks: 1. Source MAC = trusted router → allow 2. Source MAC = STA → check uplink port ONLY 3. ICMPv6 type 134 from wrong port → drop RA flood attack: attacker generates thousands of /64 prefixes → STA builds huge routing table → CPU exhaustion. RA Guard + rate limiting mitigates.
PMKSA Caching vs OKC vs ERP vs FT	IEEE 802.11-2020 RFC 6696 IEEE 802.11r	Comparison of fast re-authentication mechanisms: 1. PMKSA Cache (same AP): • PMK cached at AP and STA • No full EAP on return to SAME AP • Lifetime: 43200s default • Works with: all standards 2. OKC (different AP, same WLC domain): • PMKID = HMAC(PMK, 'PMK Name'\|\|target_AP\|\|STA) • WLC distributes PMK to all APs • No 802.11r needed • Works with: WPA2/WPA3 Enterprise 3. ERP (RFC 6696, different auth server): • rRK derived after first EAP success • Fast re-auth via EAP-Initiate/Re-auth • rMSK → PMK for new AP • Works across different WLCs if same ERP domain 4. 802.11r FT (over-air or over-DS): • PMK-R0 → PMK-R1 → PTK without 4-way HS • Fastest: target <50ms • Requires 802.11r support on AP and client 5. FILS (combines ERP + in-frame key delivery): • Authentication + Association + Keys in 2 frames • Target: <100ms including IP address	Re-auth method selection matrix: • Same AP, repeat visit: PMKSA cache • Roaming within campus (same WLC): OKC or 802.11r • Cross-WLC roaming: ERP (if deployed) or full re-auth • IoT devices with simple association: PMKSA cache + short lifetime • High-mobility (voice/video): 802.11r FT mandatory (<50ms) • Next-gen deployment: FILS for all (requires 802.11ai-capable APs)	Latency comparison: Full EAP + 4WHS: 300-500ms PMKSA cache (same AP): 30-80ms OKC roam: 50-100ms 802.11r FT: <50ms FILS: <100ms (including IP assignment)

ADDITIONAL NETWORK PROTOCOL DETAILS - 802.11v BSS TM, IPv6 RA Guard, Multicast policies4 rows#

Topic	Standard	Description	Key Messages / Protocol Flow	Engineering Notes
802.11v BSS Transition Management Detail	IEEE 802.11-2020 §11.22.7 Wi-Fi Alliance BSS TM	BSS TM allows AP to steer clients to better APs. Avoids sticky-client problem. AP sends BSS TM Request → client may comply or reject. AP can set 'Disassociation Imminent' bit to force move.	1. AP sends BSS TM Request (Action Cat=10, Code=7): includes Candidate List (BSSID + RSSI + channel), Disassociation Timer, Disassociation Imminent bit 2. STA sends BSS TM Response: Status 0=accepted, 1=reject (no reason), 2=reject (no suitable candidates) 3. If accepted: STA roams within Disassociation Timer 4. If rejected and Disassociation Imminent=1: AP sends Disassoc after timer BTM Accept rate KPI: should be >80% for healthy WLAN	Sticky client fix: set Disassociation Imminent=1 + short timer (1-2s) as last resort. Monitor: dot11BSS TMRequestCount + dot11BSS TMResponseCount. Low accept rate = client doesn't support 802.11v or disagrees with AP steering decision. WPA3/Wi-Fi 6 certification requires 802.11v support.
Multicast-to-Unicast Policy Guidelines	IEEE 802.11-2020 §11.2.1.7 Vendor best practice	Multicast-to-unicast (M-to-U) conversion: AP converts each multicast frame to unicast for each client individually. Enables ACK and rate selection per client. Only practical for small group sizes.	Per-client unicast delivery: • Each client gets individual frame → ACK required → retransmit on failure • Rate selection: AP uses optimal MCS per client (vs one fixed multicast rate) • TXOP: each unicast uses dedicated TXOP Threshold recommendations: • Clients ≤ 30: M-to-U enabled • Clients 30-100: evaluate airtime impact • Clients > 100: disable M-to-U, use IGMP snooping + basic rate tuning instead Video streams: multicast at 24 Mbps basic rate vs unicast at MCS9 = 10× airtime saving per client	Always pair M-to-U with IGMP snooping (prevents unicast flood to non-members). mDNS/Bonjour is worst offender: Apple devices generate 20-40 mDNS/ARP packets per minute per device. At 200 devices = 4000-8000 pkt/min at basic rate. Use mDNS proxy to cache/suppress. Key metric: multicast PPS at AP radio → should be <50 pkt/s on healthy network.
CAPWAP Split-MAC Best Practices	RFC 5415/5416 Enterprise WLAN design	Recommended function placement for enterprise WLAN: Local MAC (at AP): • Beacon generation and transmission • Probe Req/Resp handling • 802.11 ACK and retransmission • Local data bridging for local SSID • 802.11 encryption/decryption (off-chip HW) Central MAC (at WLC): • User authentication (802.1X EAP relay) • DHCP assignment and IP policy • Firewall/ACL enforcement • Load balancing and band steering • PMKSA cache and key management (FT) • QoS policy enforcement • Rogue detection correlation	Modern trend: hybrid architecture per SSID policy. Corporate SSID: central MAC for security/visibility. IoT/Local SSID: local MAC for low-latency and WLC-bypass. Cloud-managed APs: local MAC everywhere (no WLC), policy from cloud. Performance: local MAC eliminates ~2ms RTT overhead per 802.11 frame exchange. Critical for VoIP and gaming.
802.1X Identity Protection - EAP Phases	RFC 3748 §7.3 IEEE 802.1X-2020	Identity protection for 802.1X EAP methods: Phase 1 (outer identity): Sent in cleartext EAP-Response/Identity → Visible to anyone on the wireless medium → Should use anonymous outer identity: anonymous@realm.com Phase 2 (inner identity): Protected inside TLS tunnel (PEAP/TTLS/FAST) → Actual username sent encrypted inside tunnel → Not visible to passive observers Risk without anonymous outer identity: → Username harvesting for social engineering → SSID-correlation attacks (CVE-2023-52160) EAP-TLS: No inner identity needed (certificate = identity)	Configure anonymous outer identity on ALL PEAP/TTLS/FAST deployments. RADIUS policy: use User-Name attribute (inner, from tunnel) for authorization decisions. Calling-Station-Id (MAC) for device fingerprinting. Never rely on EAP outer identity (User-Name in Access-Request outer) for policy decisions.