Network Working Group J. Arkko
Request for Comments: 5113 Ericsson
Category: Informational B. Aboba
Microsoft
J. Korhonen, Ed.
TeliaSonera
F. Bari
AT&T
January 2008
Network Working Group J. Arkko
Request for Comments: 5113 Ericsson
Category: Informational B. Aboba
Microsoft
J. Korhonen, Ed.
TeliaSonera
F. Bari
AT&T
January 2008
Network Discovery and Selection Problem
网络发现与选择问题
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
When multiple access networks are available, users may have difficulty in selecting which network to connect to and how to authenticate with that network. This document defines the network discovery and selection problem, dividing it into multiple sub-problems. Some constraints on potential solutions are outlined, and the limitations of several solutions (including existing ones) are discussed.
当多址网络可用时，用户可能难以选择连接到哪个网络以及如何通过该网络进行身份验证。本文档定义了网络发现和选择问题，将其划分为多个子问题。概述了潜在解决方案的一些限制，并讨论了几种解决方案（包括现有解决方案）的局限性。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology Used in This Document . . . . . . . . . . . . 4
2. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Discovery of Points of Attachment . . . . . . . . . . . . 8
2.2. Identity Selection . . . . . . . . . . . . . . . . . . . . 9
2.3. AAA Routing . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1. The Default Free Zone . . . . . . . . . . . . . . . . 13
2.3.2. Route Selection and Policy . . . . . . . . . . . . . . 14
2.3.3. Source Routing . . . . . . . . . . . . . . . . . . . . 15
2.4. Network Capabilities Discovery . . . . . . . . . . . . . . 17
3. Design Issues . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1. AAA Routing . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Backward Compatibility . . . . . . . . . . . . . . . . . . 18
3.3. Efficiency Constraints . . . . . . . . . . . . . . . . . . 19
3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 19
3.5. Static Versus Dynamic Discovery . . . . . . . . . . . . . 21
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.7. Management . . . . . . . . . . . . . . . . . . . . . . . . 22
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. Informative References . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Existing Work . . . . . . . . . . . . . . . . . . . . 32
A.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.2. IEEE 802 . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.3. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.4. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 37
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology Used in This Document . . . . . . . . . . . . 4
2. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Discovery of Points of Attachment . . . . . . . . . . . . 8
2.2. Identity Selection . . . . . . . . . . . . . . . . . . . . 9
2.3. AAA Routing . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1. The Default Free Zone . . . . . . . . . . . . . . . . 13
2.3.2. Route Selection and Policy . . . . . . . . . . . . . . 14
2.3.3. Source Routing . . . . . . . . . . . . . . . . . . . . 15
2.4. Network Capabilities Discovery . . . . . . . . . . . . . . 17
3. Design Issues . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1. AAA Routing . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Backward Compatibility . . . . . . . . . . . . . . . . . . 18
3.3. Efficiency Constraints . . . . . . . . . . . . . . . . . . 19
3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 19
3.5. Static Versus Dynamic Discovery . . . . . . . . . . . . . 21
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.7. Management . . . . . . . . . . . . . . . . . . . . . . . . 22
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. Informative References . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Existing Work . . . . . . . . . . . . . . . . . . . . 32
A.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.2. IEEE 802 . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.3. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.4. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 37
Today, network access clients are typically pre-configured with a list of access networks and corresponding identities and credentials. However, as network access mechanisms and operators have proliferated, it has become increasingly likely that users will encounter networks for which no pre-configured settings are available, yet which offer desired services and the ability to successfully authenticate with the user's home realm. It is also possible that pre-configured settings will not be adequate in some situations. In such a situation, users can have difficulty in determining which network to connect to, and how to authenticate to that network.
如今，网络访问客户端通常预先配置了访问网络列表以及相应的身份和凭据。然而，随着网络访问机制和运营商的激增，用户越来越可能遇到没有预配置设置的网络，但这些网络提供了所需的服务，并且能够成功地通过用户的家庭域进行身份验证。在某些情况下，预配置的设置也可能不充分。在这种情况下，用户很难确定要连接到哪个网络，以及如何对该网络进行身份验证。
The problem arises when any of the following conditions are true:
当下列任一条件为真时，就会出现问题：
o Within a single network, more than one network attachment point is available, and the attachment points differ in their roaming arrangements, or access to services. While the link layer capabilities of a point of attachment may be advertised, higher-layer capabilities, such as roaming arrangements, end-to-end quality of service, or Internet access restrictions, may not be. As a result, a user may have difficulty determining which services are available at each network attachment point, and which attachment points it can successfully authenticate to. For example, it is possible that a roaming agreement will only enable a user to authenticate to the home realm from some points of attachment, but not others. Similarly, it is possible that access to the Internet may be restricted at some points of attachment, but not others, or that end-to-end quality of service may not be available in all locations. In these situations, the network access client cannot assume that all points of attachment within a network offer identical capabilities.
o 在单个网络中，有多个网络连接点可用，并且连接点在漫游安排或对服务的访问方面有所不同。虽然可以公布连接点的链路层能力，但是可以不公布更高层能力，例如漫游安排、端到端服务质量或因特网访问限制。结果，用户可能难以确定在每个网络连接点上哪些服务可用，以及它可以成功地对哪些连接点进行身份验证。例如，漫游协议可能只允许用户从某些连接点（而不是其他连接点）向主域进行身份验证。同样，可能在某些连接点限制对互联网的访问，但在其他连接点不限制，或者可能无法在所有位置提供端到端的服务质量。在这些情况下，网络访问客户端不能假定网络中的所有连接点都提供相同的功能。
o Multiple networks are available for which the user has no corresponding pre-configuration. The user may not have pre-configured an identity and associated credentials for use with a network, yet it is possible that the user's home realm is reachable from that network, enabling the user to successfully authenticate. However, unless the roaming arrangements are advertised, the network access client cannot determine a priori whether successful authentication is likely. In this situation, it is possible that the user will need to try multiple networks in order to find one to which it can successfully authenticate, or it is possible that the user will not be able to obtain access at all, even though successful authentication is feasible.
o 多个网络可用，用户没有相应的预配置。用户可能没有预先配置用于网络的身份和相关凭据，但是用户的主域可能可以从该网络访问，从而使用户能够成功地进行身份验证。然而，除非漫游安排被通告，否则网络接入客户端不能先验地确定是否可能成功认证。在这种情况下，用户可能需要尝试多个网络以找到一个可以成功认证的网络，或者即使成功认证是可行的，用户也可能根本无法获得访问权。
o The user has multiple sets of credentials. Where no pre-configuration exists, it is possible that the user will not be able to determine which credentials to use with which attachment point, or even whether any credentials it possesses will allow it to authenticate successfully. An identity and associated credentials can be usable for authentication with multiple networks, and not all of these networks will be pre-configured. For example, the user could have one set of credentials from a public service provider and another set from an employer, and a network might enable authentication with one or more of these credentials. Yet, without pre-configuration, multiple unsuccessful authentication attempts could be needed for each attachment point in order to determine what credentials are usable, wasting valuable time and resulting in user frustration. In order to choose between multiple attachment points, it can be helpful to provide additional information to enable the correct credentials to be determined.
o 用户具有多组凭据。在不存在预配置的情况下，用户可能无法确定使用哪个连接点的凭据，甚至无法确定其拥有的任何凭据是否允许其成功进行身份验证。身份和相关凭据可用于多个网络的身份验证，并且并非所有这些网络都将预先配置。例如，用户可以拥有来自公共服务提供商的一组凭据和来自雇主的另一组凭据，并且网络可以使用这些凭据中的一个或多个启用身份验证。然而，如果没有预配置，每个连接点可能需要多次不成功的身份验证尝试，以确定哪些凭据可用，这浪费了宝贵的时间，并导致用户失望。为了在多个连接点之间进行选择，可以提供其他信息以确定正确的凭据。
o There are multiple potential roaming paths between the visited realm and the user's home realm, and service parameters or pricing differs between them. In this situation, there could be multiple ways for the user to successfully authenticate using the same identity and credentials, yet the cost of each approach might differ. In this case, the access network may not be able to determine the roaming path that best matches the user's preferences. This can lead to the user being charged more than necessary, or not obtaining the desired services. For example, the visited access realm could have both a direct relationship with the home realm and an indirect relationship through a roaming consortium. Current Authentication, Authorization, and Accounting (AAA) protocols may not be able to route the access request to the home AAA sever purely based on the realm within the Network Access Identifier (NAI) [RFC4282]. In addition, payload packets can be routed or tunneled differently, based on the roaming relationship path. This may have an impact on the available services or their pricing.
o 在访问的域和用户的主域之间存在多个潜在漫游路径，并且它们之间的服务参数或定价不同。在这种情况下，用户可以通过多种方式使用相同的身份和凭据成功进行身份验证，但每种方法的成本可能不同。在这种情况下，接入网络可能无法确定最符合用户偏好的漫游路径。这可能导致用户被收取超过必要的费用，或无法获得所需的服务。例如，访问的访问域可能与主域有直接关系，也可能通过漫游联盟有间接关系。当前的身份验证、授权和计费（AAA）协议可能无法纯粹基于网络访问标识符（NAI）内的域将访问请求路由到家庭AAA服务器[RFC4282]。此外，根据漫游关系路径，有效负载数据包可以以不同的方式路由或隧道。这可能会对可用服务或其定价产生影响。
In Section 2, the network discovery and selection problem is defined and divided into sub-problems. Some solution constraints are outlined in Section 3. Section 4 provides conclusions and suggestions for future work. Appendix A discusses existing solutions to portions of the problem.
在第2节中，定义了网络发现和选择问题，并将其划分为子问题。第3节概述了一些解决方案约束。第4节为今后的工作提供了结论和建议。附录A讨论了部分问题的现有解决方案。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Authentication, Authorization, and Accounting (AAA)
身份验证、授权和记帐（AAA）
AAA protocols with EAP support include Remote Authentication Dial-In User Service (RADIUS) [RFC3579] and Diameter [RFC4072].
支持EAP的AAA协议包括远程身份验证拨入用户服务（RADIUS）[RFC3579]和Diameter[RFC4072]。
Access Point (AP)
接入点（AP）
An entity that has station functionality and provides access to distribution services via the wireless medium (WM) for associated stations.
具有站点功能并通过无线媒体（WM）为相关站点提供对分发服务的访问的实体。
Access Technology Selection
接入技术选择
This refers to the selection between access technologies, e.g., 802.11, Universal Mobile Telecommunications System (UMTS), WiMAX. The selection will be dependent upon the access technologies supported by the device and the availability of networks supporting those technologies.
这是指接入技术之间的选择，例如802.11、通用移动通信系统（UMTS）、WiMAX。选择将取决于设备支持的接入技术以及支持这些技术的网络的可用性。
Bearer Selection
承载选择
For some access technologies (e.g., UMTS), there can be a possibility for delivery of a service (e.g., voice) by using either a circuit-switched or packet-switched bearer. Bearer selection refers to selecting one of the bearer types for service delivery. The decision can be based on support of the bearer type by the device and the network as well as user subscription and operator preferences.
对于一些接入技术（例如，UMTS），可以通过使用电路交换或分组交换承载来交付服务（例如，语音）。承载选择是指选择其中一种承载类型进行服务交付。该决定可以基于设备和网络对承载类型的支持以及用户订阅和运营商偏好。
Basic Service Set (BSS)
基本服务集（BSS）
A set of stations controlled by a single coordination function.
由单一协调功能控制的一组站点。
Decorated NAI
装饰奈
A NAI specifying a source route. See Section 2.7 of RFC 4282 [RFC4282] for more information.
指定源路由的NAI。更多信息，请参见RFC 4282[RFC4282]第2.7节。
Extended Service Set (ESS)
扩展服务集（ESS）
A set of one or more interconnected basic service sets (BSSs) with the same Service Set Identifier (SSID) and integrated local area networks (LANs), which appears as a single BSS to the logical link control layer at any station associated with one of those BSSs. This refers to a mechanism that a node uses to discover the networks that are reachable from a given access network.
一组具有相同服务集标识符（SSID）和集成局域网（LAN）的一个或多个互连基本服务集（BSS），在与其中一个BSS相关联的任何站点的逻辑链路控制层显示为单个BSS。这是指节点用于发现可从给定接入网络访问的网络的机制。
Network Access Identifier (NAI)
网络访问标识符（NAI）
The Network Access Identifier (NAI) [RFC4282] is the user identity submitted by the client during network access authentication. In roaming, the purpose of the NAI is to identify the user as well as to assist in the routing of the authentication request. Please note that the NAI may not necessarily be the same as the user's e-mail address or the user identity submitted in an application layer authentication.
网络访问标识符（NAI）[RFC4282]是客户端在网络访问身份验证期间提交的用户标识。在漫游中，NAI的目的是识别用户以及协助认证请求的路由。请注意，NAI不一定与应用层身份验证中提交的用户电子邮件地址或用户身份相同。
Network Access Server (NAS)
网络访问服务器（NAS）
The device that peers connect to in order to obtain access to the network. In Point-to-Point Tunneling Protocol (PPTP) terminology, this is referred to as the PPTP Access Concentrator (PAC), and in Layer 2 Tunneling Protocol (L2TP) terminology, it is referred to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it is referred to as an Access Point (AP).
对等方为了访问网络而连接到的设备。在点对点隧道协议（PPTP）术语中，这称为PPTP访问集中器（PAC），在第二层隧道协议（L2TP）术语中，这称为L2TP访问集中器（LAC）。在IEEE 802.11中，它被称为接入点（AP）。
Network Discovery
网络发现
The mechanism used to discover available networks. The discovery mechanism may be passive or active, and depends on the access technology. In passive network discovery, the node listens for network announcements; in active network discovery, the node solicits network announcements. It is possible for an access technology to utilize both passive and active network discovery mechanisms.
用于发现可用网络的机制。发现机制可以是被动的，也可以是主动的，并且取决于接入技术。在被动网络发现中，节点监听网络公告；在主动网络发现中，节点请求网络公告。接入技术可以同时利用被动和主动网络发现机制。
Network Selection
网络选择
Selection of an operator/ISP for network access. Network selection occurs prior to network access authentication.
选择网络访问的运营商/ISP。网络选择发生在网络访问身份验证之前。
Realm
领域
The realm portion of an NAI [RFC4282].
NAI的领域部分[RFC4282]。
Realm Selection
领域选择
The selection of the realm (and corresponding NAI) used to access the network. A realm can be reachable from more than one access network type, and selection of a realm may not enable network capabilities.
选择用于访问网络的领域（以及相应的NAI）。一个领域可以从多个访问网络类型访问，选择一个领域可能无法启用网络功能。
Roaming Capability
漫游能力
Roaming capability can be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support.
漫游能力可以粗略地定义为能够使用多个互联网服务提供商（ISP）中的任何一个，同时只与一个ISP保持正式的客户-供应商关系。可能需要漫游功能的案例包括ISP“联盟”和ISP提供的公司网络访问支持。
Station (STA)
车站（STA）
A device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM).
包含符合IEEE 802.11的媒体访问控制（MAC）和无线媒体（WM）的物理层（PHY）接口的设备。
The network discovery and selection problem can be broken down into multiple sub-problems. These include:
网络发现和选择问题可以分解为多个子问题。这些措施包括：
o Discovery of points of attachment. This involves the discovery of points of attachment in the vicinity, as well as their capabilities.
o 发现附着点。这包括在附近发现附着点及其能力。
o Identifier selection. This involves selection of the NAI (and credentials) used to authenticate to the selected point of attachment.
o 标识符选择。这涉及到选择用于对所选连接点进行身份验证的NAI（和凭据）。
o AAA routing. This involves routing of the AAA conversation back to the home AAA server, based on the realm of the selected NAI.
o AAA路由。这涉及根据所选NAI的领域将AAA会话路由回家庭AAA服务器。
o Payload routing. This involves the routing of data packets, in the situation where mechanisms more advanced than destination-based routing are required. While this problem is interesting, it is not discussed further in this document.
o 有效载荷路由。在需要比基于目的地的路由更高级的机制的情况下，这涉及到数据包的路由。虽然这个问题很有趣，但在本文档中不作进一步讨论。
o Network capability discovery. This involves discovering the capabilities of an access network, such as whether certain services are reachable through the access network and the charging policy.
o 网络能力发现。这涉及发现接入网络的能力，例如是否可以通过接入网络访问某些服务以及收费策略。
Alternatively, the problem can be divided into discovery, decision, and selection components. The AAA routing problem, for instance, involves all components: discovery (which mediating networks are available), decision (choosing the "best" one), and selection (selecting which mediating network to use) components.
或者，问题可以分为发现、决策和选择组件。例如，AAA路由问题涉及所有组件：发现（哪些中介网络可用）、决策（选择“最佳”一个）和选择（选择使用哪个中介网络）组件。
Traditionally, the discovery of points of attachment has been handled by out-of-band mechanisms or link or network layer advertisements.
传统上，连接点的发现由带外机制或链路或网络层广告处理。
RFC 2194 [RFC2194] describes the pre-provisioning of dial-up roaming clients, which typically included a list of potential phone numbers updated by the provider(s) with which the client had a contractual relationship. RFC 3017 [RFC3017] describes the IETF Proposed Standard for the Roaming Access eXtensible Markup Language (XML) Document Type Definition (DTD). This covers not only the attributes of the Points of Presence (PoP) and Internet Service Providers (ISPs), but also hints on the appropriate NAI to be used with a particular PoP. The XML DTD supports dial-in and X.25 access, but has extensible address and media type fields.
RFC 2194[RFC2194]描述了拨号漫游客户端的预配置，其中通常包括由与客户端有合同关系的提供商更新的潜在电话号码列表。RFC 3017[RFC3017]描述了IETF提出的漫游访问可扩展标记语言（XML）文档类型定义（DTD）标准。这不仅包括存在点（PoP）和互联网服务提供商（ISP）的属性，还包括与特定PoP一起使用的适当NAI的提示。XML DTD支持拨入和X.25访问，但具有可扩展的地址和媒体类型字段。
As access networks and the points of attachment have proliferated, out-of-band pre-configuration has become increasingly difficult. For networks with many points of attachment, keeping a complete and up-to-date list of points of attachment can be difficult. As a result, wireless network access clients typically only attempt to pre-configure information relating to access networks, rather than individual points of attachment.
随着接入网络和连接点的激增，带外预配置变得越来越困难。对于具有多个连接点的网络，保存完整且最新的连接点列表可能很困难。因此，无线网络接入客户端通常只尝试预先配置与接入网络相关的信息，而不是单独的连接点。
In IEEE 802.11 Wireless Local Area Networks (WLAN), the Beacon and Probe Request/Response mechanism provides a way for Stations to discover Access Points (AP) and the capabilities of those APs. The IEEE 802.11 specification [IEEE.802.11-2003] provides support for both passive (Beacon) and active (Probe Request/Response) discovery mechanisms; [Fixingapsel] studied the effectiveness of these mechanisms.
在IEEE 802.11无线局域网（WLAN）中，信标和探测请求/响应机制为站点发现接入点（AP）和这些AP的能力提供了一种方法。IEEE 802.11规范[IEEE.802.11-2003]提供了对被动（信标）和主动（探测请求/响应）发现机制的支持；[Fixingapsel]研究了这些机制的有效性。
Among the Information Elements (IE) included within the Beacon and Probe Response is the Service Set Identifier (SSID), a non-unique identifier of the network to which an AP is attached. The Beacon/ Probe facility therefore enables network discovery, as well as the discovery of points of attachment and the capabilities of those points of attachment.
信标和探测响应中包括的信息元素（IE）中包括服务集标识符（SSID），该标识符是AP连接到的网络的非唯一标识符。因此，信标/探测设施可以实现网络发现，以及连接点的发现和这些连接点的功能。
The Global System for Mobile Communications (GSM) specifications also provide for discovery of points of attachment, as does the Candidate Access Router Discovery (CARD) [RFC4066] protocol developed by the IETF SEAMOBY Working Group (WG).
全球移动通信系统（GSM）规范还规定了连接点的发现，IETF SEAMOBY工作组（WG）开发的候选接入路由器发现（卡）[RFC4066]协议也是如此。
Along with discovery of points of attachment, the capabilities of access networks are also typically discovered. These may include:
随着连接点的发现，接入网络的功能通常也会被发现。这些措施可能包括：
o Access network name (e.g., IEEE 802.11 SSID)
o 接入网络名称（如IEEE 802.11 SSID）
o Lower layer security mechanism (e.g., IEEE 802.11 Wired Equivalent Privacy (WEP) vs. Wi-Fi Protected Access 2 (WPA2))
o 低层安全机制（例如，IEEE 802.11有线等效隐私（WEP）与Wi-Fi保护访问2（WPA2））
o Quality of service capabilities (e.g., IEEE 802.11e support)
o 服务质量能力（例如，IEEE 802.11e支持）
o Bearer capabilities (e.g., circuit-switched, packet-switched, or both)
o 承载能力（例如，电路交换、分组交换或两者兼有）
Even though pre-configuration of access networks scales better than pre-configuration of points of attachment, where many access networks can be used to authenticate to a home realm, providing complete and up-to-date information on each access network can be challenging.
尽管接入网络的预配置比连接点的预配置具有更好的扩展性，其中许多接入网络可用于对家庭领域进行身份验证，但提供每个接入网络的完整和最新信息可能是一项挑战。
In such a situation, network access client configuration can be minimized by providing information relating to each home realm, rather than each access network. One way to enable this is for an access network to support "virtual Access Points" (virtual APs), and for each point of attachment to support virtual APs corresponding to each reachable home realm.
在这种情况下，可以通过提供与每个家庭领域（而不是每个接入网络）相关的信息来最小化网络接入客户端配置。实现这一点的一种方法是接入网络支持“虚拟接入点”（虚拟AP），每个连接点支持对应于每个可到达家庭领域的虚拟AP。
While a single IEEE 802.11 network may only utilize a single SSID, it may cover a wide geographical area, and as a result, may be segmented, utilizing multiple prefixes. It is possible that a single SSID may be advertised on multiple channels, and may support multiple access mechanisms (including Universal Access Method (UAM) and IEEE 802.1X [IEEE.8021X-2004]) which may differ between points of attachment. A single SSID may also support dynamic VLAN access as described in [RFC3580], or may support authentication to multiple home AAA servers supporting different realms. As a result, users of a single point of attachment, connecting to the same SSID, may not have the same set of services available.
虽然单个IEEE 802.11网络可能仅利用单个SSID，但它可能覆盖广泛的地理区域，因此，可以利用多个前缀进行分段。单个SSID可能在多个信道上进行广告，并且可能支持多个接入机制（包括通用接入方法（UAM）和IEEE 802.1X[IEEE.8021X-2004]），这些机制可能在连接点之间有所不同。单个SSID还可以支持[RFC3580]中所述的动态VLAN访问，或者可以支持对支持不同领域的多个家庭AAA服务器的身份验证。因此，连接到同一SSID的单个连接点的用户可能没有相同的可用服务集。
As networks proliferate, it becomes more and more likely that a user may have multiple identities and credential sets, available for use in different situations. For example, the user may have an account with one or more Public WLAN providers, a corporate WLAN, and one or more wireless Wide Area Network (WAN) providers.
随着网络的发展，用户越来越可能拥有多个身份和凭证集，可用于不同的情况。例如，用户可以具有一个或多个公共WLAN提供商、公司WLAN和一个或多个无线广域网（WAN）提供商的帐户。
Typically, the user will choose an identity and corresponding credential set based on the selected network, perhaps with additional assistance provided by the chosen authentication mechanism. For example, if Extensible Authentication Protocol - Transport Layer Security (EAP-TLS) is the authentication mechanism used with a particular network, then the user will select the appropriate EAP-TLS
通常，用户将基于所选网络选择身份和相应的凭证集，可能由所选认证机制提供额外帮助。例如，如果可扩展身份验证协议-传输层安全性（EAP-TLS）是用于特定网络的身份验证机制，则用户将选择适当的EAP-TLS
client certificate based, in part, on the list of trust anchors provided by the EAP-TLS server.
部分基于EAP-TLS服务器提供的信任锚列表的客户端证书。
However, in access networks where roaming is enabled, the mapping between an access network and an identity/credential set may not be one to one. For example, it is possible for multiple identities to be usable on an access network, or for a given identity to be usable on a single access network, which may or may not be available.
但是，在启用漫游的接入网络中，接入网络和身份/凭证集之间的映射可能不是一对一的。例如，多个标识可以在接入网络上使用，或者给定标识可以在单个接入网络上使用，这可能是可用的，也可能是不可用的。
Figure 1 illustrates a situation where a user identity may not be usable on a potential access network. In this case, access network 1 enables access to users within the realm "isp1.example.com", whereas access network 3 enables access to users within the realm "corp2.example.com"; access network 2 enables access to users within both realms.
图1说明了一种情况，其中用户身份可能无法在潜在的接入网络上使用。在这种情况下，接入网络1允许访问“isp1.example.com”领域内的用户，而接入网络3允许访问“corp2.example.com”领域内的用户；接入网络2允许访问两个领域内的用户。
? ? +---------+ +------------------+
? | Access | | |
O_/ _-->| Network |------>|"isp1.example.com"|
/| / | 1 | _->| |
| | +---------+ / +------------------+
_/ \_ | /
| +---------+ /
User "subscriber@isp1. | | Access |/
example.com" -- ? -->| Network |
also known as | | 2 |\
"employee123@corp2. | +---------+ \
example.com" | \
| +---------+ \_ +-------------------+
\_ | Access | ->| |
-->| Network |------>|"corp2.example.com"|
| 3 | | |
+---------+ +-------------------+
? ? +---------+ +------------------+
? | Access | | |
O_/ _-->| Network |------>|"isp1.example.com"|
/| / | 1 | _->| |
| | +---------+ / +------------------+
_/ \_ | /
| +---------+ /
User "subscriber@isp1. | | Access |/
example.com" -- ? -->| Network |
also known as | | 2 |\
"employee123@corp2. | +---------+ \
example.com" | \
| +---------+ \_ +-------------------+
\_ | Access | ->| |
-->| Network |------>|"corp2.example.com"|
| 3 | | |
+---------+ +-------------------+
Figure 1: Two credentials, three possible access networks
图1：两个凭证，三个可能的访问网络
In this situation, a user only possessing an identity within the "corp2.example.com" realm can only successfully authenticate to access networks 2 or 3; a user possessing an identity within the "isp1.example.com" realm can only successfully authenticate to access networks 1 or 2; a user possessing identities within both realms can connect to any of the access networks. The question is: how does the user figure out which access networks it can successfully authenticate to, preferably prior to choosing a point of attachment?
在这种情况下，仅拥有“corp2.example.com”域中的身份的用户只能成功地对访问网络2或3进行身份验证；在“isp1.example.com”域中拥有身份的用户只能成功通过身份验证访问网络1或2；在这两个领域内拥有身份的用户可以连接到任何接入网络。问题是：在选择连接点之前，用户如何确定可以成功地对哪些接入网络进行身份验证？
Traditionally, hints useful in identity selection have been provided out-of-band. For example, the XML DTD, described in [RFC3017], enables a client to select between potential points of attachment as
传统上，身份选择中有用的提示是在带外提供的。例如，[RFC3017]中描述的XML DTD允许客户机根据需要在潜在的连接点之间进行选择
well as to select the NAI and credentials to use in authenticating with it.
以及选择NAI和用于验证的凭据。
Where all points of attachment within an access network enable authentication utilizing a set of realms, selection of an access network provides knowledge of the identities that a client can use to successfully authenticate. For example, in an access network, the set of supported realms corresponding to network name can be pre-configured.
当接入网络内的所有连接点启用利用一组领域的认证时，接入网络的选择提供了关于客户端可用于成功认证的身份的知识。例如，在接入网络中，可以预先配置与网络名称相对应的受支持领域集。
In some cases, it may not be possible to determine the available access networks prior to authentication. For example, [IEEE.8021X-2004] does not support network discovery on IEEE 802 wired networks, so that the peer cannot determine which access network it has connected to prior to the initiation of the EAP exchange.
在某些情况下，可能无法在认证之前确定可用的接入网络。例如，[IEEE.8021X-2004]不支持IEEE 802有线网络上的网络发现，因此对等方无法在启动EAP交换之前确定其已连接到哪个接入网络。
It is also possible for hints to be embedded within credentials. In [RFC4334], usage hints are provided within certificates used for wireless authentication. This involves extending the client's certificate to include the SSIDs with which the certificate can be used.
也可以在凭证中嵌入提示。在[RFC4334]中，在用于无线身份验证的证书中提供了使用提示。这涉及到扩展客户机的证书，以包括可以使用证书的SSID。
However, there may be situations in which an access network may not accept a static set of realms at every point of attachment. For example, as part of a roaming agreement, only points of attachment within a given region or country may be made available. In these situations, mechanisms such as hints embedded within credentials or pre-configuration of access network to realm mappings may not be sufficient. Instead, it is necessary for the client to discover usable identities dynamically.
然而，在某些情况下，接入网络可能无法在每个连接点接受一组静态域。例如，作为漫游协议的一部分，只能提供给定区域或国家/地区内的连接点。在这些情况下，凭据中嵌入的提示或访问网络到域映射的预配置等机制可能不够。相反，客户端需要动态地发现可用的身份。
This is the problem that RFC 4284 [RFC4284] attempts to solve, using the EAP-Request/Identity to communicate a list of supported realms. However, the problems inherent in this approach are many, as discussed in Appendix A.1.
这是RFC 4284[RFC4284]试图解决的问题，它使用EAP请求/标识来传递受支持领域的列表。然而，如附录A.1所述，该方法固有的问题很多。
Note that identity selection also implies selection of different credentials, and potentially, selection of different EAP authentication methods. In some situations this may imply serious security vulnerabilities. These are discussed in depth in Section 5.
请注意，标识选择还意味着选择不同的凭证，以及可能选择不同的EAP身份验证方法。在某些情况下，这可能意味着严重的安全漏洞。这些将在第5节中进行深入讨论。
Once the identity has been selected, the AAA infrastructure needs to route the access request back to the home AAA server. Typically, the routing is based on the Network Access Identifier (NAI) defined in [RFC4282].
一旦选择了身份，AAA基础设施需要将访问请求路由回家庭AAA服务器。通常，路由基于[RFC4282]中定义的网络访问标识符（NAI）。
Where the NAI does not encode a source route, the routing of requests is determined by the AAA infrastructure. As described in [RFC2194], most roaming implementations are relatively simple, relying on a static realm routing table that determines the next hop based on the NAI realm included in the User-Name attribute within the Access-Request. Within RADIUS, the IP address of the home AAA server is typically determined based on static mappings of realms to IP addresses maintained within RADIUS proxies.
如果NAI不编码源路由，则请求的路由由AAA基础设施确定。如[RFC2194]所述，大多数漫游实现相对简单，依赖于静态领域路由表，该表基于访问请求中用户名属性中包含的NAI领域确定下一跳。在RADIUS中，家庭AAA服务器的IP地址通常基于域到RADIUS代理中维护的IP地址的静态映射来确定。
Diameter [RFC3588] supports mechanisms for intra- and inter-domain service discovery, including support for DNS as well as service discovery protocols such as Service Location Protocol version 2 (SLPv2) [RFC2608]. As a result, it may not be necessary to configure static tables mapping realms to the IP addresses of Diameter agents. However, while this simplifies maintenance of the AAA routing infrastructure, it does not necessarily simplify roaming-relationship path selection.
Diameter[RFC3588]支持域内和域间服务发现机制，包括支持DNS以及服务发现协议，如服务位置协议版本2（SLPv2）[RFC2608]。因此，可能不需要配置将领域映射到Diameter代理的IP地址的静态表。然而，虽然这简化了AAA路由基础设施的维护，但并不一定简化了漫游关系路径选择。
As noted in RFC 2607 [RFC2607], RADIUS proxies are deployed not only for routing purposes, but also to mask a number of inadequacies in the RADIUS protocol design, such as the lack of standardized retransmission behavior and the need for shared secret provisioning between each AAA client and server.
如RFC 2607[RFC2607]中所述，部署RADIUS代理不仅用于路由目的，还用于掩盖RADIUS协议设计中的一些不足之处，例如缺乏标准化的重传行为以及每个AAA客户端和服务器之间需要共享秘密供应。
Diameter [RFC3588] supports certificate-based authentication (using either TLS or IPsec) as well as Redirect functionality, enabling a Diameter client to obtain a referral to the home server from a Diameter redirect server, so that the client can contact the home server directly. In situations in which a trust model can be established, these Diameter capabilities can enable a reduction in the length of the roaming relationship path.
Diameter[RFC3588]支持基于证书的身份验证（使用TLS或IPsec）以及重定向功能，使Diameter客户端能够从Diameter重定向服务器获得对家庭服务器的引用，以便客户端可以直接联系家庭服务器。在可以建立信任模型的情况下，这些Diameter功能可以减少漫游关系路径的长度。
However, in practice there are a number of pitfalls. In order for certificate-based authentication to enable communication between a Network Access Server (NAS) or local proxy and the home AAA server, trust anchors need to be configured, and certificates need to be selected. The AAA server certificate needs to chain to a trust anchor configured on the AAA client, and the AAA client certificate needs to chain to a trust anchor configured on the AAA server. Where multiple potential roaming relationship paths are available, this will reflect itself in multiple certificate choices, transforming the path selection problem into a certificate selection problem. Depending on the functionality supported within the certificate selection implementation, this may not make the problem easier to solve. For example, in order to provide the desired control over the roaming path, it may be necessary to implement custom certificate selection logic, which may be difficult to introduce within a
然而，在实践中存在一些陷阱。为了使基于证书的身份验证能够在网络访问服务器（NAS）或本地代理与家庭AAA服务器之间进行通信，需要配置信任锚，并且需要选择证书。AAA服务器证书需要链接到AAA客户端上配置的信任锚点，AAA客户端证书需要链接到AAA服务器上配置的信任锚点。如果有多个潜在的漫游关系路径可用，这将反映在多个证书选择中，从而将路径选择问题转化为证书选择问题。根据证书选择实现中支持的功能，这可能不会使问题更容易解决。例如，为了提供对漫游路径的所需控制，可能需要实现自定义证书选择逻辑，这可能很难在漫游路径中引入
certificate handling implementation designed for general-purpose usage.
证书处理实现设计用于一般用途。
As noted in [RFC4284], it is also possible to utilize an NAI for the purposes of source routing. In this case, the client provides guidance to the AAA infrastructure as to how it would like the access request to be routed. An NAI including source-routing information is said to be "decorated"; the decoration format is defined in [RFC4282].
如[RFC4284]中所述，还可以将NAI用于源路由。在这种情况下，客户机向AAA基础设施提供有关如何路由访问请求的指导。包括源路由信息的NAI被称为“装饰”；装饰格式在[RFC4282]中定义。
When decoration is utilized, the EAP peer provides the decorated NAI within the EAP-Response/Identity, and as described in [RFC3579], the NAS copies the decorated NAI included in the EAP-Response/Identity into the User-Name attribute included within the access request. As the access request transits the roaming relationship path, AAA proxies determine the next hop based on the realm included within the User-Name attribute, in the process, successively removing decoration from the NAI included in the User-Name attribute. In contrast, the decorated NAI included within the EAP-Response/Identity encapsulated in the access request remains untouched. As a result, when the access request arrives at the AAA home server, the decorated NAI included in the EAP-Response/Identity may differ from the NAI included in the User-Name attribute (which may have some or all of the decoration removed). For the purpose of identity verification, the EAP server utilizes the NAI in the User-Name attribute, rather than the NAI in the EAP-Response/Identity.
当使用修饰时，EAP对等方在EAP响应/标识中提供修饰NAI，并且如[RFC3579]中所述，NAS将EAP响应/标识中包含的修饰NAI复制到访问请求中包含的用户名属性中。当访问请求通过漫游关系路径时，AAA代理基于用户名属性中包含的领域确定下一跳，在此过程中，依次从用户名属性中包含的NAI中删除装饰。相反，包含在访问请求中封装的EAP响应/标识中的修饰NAI保持不变。结果，当访问请求到达AAA家庭服务器时，包括在EAP响应/标识中的修饰NAI可能不同于包括在用户名属性中的NAI（其可能已移除部分或全部修饰）。为了进行身份验证，EAP服务器使用用户名属性中的NAI，而不是EAP响应/身份中的NAI。
Over the long term, it is expected that the need for NAI "decoration" and source routing will disappear. This is somewhat analogous to the evolution of email delivery. Prior to the widespread proliferation of the Internet, it was necessary to gateway between SMTP-based mail systems and alternative delivery technologies, such as Unix-to-Unix CoPy Protocol (UUCP) and FidoNet. Prior to the implementation of email gateways utilizing MX RR routing, email address-based source-routing was used extensively. However, over time the need for email source-routing disappeared.
从长远来看，预计NAI“装饰”和源路由的需求将消失。这在某种程度上类似于电子邮件传递的演变。在互联网广泛普及之前，有必要在基于SMTP的邮件系统和其他交付技术（如Unix到Unix复制协议（UUCP）和FIDONE）之间建立网关。在使用MX RR路由实现电子邮件网关之前，广泛使用基于电子邮件地址的源路由。然而，随着时间的推移，对电子邮件源路由的需求消失了。
AAA clients on the edge of the network, such as NAS devices and local AAA proxies, typically maintain a default realm route, providing a default next hop for realms not otherwise taken into account within the realm routing table. This permits devices with limited resources to maintain a small realm routing table. Deeper within the AAA infrastructure, AAA proxies may be maintained with a "default free" realm table, listing next hops for all known realms, but not providing a default realm route.
网络边缘的AAA客户端（如NAS设备和本地AAA代理）通常维护默认领域路由，为领域路由表中未考虑的领域提供默认下一跳。这允许资源有限的设备维护一个小范围的路由表。在AAA基础设施的更深处，AAA代理可以使用“默认自由”领域表进行维护，列出所有已知领域的下一个跃点，但不提供默认领域路由。
While dynamic realm routing protocols are not in use within AAA infrastructure today, even if such protocols were to be introduced, it is likely that they would be deployed solely within the core AAA infrastructure, but not on NAS devices, which are typically resource constrained.
虽然目前AAA基础设施中未使用动态领域路由协议，但即使引入此类协议，它们也可能仅部署在核心AAA基础设施中，而不会部署在NAS设备上，因为NAS设备通常资源有限。
Since NAS devices do not maintain a full realm routing table, they do not have knowledge of all the realms reachable from the local network. The situation is analogous to that of Internet hosts or edge routers that do not participate in the BGP mesh. In order for an Internet host to determine whether it can reach a destination on the Internet, it is necessary to send a packet to the destination.
由于NAS设备不维护完整的域路由表，因此它们不知道从本地网络可以访问的所有域。这种情况类似于不参与BGP网格的Internet主机或边缘路由器的情况。为了使因特网主机确定它是否能够到达因特网上的目的地，有必要向目的地发送数据包。
Similarly, when a user provides an NAI to the NAS, the NAS does not know a priori whether or not the realm encoded in the NAI is reachable; it simply forwards the access request to the next hop on the roaming relationship path. Eventually, the access request reaches the "default free" zone, where a core AAA proxy determines whether or not the realm is reachable. As described in [RFC4284], where EAP authentication is in use, the core AAA proxy can send an Access-Reject, or it can send an Access-Challenge encapsulating an EAP-Request/Identity containing "realm hints" based on the content of the "default free" realm routing table.
类似地，当用户向NAS提供NAI时，NAS先验地不知道编码在NAI中的领域是否可到达；它只是将访问请求转发到漫游关系路径上的下一个跃点。最终，访问请求到达“默认自由”区域，在该区域中，核心AAA代理确定是否可以访问该领域。如[RFC4284]所述，在使用EAP身份验证的情况下，核心AAA代理可以发送访问拒绝，也可以发送访问质询，该质询封装了EAP请求/标识，其中包含基于“默认自由”领域路由表的内容的“领域提示”。
There are a number of intrinsic problems with this approach. Where the "default free" routing table is large, it may not fit within a single EAP packet, and the core AAA proxy may not have a mechanism for selecting the most promising entries to include. Even where the "default free" realm routing table would fit within a single EAP-Request/Identity packet, the core AAA router may not choose to include all entries, since the list of realm routes could be considered confidential information not appropriate for disclosure to hosts seeking network access. Therefore, it cannot be assumed that the list of "realm hints" included within the EAP-Request/Identity is complete. Given this, a NAS or local AAA proxy snooping the EAP-Request/Identity cannot rely on it to provide a complete list of reachable realms. The "realm hint" mechanism described in [RFC4284] is not a dynamic routing protocol.
这种方法存在许多固有的问题。在“默认自由”路由表较大的情况下，它可能不适合单个EAP分组，并且核心AAA代理可能没有用于选择要包括的最有希望的条目的机制。即使在“默认自由”领域路由表适合于单个EAP请求/标识分组的情况下，核心AAA路由器也可能不会选择包括所有条目，因为领域路由列表可能被视为机密信息，不适合披露给寻求网络访问的主机。因此，不能假设EAP请求/标识中包含的“领域提示”列表是完整的。有鉴于此，窥探EAP请求/身份的NAS或本地AAA代理无法依靠它提供可访问领域的完整列表。[RFC4284]中描述的“领域提示”机制不是动态路由协议。
Along with lack of a dynamic AAA routing protocol, today's AAA infrastructure lacks mechanisms for route selection and policy. As a result, multiple routes may exist to a destination realm, without a mechanism for the selection of a preferred route.
除了缺乏动态AAA路由协议外，今天的AAA基础设施还缺乏路由选择和策略机制。因此，到目的地领域可能存在多条路由，而没有选择首选路由的机制。
In Figure 2, Roaming Groups 1 and 2 both include a route to the realm "a.example.com". However, these realm routes are not disseminated to the NAS along with associated metrics, and, as a result, there is no mechanism for implementation of dynamic routing policies (such as selection of realm routes by shortest path, or preference for routes originating at a given proxy).
在图2中，漫游组1和2都包含一条到域“a.example.com”的路由。但是，这些领域路由不会与相关的度量一起传播到NAS，因此，没有实现动态路由策略的机制（例如，通过最短路径选择领域路由，或者优先选择源自给定代理的路由）。
+---------+
| |----> "a.example.com"
| Roaming |
+---------+ | Group 1 |
| |----->| Proxy |----> "b.example.com"
user "joe@ | Access | +---------+
a.example.com"--->| Provider|
| NAS | +---------+
| |----->| |----> "a.example.com"
+---------+ | Roaming |
| Group 2 |
| Proxy |----> "c.example.com"
+---------+
+---------+
| |----> "a.example.com"
| Roaming |
+---------+ | Group 1 |
| |----->| Proxy |----> "b.example.com"
user "joe@ | Access | +---------+
a.example.com"--->| Provider|
| NAS | +---------+
| |----->| |----> "a.example.com"
+---------+ | Roaming |
| Group 2 |
| Proxy |----> "c.example.com"
+---------+
Figure 2: Multiple routes to a destination realm
图2：到目标域的多条路由
In the example in Figure 2, access through Roaming Group 1 may be less expensive than access through Roaming Group 2, and as a result it would be desirable to prefer Roaming Group 1 as a next hop for an NAI with a realm of "a.example.com". However, the only way to obtain this result would be to manually configure the NAS realm routing table with the following entries:
在图2中的示例中，通过漫游组1的访问可能比通过漫游组2的访问便宜，因此，希望漫游组1作为具有“a.example.com”领域的NAI的下一跳。但是，获得此结果的唯一方法是使用以下条目手动配置NAS领域路由表：
Realm Next Hop
----- --------
b.example.com Roaming Group 1
c.example.com Roaming Group 2
Default Roaming Group 1
Realm Next Hop
----- --------
b.example.com Roaming Group 1
c.example.com Roaming Group 2
Default Roaming Group 1
While manual configuration may be practical in situations where the realm routing table is small and entries are static, where the list of supported realms change frequently, or the preferences change dynamically, manual configuration will not be manageable.
虽然手动配置在领域路由表很小且条目是静态的、支持的领域列表经常更改或首选项动态更改的情况下可能是可行的，但手动配置将不可管理。
Due to the limitations of current AAA routing mechanisms, there are situations in which NAI-based source routing is used to influence the roaming relationship path. However, since the AAA proxies on the roaming relationship path are constrained by existing relationships, NAI-based source routing is not source routing in the classic sense;
由于当前AAA路由机制的限制，存在使用基于NAI的源路由来影响漫游关系路径的情况。然而，由于漫游关系路径上的AAA代理受到现有关系的约束，基于NAI的源路由不是经典意义上的源路由；
it merely suggests preferences that the AAA proxy can choose not to accommodate.
它只是建议AAA代理可以选择不适应的偏好。
Where realm routes are set up as the result of pre-configuration and dynamic route establishment is not supported, if a realm route does not exist, then NAI-based source routing cannot establish it. Even where dynamic route establishment is possible, such as where the AAA client and server support certificate-based authentication, and AAA servers are discoverable (such as via the mechanisms described in [RFC3588]), an AAA proxy may choose not to establish a realm route by initiating the discovery process based on a suggestion in an NAI-based source route.
如果领域路由是作为预配置的结果而设置的，并且不支持动态路由建立，则如果领域路由不存在，则基于NAI的源路由无法建立它。即使在可以建立动态路由的情况下，例如AAA客户端和服务器支持基于证书的身份验证，并且AAA服务器是可发现的（例如通过[RFC3588]中描述的机制），AAA代理可以根据基于NAI的源路由中的建议启动发现过程，从而选择不建立域路由。
Where the realm route does exist, or the AAA proxy is capable of establishing it dynamically, the AAA proxy may choose not to authorize the client to use it.
如果领域路由确实存在，或者AAA代理能够动态地建立它，AAA代理可以选择不授权客户端使用它。
While, in principle, source routing can provide users with better control over AAA routing decisions, there are a number of practical problems to be overcome. In order to enable the client to construct optimal source routes, it is necessary for it to be provided with a complete and up-to-date realm routing table. However, if a solution to this problem were readily available, then it could be applied to the AAA routing infrastructure, enabling the selection of routes without the need for user intervention.
虽然原则上，源路由可以为用户提供对AAA路由决策的更好控制，但仍有许多实际问题需要克服。为了使客户机能够构造最佳的源路由，有必要为其提供一个完整且最新的领域路由表。然而，如果这个问题的解决方案是现成的，那么它可以应用于AAA路由基础设施，从而在不需要用户干预的情况下选择路由。
As noted in [Eronen04], only a limited number of parameters can be updated dynamically. For example, quality of service or pricing information typically will be pre-provisioned or made available on the web rather than being updated on a continuous basis. Where realm names are communicated dynamically, the "default free" realm list is unlikely to be provided in full since this table could be quite large. Given the constraints on the availability of information, the construction of source routes typically needs to occur in the face of incomplete knowledge.
如[N04]所述，只能动态更新有限数量的参数。例如，服务质量或定价信息通常会预先提供或在web上提供，而不是持续更新。在动态通信领域名称的情况下，“默认自由”领域列表不太可能完整提供，因为该表可能相当大。鉴于对信息可用性的限制，源路由的构建通常需要在面对不完整的知识时进行。
In addition, there are few mechanisms available to audit whether the requested source route is honored by the AAA infrastructure. For example, an access network could advertise a realm route to "costsless.example.com", while instead routing the access-request through "costsmore.example.com". While the decorated NAI would be made available to the home AAA server in the EAP-Response/Identity, the home AAA server might have a difficult time verifying that the source route requested in the decorated NAI was actually honored by the AAA infrastructure. Similarly, it could be difficult to determine whether quality of service (QoS) or other routing requests were actually provided as requested. To some extent, this problem
此外，很少有机制可用于审计AAA基础设施是否遵守请求的源路由。例如，接入网络可以将一个领域路由播发到“costsless.example.com”，而通过“costsmore.example.com”路由接入请求。虽然在EAP响应/标识中将装饰NAI提供给家庭AAA服务器，但家庭AAA服务器可能很难验证装饰NAI中请求的源路由是否已被AAA基础设施实际遵守。类似地，可能很难确定服务质量（QoS）或其他路由请求是否实际按请求提供。在某种程度上，这个问题
may be addressed as part of the business arrangements between roaming partners, which may provide minimum service-level guarantees.
可作为漫游合作伙伴之间业务安排的一部分解决，这可能提供最低服务级别保证。
Given the potential issues with source routing, conventional AAA routing mechanisms are to be preferred wherever possible. Where an error is encountered, such as an attempt to authenticate to an unreachable realm, "realm hints" can be provided as described [RFC4284]. However, this approach has severe scalability limitations, as outlined in Appendix A.1.
考虑到源路由的潜在问题，尽可能首选传统的AAA路由机制。当遇到错误时，例如试图对无法访问的领域进行身份验证时，可以按照[RFC4284]所述提供“领域提示”。然而，如附录A.1所述，这种方法具有严重的可扩展性限制。
Network capability discovery focuses on discovery of the services offered by networks, not just the capabilities of individual points of attachment. By acquiring additional information on access network characteristics, it is possible for users to make a more informed access decision. These characteristics may include:
网络能力发现侧重于发现网络提供的服务，而不仅仅是单个连接点的能力。通过获取关于接入网络特征的附加信息，用户可以做出更明智的接入决策。这些特征可能包括：
o Roaming relationships between the access network provider and other network providers and associated costs. Where the network access client is not pre-configured with an identity and credentials corresponding to a local access network, it will need to be able to determine whether one or more home realms are reachable from an access network so that successful authentication can be possible.
o 接入网络提供商与其他网络提供商之间的漫游关系以及相关成本。如果网络接入客户端未预先配置与本地接入网络相对应的标识和凭据，则它将需要能够确定是否可以从接入网络访问一个或多个家庭领域，以便能够成功地进行身份验证。
o EAP authentication methods. While the EAP authentication methods supported by a home realm can only be determined by contacting the home AAA server, it is possible that the local realm will also support one or more EAP methods. For example, a user may be able to utilize EAP-SIM (Extensible Authentication Protocol - Subscriber Identity Module) to authenticate to the access network directly, rather than having to authenticate to the home network.
o EAP认证方法。虽然家庭领域支持的EAP身份验证方法只能通过联系家庭AAA服务器来确定，但本地领域也可能支持一个或多个EAP方法。例如，用户可以利用EAP-SIM（可扩展认证协议-用户标识模块）直接向接入网络进行认证，而不必向家庭网络进行认证。
o End-to-end quality of service capability. While local quality of service capabilities are typically advertised by the access network (e.g., support for Wi-Fi Multimedia (WMM)), the availability of end-to-end QoS services may not be advertised.
o 端到端的服务质量能力。虽然本地服务质量能力通常由接入网络公布（例如，对Wi-Fi多媒体（WMM）的支持），但端到端QoS服务的可用性可能不会公布。
o Service parameters, such as the existence of middleboxes or firewalls. If the network access client is not made aware of the Internet access that it will receive on connecting to a point of attachment, it is possible that the user may not be able to access the desired services.
o 服务参数，例如是否存在中间包或防火墙。如果网络访问客户端没有意识到它在连接到连接点时将接收到的互联网访问，则用户可能无法访问所需的服务。
Reference [IEEE.11-04-0624] classifies the possible steps at which IEEE 802.11 networks can acquire this information:
参考文献[IEEE.11-04-0624]对IEEE 802.11网络获取此信息的可能步骤进行了分类：
o Pre-association
o 会前
o Post-association (or pre-authentication)
o 后关联（或预认证）
o Post-authentication
o 认证后
In the interest of minimizing connectivity delays, all of the information required for network selection (including both access network capabilities and global characteristics) needs to be provided prior to authentication.
为了最大限度地减少连接延迟，需要在认证之前提供网络选择所需的所有信息（包括接入网络能力和全局特征）。
By the time authentication occurs, the node has typically selected the access network, the NAI to be used to authenticate, as well as the point of attachment. Should it learn information during the authentication process that would cause it to revise one or more of those decisions, the node will need to select a new network, point of attachment, and/or identity, and then go through the authentication process all over again. Such a process is likely to be both time consuming and unreliable.
当认证发生时，节点通常已选择接入网络、用于认证的NAI以及连接点。如果节点在认证过程中了解到可能导致其修改一个或多个决策的信息，则节点将需要选择新网络、连接点和/或身份，然后重新进行认证过程。这样一个过程可能既耗时又不可靠。
The following factors should be taken into consideration while evaluating solutions to the problem of network selection and discovery.
在评估网络选择和发现问题的解决方案时，应考虑以下因素。
Solutions to the AAA routing issues discussed in Section 2.3 need to apply to a wide range of AAA messages, and should not restrict the introduction of new AAA or access network functionality. For example, AAA routing mechanisms should work for access requests and responses as well as accounting requests and responses and server-initiated messages. Solutions should not restrict the development of new AAA attributes, access types, or performance optimizations (such as fast handoff support).
第2.3节中讨论的AAA路由问题的解决方案需要应用于广泛的AAA消息，并且不应限制新AAA或接入网络功能的引入。例如，AAA路由机制应该适用于访问请求和响应、记帐请求和响应以及服务器启动的消息。解决方案不应限制新AAA属性、访问类型或性能优化（如快速切换支持）的开发。
Solutions need to maintain backward compatibility. In particular:
解决方案需要保持向后兼容性。特别地：
o Selection-aware clients need to interoperate with legacy NAS devices and AAA servers.
o 支持选择的客户端需要与传统NAS设备和AAA服务器进行互操作。
o Selection-aware AAA infrastructure needs to interoperate with legacy clients and NAS devices.
o 支持选择的AAA基础架构需要与旧客户端和NAS设备进行互操作。
For example, selection-aware clients should not transmit packets larger than legacy NAS devices or AAA servers can handle. Where protocol extensions are required, changes should be required to as few infrastructure elements as possible. For example, extensions that require upgrades to existing NAS devices will be more difficult to deploy than proposals that are incrementally deployable based on phased upgrades of clients or AAA servers.
例如，支持选择的客户端不应传输比传统NAS设备或AAA服务器所能处理的数据包大的数据包。在需要协议扩展的情况下，应要求更改尽可能少的基础结构元素。例如，与基于客户机或AAA服务器的分阶段升级而增量部署的方案相比，需要升级到现有NAS设备的扩展将更难部署。
Solutions should be efficient as measured by channel utilization, bandwidth consumption, handoff delay, and energy utilization. Mechanisms that depend on multicast frames need to be designed with care since multicast frames are often sent at the lowest supported rate and therefore consume considerable channel time as well as energy on the part of listening nodes. Depending on the deployment, it is possible for bandwidth to be constrained both on the link, as well as in the backend AAA infrastructure. As a result, chatty mechanisms such as keepalives or periodic probe packets are to be avoided. Given the volume handled by AAA servers, solutions should also be conscious of adding to the load, particularly in cases where this could enable denial-of-service attacks. For example, it would be a bad idea for a NAS to attempt to obtain an updated realm routing table by periodically sending probe EAP-Response/Identity packets to the AAA infrastructure in order to obtain "realm hints" as described in [RFC4284]. Not only would this add significant load to the AAA infrastructure (particularly in cases where the AAA server was already overloaded, thereby dropping packets resulting in retransmission by the NAS), but it would also not provide the NAS with a complete realm routing table, for reasons described in Section 2.3.
通过信道利用率、带宽消耗、切换延迟和能量利用率衡量，解决方案应该是有效的。依赖于多播帧的机制需要小心设计，因为多播帧通常以支持的最低速率发送，因此在侦听节点上消耗大量的信道时间和能量。根据部署情况，链路和后端AAA基础设施上的带宽都可能受到限制。因此，要避免诸如keepalives或周期性探测包之类的聊天机制。考虑到AAA服务器处理的卷，解决方案还应注意增加负载，特别是在可能导致拒绝服务攻击的情况下。例如，NAS试图通过定期向AAA基础设施发送探测EAP响应/标识数据包来获取更新的领域路由表，以获取[RFC4284]中所述的“领域提示”，这是一个坏主意。这不仅会给AAA基础设施增加大量负载（特别是在AAA服务器已经过载的情况下，从而丢弃数据包，导致NAS重新传输），而且还不会为NAS提供完整的领域路由表，原因如第2.3节所述。
Battery consumption is a significant constraint for handheld devices. Therefore, mechanisms that require significant increases in packets transmitted, or the fraction of time during which the host needs to listen (such as proposals that require continuous scanning), are to be discouraged. In addition, the solution should not significantly impact the time required to complete network attachment.
电池消耗是手持设备的一个重要限制。因此，不鼓励需要显著增加传输的数据包或主机需要监听的时间部分的机制（例如需要连续扫描的提议）。此外，解决方案不应显著影响完成网络连接所需的时间。
Given limitations on frame sizes and channel utilization, it is important that solutions scale less than linearly in terms of the number of networks and realms supported. For example, solutions such as [RFC4284] increase the size of advertisements in proportion to the number of entries in the realm routing table. This approach does not scale to support a large number of networks and realms.
考虑到帧大小和信道利用率的限制，解决方案在所支持的网络和领域数量方面的可扩展性必须小于线性。例如，[RFC4284]等解决方案根据领域路由表中的条目数按比例增加播发的大小。这种方法不能扩展到支持大量网络和领域。
Similarly, approaches that utilize separate Beacons for each "virtual AP" introduce additional Beacons in proportion to the number of networks being advertised. While such an approach may minimize the pre-configuration required for network access clients, the proliferation of "virtual APs" can result in high utilization of the wireless medium. For example, the 802.11 Beacon is sent only at a rate within the basic rate set, which typically consists of the lowest supported rates, or perhaps only the lowest supported rate. As a result, "virtual AP" mechanisms that require a separate Beacon for each "virtual AP" do not scale well.
类似地，为每个“虚拟AP”使用单独的信标的方法引入与所宣传的网络数量成比例的额外信标。虽然这种方法可以最小化网络接入客户端所需的预配置，但是“虚拟ap”的扩散可以导致无线介质的高利用率。例如，802.11信标仅以基本速率集内的速率发送，基本速率集通常包括最低支持速率，或者可能仅包括最低支持速率。因此，需要为每个“虚拟AP”单独设置信标的“虚拟AP”机制无法很好地扩展。
For example, with a Beacon interval of 100 Time Units (TUs) or 102.4 ms (9.8 Beacons/second), twenty 802.11b "virtual APs" each announcing their own Beacon of 170 octets would result in a channel utilization of 37.9 percent. The calculation can be verified as follows:
例如，如果信标间隔为100个时间单位（TUs）或102.4毫秒（9.8个信标/秒），则二十个802.11b“虚拟AP”各自宣布其170个八位字节的信标，将导致37.9%的信道利用率。可通过以下方式验证计算结果：
1. A single 170-octet Beacon sent at 1 Mbps will utilize the channel for 1360 us (1360 bits @ 1 Mbps);
1. 以1 Mbps发送的单个170个八位组信标将使用1360 us的信道（1 Mbps时为1360位）；
2. Adding 144 us for the Physical Layer Convergence Procedure (PLCP) long preamble (144 bits @ 1 Mbps), 48 us for the PLCP header (48 bits @ 1 Mbps), 10 us for the Short Interframe Space (SIFS), 50 us for the Distributed Interframe Space (DIFS), and 320 us for the average minimum Contention Window without backoff (CWmin/2 * aSlotTime = 32/2 * 20 us) implies that a single Beacon will utilize an 802.11b channel for 1932 us;
2. 为物理层收敛过程（PLCP）长前导码（144位@1 Mbps）添加144 us，为PLCP报头添加48 us（48位@1 Mbps），为短帧间空间（SIFS）添加10 us，为分布式帧间空间（DIFS）添加50 us，为无退避的平均最小争用窗口添加320 us（CWmin/2*aSlotTime=32/2*20 us）意味着一个信标将为1932美国使用802.11b信道；
3. Multiply the channel time per Beacon by 196 Beacons/second, and we obtain a channel utilization of 378672 us/second = 37.9 percent.
3. 将每个信标的信道时间乘以196个信标/秒，我们得到的信道利用率为378672 us/秒=37.9%。
In addition, since Beacon/Probe Response frames are sent by each AP over the wireless medium, stations can only discover APs within range, which implies substantial coverage overlap for roaming to occur without interruption. Another issue with the Beacon and Probe Request/Response mechanism is that it is either insecure or its security can be assured only as part of authenticating to the network (e.g., verifying the advertised capabilities within the 4-way handshake).
此外，由于信标/探测响应帧由每个AP通过无线介质发送，因此站点只能发现范围内的AP，这意味着在不中断的情况下发生漫游的大量覆盖重叠。信标和探测请求/响应机制的另一个问题是，信标和探测请求/响应机制要么不安全，要么只能作为网络身份验证的一部分来保证其安全性（例如，在4路握手中验证公布的功能）。
A number of enhancements have been proposed to the Beacon/Probe Response mechanism in order to improve scalability and performance in roaming scenarios. These include allowing APs to announce capabilities of neighbor APs as well as their own [IEEE.802.11k]. More scalable mechanisms for support of "virtual APs" within IEEE 802.11 have also been proposed [IEEE.802.11v]; generally these proposals collapse multiple "virtual AP" advertisements into a single advertisement.
为了提高漫游场景中的可伸缩性和性能，对信标/探测响应机制提出了许多增强。其中包括允许接入点宣布邻居接入点的功能以及它们自己的[IEEE.802.11k]。还提出了在IEEE 802.11中支持“虚拟AP”的更具可扩展性的机制[IEEE.802.11v]；通常，这些建议将多个“虚拟AP”广告合并为一个广告。
Higher-layer mechanisms can also be used to improve scalability since, by running over IP, they can utilize facilities, such as fragmentation, that may not be available at the link layer. For example, in IEEE 802.11, Beacon frames cannot use fragmentation because they are multicast frames.
更高层的机制也可用于提高可伸缩性，因为通过在IP上运行，它们可以利用链路层可能不可用的设施，如碎片。例如，在IEEE 802.11中，信标帧不能使用分段，因为它们是多播帧。
"Phone-book" based approaches such as [RFC3017] can provide information for automatic selection decisions. While this approach has been applied to wireless access, it typically can only be used successfully within a single operator or limited roaming partner deployment. For example, were a "Phone-Book" approach to attempt to incorporate information from a large number of roaming partners, it could become quite difficult to keep the information simultaneously comprehensive and up to date. As noted in [Priest04] and [GROETING], a large fraction of current WLAN access points operate on the default SSID, which may make it difficult to distinguish roaming partner networks by SSID. In any case, in wireless networks, dynamic discovery is a practical requirement since a node needs to know which APs are within range before it can connect.
基于“电话簿”的方法，如[RFC3017]可以为自动选择决策提供信息。虽然此方法已应用于无线接入，但通常只能在单个运营商或有限漫游合作伙伴部署中成功使用。例如，如果采用“电话簿”方法试图合并来自大量漫游合作伙伴的信息，则很难同时保持信息的全面性和最新性。如[Priest04]和[GROETING]中所述，当前大部分WLAN接入点都在默认SSID上运行，这可能导致难以通过SSID区分漫游伙伴网络。在任何情况下，在无线网络中，动态发现都是一个实际需求，因为节点在连接之前需要知道哪些AP在范围内。
Network discovery and selection mechanisms may introduce new security vulnerabilities. As noted in Section 2.3.1, network operators may consider the AAA routing table to be confidential information, and therefore may not wish to provide it to unauthenticated peers via the mechanism described in RFC 4284. While the peer could provide a list of the realms it supports, with the authenticator choosing one, this approach raises privacy concerns. Since identity selection occurs prior to authentication, the peer's supported realms would be sent in cleartext, enabling an attacker to determine the realms for which a potential victim has credentials. This risk can be mitigated by restricting peer disclosure. For example, a peer may only disclose additional realms in situations where an initially selected identity has proved unusable.
网络发现和选择机制可能会引入新的安全漏洞。如2.3.1节所述，网络运营商可以认为AAA路由表是机密信息，因此可能不希望通过RFC 4284中描述的机制将其提供给未经认证的对等点。虽然对等方可以提供它所支持的领域的列表，由认证者选择一个，但这种方法会引起隐私问题。由于身份选择发生在身份验证之前，因此对等方支持的领域将以明文形式发送，从而使攻击者能够确定潜在受害者拥有凭据的领域。这种风险可以通过限制同行披露来缓解。例如，对等方可能仅在最初选择的身份被证明不可用的情况下披露其他领域。
Since network selection occurs prior to authentication, it is typically not possible to secure mechanisms for network discovery or identity selection, although it may be possible to provide for secure confirmation after authentication is complete. As an example, some parameters discovered during network discovery may be confirmable via EAP Channel Bindings; others may be confirmed in a subsequent Secure Association Protocol handshake.
由于网络选择发生在认证之前，因此通常不可能保护用于网络发现或身份选择的机制，尽管可能在认证完成后提供安全确认。例如，在网络发现期间发现的一些参数可以通过EAP通道绑定进行确认；其他可在随后的安全关联协议握手中确认。
However, there are situations in which advertised parameters may not be confirmable. This could lead to "bidding down" vulnerabilities. Section 7.8 of [RFC3748] states:
但是，在某些情况下，公布的参数可能不可确认。这可能导致“降低”漏洞。[RFC3748]第7.8节规定：
Within or associated with each authenticator, it is not anticipated that a particular named peer will support a choice of methods. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set. Instead, for each named peer, there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method.
在每个验证器内或与之相关联的验证器中，预计特定的命名对等方不会支持方法的选择。这会使对等方容易受到攻击，这些攻击会协商集合中最不安全的方法。相反，对于每个命名的对等方，应该有一个用于验证该对等方名称的方法的指示。如果对等方需要在不同的情况下使用不同的身份验证方法，那么应该使用不同的身份，每个身份都只标识一种身份验证方法。
In practice, where the authenticator operates in "pass-through" mode, the EAP method negotiation will occur between the EAP peer and server, and therefore the peer will need to associate a single EAP method with a given EAP server. Where multiple EAP servers and corresponding identities may be reachable from the same selected network, the EAP peer may have difficulty determining which identity (and corresponding EAP method) should be used. Unlike network selection, which may be securely confirmed within a Secure Association Protocol handshake, identity selection hints provided within the EAP-Request/Identity are not secured.
在实践中，当认证器以“通过”模式操作时，EAP方法协商将在EAP对等方和服务器之间发生，因此对等方将需要将单个EAP方法与给定的EAP服务器相关联。如果可以从同一选定网络访问多个EAP服务器和相应的标识，则EAP对等方可能难以确定应该使用哪个标识（和相应的EAP方法）。与可在安全关联协议握手中安全确认的网络选择不同，EAP请求/标识中提供的标识选择提示不安全。
As a result, where the identity selection mechanism described in RFC 4284 is used, the "hints" provided could be used by an attacker to convince the victim to select an identity corresponding to an EAP method offering lesser security (e.g., EAP MD5-Challenge). One way to mitigate this risk is for the peer to only utilize EAP methods satisfying the [RFC4017] security requirements, and for the peer to select the identity corresponding to the strongest authentication method where a choice is available.
因此，在使用RFC 4284中描述的身份选择机制的情况下，攻击者可以使用提供的“提示”说服受害者选择与提供较低安全性的EAP方法相对应的身份（例如，EAP MD5挑战）。缓解此风险的一种方法是，对等方仅使用满足[RFC4017]安全要求的EAP方法，并且对等方在有选择的情况下选择与最强身份验证方法相对应的身份。
From an operational point of view, a network device in control of network advertisement and providing "realm hints" for guiding the network discovery and selection, should at least offer a management interface capable of providing status information for operators. Status information, such as counters of each selected network and used realm, and when RFC 4284 is used, the count of delivered "realm hints" might interest operators. Especially the information related to realms that fall into the "default free zone" or the "AAA fails to route" are of interest.
从操作角度来看，控制网络广告并提供用于指导网络发现和选择的“领域提示”的网络设备应至少提供能够为运营商提供状态信息的管理接口。状态信息，例如每个选定网络和已使用领域的计数器，以及使用RFC 4284时，交付的“领域提示”计数可能会引起操作员的兴趣。特别是与落入“无违约区”或“AAA无法路由”的领域相关的信息令人感兴趣。
Larger deployments would benefit from a management interface that allow full remote configuration capabilities, for example, of "realm
更大的部署将受益于允许完全远程配置功能的管理界面，例如“领域”
hints" in case of RFC 4284-conforming network devices. While changes to "realm hints" and realm routing information are not expected to be frequent, centralized remote management tends to lower the frequency of misconfigured devices.
对于符合RFC 4284标准的网络设备，“提示”。虽然对“领域提示”和领域路由信息的更改预计不会频繁，但集中远程管理往往会降低错误配置设备的频率。
This document describes the network selection and discovery problem. In the opinion of the authors, the major findings are as follows:
本文档介绍网络选择和发现问题。作者认为，主要发现如下：
o There is a need for additional work on access network discovery, identifier selection, AAA routing, and payload routing.
o 需要在接入网络发现、标识符选择、AAA路由和有效负载路由方面进行额外的工作。
o Credential selection and AAA routing are aspects of the same problem, namely identity selection.
o 凭证选择和AAA路由是同一问题的两个方面，即身份选择。
o When considering selection among a large number of potential access networks and points of attachment, the issues described in the document become much harder to solve in an automated way, particularly if there are constraints on handoff latency.
o 当考虑在大量潜在接入网络和连接点之间进行选择时，文档中描述的问题变得更加难以以自动化方式解决，特别是在切换延迟受到限制的情况下。
o The proliferation of network discovery technologies within IEEE 802, IETF, and 3rd Generation Partnership Project (3GPP) has the potential to become a significant problem going forward. Without a unified approach, multiple non-interoperable solutions may be deployed.
o IEEE 802、IETF和第三代合作伙伴计划（3GPP）中网络发现技术的扩散有可能成为未来的一个重大问题。如果没有统一的方法，可能会部署多个不可互操作的解决方案。
o New link-layer designs should include efficient distribution of network and realm information as a design requirement.
o 新的链路层设计应将网络和领域信息的有效分布作为设计要求。
o It may not be possible to solve all aspects of the problem for legacy NAS devices on existing link layers. Therefore, a phased approach may be more realistic. For example, a partial solution could be made available for existing link layers, with a more complete solution requiring support for link layer extensions.
o 对于现有链路层上的旧式NAS设备，可能无法解决所有方面的问题。因此，分阶段的方法可能更现实。例如，可以为现有链接层提供部分解决方案，而更完整的解决方案需要支持链接层扩展。
With respect to specific mechanisms for access network discovery and selection:
关于接入网络发现和选择的特定机制：
o Studies such as [MACScale] and [Velayos], as well as the calculations described in Section 2.1, demonstrate that the IEEE 802.11 Beacon/Probe Response mechanism has substantial scaling issues in situations where a new Beacon is used for each "virtual AP". As a result, a single channel is, in practice, limited to less than twenty Beacon announcements with IEEE 802.11b.
o [MACScale]和[Velayos]等研究以及第2.1节中所述的计算表明，在每个“虚拟AP”使用新信标的情况下，IEEE 802.11信标/探头响应机制存在严重的缩放问题。因此，在实践中，使用IEEE 802.11b，单个信道仅限于不到二十个信标公告。
The situation is improved substantially with successors, such as IEEE 802.11a, that enable additional channels, thus potentially increasing the number of potential virtual APs.
这种情况通过后继者（例如IEEE 802.11a）得到了实质性的改善，这些后继者启用了额外的信道，从而潜在地增加了潜在虚拟ap的数量。
However, even with these enhancements, it is not feasible to advertise more than 50 different networks, and probably less in most circumstances.
然而，即使有了这些增强功能，也不可能为超过50个不同的网络做广告，在大多数情况下可能会更少。
As a result, there appears to be a need to enhance the scalability of IEEE 802.11 network advertisements.
因此，似乎需要增强IEEE 802.11网络广告的可伸缩性。
o Work is underway in IEEE 802.1, IEEE 802.21, and IEEE 802.11u [IEEE.802.11u] to provide enhanced discovery functionality. Similarly, IEEE 802.1af [IEEE.802.1af] has discussed the addition of network discovery functionality to IEEE 802.1X [IEEE.8021X-2004]. However, neither IEEE 802.1AB [IEEE.802.1ab] nor IEEE 802.1af is likely to support fragmentation of network advertisement frames so that the amount of data that can be transported will be limited.
o IEEE 802.1、IEEE 802.21和IEEE 802.11u[IEEE.802.11u]的工作正在进行，以提供增强的发现功能。类似地，IEEE 802.1af[IEEE.802.1af]讨论了将网络发现功能添加到IEEE 802.1X[IEEE.8021X-2004]中。然而，IEEE 802.1AB[IEEE.802.1AB]和IEEE 802.1af都不可能支持网络广告帧的分段，因此可以传输的数据量将受到限制。
o While IEEE 802.11k [IEEE.802.11k] provides support for the Neighbor Report, this only provides for gathering of information on neighboring 802.11 APs, not points of attachment supporting other link layers. Solution to this problem would appear to require coordination across IEEE 802 as well as between standards bodies.
o 虽然IEEE 802.11k[IEEE.802.11k]提供了对邻居报告的支持，但这只提供了对相邻802.11 AP的信息收集，而不是支持其他链路层的连接点。这个问题的解决方案似乎需要IEEE 802之间以及标准机构之间的协调。
o Given that EAP does not support fragmentation of EAP-Request/ Identity packets, the volume of "realm hints" that can be fit with these packets is limited. In addition, within IEEE 802.11, EAP packets can only be exchanged within State 3 (associated and authenticated). As a result, use of EAP for realm discovery may result in significant delays. The extension of the realm advertisement mechanism defined in [RFC4284] to handle advertisement of realm capability information (such as QoS provisioning) is not recommended due to semantic and packet size limitations [GROETING]. As a result, we believe that extending the mechanism described in [RFC4284] for discovery of realm capabilities is inappropriate. Instead, we believe it is more appropriate for this functionality to be handled within the link layer so that the information can be available early in the handoff process.
o 鉴于EAP不支持EAP请求/标识数据包的碎片化，因此适合这些数据包的“领域提示”的数量是有限的。此外，在IEEE 802.11中，EAP数据包只能在状态3（关联和认证）内交换。因此，使用EAP进行领域发现可能会导致严重的延迟。由于语义和数据包大小的限制[GROETING]，不建议扩展[RFC4284]中定义的领域播发机制来处理领域能力信息的播发（如QoS提供）。因此，我们认为扩展[RFC4284]中描述的发现领域能力的机制是不合适的。相反，我们认为在链路层内处理此功能更合适，以便在切换过程的早期可以获得信息。
o Where link-layer approaches are not available, higher-layer approaches can be considered. A limitation of higher-layer solutions is that they can only optimize the movement of already connected hosts, but cannot address scenarios where network discovery is required for successful attachment.
o 在链路层方法不可用的情况下，可以考虑采用更高层的方法。高层解决方案的一个限制是，它们只能优化已连接主机的移动，但无法解决成功连接需要网络发现的情况。
Higher-layer alternatives worth considering include the SEAMOBY CARD protocol [RFC4066], which enables advertisement of network device capabilities over IP, and Device Discovery Protocol (DDP) [MARQUES], which provides functionality equivalent to IEEE 802.1AB using ASN.1 encoded advertisements sent to a link-local scope multicast address.
值得考虑的更高层替代方案包括SEAMOBY卡协议[RFC4066]，该协议支持通过IP公布网络设备功能，以及设备发现协议（DDP）[MARQUES]，该协议使用发送到链路本地范围多播地址的ASN.1编码公布，提供等同于IEEE 802.1AB的功能。
All aspects of the network discovery and selection problem are security related. The security issues and requirements have been discussed in the previous sections.
网络发现和选择问题的所有方面都与安全相关。安全问题和要求已在前面的章节中讨论过。
The security requirements for network discovery depend on the type of information being discovered. Some of the parameters may have a security impact, such as the claimed name of the network to which the user tries to attach. Unfortunately, current EAP methods do not always make the verification of such parameters possible. EAP methods, such as Protected EAP (PEAP) [JOSEFSSON] and EAP-IKEv2 [IKEV2], may make this possible, however. There is even an attempt to provide a backward-compatible extension to older methods [ARKKO].
网络发现的安全要求取决于所发现的信息类型。某些参数可能会产生安全影响，例如用户试图连接的网络的声明名称。不幸的是，目前的EAP方法并不总是能够验证这些参数。然而，EAP方法，如受保护的EAP（PEAP）[JOSEFSSON]和EAP-IKEv2[IKEv2]，可能使这成为可能。甚至有人试图为旧方法[ARKKO]提供向后兼容的扩展。
The security requirements for network selection depend on whether the selection is considered a mandate or a hint. In general, treating network advertisements as a hint is a more secure approach, since it reduces access client vulnerability to forged network advertisements. For example, "realm hints" may be ignored by an EAP peer if they are incompatible with the security policy corresponding to a selected access network.
网络选择的安全性要求取决于选择是被视为强制还是暗示。一般来说，将网络广告视为提示是一种更安全的方法，因为它减少了访问客户端对伪造网络广告的漏洞。例如，“领域提示”如果与所选接入网络对应的安全策略不兼容，EAP对等方可能会忽略它们。
Similarly, network access clients may refuse to connect to a point of attachment if the advertised security capabilities do not match those that have been pre-configured. For example, if an IEEE 802.11 access client has been pre-configured to require WPA2 enterprise support within an access network, it may refuse to connect to access points advertising support for WEP.
类似地，如果公布的安全功能与预先配置的安全功能不匹配，则网络访问客户端可能会拒绝连接到连接点。例如，如果IEEE 802.11接入客户端已预先配置为在接入网络内需要WPA2企业支持，则它可能拒绝连接到宣传WEP支持的接入点。
Where the use of methods that do not satisfy the security requirements of [RFC4017] is allowed, it may be possible for an attacker to trick a peer into using an insecure EAP method, leading to the compromise of long-term credentials. This can occur either where a network is pre-configured to allow use of an insecure EAP method, or where connection without pre-configuration is permitted using such methods.
如果允许使用不满足[RFC4017]安全要求的方法，攻击者可能会诱使对等方使用不安全的EAP方法，从而导致长期凭据受损。这可能发生在预先配置网络以允许使用不安全的EAP方法的情况下，或者允许使用此类方法进行未预先配置的连接的情况下。
For example, an attacker can spoof a network advertisement, possibly downgrading the advertised security capabilities. The rogue access point would then attempt to negotiate an insecure EAP method. Such
例如，攻击者可以欺骗网络广告，可能会降低广告的安全功能。然后，恶意接入点将尝试协商不安全的EAP方法。这样的
an attack can be prevented if the peer refuses to connect to access points not meeting its security requirements, which would include requiring use of EAP methods satisfying the [RFC4017] requirements.
如果对等方拒绝连接到不符合其安全要求的接入点（包括要求使用满足[RFC4017]要求的EAP方法），则可以防止攻击。
Support for secure discovery could potentially protect against spoofing of network advertisements, enabling verifiable information to guide connection decisions. However, development of these mechanisms requires solving several difficult engineering and deployment problems.
对安全发现的支持可能会防止网络广告的欺骗，从而使可验证信息能够指导连接决策。然而，开发这些机制需要解决几个困难的工程和部署问题。
Since discovery is a prerequisite for authentication, it is not possible to protect initial discovery using dynamic keys derived in the authentication process. On the other hand, integrity protection of network advertisements utilizing symmetric keys or digital signatures would require pre-configuration.
由于发现是身份验证的先决条件，因此无法使用在身份验证过程中派生的动态密钥来保护初始发现。另一方面，使用对称密钥或数字签名的网络广告的完整性保护需要预先配置。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3017] Riegel, M. and G. Zorn, "XML DTD for Roaming Access Phone Book", RFC 3017, December 2000.
[RFC3017]Riegel，M.和G.Zorn，“用于漫游接入电话簿的XML DTD”，RFC 3017，2000年12月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", RFC 4334, February 2006.
[RFC4334]Housley，R.和T.Moore，“支持点对点协议（PPP）和无线局域网（WLAN）认证的证书扩展和属性”，RFC 4334，2006年2月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072]Eronen，P.，Hiller，T.，和G.Zorn，“直径可扩展认证协议（EAP）应用”，RFC 4072，2005年8月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997.
[RFC2194]Aboba，B.，Lu，J.，Alsop，J.，Ding，J.，和W.Wang，“漫游实施回顾”，RFC 2194，1997年9月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607]Aboba，B.和J.Vollbrecht，“漫游中的代理链接和策略实施”，RFC 2607，1999年6月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608]Guttman，E.，Perkins，C.，Veizades，J.，和M.Day，“服务位置协议，版本2”，RFC 26081999年6月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580]Congdon，P.，Aboba，B.，Smith，A.，Zorn，G.，和J.Roese，“IEEE 802.1X远程认证拨入用户服务（RADIUS）使用指南”，RFC 35802003年9月。
[RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity Selection Hints for the Extensible Authentication Protocol (EAP)", RFC 4284, January 2006.
[RFC4284]Adrangi，F.，Lortz，V.，Bari，F.，和P.Ernen，“可扩展身份验证协议（EAP）的身份选择提示”，RFC 4284，2006年1月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]Stanley，D.，Walker，J.，和B.Aboba，“无线局域网的可扩展认证协议（EAP）方法要求”，RFC 401712005年3月。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC2486]Aboba，B.和M.Beadles，“网络接入标识符”，RFC 2486，1999年1月。
[RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", RFC 4066, July 2005.
[RFC4066]Liebsch，M.，Singh，A.，Chaskar，H.，Funato，D.，和E.Shim，“候选接入路由器发现（卡）”，RFC 4066，2005年7月。
[IKEV2] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "EAP-IKEv2 Method", Work in Progress, September 2007.
[IKEV2]Tschofenig，H.，Kroeselberg，D.，Pashalidis，A.，Ohba，Y.，和F.Bersani，“EAP-IKEV2方法”，正在进行的工作，2007年9月。
[ARKKO] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", Work in Progress, October 2005.
[ARKKO]ARKKO，J.和P.Eronen，“可扩展认证协议（EAP）的认证服务信息”，正在进行的工作，2005年10月。
[GROETING] Groeting, W., Berg, S., Tschofenig, H., and M. Ness, "Network Selection Implementation Results", Work in Progress, July 2004.
[GROETING]GROETING，W.，Berg，S.，Tschofenig，H.，和M.Ness，“网络选择实施结果”，正在进行的工作，2004年7月。
[JOSEFSSON] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
[JOSEFSSON]Palekar，A.，Simon，D.，Salowey，J.，Zhou，H.，Zorn，G.，和S.JOSEFSSON，“受保护的EAP协议（PEAP）版本2”，正在进行的工作，2004年10月。
[MARQUES] Enns, R., Marques, P., and D. Morrell, "Device Discovery Protocol (DDP)", Work in Progress, May 2003.
[MARQUES]Enns，R.，MARQUES，P.，和D.Morrell，“设备发现协议（DDP）”，正在进行的工作，2003年5月。
[OHBA] Taniuchi, K., Ohba, Y., and D. Subir, "IEEE 802.21 Basic Schema", Work in Progress, October 2007.
[OHBA]Taniuchi，K.，OHBA，Y.，和D.Subir，“IEEE 802.21基本模式”，正在进行的工作，2007年10月。
[IEEE.802.11-2003] IEEE, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 2003.
[IEEE.802.11-2003]IEEE，“无线局域网介质访问控制（MAC）和物理层（PHY）规范”，IEEE标准802.11，2003。
[Fixingapsel] Judd, G. and P. Steenkiste, "Fixing 802.11 Access Point Selection", Sigcomm Poster Session 2002.
[Fixingapsel]Judd，G.和P.Steenkiste，“修复802.11接入点选择”，SIGCOM海报会议2002。
[IEEE.802.11k] IEEE, "Draft Ammendment to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Radio Resource Management", IEEE 802.11k, D7.0, January 2007.
[IEEE.802.11k]IEEE，“系统间电信和信息交换标准的附录草案——LAN/MAN特定要求——第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范：无线电资源管理”，IEEE 802.11k，D7.0，2007年1月。
[IEEE.802.1ab] IEEE, "Draft Standard for Local and Metropolitan Area Networks - Station and Media Access Control Connectivity Discovery", IEEE 802.1AB, D1.0, April 2007.
[IEEE.802.1ab]IEEE，“局域网和城域网标准草案-站点和媒体访问控制连接发现”，IEEE 802.1ab，D1.0，2007年4月。
[IEEE.802.1af] IEEE, "Draft Standard for Local and Metropolitan Area Networks - Port-Based Network Access Control - Amendment 1: Authenticated Key Agreement for Media Access Control (MAC) Security", IEEE 802.1af, D1.2, January 2007.
[IEEE.802.1af]IEEE，“局域网和城域网标准草案-基于端口的网络访问控制-修改件1：媒体访问控制（MAC）安全认证密钥协议”，IEEE 802.1af，D1.22007年1月。
[IEEE.802.11v] IEEE, "Draft Amemdment to Standard for Information Technology - Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Wireless Network Management", IEEE 802.11v, D0.09, March 2007.
[IEEE.802.11v]IEEE，“信息技术标准草案——系统间电信和信息交换——LAN/MAN特定要求——第11部分：无线媒体访问控制（MAC）和物理层（PHY）规范：无线网络管理”，IEEE 802.11v，D0.09，2007年3月。
[Eronen04] Eronen, P. and J. Arkko, "Role of authorization in wireless network security", Extended abstract presented in the DIMACS workshop, November 2004.
[Eronen04]Eronen，P.和J.Arkko，“授权在无线网络安全中的作用”，2004年11月在DIMACS研讨会上发表的扩展摘要。
[IEEE.11-04-0624] Berg, S., "Information to Support Network Selection", IEEE Contribution 11-04-0624 2004.
[IEEE.11-04-0624]Berg，S.，“支持网络选择的信息”，IEEE投稿11-04-0624 2004。
[Priest04] Priest, J., "The State of Wireless London", July 2004.
[Priest04]Prist，J.，“无线伦敦州”，2004年7月。
[MACScale] Heusse, M., "Performance Anomaly of 802.11b", LSR-IMAG Laboratory, Grenoble, France, IEEE Infocom 2003.
[MACScale]Heusse，M.，“802.11b的性能异常”，LSR-IMAG实验室，格勒诺布尔，法国，IEEE Infocom 2003。
[Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b MAC Layer Handover Time", Laboratory for Communication Networks, KTH, Royal Institute of Technology, Stockholm, Sweden, TRITA-IMIT-LCN R 03:02, April 2003.
[Velayos]Velayos，H.和G.Karlsson，“减少IEEE 802.11b MAC层切换时间的技术”，通信网络实验室，KTH，瑞典斯德哥尔摩皇家理工学院，TRITA-IMIT-LCN R 03:022003年4月。
[IEEE.802.11u] IEEE, "Draft Amendment to STANDARD FOR Information Technology - LAN/MAN Specific Requirements - Part 11: Interworking with External Networks; Draft Amendment to Standard; IEEE P802.11u/D0.04", IEEE 802.11u, D0.04, April 2007.
[IEEE.802.11u]IEEE，“信息技术标准修订草案-局域网/城域网特定要求-第11部分：与外部网络的互通；标准修订草案；IEEE P802.11u/D0.04”，IEEE 802.11u，D0.042007年4月。
[IEEE-11-03-154r1] Aboba, B., "Virtual Access Points", IEEE Contribution 11- 03-154r1, May 2003.
[IEEE-11-03-154r1]Aboba，B.，“虚拟接入点”，IEEE贡献11-03-154r1，2003年5月。
[IEEE-11-03-0827] Hepworth, E., "Co-existence of Different Authentication Models", IEEE Contribution 11-03-0827 2003.
[IEEE-11-03-0827]Hepworth，E.“不同认证模型的共存”，IEEE投稿11-03-0827 2003。
[11-05-0822-03-000u-tgu-requirements] Moreton, M., "TGu Requirements", IEEE Contribution 11-05- 0822-03-000u-tgu-requirements, August 2005.
[11-05-0822-03-000u-tgu-requirements]莫顿，M.，“tgu要求”，IEEE投稿11-05-0822-03-000u-tgu-requirements，2005年8月。
[3GPPSA2WLANTS] 3GPP, "3GPP System to Wireless Local Area Network (WLAN) interworking; System De scription; Release 6; Stage 2", 3GPP Technical Specification 23.234, September 2005.
[3GPPSA2WLANTS]3GPP，“3GPP系统到无线局域网（WLAN）的互通；系统描述；第6版；第2阶段”，3GPP技术规范23.234，2005年9月。
[3GPP-SA3-030736] Ericsson, "Security of EAP and SSID based network advertisements", 3GPP Contribution S3-030736, November 2003.
[3GPP-SA3-030736]爱立信，“基于EAP和SSID的网络广告的安全”，3GPP投稿S3-030736，2003年11月。
[3GPP.23.122] 3GPP, "Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode", 3GPP TS 23.122 6.5.0, October 2005.
[3GPP.23.122]3GPP，“空闲模式下与移动站（MS）相关的非接入层（NAS）功能”，3GPP TS 23.122 6.5.0，2005年10月。
[WWRF-ANS] Eijk, R., Brok, J., Bemmel, J., and B. Busropan, "Access Network Selection in a 4G Environment and the Role of Terminal and Service Platform", 10th WWRF, New York, October 2003.
[WWRF-ANS]Eijk，R.，Brok，J.，Bemmel，J.，和B.Busropan，“4G环境中的接入网络选择以及终端和服务平台的作用”，第十届WWRF，纽约，2003年10月。
[WLAN3G] Ahmavaara, K., Haverinen, H., and R. Pichna, "Interworking Architecture between WLAN and 3G Systems", IEEE Communications Magazine, November 2003.
[WLAN3G]Ahmavara，K.，Haverinen，H.，和R.Pichna，“WLAN和3G系统之间的互通架构”，IEEE通信杂志，2003年11月。
[INTELe2e] Intel, "Wireless LAN (WLAN) End to End Guidelines for Enterprises and Public Hotspot Service Providers", November 2003.
[INTELe2e]英特尔，“面向企业和公共热点服务提供商的无线局域网（WLAN）端到端指南”，2003年11月。
[Eronen03] Eronen, P., "Network Selection Issues", presentation to EAP WG at IETF 58, November 2003.
[Eronen 03]Eronen，P.，“网络选择问题”，在IETF 58上向EAP工作组的介绍，2003年11月。
[3GPPSA3WLANTS] 3GPP, "3GPP Technical Specification Group Service and System Aspects; 3G Security; Wireless Local Area Network (WLAN) interworking security (Release 6); Stage 2", 3GPP Technical Specification 33.234 v 6.6.0, October 2005.
[3GPPSA3WLANTS]3GPP，“3GPP技术规范组服务和系统方面；3G安全；无线局域网（WLAN）互通安全（第6版）；第2阶段”，3GPP技术规范33.234 v 6.6.0，2005年10月。
[3GPPCT1WLANTS] 3GPP, "3GPP System to Wireless Local Area Network (WLAN) interworking; User Equipment (UE) to network protocols; Stage 3 (Release 6)", 3GPP Technical Specification 24.234 v 6.4.0, October 2005.
[3GPPCT1WLANTS]3GPP，“3GPP系统到无线局域网（WLAN）的互通；用户设备（UE）到网络协议；第3阶段（第6版）”，3GPP技术规范24.234 v 6.4.0，2005年10月。
[IEEE.802.21] IEEE, "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE 802.21, D05.00, April 2007.
[IEEE.802.21]IEEE，“局域网和城域网IEEE标准草案：媒体独立切换服务”，IEEE 802.21，D05.00，2007年4月。
[3GPPCT4WLANTS] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) interworking; Stage 3 (Release 6)", 3GPP Technical Specification 29.234 v 6.4.0, October 2005.
[3GPPCT4WLANTS]3GPP，“3GPP系统到无线局域网（WLAN）互通；第3阶段（第6版）”，3GPP技术规范29.234 v 6.4.0，2005年10月。
[IEEE.8021X-2004] IEEE, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, July 2004.
[IEEE.8021X-2004]IEEE，“局域网和城域网：基于端口的网络访问控制”，IEEE标准802.1X，2004年7月。
Several IETF WGs have dealt with aspects of the network selection problem, including the AAA, EAP, PPP, RADIUS, ROAMOPS, and RADEXT WGs.
几个IETF工作组处理了网络选择问题的各个方面，包括AAA、EAP、PPP、RADIUS、ROAMOP和RADEXT工作组。
ROAMOPS WG developed the NAI, originally defined in [RFC2486], and subsequently updated in [RFC4282]. Initial roaming implementations are described in [RFC2194], and the use of proxies in roaming is addressed in [RFC2607]. The SEAMOBY WG developed CARD [RFC4066], which assists in discovery of suitable base stations. PKIX WG produced [RFC3280], which addresses issues of certificate selection. The AAA WG developed more sophisticated access routing, authentication, and service discovery mechanisms within Diameter [RFC3588].
ROAMOPS WG开发了NAI，最初在[RFC2486]中定义，随后在[RFC4282]中更新。初始漫游实现在[RFC2194]中进行了描述，漫游中代理的使用在[RFC2607]中进行了说明。SEAMOBY WG开发的卡[RFC4066]，有助于发现合适的基站。PKIX WG生成了[RFC3280]，它解决了证书选择问题。AAA WG在Diameter[RFC3588]中开发了更复杂的访问路由、身份验证和服务发现机制。
Adrangi et al. [RFC4284] defines the use of the EAP-Request/Identity to provide "realm hints" useful for identity selection. The NAI syntax described in [RFC4282] enables the construction of source routes. Together, these mechanisms enable the user to determine whether it possesses an identity and corresponding credential suitable for use with an EAP-capable NAS. This is particularly useful in situations where the lower layer provides limited information (such as in wired IEEE 802 networks where IEEE 802.1X currently does not provide for advertisement of networks and their capabilities).
Adrangi等人[RFC4284]定义了EAP请求/身份的使用，以提供对身份选择有用的“领域提示”。[RFC4282]中描述的NAI语法支持构建源路由。总之，这些机制使用户能够确定其是否拥有适合与支持EAP的NAS一起使用的身份和相应凭证。这在较低层提供有限信息的情况下特别有用（例如在有线IEEE 802网络中，其中IEEE 802.1X目前不提供网络及其功能的广告）。
However, advertisement mechanisms based on the use of the EAP-Request/Identity have scalability problems. As noted in [RFC3748] Section 3.1, the minimum EAP Maximum Transmission Unit (MTU) is 1020 octets, so that an EAP-Request/Identity is only guaranteed to be able to include 1015 octets within the Type-Data field. Since RFC 1035 [RFC1035] enables Fully Qualified Domain Names (FQDN) to be up to 255 octets in length, this may not enable the announcement of many realms. The use of network identifiers other than domain names is also possible.
然而，基于EAP请求/标识使用的广告机制存在可伸缩性问题。如[RFC3748]第3.1节所述，最小EAP最大传输单元（MTU）为1020个八位字节，因此EAP请求/标识只能保证在类型数据字段中包含1015个八位字节。由于RFC1035[RFC1035]允许完全限定域名（FQDN）的长度最多为255个八位字节，因此可能无法宣布许多领域。也可以使用域名以外的网络标识符。
As noted in [Eronen03], the use of the EAP-Request/Identity for realm discovery has substantial negative impact on handoff latency, since this may result in a station needing to initiate an EAP conversation with each Access Point in order to receive an EAP-Request/Identity describing which realms are supported. Since IEEE 802.11-2003 does not support use of Class 1 data frames in State 1 (unauthenticated, unassociated) within an Extended Service Set (ESS), this implies either that the APs must support 802.1X pre-authentication (optional in IEEE 802.11i-2004), or that the station must associate with each
如[N03]中所述，使用EAP请求/标识进行领域发现对切换延迟有很大的负面影响，因为这可能导致站点需要启动与每个接入点的EAP对话，以便接收描述支持哪些领域的EAP请求/标识。由于IEEE 802.11-2003不支持在扩展服务集（ESS）内使用状态1（未经验证、未关联）中的1类数据帧，这意味着AP必须支持802.1X预验证（IEEE 802.11i-2004中可选），或者站点必须与每个状态关联
AP prior to sending an EAPOL-Start to initiate EAP (here, EAPOL refers to EAP over LAN). This will dramatically increase handoff latency.
在发送EAPOL开始启动EAP之前的AP（此处，EAPOL指局域网上的EAP）。这将显著增加切换延迟。
Thus, rather than thinking of [RFC4284] as an effective network discovery mechanism, it is perhaps better to consider the use of "realm hints" as an error recovery technique to be used to inform the EAP peer that AAA routing has failed, and perhaps to enable selection of an alternate identity that can enable successful authentication. Where "realm hints" are only provided in event of a problem, rather than as a staple network discovery technique, it is probably best to enable "realm hints" to be sent by core AAA proxies in the "default free" zone. This way, it will not be necessary for NASes to send "realm hints", which would require them to maintain a complete and up-to-date realm routing table, something that cannot be easily accomplished given the existing state of AAA routing technology.
因此，与其将[RCF424]看作是一种有效的网络发现机制，不如考虑使用“域提示”作为错误恢复技术，用于通知EAP对等方AAA路由失败，并且可能允许选择允许成功认证的替代标识。如果“领域提示”仅在出现问题时提供，而不是作为一种主要的网络发现技术，那么最好是在“无默认”区域启用核心AAA代理发送“领域提示”。这样，NASE就没有必要发送“领域提示”，这将要求它们维护一个完整的、最新的领域路由表，鉴于AAA路由技术的现有状态，这是不容易实现的。
If realm routing tables are manually configured on the NAS, then changes in the "default free" realm routing table will not automatically be reflected in the realm list advertised by the NAS. As a result, a realm advertised by the NAS might not, in fact, be reachable, or the NAS might neglect to advertise one or more realms that were reachable. This could result in multiple EAP-Identity exchanges, with the initial set of "realm hints" supplied by the NAS subsequently updated by "realm hints" provided by a core AAA proxy. In general, originating "realm hints" on core AAA proxies appears to be a more sound approach, since it provides for "fate sharing" -- generation of "realm hints" by the same entity (the core AAA proxy) that will eventually need to route the request based on the hints. This approach is also preferred from a management perspective, since only core AAA proxies would need to be updated; no updates would be required to NAS devices.
如果在NAS上手动配置领域路由表，则“默认免费”领域路由表中的更改不会自动反映在NAS公布的领域列表中。因此，NAS公布的领域实际上可能不可访问，或者NAS可能忽略公布一个或多个可访问的领域。这可能导致多个EAP身份交换，NAS提供的初始“领域提示”集随后由核心AAA代理提供的“领域提示”更新。一般来说，在核心AAA代理上发起“领域提示”似乎是一种更合理的方法，因为它提供了“命运共享”——由最终需要根据提示路由请求的同一实体（核心AAA代理）生成“领域提示”。从管理角度来看，这种方法也是首选的，因为只需要更新核心AAA代理；NAS设备不需要更新。
There has been work in several IEEE 802 working groups relating to network discovery:
多个IEEE 802工作组已经开展了与网络发现相关的工作：
o [IEEE.802.11-2003] defines the Beacon and Probe Response mechanisms within IEEE 802.11. Unfortunately, Beacons may be sent only at a rate within the base rate set, which typically consists of the lowest supported rate, or perhaps the next lowest rate. Studies such as [MACScale] have identified MAC layer performance problems, and [Velayos] has identified scaling issues from a lowering of the Beacon interval.
o [IEEE.802.11-2003]定义了IEEE 802.11中的信标和探测响应机制。不幸的是，信标只能以基本速率集内的速率发送，基本速率集通常包括支持的最低速率，或者可能是下一个最低速率。像[MACScale]这样的研究已经发现了MAC层性能问题，[Velayos]已经发现了信标间隔降低带来的扩展问题。
o [IEEE-11-03-0827] discusses the evolution of authentication models in WLANs and the need for the network to migrate from existing
o [IEEE-11-03-0827]讨论了无线局域网中认证模型的演变以及网络从现有网络迁移的需要
models to new ones, based on either EAP layer indications or through the use of SSIDs to represent more than the local network. It notes the potential need for management or structuring of the SSID space.
基于EAP层指示或通过使用SSID来表示更多的本地网络，将模型转换为新模型。它指出了SSID空间管理或结构的潜在需求。
The paper also notes that virtual APs have scalability issues. It does not compare these scalability issues to those of alternative solutions, however.
论文还指出，虚拟AP存在可伸缩性问题。但是，它没有将这些可伸缩性问题与替代解决方案的可伸缩性问题进行比较。
o [IEEE-11-03-154r1] discusses mechanisms currently used to provide "virtual AP" capabilities within a single physical access point. A "virtual AP" appears at the MAC and IP layers to be a distinct physical AP. As noted in the paper, full compatibility with existing 802.11 station implementations can only be maintained if each "virtual AP" uses a distinct MAC address (BSSID) for use in Beacons and Probe Responses. This paper does not discuss scaling issues in detail, but recommends that only a limited number of "virtual APs" be supported by a single physical access point.
o [IEEE-11-03-154r1]讨论了当前用于在单个物理接入点内提供“虚拟AP”功能的机制。“虚拟AP”出现在MAC层和IP层，是一个不同的物理AP。如本文所述，只有当每个“虚拟AP”在信标和探测响应中使用不同的MAC地址（BSSID）时，才能保持与现有802.11站点实现的完全兼容性。本文不详细讨论扩展问题，但建议单个物理接入点只支持有限数量的“虚拟AP”。
o IEEE 802.11u is working on realm discovery and network selection [11-05-0822-03-000u-tgu-requirements] [IEEE.802.11u]. This includes a mechanism for enabling a station to determine the identities it can use to authenticate to an access network, prior to associating with that network. As noted earlier, solving this problem requires the AP to maintain an up-to-date, "default free" realm routing table, which is not feasible without dynamic routing support within the AAA infrastructure. Similarly, a priori discovery of features supported within home realms (such as enrollment) is also difficult to implement in a scalable way, absent support for dynamic routing. Determination of network capabilities (such as QoS support) is considerably simpler, since these depend solely on the hardware and software contained within the AP. However, 802.11u is working on Generic Advertisement Service (GAS) mechanism, which can be used to carry 802.21 Information Service (IS) messages and, in that way, allow a more sophisticated way of delivering information from the network side.
o IEEE 802.11u正在进行领域发现和网络选择[11-05-0822-03-000u-tgu-requirements][IEEE.802.11u]。这包括一种机制，用于使站点能够在与接入网络关联之前确定其可用于对接入网络进行身份验证的身份。如前所述，解决此问题需要AP维护最新的“无默认”领域路由表，如果没有AAA基础设施内的动态路由支持，这是不可行的。类似地，如果不支持动态路由，家庭领域内支持的功能（如注册）的先验发现也很难以可伸缩的方式实现。确定网络能力（如QoS支持）相当简单，因为这些能力完全取决于AP中包含的硬件和软件。然而，802.11u正在研究通用广告服务（GAS）机制，该机制可用于承载802.21信息服务（is）消息，并以这种方式允许从网络端以更复杂的方式传递信息。
o IEEE 802.21 [IEEE.802.21] is developing standards to enable handover between heterogeneous link layers, including both IEEE 802 and non-IEEE 802 networks. To enable this, a general mechanism for capability advertisement is being developed, which could conceivably benefit aspects of the network selection problem, such as realm discovery. For example, IEEE 802.21 is developing Information Elements (IEs) that may assist with network selection, including information relevant to both layer 2 and layer 3. Query mechanisms (including both XML and TLV support) are also under development. IEEE 802.21 also defines a Resource Description Framework (RDF) schema to allow use of a query
o IEEE 802.21[IEEE.802.21]正在开发标准，以实现异构链路层之间的切换，包括IEEE 802和非IEEE 802网络。为了实现这一点，正在开发一种通用的能力广告机制，这可能会有益于网络选择问题的各个方面，例如领域发现。例如，IEEE 802.21正在开发可能有助于网络选择的信息元素，包括与第2层和第3层相关的信息。查询机制（包括XML和TLV支持）也在开发中。IEEE 802.21还定义了资源描述框架（RDF）模式，以允许使用查询
language (i.e., SPARQL). The schema is a normative part of IEEE 802.21 and also defined in [OHBA].
语言（即SPARQL）。该模式是IEEE 802.21的规范性部分，在[OHBA]中也有定义。
The 3GPP stage 2 technical specification [3GPPSA2WLANTS] covers the architecture of 3GPP Interworking WLAN (I-WLAN) with 2G and 3G networks. This specification also discusses realm discovery and network selection issues. The I-WLAN realm discovery procedure borrows ideas from the cellular Public Land-based Mobile Network (PLMN) selection principles, known as "PLMN Selection".
3GPP第2阶段技术规范[3GPPSA2WLANTS]涵盖了3GPP互通WLAN（I-WLAN）与2G和3G网络的体系结构。本规范还讨论领域发现和网络选择问题。I-WLAN领域发现程序借鉴了蜂窝公共陆地移动网络（PLMN）选择原则的思想，称为“PLMN选择”。
In 3GPP PLMN selection [3GPP.23.122], the mobile node monitors surrounding cells and prioritizes them based on signal strength before selecting a new potential target cell. Each cell broadcasts its PLMN. A mobile node may automatically select cells that belong to its Home PLMN, Registered PLMN, or an allowed set of Visited PLMNs. The PLMN lists are prioritized and stored in the Subscriber Identity Module (SIM). In the case of manual PLMN selection, the mobile node lists the PLMNs it learns about from surrounding cells and enables the user to choose the desired PLMN. After the PLMN has been selected, cell prioritization takes place in order to select the appropriate target cell.
在3GPP PLMN选择[3GPP.23.122]中，移动节点监视周围小区，并在选择新的潜在目标小区之前基于信号强度对其进行优先级排序。每个小区广播其PLMN。移动节点可以自动选择属于其归属的PLMN、注册的PLMN或所访问的PLMN的允许集合的小区。PLMN列表按优先级排列并存储在用户识别模块（SIM）中。在手动PLMN选择的情况下，移动节点列出它从周围小区了解到的PLMN，并使用户能够选择所需的PLMN。选择PLMN后，进行单元优先级排序，以选择适当的目标单元。
[WLAN3G] discusses the new realm (PLMN) selection requirements introduced by I-WLAN roaming, which support automatic PLMN selection, not just manual selection. Multiple network levels may be present, and the hotspot owner may have a contract with a provider who, in turn, has a contract with a 3G network, which may have a roaming agreement with other networks.
[WLAN3G]讨论了I-WLAN漫游引入的新领域（PLMN）选择要求，它支持自动PLMN选择，而不仅仅是手动选择。可能存在多个网络级别，热点所有者可能与提供商签订合同，而提供商又与3G网络签订合同，3G网络可能与其他网络签订漫游协议。
The I-WLAN specification requires that network discovery be performed as specified in the relevant WLAN link layer standards. In addition to network discovery, it is necessary to select intermediary realms to enable construction of source routes. In 3GPP, the intermediary networks are PLMNs, and it is assumed that an access network may have a roaming agreement with more than one PLMN. The PLMN may be a Home PLMN (HPLMN) or a Visited PLMN (VPLMN), where roaming is supported. GSM/UMTS roaming principles are employed for routing AAA requests from the VPLMN to the Home Public Land-based Mobile Network (HPLMN) using either RADIUS or Diameter. The procedure for selecting the intermediary network has been specified in the stage 3 technical specifications [3GPPCT1WLANTS] and [3GPPCT4WLANTS].
I-WLAN规范要求按照相关WLAN链路层标准中的规定执行网络发现。除了网络发现之外，还需要选择中间领域来构建源路由。在3GPP中，中间网络是PLMN，并且假设接入网络可以具有与多个PLMN的漫游协议。PLMN可以是支持漫游的归属PLMN（HPLMN）或到访PLMN（VPLMN）。GSM/UMTS漫游原则用于使用半径或直径将AAA请求从VPLMN路由到家庭公共陆地移动网络（HPLMN）。第3阶段技术规范[3GPPCT1WLANTS]和[3GPPCT4WLANTS]中规定了选择中间网络的程序。
In order to select the PLMN, the following procedure is required:
要选择PLMN，需要以下步骤：
o The user may choose the desired HPLMN or VPLMN manually or let the WLAN User Equipment (WLAN UE) choose the PLMN automatically, based on user and operator defined preferences.
o 用户可以手动选择所需的HPLMN或VPLMN，或者让WLAN用户设备（WLAN UE）根据用户和运营商定义的偏好自动选择PLMN。
o AAA messages are routed based on the decorated or undecorated NAI.
o AAA消息根据修饰或未修饰的NAI进行路由。
o EAP is utilized as defined in [RFC3748] and [RFC3579].
o 按照[RFC3748]和[RFC3579]中的定义使用EAP。
o PLMN advertisement and selection is based on [RFC4284], which defines only realm advertisement. The document refers to the potential need for extensibility, though EAP MTU restrictions make this difficult.
o PLMN广告和选择基于[RFC4284]，它仅定义领域广告。该文档提到了对扩展性的潜在需求，尽管EAP MTU的限制使这一点变得困难。
The I-WLAN specification states that "realm hints" are only provided when an unreachable realm is encountered. Where VPLMN control is required, this is handled via NAI decoration. The station may manually trigger PLMN advertisement by including an unknown realm (known as the Alternative NAI) within the EAP-Response/Identity. A realm guaranteed not to be reachable within 3GPP networks is utilized for this purpose.
I-WLAN规范规定，“领域提示”仅在遇到无法访问的领域时提供。如果需要VPLMN控制，则通过NAI装饰处理。站点可以通过在EAP响应/标识中包括未知领域（称为备选NAI）来手动触发PLMN广告。保证在3GPP网络内不可到达的领域用于此目的。
The I-WLAN security requirements are described in the 3GPP stage 3 technical specification [3GPPSA3WLANTS]. The security requirements for PLMN selection are discussed in 3GPP contribution [3GPP-SA3-030736], which concludes that both SSID and EAP-based mechanisms have similar security weaknesses. As a result, it recommends that PLMN advertisements should be considered as hints.
I-WLAN安全要求在3GPP第3阶段技术规范[3GPPSA3WLANTS]中描述。3GPP贡献[3GPP-SA3-030736]中讨论了PLMN选择的安全要求，其结论是基于SSID和EAP的机制都有类似的安全弱点。因此，它建议将PLMN广告视为提示。
[INTELe2e] discusses the need for realm selection where an access network may have more than one roaming relationship path to a home realm. It also describes solutions to the realm selection problem based on EAP, SSID and Protected EAP (PEAP) based mechanisms.
[INTELe2e]讨论了在接入网络可能有多条到归属域的漫游关系路径的情况下选择域的必要性。它还描述了基于EAP、SSID和基于保护EAP（PEAP）机制的领域选择问题的解决方案。
Eijk et al. [WWRF-ANS] discusses the realm and network selection problem. The authors concentrate primarily on discovery of access networks meeting a set of criteria, noting that information on the realm capabilities and reachability inherently resides in home AAA servers, and therefore it is not readily available in a central location, and may not be easily obtained by NAS devices.
Eijk等人[WWRF-ANS]讨论了领域和网络选择问题。作者主要集中于发现满足一组标准的接入网络，指出领域能力和可达性的信息固有地驻留在家庭AAA服务器中，因此在中心位置不容易获得，NAS设备可能不容易获得。
The authors of this document would like to especially acknowledge the contributions of Farid Adrangi, Michael Richardson, Pasi Eronen, Mark Watson, Mark Grayson, Johan Rune, and Tomas Goldbeck-Lowe.
本文作者特别感谢Farid Adrangi、Michael Richardson、Pasi Eronen、Mark Watson、Mark Grayson、Johan Rune和Tomas Goldbeck Lowe的贡献。
Input for the early versions of this document has been gathered from many sources, including the above persons as well as 3GPP and IEEE developments. We would also like to thank Alper Yegin, Victor Lortz, Stephen Hayes, and David Johnston for comments.
本文档早期版本的输入来自多个来源，包括上述人员以及3GPP和IEEE开发人员。我们还要感谢阿尔珀·耶金、维克多·洛茨、斯蒂芬·海斯和大卫·约翰斯顿的评论。
Jouni Korhonen would like to thank the Academy of Finland for providing funding to work on this document.
Jouni Korhonen感谢芬兰科学院为编写本文件提供资金。
Authors' Addresses
作者地址
Jari Arkko Ericsson Jorvas 02420 Finland
雅丽爱立信芬兰公司02420
EMail: jari.arkko@ericsson.com
EMail: jari.arkko@ericsson.com
Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 USA
Bernard Aboba微软一路微软美国华盛顿州雷德蒙98052
EMail: bernarda@microsoft.com
EMail: bernarda@microsoft.com
Jouni Korhonen TeliaSonera Teollisuuskatu 13 Sonera FIN-00051 Finland
Jouni Korhonen TeliaSonera Teollisuuskatu 13 Sonera FIN-00051芬兰
EMail: jouni.korhonen@teliasonera.com
EMail: jouni.korhonen@teliasonera.com
Farooq Bari AT&T 7277 164th Avenue N.E. Redmond WA 98052 USA
美国华盛顿州雷德蒙东北164大街7277号法鲁克巴里电话电报公司98052
EMail: farooq.bari@att.com
EMail: farooq.bari@att.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.