IEEE 802.11f标准：多厂商接入点互操作性实践

需积分: 9 123 浏览量更新于2024-07-24 收藏 621KB PDF 举报

"IEEE 802.11f 是一个已撤销的 IEEE 标准，旨在促进多厂商之间的无线接入点（Access Point, AP）互操作性，通过一种跨分布系统的 Inter-Access Point Protocol（IAPP）实现，支持基于 IEEE 802.11 的操作。该标准在2003年发布，但在2006年被撤销。" 802.11f 标准是 IEEE 802.11 系列标准的一部分，它特别关注无线局域网（WLAN）中不同厂商设备间的互操作性问题。802.11 系列标准定义了无线局域网的通信规范，包括数据传输速率、频段、加密方式等。802.11f 的主要目标是解决接入点之间协作的问题，以确保在一个由多个厂商设备组成的网络环境中，它们能够无缝地协同工作。 IAPP（Inter-Access Point Protocol）是 802.11f 标准的核心，它提供了一种机制，允许接入点之间交换信息，例如网络状态、负载情况、漫游指导等，以提高整个网络的性能和用户移动时的连接体验。这种协议对于大型企业或公共场所的无线网络尤其重要，因为这些环境通常包含来自不同供应商的设备。然而，尽管 802.11f 提出了解决方案，但最终没有得到广泛采纳。可能的原因包括标准制定过程中的复杂性、实施难度、以及后来的 802.11h 和 802.11i 等标准引入了更紧急的安全和管理特性。这些标准在 802.11f 撤销前发布，使得 802.11f 的需求变得不再紧迫。因此，2006 年，IEEE 决定撤销该标准，不再推荐使用。尽管 802.11f 已经不再有效，但它在无线网络技术发展史上占据一席之地，体现了行业对提升无线网络设备兼容性和性能的持续探索。随着 802.11 系列标准的不断演进，如 802.11ac、802.11ax（也称为 Wi-Fi 6），无线网络的互操作性和性能得到了显著提升，满足了日益增长的高速、低延迟的无线连接需求。

IEEE Trial-Use Recommended Practice

for Multi-Vendor Access Point

Interoperability via an Inter-Access

Point Protocol Across Distribution

Systems Supporting IEEE 802.11™

Operation

1. Overview

1.1 Scope

The scope of this document is to describe recommended practices for implementation of an Inter-Access

Point Protocol (IAPP) on a Distribution System (DS) supporting ISO/IEC 8802-11:1999 and IEEE 802.11™

wireless local access network (WLAN) links. The recommended DS utilizes an IAPP that provides the nec-

essary capabilities to achieve multi-vendor Access Point (AP) interoperability within the DS. This IAPP is

described for a DS consisting of IEEE 802

LAN components utilizing an Internet Engineering Task Force

(IETF) Internet Protocol (IP) environment. Throughout this recommended practice, the terms

ISO/IEC

8802-11:1999

IEEE 802.11

802.11™

, and

IEEE Std 802.11™-1999

are used interchangeably to refer to

the same document, ISO/IEC 8802-11:1999, and its amendments and supplements published at the time this

recommended practice was adopted.

1.2 Purpose

IEEE 802.11 speciﬁes the MAC and PHY layers of a WLAN system and includes the basic architecture of

such systems, including the concepts of APs and DSs. Implementations of these concepts were purposely not

deﬁned by IEEE 802.11 because there are many ways to create a WLAN system. Additionally, many of the

possible implementation approaches involve higher network layers. While this leaves great ﬂexibility in DS

and AP functional design, the associated cost is that physical AP devices are unlikely to interoperate across a

DS. In particular, the enforcement of the restriction that a station (STA) has a single association at a given

time is unlikely to be achieved.

As IEEE 802.11 systems have grown in popularity, it has become clear that there are a small number of DS

environments that comprise the bulk of the commercial and private WLAN system installations.

WITHDRAWN WITHDRAWN

IEEE

Std 802.11F-2003 MULTI-VENDOR ACCESS POINT INTEROPERABILITY VIA AN IAPP

This recommended practice speciﬁes the information to be exchanged between APs amongst themselves and

higher-layer management entities to support the 802.11 DS functions. The information exchanges are speci-

ﬁed for DSs built on the IETF IP in a manner sufﬁcient to enable the interoperation of DSs containing APs

from different vendors that adhere to the recommended practice.

