[要約] RFC 7458は、Wi-FiとEvolved Packet Coreの統合における拡張認証プロトコル（EAP）属性に関するものです。このRFCの目的は、EAPを使用してWi-FiネットワークをEvolved Packet Coreに統合するための属性の定義と使用方法を提供することです。
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
Evolved Packet CoreとのWi-Fi統合のための拡張認証プロトコル（EAP）属性
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が出現しているため、3Gおよび4Gネットワークで一般的に利用可能な機能をWi-Fiアクセスネットワークでも提供することが重要になっています。このような機能には、アクセスポイント名（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.
モバイルデバイスがWi-Fiネットワーク経由でモバイルEvolved Packet Core（EPC）にアクセスするためには、EAP認証と鍵合意（EAP-AKA）およびEAP-AKA 'プロトコルが必要です。このドキュメントでは、このようなネットワークで上記の機能を有効にするために、いくつかの新しいEAP属性を定義しています。属性は、サービスプロバイダーのインフラストラクチャ内のクライアント（モバイルノード（MN）など）とクライアントのネットワーク（認証、承認、アカウンティング（AAA）サーバーなど）の間で交換されます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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は、モバイルサービスプロバイダー向けの「信頼できる」アクセステクノロジーとして登場しました。 「信頼できる」アクセスの第3世代パートナーシッププロジェクト（3GPP）の説明については、[EPC2]を参照してください。 IEEE 802.11u [IEEE802.11u]と "HotSpot 2.0" [hs20]の進歩により、モバイルノードがセルラーネットワークにローミングするのと同じようにWi-Fiアクセスネットワークを選択して接続できるシームレスローミングが可能になりました。したがって、3Gや4Gネットワークなどのライセンススペクトルネットワークで一般的にサポートされているWi-Fiの特定の機能を提供することが重要になっています。このドキュメントでは、MNがネットワークと対話してこれらの機能の一部をサポートするために、いくつかの新しいEAP属性を指定します（以下を参照）。これらの新しい属性は、関連するモビリティ操作を実行するためのプロキシモバイルIPv6ネットワークノードのトリガーとして機能します。たとえば、MNが新しいIPセッション（3GPPの新しいAPN）を要求し、ネットワークが同意すると、対応する属性（以下で定義）がモバイルアンカーゲートウェイ（MAG）のトリガーとして機能し、新しいモビリティセッションを開始します。ローカルモビリティアンカー（LMA）。このドキュメントでは、ここで使用されるモバイルネットワーク用語（APNなど）の基本的な定義について[RFC6459]を参照しています。
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 あなたの選択
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からZG / ChG（Universal Terrestrial Radio Access Network（UTRAN）/ Evolved 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サブスクライバーIDモジュール（EAP-SIM）[RFC4186]に適用可能であり、適切な拡張機能があれば、他のEAPメソッドにも適用できる可能性があります。 。信頼できるWi-Fiアクセスネットワークに加えて、属性は、EAP方式を使用し、モバイルEPCへの接続を提供する信頼できる「非3GPP」アクセスネットワークに適用できます。これにより、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 "IMSvoice"を選択します。
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に接続します。このドキュメントは、複数のAPN接続をサポートするMNの機能を示す属性を指定します。特定の接続タイプは、プロキシモバイル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は、両方のアクセステクノロジーを同時に使用して接続し、2つの独立したIPアタッチメントを維持することを選択できます。これらのシナリオを実装するには、MNはUTRAN / E-UTRANセッションを新しいWi-Fiセッションと関連付ける方法が必要です。このドキュメントでは、EAPを介してE-UTRANセッションIDをネットワークに伝播するための属性を指定します。これは、ネットワークが2つの無線アクセスネットワーク（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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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]などのペイロードプロトコルの1つと組み合わせて、ネットワークでいくつかのことを実行できます。
o Establish the identity of the user (MN) to the network.
o ネットワークへのユーザー（MN）のIDを確立します。
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 Fast Re-Authentication」と呼ばれます。
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高速再認証手順の使用は、今後の検討課題です。 EAP認証とEAP Fast Re-Authenticationの両方の手順は、3GPP [TS-33.402]で信頼できるアクセスネットワークを使用するために指定されています。
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のIDを証明するというコア機能とは別に、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 WAN：Wi-Fiアクセスノード。通常、Wi-FiアクセスポイントとWi-Fiコントローラーで構成されます。 CAPWAP [RFC5415]プロトコルを使用すると、これらの機能を個別の物理ノードまたは単一ノードで実現できます。プロキシモバイルIPv6（PMIPv6）[RFC5213]ネットワークでは、MAG機能は、Wi-FiアクセスポイントまたはWi-FiコントローラーのいずれかのWANにあります。
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|
| | | |
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 Protected Access（WPA）/ WPA2モードでは、これはセキュリティ認証情報を検証しないオープン認証です。
4. The MN initiates 802.11 Association with the Wi-Fi network.
4. MNはWi-Fiネットワークとの802.11アソシエーションを開始します。
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は、永続的または一時的なIDで応答します。
7. The Wi-Fi network challenges the MN to prove its identity by sending EAP Request/AKA-Challenge.
7. Wi-Fiネットワークは、EAP要求/ AKA-Challengeを送信して、MNにIDを証明するよう要求します。
8. The MN calculates the security digest and responds with EAP Response/AKA-Challenge.
8. MNはセキュリティダイジェストを計算し、EAP Response / AKA-Challengeで応答します。
9. If the authentication is successful, the Wi-Fi network responds to the MN with EAP Success.
9. 認証が成功すると、Wi-FiネットワークはEAP成功で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は最初のPDN接続に必要なAPN IDを示すために、EAP-Response / AKA-ChallengeにAT_VIRTUAL_NETWORK_ID属性を含めます。
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-Response / AKA-Challengeに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には、単一または複数のPDN機能を示すAT_VIRTUAL_NETWORK_REQ属性が含まれています。さらに、属性のSubタイプは、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-Response / AKA-ChallengeメッセージのAT_CONNECTIVITY_TYPE属性を使用して接続の優先度を示します。プリファレンスは、MNがEvolved Packet Coreへの接続（いわゆる「EPC PDN接続」）またはインターネットオフロード（「非シームレスワイヤレスオフロード」と呼ばれる）を希望するかどうかを示します。
The network makes its decision and replies with the same attribute in the EAP Success message.
ネットワークは決定を行い、EAP Successメッセージの同じ属性で応答します。
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-Response / AKA-Challengeに適用されます。
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_HANDOVER_INDICATION：この属性は、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_HANDOVER_SESSION_ID：MNはこの属性を使用して、UTRAN / E-UTRAN上のセッションを識別できます。使用する場合、前のセッションがUTRANであった場合、この属性にはパケット一時モバイルサブスクライバーID（P-TMSI）が含まれます。前のセッションがE-UTRANであった場合は、モバイル一時モバイルサブスクライバーID（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属性は、国際モバイル機器識別（IMEI）および国際モバイル機器識別ソフトウェアバージョン（IMEISV）を含むMNのシリアル番号を定義します。 IMEI（またはIMEISV）は、正当な（盗難ではなく）デバイスが使用されていることを確認するために使用されます。他と同様に、この属性はサービスプロバイダーのAAAサーバーと交換されます。 MN_SERIAL_IDは、AAAサーバーによって他のノードにさらに伝播してはなりません（MUST NOT）。
The format for the new attributes follows that in [RFC4187]. Note that the Length field value is inclusive of the first two bytes.
新しい属性の形式は、[RFC4187]の形式に従います。長さフィールドの値には、最初の2バイトが含まれることに注意してください。
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-Response / AKA-Challengeメッセージに含める必要があります（SHOULD）。
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_VIRTUAL_NETWORK_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を接続する予定の場合、この属性を使用して、ネットワークに異なる機能を示す必要があります（SHOULD）。次に、ネットワークはサポートされているものを提供します。
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-Response / Identityにのみ含めることができます。ネットワークから、それはEAP Request / AKA-Challengeメッセージに含まれる必要があります。 MNからネットワークへの方向では、タイプフィールド（下）はMNの要求を示します。ネットワークからMNへの方向では、タイプフィールドは、要求をサポートするネットワークの意欲を示します。現在の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_VIRTUAL_ | Length | Virt-Net-Req | Virt-Net-Req |
|NETWORK_REQ | | Type | Sub type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: AT_VIRTUAL_NETWORK_REQ EAP Attribute
図3：AT_VIRTUAL_NETWORK_REQ EAP属性
Virt-Net-Req Type:
Virt-Net-Reqタイプ：
Type can have one of the following values:
タイプには、次のいずれかの値を指定できます。
o 0: Reserved o 1: Single PDN connection
o 0：予約済み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-Net-Reqサブタイプ：
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-Response / Identityにのみ含めることができます。ネットワークから、それはEAP Request / AKA-Challengeメッセージに含まれる必要があります。
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_CONNECTIVITY_TYPE 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.
この属性は、既存のIPアタッチメントのMNのハンドオーバーの意図を示します。
This attribute SHOULD be included in the EAP-Response/AKA-Challenge message.
この属性は、EAP-Response / AKA-Challengeメッセージに含める必要があります（SHOULD）。
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_HANDOVER_INDICATION 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はUTRAN / E-UTRANとのIPセッションを中断することなく、Wi-Fiネットワークとの独立した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は、このWi-FiセッションをUTRAN / E-UTRANセッションと関連付けるためにセッションID（セクション5.5）を含めることができます（MAY）。
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からの以前のセッションを識別するのに役立つセッションIDを伝播できます。この属性は、一般的なオクテット文字列として定義されています。前のセッションがE-UTRANセッションであった場合、MNにはE-UTRANグローバルユニークテンポラリユーザー機器ID（GUTI）を含めることができます（MAY）。前のセッションがUTRANセッションであった場合、MNはUTRANグローバルラジオネットワークコントローラ（RNC）ID（モバイル国コード（MCC）、モバイルネットワークコード（MNC）、RNC ID）とオクテット文字列として連結されたP-TMSIを含むことができます（MAY） 。
This attribute SHOULD be included in the EAP-Response/AKA-Challenge message.
この属性は、EAP-Response / AKA-Challengeメッセージに含める必要があります（SHOULD）。
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_HANDOVER_SESSION_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 3：Aランディング
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.
ソースアクセステクノロジーのセッションを識別する可変長のオクテット文字列。このセクションの冒頭で定義されているように、実際の値はRANテクノロジーによって異なります。 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-Request / AKA-Challengeメッセージで属性のリクエストを送信する必要があります。属性が存在する場合、MNはEAP-Response / AKA-Challengeメッセージに属性を含める必要があります（SHOULD）。 MNが属性を送信する場合は、AT_ENCR_DATA属性内に含める必要があります。 MNは、EAP / AKAを介して認証されたネットワークから要求を受信しない限り、属性を提供してはなりません（MUST NOT）。
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 IDのタイプを識別します。
o 0: Reserved
o 0：予約済み
o 1: IMEI
o 1：IMEI
o 2: IMEISV
o 2：IMEISV
MN Serial Id:
シリアルから：
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-Request / AKA-Challengeメッセージで送信される場合、このフィールドは存在しません。これは、MNがEAP-Response / AKA-Challengeメッセージで属性を提供するための指標として機能します。
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 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.
ここで定義されている属性は、既存の3Gおよび4Gネットワークで使用されるフィールドで、モバイルネットワーク認証（UMTS-AKAメカニズムを使用するなど）に続いて（3Gおよび4Gネットワークに固有のプロトコルで）交換されます。 3Gおよび4Gアクセスと同じコアインフラストラクチャに接続されているオペレーター制御のWi-Fiアクセスの場合、ここでは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-Request / AKA-IdentityまたはEAP-Response / AKA-Identityで交換される属性をAT_CHECKCODEで整合性保護する必要があります。 [RFC4187]のセクション8.2をご覧ください。この要件は、このドキュメントで定義されているAT_CONNECTIVITY_TYPEおよびAT_VIRTUAL_NETWORK_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属性は、信頼されたWi-Fiサービスのプロバイダーによって展開されたセキュアなトランスポート（専用線、VPNなど）を超えて、AKA（ '）またはEAP-SIMメソッドによって提供される機密保護を備えている必要があります。
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属性を定義しています。これらの属性は、<https://www.iana.org/assignments/ eapsimaka-numbers>の「EAP-AKAおよびEAP-SIMパラメータ」レジストリから割り当てられています。
o AT_VIRTUAL_NETWORK_ID (Section 5.1): 145
o AT_VIRTUAL_NETWORK_ID（セクション5.1）：145
o AT_VIRTUAL_NETWORK_REQ (Section 5.2): 146
o AT_VIRTUAL_NETWORK_REQ（セクション5.2）：146
o AT_CONNECTIVITY_TYPE (Section 5.3): 147
o AT_CONNECTIVITY_TYPE（セクション5.3）：147
o AT_HANDOVER_INDICATION (Section 5.4): 148
o AT_HANDOVER_INDICATION（セクション5.4）：148
o AT_HANDOVER_SESSION_ID (Section 5.5): 149
o AT_HANDOVER_SESSION_ID（セクション5.5）：149
o AT_MN_SERIAL_ID (Section 5.6): 150
o AT_MN_SERIAL_ID（セクション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].
「Trusted Non-3GPP Access EAP Parameters」というタイトルの新しいIANAレジストリが作成されました。レジストリのタイプとサブタイプの両方の範囲は0〜127で、0（ゼロ）は予約済みの値です。 IANAは、1から始めて1ずつ増加する単調に増加する順序で割り当てを行いました。このレジストリの新しい割り当ては、Specification Requiredポリシー[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 Designated Expertは、リクエストのソース（例：標準化団体）、導入ニーズ（例：業界コンソーシアム、オペレーターコミュニティ）、実験的ニーズ（例：アカデミア、産業ラボ）。新しい割り当ての目的を概説する文書は、要求に添付する必要があります。このようなドキュメントは、標準ドキュメントまたは研究プロジェクトの説明です。指定専門家は、エンドポイント（モバイルデバイスなど）とインフラストラクチャ（AAAサーバー、ゲートウェイなど）の両方で潜在的な使用の十分な証拠があることを考慮する必要があります
The following fields have been assigned:
次のフィールドが割り当てられています。
o Virt-Net-Req Type (Section 5.2): 1
o Virt-Net-Reqタイプ（セクション5.2）：1
o Virt-Net-Req Sub type (Section 5.2): 2
o Virt-Net-Reqサブタイプ（セクション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、「Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement（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、「RFCで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.、and K. Iisakkila、 "IPv6 in the 3rd Generation Partnership Project（3GPP）Evolved Packet System（ 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、「General Packet Radio Service（GPRS）; Evolved Universal Terrestrial Radio Access Network（E-UTRAN）access」、TS 23.401 8.8.0、2009年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.060、2006年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 Standard for Information Technology-Telecommunications and information exchange between systems-Local and Metropolitan network-specific requirements-Part II：Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY）仕様：Amendment 9 ：Interworking with External Networks」、IEEE Std 802.11u-2011、February 2011、<http://standards.ieee.org/findstds/standard/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、編、「Extensible Authentication Protocol（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、編、「モバイルコミュニケーション用グローバルシステム（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.、and B. Patil、 "Proxy Mobile IPv6"、RFC 5213、August 2008、<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、「Control and Provisioning of Wireless Access Points（CAPWAP）Protocol Specification」、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. Eronen、「Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement（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.0、2014年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 System Architecture Evolution（SAE）;非3GPPアクセスのセキュリティ側面」、TS 33.402 8.6.0、2009年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] Wetherall et al。、D。、「Webおよびモバイルアプリのプライバシーの啓示」、オペレーティングシステムのホットトピック集（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]「Hotspot 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に感謝します。 MNシリアルID属性を提案してくれたMark Graysonに、新しいレジストリを提案してくれたBrian Habermanに感謝します。
Authors' Addresses
著者のアドレス
Ravi Valmikam Unaffiliated United States
Ravi Valmikam非関連国アメリカ合衆国
EMail: valmikam@gmail.com
Rajeev Koodli Intel United States
Rajeev Coodley Intelアメリカ合衆国
EMail: rajeev.koodli@intel.com