Internet Engineering Task Force (IETF) R. Valmikam
Request for Comments: 7458 Unaffiliated
Category: Informational R. Koodli
ISSN: 2070-1721 Intel
February 2015
Internet Engineering Task Force (IETF) R. Valmikam
Request for Comments: 7458 Unaffiliated
Category: Informational R. Koodli
ISSN: 2070-1721 Intel
February 2015
Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core
可扩展身份验证协议（EAP）属性，用于与演进包核心的Wi-Fi集成
Abstract
摘要
With Wi-Fi emerging as a crucial access network for mobile service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections, and seamless mobility between Wi-Fi and 3G/4G networks.
随着Wi-Fi逐渐成为移动服务提供商的关键接入网络，在Wi-Fi接入网络中提供3G和4G网络中常见的功能也变得非常重要。这些功能包括接入点名称（APN）选择、多分组数据网络（PDN）连接以及Wi-Fi和3G/4G网络之间的无缝移动。
The EAP Authentication and Key Agreement (EAP-AKA), and EAP-AKA', protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via Wi-Fi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in such networks. The attributes are exchanged between a client (such as a Mobile Node (MN)) and its network counterpart (such as an Authentication, Authorization, and Accounting (AAA) server) in the service provider's infrastructure.
移动设备需要EAP认证和密钥协议（EAP-AKA）和EAP-AKA'协议，才能通过Wi-Fi网络访问移动演进包核心（EPC）。本文档定义了一些新的EAP属性，以在此类网络中启用上述功能。在服务提供商的基础设施中，在客户端（例如移动节点（MN））与其网络对应方（例如认证、授权和计费（AAA）服务器）之间交换属性。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7458.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7458.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. APN Selection ..............................................4
1.2. Multiple APN Connectivity ..................................4
1.3. Wi-Fi to E-UTRAN Mobility ..................................4
2. Terminology .....................................................4
3. Protocol Overview ...............................................5
3.1. Brief Introduction to EAP ..................................5
3.2. IEEE 802.11 Authentication Using EAP over 802.1X ...........5
4. New EAP Attributes ..............................................7
4.1. APN Selection ..............................................7
4.2. Connectivity Type ..........................................7
4.3. Wi-Fi to UTRAN/E-UTRAN Mobility ............................8
4.4. MN Serial ID ...............................................8
5. Attribute Extensions ............................................8
5.1. AT_VIRTUAL_NETWORK_ID ......................................8
5.2. AT_VIRTUAL_NETWORK_REQ .....................................9
5.3. AT_CONNECTIVITY_TYPE ......................................10
5.4. AT_HANDOVER_INDICATION ....................................11
5.5. AT_HANDOVER_SESSION_ID ....................................11
5.6. AT_MN_SERIAL_ID ...........................................12
6. Security Considerations ........................................13
7. IANA Considerations ............................................14
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
Acknowledgments ...................................................18
Authors' Addresses ................................................18
1. Introduction ....................................................3
1.1. APN Selection ..............................................4
1.2. Multiple APN Connectivity ..................................4
1.3. Wi-Fi to E-UTRAN Mobility ..................................4
2. Terminology .....................................................4
3. Protocol Overview ...............................................5
3.1. Brief Introduction to EAP ..................................5
3.2. IEEE 802.11 Authentication Using EAP over 802.1X ...........5
4. New EAP Attributes ..............................................7
4.1. APN Selection ..............................................7
4.2. Connectivity Type ..........................................7
4.3. Wi-Fi to UTRAN/E-UTRAN Mobility ............................8
4.4. MN Serial ID ...............................................8
5. Attribute Extensions ............................................8
5.1. AT_VIRTUAL_NETWORK_ID ......................................8
5.2. AT_VIRTUAL_NETWORK_REQ .....................................9
5.3. AT_CONNECTIVITY_TYPE ......................................10
5.4. AT_HANDOVER_INDICATION ....................................11
5.5. AT_HANDOVER_SESSION_ID ....................................11
5.6. AT_MN_SERIAL_ID ...........................................12
6. Security Considerations ........................................13
7. IANA Considerations ............................................14
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
Acknowledgments ...................................................18
Authors' Addresses ................................................18
Wi-Fi has emerged as a "trusted" access technology for mobile service providers; see [EPC2] for reference to the 3rd Generation Partnership Project (3GPP) description of "trusted" access. Advances in IEEE 802.11u [IEEE802.11u] and "HotSpot 2.0" [hs20] have enabled seamless roaming, in which a Mobile Node can select and connect to a Wi-Fi access network just as it would roam into a cellular network. It has thus become important to provide certain functions in Wi-Fi that are commonly supported in licensed-spectrum networks such as 3G and 4G networks. This document specifies a few new EAP attributes for an MN to interact with the network to support some of these functions (see below). These new attributes serve as a trigger for Proxy Mobile IPv6 network nodes to undertake the relevant mobility operations. For instance, when the MN requests a new IP session (i.e., a new APN in 3GPP) and the network agrees, the corresponding attribute (defined below) acts as a trigger for the Mobile Anchor Gateway (MAG) to initiate a new mobility session with the Local Mobility Anchor (LMA). This document refers to [RFC6459] for the basic definitions of mobile network terminology (such as APN) used here.
Wi-Fi已成为移动服务提供商的“可信”接入技术；有关第三代合作伙伴关系项目（3GPP）“受信任”访问的描述，请参见[EPC2]。IEEE 802.11u[IEEE802.11u]和“热点2.0”[hs20]的进步实现了无缝漫游，移动节点可以选择并连接到Wi-Fi接入网络，就像漫游到蜂窝网络一样。因此，在Wi-Fi中提供某些功能变得非常重要，这些功能通常在3G和4G网络等许可频谱网络中得到支持。本文档为MN指定了几个新的EAP属性，以便与网络交互以支持其中一些功能（见下文）。这些新属性充当代理移动IPv6网络节点执行相关移动操作的触发器。例如，当MN请求新的IP会话（即，3GPP中的新APN）并且网络同意时，相应的属性（定义如下）充当移动锚网关（MAG）的触发器，以发起与本地移动锚（LMA）的新移动会话。本文件参考[RFC6459]，了解此处使用的移动网络术语（如APN）的基本定义。
The 3GPP networks support many functions that are not commonly implemented in a Wi-Fi network. This document defines EAP attributes that enable the following functions in Wi-Fi access networks using EAP-AKA [RFC4187] and EAP-AKA' [RFC5448]:
3GPP网络支持在Wi-Fi网络中通常不实现的许多功能。本文档定义了使用EAP-AKA[RFC4187]和EAP-AKA'[RFC5448]在Wi-Fi接入网络中启用以下功能的EAP属性：
o APN Selection
o APN选择
o Multiple APN Connectivity
o 多APN连接
o Wi-Fi to 3G/4G (Universal Terrestrial Radio Access Network (UTRAN) / Evolved UTRAN (E-UTRAN)) mobility
o Wi-Fi到3G/4G（通用地面无线接入网（UTRAN）/演进型UTRAN（E-UTRAN））移动性
The attributes defined here are exchanged between the MN and the EAP server, typically realized as part of the AAA server infrastructure in a service provider's infrastructure. In particular, the Wi-Fi access network simply conveys the attributes to the service provider's core network where the EAP processing takes place [EPC]. Since these attributes share the same IANA registry, the methods are applicable to EAP-AKA, EAP-AKA', EAP Subscriber Identity Modules (EAP-SIM) [RFC4186], and with appropriate extensions, are possibly applicable for other EAP methods as well. In addition to the trusted Wi-Fi access networks, the attributes are applicable to any trusted "non-3GPP" access network that uses the EAP methods and provides connectivity to the mobile EPC, which provides connectivity for 3G, 4G, and other non-3GPP access networks [EPC2].
此处定义的属性在MN和EAP服务器之间交换，通常作为服务提供商基础设施中AAA服务器基础设施的一部分实现。特别是，Wi-Fi接入网络简单地将这些属性传送到进行EAP处理的服务提供商的核心网络[EPC]。由于这些属性共享相同的IANA注册表，因此这些方法适用于EAP-AKA、EAP-AKA'，EAP订户标识模块（EAP-SIM）[RFC4186]，并且具有适当的扩展，可能也适用于其他EAP方法。除了受信任的Wi-Fi接入网络外，这些属性还适用于使用EAP方法并提供与移动EPC连接的任何受信任的“非3GPP”接入网络，移动EPC为3G、4G和其他非3GPP接入网络提供连接[EPC2]。
The 3GPP networks support the concept of an APN. This is defined in [GPRS]. Each APN is an independent IP network with its own set of IP services. When the MN attaches to the network, it may select a specific APN to receive desired services. For example, to receive generic Internet services, a user device may select APN "Internet"; and to receive IP Multimedia Subsystems (IMS) voice services, it may select APN "IMSvoice".
3GPP网络支持APN的概念。这在[GPRS]中定义。每个APN都是一个独立的IP网络，具有自己的IP服务集。当MN连接到网络时，它可以选择特定的APN来接收期望的服务。例如，为了接收通用因特网服务，用户设备可以选择APN“因特网”；为了接收IP多媒体子系统（IMS）语音服务，它可以选择APN“IMS语音”。
In a Wi-Fi access scenario, an MN needs a way of sending the desired APN name to the network. This document specifies a new attribute to propagate the APN information via EAP. The agreed APN is necessary for the Proxy Mobile IPv6 MAG to initiate a new session with the LMA.
在Wi-Fi接入场景中，MN需要一种向网络发送所需APN名称的方式。本文档指定了通过EAP传播APN信息的新属性。商定的APN对于代理移动IPv6 MAG启动与LMA的新会话是必要的。
As an extension of APN Selection, an MN may choose to connect to multiple IP networks simultaneously. 3GPP provides this feature via additional Packet Data Protocol (PDP) contexts or additional Packet Data Network (PDN) connections and defines the corresponding set of signaling procedures. In a trusted Wi-Fi network, an MN connects to the first APN via DHCPv4 or IPv6 Router Solicitation. This document specifies an attribute that indicates the MN's capability to support multiple APN connectivity. The specific connectivity types are also necessary for the Proxy Mobile IPv6 signaling.
作为APN选择的扩展，MN可以选择同时连接到多个IP网络。3GPP通过附加分组数据协议（PDP）上下文或附加分组数据网络（PDN）连接提供该特性，并定义相应的信令过程集。在可信Wi-Fi网络中，MN通过DHCPv4或IPv6路由器请求连接到第一个APN。本文档指定了一个属性，该属性指示MN支持多个APN连接的能力。代理移动IPv6信令也需要特定的连接类型。
When operating in a multiaccess network, an MN may want to gracefully handover its IP attachment from one access network to another. For instance, an MN connected to a 3GPP E-UTRAN network may choose to move its connectivity to a trusted Wi-Fi network. Alternatively, the MN may choose to connect using both access technologies simultaneously and maintain two independent IP attachments. To implement these scenarios, the MN needs a way to correlate the UTRAN/ E-UTRAN session with the new Wi-Fi session. This document specifies an attribute to propagate E-UTRAN session identification to the network via EAP. This helps the network to correlate the sessions between the two Radio Access Network (RAN) technologies and thus helps the overall handover process.
当在多址网络中操作时，MN可能希望将其IP连接从一个接入网络优雅地切换到另一个接入网络。例如，连接到3GPP E-UTRAN网络的MN可以选择将其连接移动到可信Wi-Fi网络。或者，MN可以选择同时使用两种接入技术进行连接，并维护两个独立的IP附件。为了实现这些场景，MN需要一种将UTRAN/E-UTRAN会话与新的Wi-Fi会话相关联的方法。本文档指定了通过EAP将E-UTRAN会话标识传播到网络的属性。这有助于网络将两种无线接入网络（RAN）技术之间的会话关联起来，从而有助于整个切换过程。
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]中所述进行解释。
EAP is defined as a generic protocol in [RFC3748]. EAP, combined with one of the payload protocols such as EAP-AKA' [RFC5448] can accomplish several things in a network:
EAP在[RFC3748]中定义为通用协议。EAP与EAP-AKA'[RFC5448]等有效负载协议之一相结合，可在网络中完成多项任务：
o Establish the identity of the user (MN) to the network.
o 向网络建立用户（MN）的身份。
o Authenticate the user during the first attach with the help of an authentication center that securely maintains the user credentials. This process is called "EAP Authentication".
o 在安全维护用户凭据的身份验证中心的帮助下，在首次连接期间对用户进行身份验证。此过程称为“EAP身份验证”。
o Re-authenticate the user periodically, but without the overhead of a round-trip to the authentication center. This process is called "EAP Fast Re-Authentication".
o 定期重新验证用户，但不需要往返验证中心的开销。此过程称为“EAP快速重新认证”。
This document makes use of the EAP Authentication procedure. The use of the EAP Fast Re-Authentication procedure is for further study. Both the EAP Authentication and EAP Fast Re-Authentication procedures are specified for trusted access network use in 3GPP[TS-33.402].
本文件使用EAP认证程序。EAP快速重新认证程序的使用有待进一步研究。在3GPP[TS-33.402]中，EAP认证和EAP快速重新认证过程都被指定用于可信接入网络。
In a Wi-Fi network, EAP is carried over the IEEE 802.1X Authentication protocol. The IEEE 802.1X Authentication is a transparent, payload-unaware mechanism to carry the authentication messages between the MN and the Wi-Fi network elements.
在Wi-Fi网络中，EAP通过IEEE 802.1X认证协议传输。IEEE 802.1X身份验证是一种透明的、不知道有效负载的机制，用于在MN和Wi-Fi网络元件之间传输身份验证消息。
EAP, on the other hand, has multiple purposes. Apart from its core functions of communicating an MN's credentials to the network and proving the MN's identity, it also allows the MN to send arbitrary information elements to help establish the MN's IP session in the network. Figure 1 shows an example of end-to-end EAP flow in the context of an IEEE 802.11 Wi-Fi network. We first define the terminology:
另一方面，EAP有多种用途。除了将MN的凭证传送到网络和证明MN身份的核心功能外，它还允许MN发送任意信息元素以帮助在网络中建立MN的IP会话。图1显示了IEEE 802.11 Wi-Fi网络环境中端到端EAP流的示例。我们首先定义术语：
o MN: Mobile Node
o 移动节点
o WAN: Wi-Fi Access Node, typically consisting of Wi-Fi Access Point and Wi-Fi Controller. The CAPWAP [RFC5415] protocol allows these functions to be realized in separate physical nodes or in a single node. In a Proxy Mobile IPv6 (PMIPv6) [RFC5213] network, the MAG functionality is located in the WAN, either in the Wi-Fi Access Point or in the Wi-Fi Controller.
o 广域网：Wi-Fi接入节点，通常由Wi-Fi接入点和Wi-Fi控制器组成。CAPWAP[RFC5415]协议允许在单独的物理节点或单个节点中实现这些功能。在代理移动IPv6（PMIPv6）[RFC5213]网络中，MAG功能位于WAN中，位于Wi-Fi接入点或Wi-Fi控制器中。
o AAA: The infrastructure node supporting the AAA server with the EAP methods (AKA, AKA', EAP-SIM). The endpoints of the EAP method are the MN and the AAA server.
o AAA：使用EAP方法（AKA，AKA'，EAP-SIM）支持AAA服务器的基础结构节点。EAP方法的端点是MN和AAA服务器。
o IPCN: IP Core Network. This includes the PMIPv6 LMA function.
o IPCN：IP核心网络。这包括PMIPv6 LMA功能。
MN WAN AAA IPCN
(MAG) (LMA)
1)|<----------Beacon--------| | |
2)|<----------Probe-------->| | |
| | | |
| 802.11 Auth| | |
3)|<----------------------->| | |
| | | |
| 802.11 Association| | |
4)|<----------------------->| | |
| | | |
5)|<----EAP Req/Identity----| | |
| | | |
6)|----EAP Resp/Identity----|->--EAP Resp/Identity--->| |
| | | |
7)|<-EAP Req/AKA-Challenge<-|--EAP Req/AKA-Challenge--| |
| | | |
8)|-EAP Resp/AKA-Challenge--|>EAP Resp/AKA-Challenge->| |
| | | |
9)|<-----EAP Success------<-|------EAP Success--------| |
| | | |
10)|<====== 802.11 Data ====>|<========== 802.11 Data ====Tunnel to=>|
| | | core network|
| | | |
MN WAN AAA IPCN
(MAG) (LMA)
1)|<----------Beacon--------| | |
2)|<----------Probe-------->| | |
| | | |
| 802.11 Auth| | |
3)|<----------------------->| | |
| | | |
| 802.11 Association| | |
4)|<----------------------->| | |
| | | |
5)|<----EAP Req/Identity----| | |
| | | |
6)|----EAP Resp/Identity----|->--EAP Resp/Identity--->| |
| | | |
7)|<-EAP Req/AKA-Challenge<-|--EAP Req/AKA-Challenge--| |
| | | |
8)|-EAP Resp/AKA-Challenge--|>EAP Resp/AKA-Challenge->| |
| | | |
9)|<-----EAP Success------<-|------EAP Success--------| |
| | | |
10)|<====== 802.11 Data ====>|<========== 802.11 Data ====Tunnel to=>|
| | | core network|
| | | |
Figure 1: Example EAP Deployment
图1：EAP部署示例
1. An MN detects a beacon from a WAP in the vicinity.
1. MN从附近的WAP检测到信标。
2. The MN probes the WAP to determine suitability to attach (Verify Service Set Identifier (SSID) list, authentication type, and so on).
2. MN探测WAP以确定是否适合附加（验证服务集标识符（SSID）列表、身份验证类型等）。
3. The MN initiates the IEEE 802.11 Authentication with the Wi-Fi network. In Wi-Fi Protected Access (WPA) / WPA2 mode, this is an open authentication without any security credential verification.
3. MN通过Wi-Fi网络发起IEEE 802.11认证。在Wi-Fi保护访问（WPA）/WPA2模式下，这是一种开放式身份验证，无需任何安全凭据验证。
4. The MN initiates 802.11 Association with the Wi-Fi network.
4. MN发起802.11与Wi-Fi网络的关联。
5. The Wi-Fi network initiates 802.1X/EAP Authentication procedures by sending EAP Request/Identity.
5. Wi-Fi网络通过发送EAP请求/标识来启动802.1X/EAP身份验证过程。
6. The MN responds with its permanent or temporary identity.
6. MN以其永久或临时标识进行响应。
7. The Wi-Fi network challenges the MN to prove its identity by sending EAP Request/AKA-Challenge.
7. Wi-Fi网络通过发送EAP请求/AKA质询来质询MN以证明其身份。
8. The MN calculates the security digest and responds with EAP Response/AKA-Challenge.
8. MN计算安全摘要并使用EAP响应/AKA质询进行响应。
9. If the authentication is successful, the Wi-Fi network responds to the MN with EAP Success.
9. 如果身份验证成功，Wi-Fi网络将以EAP Success响应MN。
10. An end-to-end data path is available for the MN to start IP layer communication (DHCPv4, IPv6 Router Solicitation, and so on).
10. MN可以使用端到端数据路径来启动IP层通信（DHCPv4、IPv6路由器请求等）。
The following subsections define the new EAP attributes and their usage.
以下小节定义了新的EAP属性及其用法。
In a Wi-Fi network, an MN includes the AT_VIRTUAL_NETWORK_ID attribute in the EAP-Response/AKA-Challenge to indicate the desired APN identity for the first PDN connection.
在Wi-Fi网络中，MN在EAP响应/AKA质询中包括AT_VIRTUAL_network_ID属性，以指示第一个PDN连接所需的APN标识。
If the MN does not include the AT_VIRTUAL_NETWORK_ID attribute in the EAP-Response/AKA-Challenge, the network may select an APN by other means. This selection mechanism is outside the scope of this document.
如果MN在EAP响应/AKA质询中不包括AT_VIRTUAL_NETWORK_ID属性，则网络可以通过其他方式选择APN。此选择机制不在本文档的范围内。
An MN includes the AT_VIRTUAL_NETWORK_REQ attribute to indicate single or multiple PDN capability. In addition, a Sub type in the attribute indicates IPv4, IPv6, or dual IPv4v6 PDN connectivity.
MN包括AT_VIRTUAL_NETWORK_REQ属性以指示单个或多个PDN能力。此外，属性中的子类型表示IPv4、IPv6或双IPv4v6 PDN连接。
An MN indicates its preference for connectivity using the AT_CONNECTIVITY_TYPE attribute in the EAP-Response/AKA-Challenge message. The preference indicates whether the MN wishes connectivity to the Evolved Packet Core (the so-called "EPC PDN connectivity") or Internet Offload (termed as "Non-Seamless Wireless Offload").
MN使用EAP响应/AKA质询消息中的AT_connectivity_TYPE属性指示其连接偏好。首选项指示MN是希望连接到演进的分组核心（所谓的“EPC-PDN连接”）还是因特网卸载（称为“非无缝无线卸载”）。
The network makes its decision and replies with the same attribute in the EAP Success message.
网络做出决定并在EAP成功消息中使用相同的属性进行回复。
When a multiaccess MN enters a Wi-Fi network, the following parameters are applicable in the EAP-Response/AKA-Challenge for IP session continuity from UTRAN/E-UTRAN.
当多址MN进入Wi-Fi网络时，以下参数适用于来自UTRAN/E-UTRAN的IP会话连续性EAP响应/AKA质询。
o AT_HANDOVER_INDICATION: This attribute indicates to the network that the MN intends to continue the IP session from UTRAN/E-UTRAN. If a previous session can be located, the network will honor this request by connecting the Wi-Fi access to the existing IP session.
o AT_切换_指示：该属性向网络指示MN打算从UTRAN/E-UTRAN继续IP会话。如果可以找到以前的会话，网络将通过将Wi-Fi接入连接到现有IP会话来满足此请求。
o AT_HANDOVER_SESSION_ID: An MN MAY use this attribute to identify the session on UTRAN/E-UTRAN. If used, this attribute contains Packet Temporary Mobile Subscriber Identity (P-TMSI) if the previous session was on UTRAN; if the previous session was on E-UTRAN, it contains Mobile Temporary Mobile Subscriber Identity (M-TMSI). This attribute helps the network correlate the Wi-Fi session to an existing UTRAN/E-UTRAN session.
o AT_切换_会话_ID：MN可以使用该属性来标识UTRAN/E-UTRAN上的会话。如果使用，该属性包含数据包临时移动用户标识（P-TMSI），前提是前一个会话在UTRAN上；如果上一个会话在E-UTRAN上，则它包含移动临时移动用户标识（M-TMSI）。此属性有助于网络将Wi-Fi会话与现有UTRAN/E-UTRAN会话关联起来。
The MN_SERIAL_ID attribute defines an MN's serial number, including International Mobile Equipment Identity (IMEI) and International Mobile Equipment Identity Software Version (IMEISV). The IMEI (or IMEISV) is used for ensuring a legitimate (and not a stolen) device is in use. As with the others, this attribute is exchanged with the service provider's AAA server. The MN_SERIAL_ID MUST NOT be propagated further by the AAA server to any other node.
MN_SERIAL_ID属性定义MN的序列号，包括国际移动设备标识（IMEI）和国际移动设备标识软件版本（IMEISV）。IMEI（或IMEISV）用于确保使用合法（而非被盗）设备。与其他属性一样，此属性与服务提供商的AAA服务器交换。AAA服务器不得将MN_串行_ID进一步传播到任何其他节点。
The format for the new attributes follows that in [RFC4187]. Note that the Length field value is inclusive of the first two bytes.
新属性的格式遵循[RFC4187]中的格式。请注意，长度字段值包含前两个字节。
The AT_VIRTUAL_NETWORK_ID attribute identifies the virtual IP network to which the MN intends to attach. The implementation of the virtual network on the core network side is technology specific. For instance, in a 3GPP network, the virtual network is implemented based on the 3GPP APN primitive.
AT_VIRTUAL_NETWORK_ID属性标识MN打算连接到的虚拟IP网络。核心网络端虚拟网络的实现是特定于技术的。例如，在3GPP网络中，基于3GPP APN原语实现虚拟网络。
This attribute SHOULD be included in the EAP-Response/AKA-Challenge message.
此属性应包含在EAP响应/AKA质询消息中。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_VIRTUAL | Length | Virtual Network Id |
| _NETWORK_ID | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Network Id |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_VIRTUAL | Length | Virtual Network Id |
| _NETWORK_ID | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Network Id |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: AT_VIRTUAL_NETWORK_ID EAP Attribute
图2:AT_虚拟_网络_ID EAP属性
Virtual Network Id:
虚拟网络Id:
An arbitrary octet string that identifies a virtual network in the access technology to which the MN is attaching. For instance, in 3GPP E-UTRAN, this could be an APN. See [TS-23.003] for encoding of the field.
在MN所连接的接入技术中标识虚拟网络的任意八位字节字符串。例如，在3GPP E-UTRAN中，这可以是APN。字段编码见[TS-23.003]。
When an MN intends to connect an APN, it SHOULD use this attribute to indicate different capabilities to the network. In turn, the network provides what is supported.
当MN打算连接APN时，它应该使用此属性向网络指示不同的能力。反过来，网络提供所支持的内容。
From the MN, this attribute can be included only in EAP-Response/ Identity. From the network, it SHOULD be included in the EAP Request/AKA-Challenge message. In the MN-to-network direction, the Type field (below) indicates the MN's request. In the network-to-MN direction, the Type field indicates the network's willingness to support the request; a present Type field value indicates the network support for that Type.
从MN中，此属性只能包含在EAP响应/标识中。从网络上，它应该包含在EAP请求/AKA质询消息中。在MN到网络的方向上，类型字段（下面）表示MN的请求。在网络到MN方向，类型字段表示网络愿意支持请求；“当前类型”字段值表示该类型的网络支持。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_VIRTUAL_ | Length | Virt-Net-Req | Virt-Net-Req |
|NETWORK_REQ | | Type | Sub type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_VIRTUAL_ | Length | Virt-Net-Req | Virt-Net-Req |
|NETWORK_REQ | | Type | Sub type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: AT_VIRTUAL_NETWORK_REQ EAP Attribute
图3:AT_虚拟_网络_请求EAP属性
Virt-Net-Req Type:
虚拟网络请求类型：
Type can have one of the following values:
类型可以具有以下值之一：
o 0: Reserved
o 0:保留
o 1: Single PDN connection
o 1：单PDN连接
o 2: Multiple PDN connection. Can request Non-Seamless Wi-Fi Offload or EPC connectivity (see the Connectivity Type attribute below)
o 2：多个PDN连接。可以请求非无缝Wi-Fi卸载或EPC连接（请参阅下面的连接类型属性）
Virt-Net-Req Sub type:
Virt网络请求子类型：
Sub type can have one of the following values:
子类型可以具有以下值之一：
o 0: Reserved
o 0:保留
o 1: PDN Type: IPv4
o 1:PDN类型：IPv4
o 2: PDN Type: IPv6
o 2:PDN类型：IPv6
o 3: PDN Type: IPv4v6
o 3:PDN类型：IPv4v6
An MN uses this attribute to indicate whether it wishes the connectivity type to be Non-Seamless WLAN Offload or EPC. This attribute is applicable for multiple PDN connections only.
MN使用此属性指示其希望连接类型是非无缝WLAN卸载还是EPC。此属性仅适用于多个PDN连接。
From the MN, this attribute can be included only in EAP-Response/ Identity. From the network, it SHOULD be included in the EAP Request/AKA-Challenge message.
从MN中，此属性只能包含在EAP响应/标识中。从网络上，它应该包含在EAP请求/AKA质询消息中。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_CONNECTIVITY| Length | Connectivity | Reserved |
|_TYPE | | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_CONNECTIVITY| Length | Connectivity | Reserved |
|_TYPE | | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: AT_CONNECTIVITY_TYPE EAP Attribute
图4:AT_连接类型EAP属性
Connectivity Type:
连接类型：
Connectivity Type can have one of the following values:
连接类型可以具有以下值之一：
o 0: Reserved
o 0:保留
o 1: Non-Seamless WLAN Offload (NSWO)
o 1：非无缝WLAN卸载（NSWO）
o 2: EPC PDN connectivity
o 2:EPC PDN连接
This attribute indicates an MN's handover intention of an existing IP attachment.
此属性表示MN对现有IP附件的切换意图。
This attribute SHOULD be included in the EAP-Response/AKA-Challenge message.
此属性应包含在EAP响应/AKA质询消息中。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_HANDOVER_IND| Length | Handover | Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_HANDOVER_IND| Length | Handover | Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: AT_HANDOVER_INDICATION EAP Attribute
图5:AT_移交指示EAP属性
Handover Type:
移交类型：
o 0 - The MN has no intention of handing over an existing IP session, i.e., the MN is requesting an independent IP session with the Wi-Fi network without disrupting the IP session with the UTRAN/E-UTRAN. In this case, no Session Id (Section 5.5) is included.
o 0-MN无意移交现有IP会话，即，MN正在请求与Wi-Fi网络的独立IP会话，而不会中断与UTRAN/e-UTRAN的IP会话。在这种情况下，不包括会话Id（第5.5节）。
o 1 - The MN intends to handover an existing IP session. In this case, MN MAY include a Session Id (Section 5.5) to correlate this Wi-Fi session with a UTRAN/E-UTRAN session.
o 1-MN打算移交现有IP会话。在这种情况下，MN可以包括会话Id（第5.5节），以将该Wi-Fi会话与UTRAN/E-UTRAN会话相关联。
When an MN intends to handover an earlier IP session to the current access network, it may propagate a session identity that can help identify the previous session from UTRAN/E-UTRAN that the MN intends to handover. This attribute is defined as a generic octet string. The MN MAY include an E-UTRAN Globally Unique Temporary User Equipment Identity (GUTI) if the previous session was an E-UTRAN session. If the previous session was a UTRAN session, the MN MAY include a UTRAN Global Radio Network Controller (RNC) ID (Mobile Country Code (MCC), Mobile Network Code (MNC), RNC ID) and P-TMSI concatenated as an octet string.
当MN打算将较早的IP会话切换到当前接入网络时，它可以传播会话标识，该会话标识可以帮助从MN打算切换的UTRAN/E-UTRAN识别先前的会话。此属性定义为通用八位字节字符串。如果先前会话是E-UTRAN会话，则MN可以包括E-UTRAN全局唯一临时用户设备标识（GUTI）。如果前一会话是UTRAN会话，则MN可以包括UTRAN全球无线网络控制器（RNC）ID（移动国家代码（MCC）、移动网络代码（MNC）、RNC ID）和作为八位字节字符串串联的P-TMSI。
This attribute SHOULD be included in the EAP-Response/AKA-Challenge message.
此属性应包含在EAP响应/AKA质询消息中。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_HANDOVER_ | Length | Access | Reserved |
| SESSION_ID | | Technology | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Id |
| ... |
| ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_HANDOVER_ | Length | Access | Reserved |
| SESSION_ID | | Technology | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Id |
| ... |
| ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: AT_HANDOVER_SESSION_ID EAP Attribute
图6:AT\U切换\U会话\U ID EAP属性
Access Technology:
接入技术：
This field represents the RAN technology from which the MN is undergoing a handover.
该字段表示MN正在从中进行切换的RAN技术。
o 0: Reserved
o 0:保留
o 1: UTRAN
o 1:UTRAN
o 2: E-UTRAN
o 2:E-UTRAN
Session Id:
会话Id:
An octet string of variable length that identifies the session in the source access technology. As defined at the beginning of this section, the actual value is RAN technology dependent. For E-UTRAN, the value is GUTI. For UTRAN, the value is Global RNC ID (6 bytes) followed by P-TMSI (4 bytes). See [TS-23.003] for encoding of the field.
一个长度可变的八位字节字符串，用于标识源访问技术中的会话。如本节开头所述，实际值取决于技术。对于E-UTRAN，值为GUTI。对于UTRAN，该值是全局RNC ID（6字节），后跟P-TMSI（4字节）。字段编码见[TS-23.003]。
This attribute defines the MN's machine serial number. Examples are IMEI and IMEISV.
此属性定义MN的机器序列号。例如IMEI和IMEISV。
A network that requires the machine serial number for authorization purposes MUST send a request for the attribute in an EAP-Request/ AKA-Challenge message. If the attribute is present, the MN SHOULD include the attribute in the EAP-Response/AKA-Challenge message. If the MN sends the attribute, it MUST be contained within an AT_ENCR_DATA attribute. An MN MUST NOT provide the attribute unless it receives the request from a network authenticated via EAP/AKA.
出于授权目的需要机器序列号的网络必须发送EAP请求/AKA质询消息中的属性请求。如果该属性存在，MN应在EAP响应/AKA质询消息中包含该属性。如果MN发送该属性，则该属性必须包含在AT_ENCR_数据属性中。MN必须不提供该属性，除非它从通过EAP/AKA认证的网络接收请求。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_MN_ | Length | Serial ID | Reserved |
| SERIAL_ID | | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Serial Id |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_MN_ | Length | Serial ID | Reserved |
| SERIAL_ID | | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Serial Id |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: AT_MN_SERIAL_ID EAP Attribute
图7:AT_MN_SERIAL_ID EAP属性
Serial ID Type:
序列ID类型：
This field identifies the type of the MN Identifier.
此字段标识MN标识符的类型。
o 0: Reserved
o 0:保留
o 1: IMEI
o 1:IMEI
o 2: IMEISV
o 2:IMEISV
MN Serial Id:
MN序列号：
An arbitrary octet string that identifies the MN's machine serial number. The actual value is device specific. See [TS-23.003] for encoding of the field. When sent by the network in the EAP-Request/ AKA-Challenge message, this field is not present, which serves as an indication for the MN to provide the attribute in the EAP-Response/ AKA-Challenge message.
标识MN机器序列号的任意八位字节字符串。实际值是特定于设备的。字段编码见[TS-23.003]。当网络在EAP请求/AKA质询消息中发送时，此字段不存在，它用作指示MN在EAP响应/AKA质询消息中提供属性。
An AT_MN_SERIAL_ID attribute MUST only be used with methods that can provide mutual (network and device) authentication, such as AKA, AKA', and EAP-SIM.
AT_MN_SERIAL_ID属性只能与可提供相互（网络和设备）身份验证的方法一起使用，如AKA、AKA'和EAP-SIM。
This document defines new EAP attributes to extend the capability of the EAP-AKA protocol as specified in Section 8.2 of [RFC4187]. The attributes are passed between an MN and a AAA server in provider-controlled, trusted Wi-Fi networks, where the Wi-Fi access network is a relay between the MN and the AAA server. The document does not specify any new messages or options to the EAP-AKA protocol.
本文件定义了新的EAP属性，以扩展[RFC4187]第8.2节规定的EAP-AKA协议的能力。在提供商控制的可信Wi-Fi网络中，这些属性在MN和AAA服务器之间传递，其中Wi-Fi接入网络是MN和AAA服务器之间的中继。本文件未指定EAP-AKA协议的任何新消息或选项。
The attributes defined here are fields that are used in existing 3G and 4G networks, where they are exchanged (in protocols specific to 3G and 4G networks) subsequent to the mobile network authentication (e.g., using the UMTS-AKA mechanism). For the operator-controlled
此处定义的属性是在现有3G和4G网络中使用的字段，在移动网络认证（例如，使用UMTS-AKA机制）之后，在这些网络中进行交换（在3G和4G网络特定的协议中）。对于操作员控制
Wi-Fi access that is connected to the same core infrastructure as the 3G and 4G access, a similar model is followed here with the EAP-AKA (or EAP-AKA', EAP-SIM) authentication. In doing so, processing these attributes, security-wise, is no worse than that in existing 3G and 4G mobile networks.
Wi-Fi接入连接到与3G和4G接入相同的核心基础设施，这里采用了类似的模式，即EAP-AKA（或EAP-AKA'，EAP-SIM）认证。在这样做的过程中，在安全方面处理这些属性并不比现有3G和4G移动网络差。
The attributes inherit the security protection (integrity, replay, and confidentiality) provided by the parameters in the AKA(') or SIM methods; see Section 12.6 in [RFC4187]. Furthermore, RFC 4187 requires attributes exchanged in EAP-Request/AKA-Identity or EAP-Response/AKA-Identity to be integrity-protected with AT_CHECKCODE; see Section 8.2 in [RFC4187]. This requirement applies to the AT_CONNECTIVITY_TYPE and AT_VIRTUAL_NETWORK_REQ attributes defined in this document.
属性继承由AKA（'）或SIM方法中的参数提供的安全保护（完整性、重播和机密性）；参见[RFC4187]中的第12.6节。此外，RFC 4187要求在EAP请求/AKA标识或EAP响应/AKA标识中交换的属性使用AT_校验码进行完整性保护；参见[RFC4187]中的第8.2节。本要求适用于本文件中定义的AT_连接类型和AT_虚拟网络REQ属性。
The AT_MN_SERIAL_ID attribute MUST have confidentiality protection provided by the AKA(') or EAP-SIM methods beyond the secure transport (such as private leased lines, VPN, etc.) deployed by the provider of the trusted Wi-Fi service.
AT_MN_SERIAL_ID属性必须具有AKA（'）或EAP-SIM方法提供的机密性保护，而不包括受信任Wi-Fi服务提供商部署的安全传输（如专用专线、VPN等）。
Use of identifiers such as IMEI could have privacy implications, wherein devices can be profiled and tracked. With additional information, this could also lead to profiling of user's network access patterns. Implementers should consult [hotos-2011], and the references therein, for a broader discussion and possible mitigation methods on the subject.
使用诸如IMEI之类的标识符可能会涉及隐私，其中可以对设备进行分析和跟踪。如果有其他信息，这也可能导致对用户的网络访问模式进行分析。实施者应参考[hotos-2011]和其中的参考文献，以便对该主题进行更广泛的讨论和可能的缓解方法。
This document defines the following new skippable EAP-AKA attributes. These attributes have been assigned from the "EAP-AKA and EAP-SIM Parameters" registry at <https://www.iana.org/assignments/ eapsimaka-numbers>.
本文档定义了以下新的可跳过EAP-AKA属性。这些属性已从位于的“EAP-AKA和EAP-SIM参数”注册表中分配<https://www.iana.org/assignments/ eapsimaka编号>。
o AT_VIRTUAL_NETWORK_ID (Section 5.1): 145
o AT虚拟网络ID（第5.1节）：145
o AT_VIRTUAL_NETWORK_REQ (Section 5.2): 146
o AT虚拟网络请求（第5.2节）：146
o AT_CONNECTIVITY_TYPE (Section 5.3): 147
o AT_连接类型（第5.3节）：147
o AT_HANDOVER_INDICATION (Section 5.4): 148
o AT_移交指示（第5.4节）：148
o AT_HANDOVER_SESSION_ID (Section 5.5): 149
o 移交时会话ID（第5.5节）：149
o AT_MN_SERIAL_ID (Section 5.6): 150
o AT MNU序列号（第5.6节）：150
A new IANA registry titled "Trusted Non-3GPP Access EAP Parameters" has been created. The range for both Types and Sub types in the registry is 0 - 127, with 0 (zero) being a reserved value. IANA has made assignments in a monotonically increasing order in increments of 1, starting from 1. New assignments in this registry are made with the Specification Required policy [RFC5226].
已创建名为“受信任的非3GPP访问EAP参数”的新IANA注册表。注册表中类型和子类型的范围都是0-127，0（零）是保留值。IANA以1为增量，从1开始，以单调递增的顺序分配作业。此注册表中的新分配使用规范要求的策略[RFC5226]进行。
The IANA Designated Expert should review the requirements for new assignments based on factors including, but not limited to, the source of request (e.g., standards bodies), deployment needs (e.g., industry consortium, operator community), and experimental needs (e.g., academia, industrial labs). A document outlining the purpose of new assignments should accompany the request. Such a document could be a standards document or a research project description. The Designated Expert should consider that there is sufficient evidence of potential usage both on the endpoints (e.g., Mobile Devices, etc.) and the infrastructure (e.g., AAA servers, gateways, etc.)
IANA指定的专家应根据包括但不限于请求来源（如标准机构）、部署需求（如行业联盟、运营商社区）和实验需求（如学术界、工业实验室）在内的因素审查新任务的要求。申请时应附上一份概述新任务目的的文件。此类文件可以是标准文件或研究项目说明。指定的专家应该考虑到在端点（例如，移动设备等）和基础设施（例如，AAA服务器、网关等）上有充分的潜在使用的证据。
The following fields have been assigned:
已分配以下字段：
o Virt-Net-Req Type (Section 5.2): 1
o Virt净需求类型（第5.2节）：1
o Virt-Net-Req Sub type (Section 5.2): 2
o Virt净需求子类型（第5.2节）：2
o Connectivity Type (Section 5.3): 3
o 连接类型（第5.3节）：3
o Access Technology (Section 5.5): 4
o 接入技术（第5.5节）：4
o Serial ID Type (Section 5.6): 5
o 序列ID类型（第5.6节）：5
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC4187, January 2006, <http://www.rfc-editor.org/info/rfc4187>.
[RFC4187]Arkko，J.和H.Haverinen，“第三代认证和密钥协商的可扩展认证协议方法（EAP-AKA）”，RFC4187，2006年1月<http://www.rfc-editor.org/info/rfc4187>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012, <http://www.rfc-editor.org/info/rfc6459>.
[RFC6459]Korhonen，J.，Ed.，Soininen，J.，Patil，B.，Savolainen，T.，Bajko，G.，和K.Iisakkila，“第三代合作伙伴关系项目（3GPP）中的IPv6演进包系统（EPS）”，RFC 6459，2012年1月<http://www.rfc-editor.org/info/rfc6459>.
[EPC] 3GPP, "General Packet Radio Service (GPRS); enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", TS 23.401 8.8.0, December 2009, <http://www.3gpp.org/ftp/Specs/html-info/23401.htm>.
[EPC]3GPP，“通用分组无线业务（GPRS）；演进型通用地面无线接入网（E-UTRAN）接入的增强”，TS 23.401 8.8.02009年12月<http://www.3gpp.org/ftp/Specs/html-info/23401.htm>.
[EPC2] 3GPP, "Architecture enhancements for non-3GPP accesses", TS 23.402 8.8.0, December 2009, <http://www.3gpp.org/ftp/Specs/html-info/23402.htm>.
[EPC2]3GPP，“非3GPP接入的架构增强”，TS 23.402 8.8.0，2009年12月<http://www.3gpp.org/ftp/Specs/html-info/23402.htm>.
[GPRS] 3GPP, "General Packet Radio Service (GPRS); Service description, Stage 2", TS 23.060, December 2006, <http://www.3gpp.org/ftp/Specs/html-info/23060.htm>.
[GPRS]3GPP，“通用分组无线业务（GPRS）；服务说明，第2阶段”，TS 23.0602006年12月<http://www.3gpp.org/ftp/Specs/html-info/23060.htm>.
[IEEE802.11u] IEEE, "IEEE Standard for Information Technology-Telecommunications and information exchange between systems-Local and Metropolitan networks-specific requirements-Part II: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Amendment 9: Interworking with External Networks", IEEE Std 802.11u-2011, February 2011, <http://standards.ieee.org/findstds/ standard/802.11u-2011.html>.
[IEEE802.11u]IEEE，“系统间信息技术电信和信息交换的IEEE标准本地和城域网特定要求第二部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范：修改件9：与外部网络的互通”，IEEE Std 802.11u-2011，2011年2月<http://standards.ieee.org/findstds/ 标准/802.11u-2011.html>。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC3748, June 2004, <http://www.rfc-editor.org/info/rfc3748.txt>.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展身份验证协议（EAP）”，RFC3748，2004年6月<http://www.rfc-editor.org/info/rfc3748.txt>.
[RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006, <http://www.rfc-editor.org/info/rfc4186>.
[RFC4186]Haverinen，H.，Ed.和J.Salowey，Ed.，“全球移动通信系统（GSM）用户身份模块（EAP-SIM）的可扩展认证协议方法”，RFC 4186，2006年1月<http://www.rfc-editor.org/info/rfc4186>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008, <http://www.rfc-editor.org/info/rfc5213>.
[RFC5213]Gundavelli，S.，Ed.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 52132008年8月<http://www.rfc-editor.org/info/rfc5213>.
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC5415, January 2009, <http://www.rfc-editor.org/info/rfc5415.txt>.
[RFC5415]Calhoun，P.，Montemurro，M.，和D.Stanley，“无线接入点的控制和供应（CAPWAP）协议规范”，RFC5415，2009年1月<http://www.rfc-editor.org/info/rfc5415.txt>.
[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')", RFC 5448, May 2009, <http://www.rfc-editor.org/info/rfc5448>.
[RFC5448]Arkko，J.，Lehtovirta，V.，和P.Erenen，“第三代认证和密钥协议（EAP-AKA'）的改进可扩展认证协议方法”，RFC 5448，2009年5月<http://www.rfc-editor.org/info/rfc5448>.
[TS-23.003] 3GPP, "Numbering, addressing and identification", TS 23.003 12.2.0, March 2014, <http://www.3gpp.org/ftp/Specs/html-info/23003.htm>.
[TS-23.003]3GPP，“编号、寻址和标识”，TS 23.003 12.2.012014年3月<http://www.3gpp.org/ftp/Specs/html-info/23003.htm>.
[TS-33.402] 3GPP, "3GPP System Architecture Evolution (SAE); Security aspects of non-3GPP accesses", TS 33.402 8.6.0, December 2009, <http://www.3gpp.org/ftp/Specs/html-info/33402.htm>.
[TS-33.402]3GPP，“3GPP系统架构演进（SAE）；非3GPP接入的安全方面”，TS 33.402 8.6.012009年12月<http://www.3gpp.org/ftp/Specs/html-info/33402.htm>.
[hotos-2011] Wetherall, et al., D., "Privacy Revelations for Web and Mobile Apps", Proceedings of the Hot Topics in Operating Systems (HotOS), May 2011, <https://www.usenix.org/legacy/events/hotos11/tech/>.
[hotos-2011]Wetheral等人，D.，“网络和移动应用程序的隐私披露”，操作系统热点话题会议录（hotos），2011年5月<https://www.usenix.org/legacy/events/hotos11/tech/>.
[hs20] "Hotspot 2.0 (Release 2) Technical Specification Package v1.0.0", <https://www.wi-fi.org/hotspot-20-release-2- technical-specification-package-v100>.
[hs20]“热点2.0（第2版）技术规范包v1.0.0”<https://www.wi-fi.org/hotspot-20-release-2- technical-specification-package-v100>。
Acknowledgments
致谢
Thanks to Sebastian Speicher for the review and suggesting improvements. Thanks to Mark Grayson for proposing the MN Serial ID attribute, and thanks to Brian Haberman for suggesting a new registry.
感谢Sebastian Speicher的审查并提出改进建议。感谢Mark Grayson提出的MN Serial ID属性，感谢Brian Haberman提出的新注册表。
Authors' Addresses
作者地址
Ravi Valmikam Unaffiliated United States
Ravi Valmikam非附属美国
EMail: valmikam@gmail.com
EMail: valmikam@gmail.com
Rajeev Koodli Intel United States
美国英特尔公司拉吉耶夫·库德利
EMail: rajeev.koodli@intel.com
EMail: rajeev.koodli@intel.com