1.3 Inter-AP recommended practice overview

This recommended practice describes a service access point (SAP), service primitives, a set of functions and

a protocol that will allow APs to interoperate on a common DS, using the Transmission Control Protocol

over IP (TCP/IP) or User Datagram Protocol over IP (UDP/IP) to carry IAPP packets between APs, as well

as describing the use of the Remote Authentication Dial-in User Service (RADIUS) Protocol, so APs may

obtain information about one another. A proactive caching mechanism is also described that provides faster

roaming times by sending STA context to neighboring APs. The devices in a network that might use the

IAPP are 802.11 APs. Other devices in a network that are affected by the operation of the IAPP are layer 2

networking devices, such as bridges and switches.

Throughout this recommended practice, reference is made to an “AP management entity (APME).” These

are references to a function that is external to the IAPP, though likely still a function of the AP device.

Typically, this management entity is the main operational program of the AP, implementing an AP manufac-

turer’s proprietary features and algorithms, and incorporating the station management entity (SME) of

802.11. Figure 1 depicts an architecture of a typical AP in which the IAPP operates. The grey areas indicate

areas where there is an absence of connection between blocks. The IAPP services are accessed by the APME

through the IAPP SAP. The IAPP SAP is shown in Figure 1, as the small block between the APME and the

IAPP blocks. IAPP service primitives are deﬁned that allow the AP management entity to cause the IAPP to

perform some function or to communicate with other APs in the DS or with a RADIUS server. Other service

primitives indicate to the AP management entity that operations have taken place at other APs in the DS that

can have an effect on information local to the AP.

The invocation of some IAPP service primitives relies on the RADIUS protocol to implement certain func-

tions that are required for the correct and secure operation of the IAPP. In particular, the IAPP entity must be

able to ﬁnd and use a RADIUS server to look up the IP addresses of other APs in the ESS when given the

Basic Service Set Identiﬁer (BSSIDs) of those other APs (if a local capability to perform such a translation is

not present), and to obtain security information to protect the content of certain IAPP packets. The RADIUS

server must provide extensions for IAPP-speciﬁc operations. There is currently work being performed in the

IETF on RADIUS client conﬁguration. Refer to RADIUS Client Kickstart by Robert Moskowitz

on the

topic. This work may be useful in conjunction with this recommended practice.

Information on references can be found in Clause 2.

WITHDRAWN WITHDRAWN

IEEE

ACROSS DISTRIBUTION SYSTEMS SUPPORTING IEEE 802.11 OPERATION Std 802.11F-2003

The IAPP is not a routing protocol. The IAPP does not deal directly with the delivery of 802.11 data frames

to the STA; instead the DS utilizes existing network functionality for data frame delivery. The data delivery

service of the DS will function as desired when the STAs maintain a network layer address, e.g., IP address,

or addresses that are valid for their point of connection to the network, i.e., when a STA associates or reasso-

ciates, the STA must ascertain that its network layer address(es) is conﬁgured such that the normal routing

functions of the network attaching to the BSS will correctly deliver the STA’s trafﬁc to the BSS to which it is

associated. If the mobile device incorporating the STA determines that the network layer address(es) is not

conﬁgured so as to allow the normal routing functions of the network to deliver the STA’s trafﬁc to the BSS

to which it is associated, the STA must obtain such an address(es), before any network trafﬁc can be deliv-

ered to it. A STA can meet the local IP address requirement in many ways. Two mechanisms for a STA to

accomplish this are to renew a Dynamic Host Conﬁguration Protocol (DHCP) lease for its IP address and to

use Mobile IP to obtain a local IP address. Other mechanisms are possible that meet this requirement.

With the requirement that STAs maintain a valid network layer address, APs function much the same as

IEEE 802.1D™ bridges. Additionally, the IAPP supports the following functions:

— DS Services, as deﬁned in ISO/IEC 8802-11:1999.

— Address mapping of wireless medium addresses of APs (their BSSID) to DS network layer addresses

(IP addresses).

— Formation of a DS.

— Maintenance of the DS.

— Enforcement of the restriction of ISO/IEC 8802-11:1999 that a STA may have only a single associa-

tion at any given time.

— Transfer of STA context information between APs.

APME

IAPP SAP

Srvice

MAC

IAPP

RADIUS Client

UDP/TCP

ESP

802.2

D Se s

DSM MAC

MLME

DSM PHY

PHY

PLME

Figure 1—AP architecture with IAPP

WITHDRAWN WITHDRAWN

IEEE

Std 802.11F-2003 MULTI-VENDOR ACCESS POINT INTEROPERABILITY VIA AN IAPP

IAPP transactions are over the DS. Hence, IAPP is independent of the security scheme deﬁned in ISO/IEC

8802-11:1999.

This recommended practice makes use of the IETF RFCs listed in Clause 2 to implement many of its func-

tions. It also relies on a STA making use of the 802.11 Reassociation Request frame when roaming from one

AP to another, in order to provide the most complete services to the APs using the IAPP. When a STA uses

the 802.11 Association Request, rather than the Reassociation Request, the IAPP may not be able to notify

the AP at which the STA was previously associated of the new association. This may result in the old AP

(indicated in the “current AP” ﬁeld of the reassociation request frame) maintaining context for the STA that

has roamed to a new AP for a longer time than is strictly necessary. This may cause undue waste of resources

at the old AP, as well as limiting the ability of the IAPP to help enforce the single STA association require-

ment of 802.11.

One issue that AP designers should address that can cause signiﬁcant problems in a WLAN is the continued

operation of an AP when it has lost its link to the DS. When an AP continues to accept associations without

a link to the DS, it is a black hole in the WLAN, where STAs associate and cannot communicate with

anything beyond the AP’s BSS. When an AP loses its link to the DS, it should cease transmitting Beacons,

disassociate all associated stations, and cease responding to Probe Request, Authentication, and Association

Request frames.

1.4 Inter-AP security risks

Inter-AP communications present opportunities to an attacker. The attacker can use IAPP or forged 802.11

MAC management frames as a Denial-of-Service (DoS) attack against a STA state in its AP. It can capture

MOVE packets to gather information on the STA that is roaming. It can act as a rogue AP in the ESS.

A bogus MOVE or ADD-Notify might cause an AP to drop all state it has with a STA. Since these IAPP

packets are transmitted over IP, they could be introduced anywhere, from any device that has the necessary

knowledge. This attack can best be eliminated by providing packet authentication to all MOVE and ADDs.

The protection for the MOVEs can be provided by IP Encapsulating Security Payload (ESP) (RFC

2406:1998) pair-wise Security Associations (SA). The protection for the ADDs requires a group ESP SA.

The content of the MOVE can be encrypted by the same ESP pair-wise SAs, protecting it from scrutiny of an

attacker.

The use of ESP with RADIUS for the Key Management provides for discovery of Rogue APs. The use of

ESP for IAPP MOVEs prevents a STA from roaming from a Rogue AP to a valid AP in the ESS. It also

blocks the move of the STA context information to a Rogue AP if the STA roams to it. The RADIUS Access-

Request provides the RADIUS server with knowledge of the presence of a Rogue AP.

2. References

The following standards contain provisions which, through references in this text, constitute provisions of

this recommended practice. At the time of publication, the editions indicated were valid. All standards are

subject to revision. When a standard is superceded by an approved revision, the revision applies.

IEEE Std 802.11, 1999 Edition (R2003) (ISO/IEC 8802-11: 1999), IEEE Standard for Information Technol-

ogy—Telecommunications and Information Exchange between Systems—Local and Metropolitan Area

Network—Speciﬁc Requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical

Layer (PHY) Speciﬁcations.

The IEEE standards referred to in Clause 2 are trademarks belonging to the Institute of Electrical and Electronics Engineers, Inc.

IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway,

NJ 08855-1331, USA (http://www.standards.ieee.org/).

WITHDRAWN WITHDRAWN

剩余78页未读，继续阅读

天行健君子自强不息

粉丝: 1
资源: 3

IEEE 802.11f标准：多厂商接入点互操作性实践

802.11 in Linux

802.11ax draft6.0.pdf

IEEE_802.11.rar_802.11_802.11 beacon_WiFi probe_beacon_cardr7v

NS-Mac-802_11-Document-Public_Release.rar_802.11 ns2_MAC层协议_mac协

IEEE 802.11 Tutorial

IEEE802.16.rar_802.16_802.16m _IEEE 802.16_IEEE 802.16m_evaluati

802.11e-presentation

Draft P802.11ax_D3.0.pdf

802.11 WLAN Roaming and Fast-Secure

Draft P802.11ax_D6.0

最新资源