Internet Engineering Task Force (IETF) J. Henry
Request for Comments: 9797 Cisco Systems
Category: Informational Y. Lee
ISSN: 2070-1721 Comcast
June 2025
To limit the privacy issues created by the association between a device, its traffic, its location, and its user in IEEE 802 networks, client vendors and client OS vendors have started implementing Media Access Control (MAC) address randomization. This technology is particularly important in Wi-Fi networks (defined in IEEE 802.11) due to the over-the-air medium and device mobility. When such randomization happens, some in-network states may break, which may affect network connectivity and user experience. At the same time, devices may continue using other stable identifiers, defeating the purpose of MAC address randomization.
デバイス、そのトラフィック、その場所、およびIEEE 802ネットワークのユーザーとの関連によって生じるプライバシーの問題を制限するために、クライアントベンダーとクライアントのOSベンダーは、メディアアクセス制御（MAC）アドレスのランダム化の実装を開始しました。このテクノロジーは、空気中の媒体およびデバイスのモビリティにより、Wi-Fiネットワーク（IEEE 802.11で定義されています）で特に重要です。そのようなランダム化が発生すると、一部のネットワーク内の状態が破損し、ネットワーク接続とユーザーエクスペリエンスに影響を与える可能性があります。同時に、デバイスは他の安定した識別子を使用し続け、MACアドレスのランダム化の目的を打ち負かすことができます。
This document lists various network environments and a range of network services that may be affected by such randomization. This document then examines settings where the user experience may be affected by in-network state disruption. Last, this document examines some existing frameworks that maintain user privacy while preserving user quality of experience and network operation efficiency.
このドキュメントには、さまざまなネットワーク環境と、そのようなランダム化の影響を受ける可能性のあるさまざまなネットワークサービスがリストされています。次に、このドキュメントでは、ユーザーエクスペリエンスがネットワーク内の州の混乱の影響を受ける可能性がある設定を調べます。最後に、このドキュメントでは、ユーザーのプライバシーを維持しながら、ユーザーの品質のエクスペリエンスとネットワーク運用効率を維持する既存のフレームワークを検討します。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9797.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9797で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. MAC Address as Identity: User vs. Device
2.1. Privacy of MAC Addresses
3. The Actors: Network Functional Entities and Human Entities
3.1. Network Functional Entities
3.2. Human-Related Entities
4. Degrees of Trust
5. Environments
6. Network Services
6.1. Device Identification and Associated Problems
7. IANA Considerations
8. Security Considerations
9. Informative References
Appendix A. Existing Frameworks
A.1. IEEE 802.1X with WPA2 / WPA3
A.2. OpenRoaming
A.3. Proprietary RCM Schemes
Authors' Addresses
When the MAC address was first introduced in [IEEE_802], it was used in wired Ethernet networks [IEEE_802.3]. Due to the nature of wired networks, devices were relatively stationary, and the physical connection imposed a boundary that restricted attackers from easily accessing the network data. However, [IEEE_802.11] (Wi-Fi) brought new challenges when it was introduced.
[IEEE_802]でMACアドレスが最初に導入されたとき、有線イーサネットネットワーク[IEEE_802.3]で使用されました。有線ネットワークの性質により、デバイスは比較的静止しており、物理的な接続は攻撃者がネットワークデータに簡単にアクセスすることを制限する境界を課しました。ただし、[IEEE_802.11]（Wi-Fi）は、導入されたときに新しい課題をもたらしました。
The flexibility of Wi-Fi technology has revolutionized communications and become the preferred, and sometimes the only, technology used by devices such as laptops, tablets, and Internet of Things (IoT) devices. Wi-Fi is an over-the-air medium that allows attackers with surveillance equipment to monitor WLAN packets and track the activity of WLAN devices. It is also sometimes possible for attackers to monitor the WLAN packets behind the Wi-Fi Access Point (AP) over the wired Ethernet. Once the association between a device and its user is made, identifying the device and its activity is sufficient to deduce information about what the user is doing, without the user's consent.
Wi-Fiテクノロジーの柔軟性は、通信に革命をもたらし、ラップトップ、タブレット、モノのインターネット（IoT）デバイスなどのデバイスで使用される唯一の技術になります。Wi-Fiは、監視機器を備えた攻撃者がWLANパケットを監視し、WLANデバイスのアクティビティを追跡できるようにするオーバーザエアメディアです。また、攻撃者が有線イーサネット上のWi-Fiアクセスポイント（AP）の背後にあるWLANパケットを監視することもできます。デバイスとそのユーザーとの関連が作成されると、ユーザーの同意なしに、ユーザーが何をしているかについての情報を推測するには、デバイスとそのアクティビティを特定するだけで十分です。
To reduce the risks of identifying a device only by the MAC address, client OS vendors have started implementing Randomized and Changing MAC addresses (RCM). By randomizing the MAC address, it becomes harder to use the MAC address to construct a persistent association between a flow of data packets and a device, assuming no other visible unique identifiers or stable patterns are in use. When individual devices are no longer easily identifiable, it also becomes difficult to associate a series of network packet flows in a prolonged period with a particular individual using one specific device if the device randomizes the MAC address governed by the OS privacy policies.
MACアドレスによってのみデバイスを識別するリスクを減らすために、クライアントOSベンダーはランダム化および変更MACアドレス（RCM）の実装を開始しました。MACアドレスをランダム化することにより、MACアドレスを使用して、データパケットのフローとデバイスの間に持続的な関連性を構築することが難しくなります。個々のデバイスが簡単に識別できなくなった場合、デバイスがOSプライバシーポリシーによって管理されたMACアドレスをランダム化する場合、特定のデバイスを使用して特定のデバイスを使用して、特定のデバイスを使用して一連のネットワークパケットフローを特定の個人と関連付けることも困難になります。
However, such address changes may affect the user experience and the efficiency of legitimate network operations. For a long time, network designers and implementers relied on the assumption that a given machine, in a network implementing IEEE 802 technologies [IEEE_802], would be represented by a unique network MAC address that would not change over time. When this assumption is broken, network communication may be disrupted. For example, sessions established between the end device and the network services may break, and packets in transit may suddenly be lost. If multiple clients implement aggressive (e.g., once an hour or shorter) MAC address randomization without coordination with network services, some network services, such as MAC address caching in the AP and the upstream Layer 2 switch, may not be able to handle the load, which may result in an unexpected network interruption.
ただし、このようなアドレスの変更は、ユーザーエクスペリエンスと合法的なネットワーク操作の効率に影響を与える可能性があります。長い間、ネットワーク設計者と実装者は、IEEE 802テクノロジー[IEEE_802]を実装するネットワークで、特定のマシンが時間とともに変化しない一意のネットワークMACアドレスで表されるという仮定に依存していました。この仮定が破られると、ネットワーク通信が破壊される可能性があります。たとえば、エンドデバイスとネットワークサービスの間に確立されたセッションが破損し、輸送中のパケットが突然失われる可能性があります。複数のクライアントがネットワークサービスと調整せずに攻撃的（1時間または短い1時間または短い）アドレスのランダム化を実装する場合、MACアドレスのAPや上流レイヤー2スイッチなどの一部のネットワークサービスは、負荷を処理できない可能性があります。
At the same time, some network services rely on the end station (as defined by [IEEE_802]) to provide an identifier, which can be the MAC address or another value. This document also refers to the end station as a "device" or "machine". If the client implements MAC address randomization but continues sending the same static identifier, then the association between a stable identifier and the station continues despite the RCM scheme. There may be environments where such continued association is desirable, but there may be others where user privacy has more value than any continuity of network service state.
同時に、一部のネットワークサービスは、MACアドレスまたは別の値である可能性のある識別子を提供するために、エンドステーション（[IEEE_802]で定義されている）に依存しています。このドキュメントでは、エンドステーションを「デバイス」または「マシン」と呼んでいます。クライアントがMACアドレスのランダム化を実装しているが、同じ静的識別子の送信を継続する場合、RCMスキームにもかかわらず、安定した識別子とステーションとの関連性は継続します。そのような継続的な関連性が望ましい環境があるかもしれませんが、ユーザーのプライバシーがネットワークサービス状態のどの継続性よりも価値がある他の環境があるかもしれません。
It is useful for implementations of client and network devices to enumerate services that may be affected by RCM and to evaluate possible frameworks to maintain both the quality of user experience and network efficiency while RCM happens and user privacy is strengthened. This document presents these assessments and recommendations.
クライアントおよびネットワークデバイスの実装には、RCMの影響を受ける可能性のあるサービスを列挙し、可能なフレームワークを評価して、RCMが発生し、ユーザーのプライバシーが強化されている間、ユーザーエクスペリエンスとネットワーク効率の品質を維持するために役立ちます。このドキュメントでは、これらの評価と推奨事項を提示します。
Although this document mainly discusses MAC address randomization in Wi-Fi networks [IEEE_802.11], the same principles can be easily extended to any IEEE 802 networks [IEEE_802].
このドキュメントは、主にWi-Fiネットワーク[IEEE_802.11]のMACアドレスランダム化について説明していますが、同じ原則をIEEE 802ネットワーク[IEEE_802]に簡単に拡張できます。
This document is organized as follows:
このドキュメントは次のように整理されています。
* Section 2 discusses the current status of using MAC address as identity.
* セクション2では、MACアドレスをIDとして使用する現在のステータスについて説明します。
* Section 3 discusses various actors in the network that will be impacted by MAC address randomization.
* セクション3では、ネットワーク内のさまざまなアクターについて説明します。これは、MACアドレスのランダム化の影響を受けます。
* Section 4 examines the degrees of trust between personal devices and the entities at play in a network domain.
* セクション4では、個人のデバイスとネットワークドメインで再生されているエンティティ間の信頼度を調べます。
* Section 5 discusses various network environments that will be impacted.
* セクション5では、影響を受けるさまざまなネットワーク環境について説明します。
* Section 6 analyzes some existing network services that will be impacted.
* セクション6では、影響を受けるいくつかの既存のネットワークサービスを分析します。
* Appendix A includes some existing frameworks.
* 付録Aには、いくつかの既存のフレームワークが含まれています。
In IEEE 802 [IEEE_802] technologies, the Media Access Control (MAC) layer defines rules to control how a device accesses the shared medium. In a network where a machine can communicate with one or more other machines, one such rule is that each machine needs to be identified as either the target destination of a message or the source of a message (and the target destination of the answer). Initially intended as a 48-bit (6-octet) value in the first versions of IEEE 802, other standards under the IEEE 802 [IEEE_802] umbrella allow this address to take an extended format of 64 bits (8 octets), which enabled a larger number of MAC addresses to coexist as IEEE 802 technologies became widely adopted.
IEEE 802 [IEEE_802]テクノロジーでは、メディアアクセス制御（MAC）レイヤーがルールを定義して、デバイスが共有メディアにアクセスする方法を制御します。マシンが1つ以上の他のマシンと通信できるネットワークでは、そのようなルールの1つは、各マシンをメッセージのターゲット宛先またはメッセージのソース（および回答のターゲット宛先）のいずれかとして識別する必要があることです。当初、IEEE 802の最初のバージョンで48ビット（6-OCTET）値として意図されていましたが、IEEE 802 [IEEE_802]傘下のその他の標準により、このアドレスは64ビット（8オクテット）の拡張形式（8オクテット）を取ることができました。
Regardless of the address length, different networks have different needs, and several bits of the first octet are reserved for specific purposes. In particular, the first bit is used to identify the destination address as an individual (bit set to 0) or a group address (bit set to 1). The second bit, called the Universal/Local (U/L) address bit, indicates whether the address has been assigned by a universal or local administrator. Universally administered addresses have this bit set to 0. If this bit is set to 1, the entire address is considered to be locally administered (see Clause 8.4 of [IEEE_802]). Note that universally administered MAC addresses are required to be registered with the IEEE, while locally administered MAC addresses are not.
アドレスの長さに関係なく、ネットワークによって異なるニーズがあり、最初のオクテットのいくつかのビットは特定の目的のために予約されています。特に、最初のビットは、宛先アドレスを個人（0に設定）またはグループアドレス（ビット設定1に設定）として識別するために使用されます。ユニバーサル/ローカル（U/L）アドレスビットと呼ばれる2番目のビットは、アドレスがユニバーサル管理者またはローカル管理者によって割り当てられているかどうかを示します。普遍的に管理されているアドレスのビットは0に設定されています。このビットが1に設定されている場合、アドレス全体がローカルに管理されていると見なされます（[IEEE_802]の8.4項を参照）。普遍的に管理されたMACアドレスはIEEEに登録する必要がありますが、ローカルに管理されたMACアドレスはそうではありません。
The intent of this provision is important for the present document. [IEEE_802] recognizes that some devices (e.g., smart thermostats) may never change their attachment network and will not need a globally unique MAC address to prevent address collision against any other device in any other network. The U/L bit can be set to signal to the network that the MAC address is intended to be locally unique (not globally unique). [IEEE_802] did not initially define the MAC address allocation schema when the U/L bit is set to 1. It states the address must be unique in a given broadcast domain (i.e., the space where the MAC addresses of devices are visible to one another).
この規定の意図は、現在の文書にとって重要です。[IEEE_802]は、一部のデバイス（スマートサーモスタットなど）がアタッチメントネットワークを変更することはなく、他のネットワークの他のデバイスに対するアドレス衝突を防ぐためにグローバルに一意のMACアドレスを必要としないことを認識しています。U/Lビットは、MACアドレスがローカルで一意であることを意図していることをネットワークに信号にするように設定できます（グローバルに一意ではありません）。[IEEE_802]は、U/Lビットが1に設定されている場合、最初にMACアドレス割り当てスキーマを定義しませんでした。アドレスは、特定のブロードキャストドメイン（つまり、デバイスのMACアドレスが互いに表示される空間）で一意でなければならないと述べています。
It is also important to note that the purpose of the universal version of the address was to avoid collisions and confusion, as any machine could connect to any network, and each machine needs to determine if it is the intended destination of a message or its response. Clause 8.4 of [IEEE_802] reminds network designers and operators that all potential members of a network need to have a unique identifier in that network (if they are going to coexist in the network without confusion on which machine is the source or destination of any message). The advantage of an administrated address is that a node with such an address can be attached to any Local Area Network (LAN) in the world with an assurance that its address is unique in that network.
また、アドレスのユニバーサルバージョンの目的は、任意のマシンが任意のネットワークに接続できるため、衝突や混乱を避けることであり、各マシンがメッセージの意図された宛先かその応答かを判断する必要があることに注意することも重要です。[IEEE_802]の条項8.4は、ネットワークデザイナーとオペレーターに、ネットワークのすべての潜在的なメンバーがそのネットワークに一意の識別子を持つ必要があることを思い出させます（メッセージのソースまたは宛先であるマシンが混乱することなくネットワークに共存する場合）。管理されたアドレスの利点は、そのようなアドレスを持つノードを、そのアドレスがそのネットワークで一意であるという保証で、世界のローカルエリアネットワーク（LAN）に添付できることです。
With the rapid development of wireless technologies and mobile devices, this scenario became very common. With a vast majority of networks implementing IEEE 802 radio technologies [IEEE_802] at the access, the MAC address of a wireless device can appear anywhere on the planet and collisions should still be avoided. However, the same evolution brought the distinction between two types of devices that [IEEE_802] generally refers to as "nodes in a network" (see Section 6.2 of [IEEE_802E] for definitions of these devices):
ワイヤレステクノロジーとモバイルデバイスの急速な開発により、このシナリオは非常に一般的になりました。アクセス時にIEEE 802ラジオテクノロジー[IEEE_802]を実装するネットワークの大部分が、ワイヤレスデバイスのMACアドレスが地球上のどこにでも表示され、衝突はまだ回避する必要があります。ただし、同じ進化は、[IEEE_802]が一般に「ネットワーク内のノード」と呼ぶ2つのタイプのデバイス間の区別をもたらしました（これらのデバイスの定義については[IEEE_802E]のセクション6.2を参照）。
Shared Service Device:
共有サービスデバイス：
A device used by enough people that the device itself, its functions, or its traffic cannot be associated with a single or small group of people. Examples of such devices include switches in a dense network, (WLAN) access points [IEEE_802.11] in a crowded airport, and task-specific devices (e.g., barcode scanners).
デバイス自体、その機能、またはそのトラフィックを1人または小グループの人々に関連付けることができない十分な人が使用するデバイス。このようなデバイスの例には、密集したネットワーク、（WLAN）アクセスポイント[IEEE_802.11]の混雑した空港のスイッチ、およびタスク固有のデバイス（例：バーコードスキャナー）が含まれます。
Personal Device:
パーソナルデバイス：
A machine or node primarily used by a single person or small group of people, so that any identification of the device or its traffic can also be associated with the identification of the primary user or their online activity.
主に単一の人または小グループが使用するマシンまたはノード。そのため、デバイスまたはそのトラフィックの識別は、プライマリユーザーまたはそのオンラインアクティビティの識別にも関連付けられます。
Identifying the device is trivial if it has a unique MAC address. Once this unique MAC address is established, detecting any elements that directly or indirectly identify the user of the device (i.e., Personally Identifiable Information (PII)) is enough to link the MAC address to that user. Then, any detection of traffic that can be associated with the device will also be linked to the known user of that device (i.e., Personally Correlated Information (PCI)).
デバイスが一意のMACアドレスがある場合、デバイスを識別することは些細なことです。この一意のMACアドレスが確立されると、デバイスのユーザーを直接または間接的に識別する要素（つまり、個人識別可能な情報（PII））を検出するだけで、Macアドレスをそのユーザーにリンクするのに十分です。次に、デバイスに関連付けられるトラフィックの検出は、そのデバイスの既知のユーザー（つまり、個人的に相関した情報（PCI））にもリンクされます。
The possible identification or association presents a privacy issue, especially with wireless technologies. For most of them ([IEEE_802.11] in particular), the source and destination MAC addresses are not encrypted even in networks that implement encryption. This lack of encryption allows each machine to easily detect if it is the intended target of the message before attempting to decrypt its content and also helps identify the transmitter in order to use the right decryption key when multiple unicast keys are in effect.
可能な識別または関連性は、特にワイヤレステクノロジーに関するプライバシーの問題を提示します。それらのほとんど（特に[IEEE_802.11]）では、ソースおよび宛先MACアドレスは、暗号化を実装するネットワークでも暗号化されていません。この暗号化の欠如により、各マシンは、コンテンツを復号化しようとする前にメッセージの意図されたターゲットであるかどうかを簡単に検出でき、複数のユニキャストキーが有効になっているときに正しい復号化キーを使用するために送信機を識別するのにも役立ちます。
This identification of the user associated with a node was clearly not the intent of the IEEE 802 MAC address. A logical solution to remove this association is to use a locally administered address instead and change the address in a fashion that prevents a continuous association between one MAC address and some PII. However, other network devices on the same LAN implementing a MAC layer also expect each device to be associated with a MAC address that would persist over time. When a device changes its MAC address, other devices on the same LAN may fail to recognize that the same machine is attempting to communicate with them. This type of MAC address is referred to as 'persistent' MAC address in this document. This assumption sometimes adds to the PII confusion, for example, in the case of Authentication, Authorization, and Accounting (AAA) services [RFC3539] authenticating the user of a machine and associating the authenticated user to the device MAC address. Other services solely focus on the machine (e.g., DHCPv4 [RFC2131]) but still expect each device to use a persistent MAC address, for example, to reassign the same IP address to a returning device. Changing the MAC address may disrupt these services.
ノードに関連付けられたユーザーのこの識別は、明らかにIEEE 802 Macアドレスの意図ではありませんでした。この関連付けを削除するための論理的なソリューションは、代わりにローカルに管理されたアドレスを使用し、1つのMACアドレスといくつかのPII間の継続的な関連性を防ぐファッションでアドレスを変更することです。ただし、MACレイヤーを実装する同じLAN上の他のネットワークデバイスは、各デバイスが時間の経過とともに持続するMACアドレスに関連付けられることも期待しています。デバイスがMACアドレスを変更すると、同じLAN上の他のデバイスが同じマシンがそれらと通信しようとしていることを認識できない場合があります。このタイプのMACアドレスは、このドキュメントの「永続的な」MACアドレスと呼ばれます。この仮定は、たとえば、認証、承認、および会計（AAA）サービス[RFC3539]の場合、マシンのユーザーを認証し、認証されたユーザーをデバイスMACアドレスに関連付ける場合、PIIの混乱に追加されることがあります。他のサービスは、マシン（例：DHCPV4 [RFC2131]など）のみに焦点を当てていますが、各デバイスが永続的なMACアドレスを使用して、同じIPアドレスを返されるデバイスに再割り当てすることを期待しています。MACアドレスを変更すると、これらのサービスが中断される場合があります。
The risk of service disruption is weighed against the privacy benefits. However, the plurality of actors involved in the exchanges tends to blur the boundaries of which privacy violations should be protected against. Therefore, it is useful to list the actors associated with the network exchanges because they either actively participate in these exchanges or can observe them. Some actors are functional entities, while others are human (or related) entities.
サービスの中断のリスクは、プライバシーの利点と比較検討されます。ただし、交換に関与する複数の俳優は、プライバシー違反を保護すべき境界を曖昧にする傾向があります。したがって、ネットワーク交換に関連するアクターをリストすると便利です。なぜなら、それらはこれらの交換に積極的に参加するか、それらを観察することができるからです。一部のアクターは機能的なエンティティであり、他の関係者は人間（または関連する）エンティティです。
Network communications based on IEEE 802 technologies commonly rely on station identifiers based on a MAC address. This MAC address is utilized by several types of network functional entities such as applications or devices that provide a service related to network operations.
IEEE 802テクノロジーに基づくネットワーク通信は、一般にMACアドレスに基づいたステーション識別子に依存しています。このMacアドレスは、ネットワーク操作に関連するサービスを提供するアプリケーションやデバイスなど、いくつかのタイプのネットワーク機能エンティティによって利用されます。
1. Wireless access network infrastructure devices (e.g., WLAN access points or controllers): These devices participate in IEEE 802 LAN operations. As such, they need to identify each machine as a source or destination to successfully continue exchanging frames. As a device changes its network attachment (roams) from one access point to another, the access points can exchange contextual information (e.g., device MAC address and keying material), allowing the device session to continue seamlessly. These access points can also inform devices further in the wired network about the roam to ensure that Layer 2 frames are redirected to the new device access point.
1. ワイヤレスアクセスネットワークインフラストラクチャデバイス（WLANアクセスポイントやコントローラーなど）：これらのデバイスは、IEEE 802 LAN操作に参加しています。そのため、フレームの交換を継続するために、各マシンをソースまたは宛先として識別する必要があります。デバイスが1つのアクセスポイントから別のアクセスポイントにネットワーク添付ファイル（ROAM）を変更すると、アクセスポイントはコンテキスト情報（デバイスMACアドレスやキーイング素材など）を交換でき、デバイスセッションをシームレスに継続できます。また、これらのアクセスポイントは、Wiredネットワークでローマについてさらにデバイスに通知し、レイヤー2フレームが新しいデバイスアクセスポイントにリダイレクトされるようにすることもできます。
2. Other network devices operating at the MAC layer: Many wireless network access devices (e.g., access points [IEEE_802.11]) are conceived as Layer 2 devices, and as such, they bridge a frame from one medium (e.g., Wi-Fi [IEEE_802.11]) to another (e.g., Ethernet [IEEE_802.3]). This means that the MAC address of a wireless device often exists on the wire beyond the wireless access device. Devices connected to this wire also implement IEEE 802.3 technologies [IEEE_802.3], and as such, they operate on the expectation that each device is associated with a MAC address that persists for the duration of continuous exchanges. For example, switches and bridges associate MAC addresses to individual ports (so as to know to which port to send a frame intended for a particular MAC address). Similarly, AAA services can validate the identity of a device and use the device MAC address as the first pointer to the device identity (before operating further verification). Similarly, some networking devices offer Layer 2 filtering policies that may rely on the connected MAC addresses. IEEE 802.1X-enabled devices [IEEE_802.1X] may also selectively put the interface in a blocking state until a connecting device is authenticated. These services then use the MAC address as the first pointer to the device identity to allow or block data traffic. This list is not exhaustive. Multiple services are defined for Ethernet networks [IEEE_802.3], and multiple services defined by the IEEE 802.1 working group are also applicable to Ethernet networks [IEEE_802.3]. Wireless access points may also connect using other mediums (e.g., the Data-Over-Cable Service Interface Specification (DOCSIS) [DOCSIS]) that implement mechanisms under the umbrella of the general 802 Standard and therefore expect the unique and persistent association of a MAC address to a device.
2. MACレイヤーで動作する他のネットワークデバイス：多くのワイヤレスネットワークアクセスデバイス（例：アクセスポイント[IEEE_802.11]）はレイヤー2デバイスとして考案されているため、1つの媒体（Wi-Fi [IEEE_802.11]など）を別の媒体（Ethernet [IEEE_802.3]）に橋渡しします。これは、ワイヤレスデバイスのMACアドレスが、しばしばワイヤレスアクセスデバイスを越えてワイヤーに存在することを意味します。このワイヤーに接続されたデバイスは、IEEE 802.3テクノロジー[IEEE_802.3]も実装するため、各デバイスが継続的な交換の期間中に持続するMACアドレスに関連付けられるという期待に応じて動作します。たとえば、スイッチとブリッジは、MACアドレスを個々のポートに関連付けます（特定のMACアドレス用のフレームを送信するポートを知るため）。同様に、AAAサービスはデバイスのIDを検証し、デバイスIDの最初のポインターとしてデバイスMacアドレスを使用できます（さらに検証する前に）。同様に、一部のネットワーキングデバイスは、接続されたMacアドレスに依存する可能性のあるレイヤー2フィルタリングポリシーを提供します。IEEE 802.1x対応のデバイス[IEEE_802.1x]は、接続デバイスが認証されるまで、インターフェイスをブロッキング状態に選択的に配置することもできます。これらのサービスは、MACアドレスをデバイスIDの最初のポインターとして使用して、データトラフィックを許可またはブロックします。このリストは網羅的ではありません。イーサネットネットワーク[IEEE_802.3]に対して複数のサービスが定義されており、IEEE 802.1ワーキンググループによって定義された複数のサービスもイーサネットネットワーク[IEEE_802.3]に適用できます。ワイヤレスアクセスポイントは、一般802標準の傘下でメカニズムを実装する他のメディア（たとえば、データオーバーケーブルサービスインターフェイス仕様（docsis）[docsis]）を使用して接続することもできます。
3. Network devices operating at upper layers: Some network devices provide functions and services above the MAC layer. Some of them also operate a MAC layer function. For example, routers provide IP forwarding services but rely on the device MAC address to create the appropriate frame structure. Other devices and services operate at upper layers but also rely upon the IEEE 802 principles of unique MAC-to-device mapping. For example, the Address Resolution Protocol (ARP) [RFC826] and Neighbor Discovery Protocol (NDP) [RFC4861] use a MAC address to create the mapping of an IP address to a MAC address for packet forwarding. If a device changes its MAC address without a mechanism to notify the Layer 2 switch it is connected to or is the provider of a service that expects a stable MAC-to-device mapping, the provider of the service and traffic forwarding may be disrupted.
3. 上層層で動作するネットワークデバイス：一部のネットワークデバイスは、MACレイヤーの上の機能とサービスを提供します。それらのいくつかは、MACレイヤー関数も動作します。たとえば、ルーターはIP転送サービスを提供しますが、デバイスMACアドレスに依存して適切なフレーム構造を作成します。他のデバイスとサービスは上層層で動作しますが、一意のMac-to-DeviceマッピングのIEEE 802原則にも依存しています。たとえば、アドレス解像度プロトコル（ARP）[RFC826]およびNeighbor Discoveryプロトコル（NDP）[RFC4861]は、MACアドレスを使用して、パケット転送のためにMACアドレスへのIPアドレスのマッピングを作成します。デバイスがレイヤー2スイッチを通知するメカニズムなしでMACアドレスを変更すると、安定したMACからデバイスマッピングが予想されるサービスのプロバイダーである場合、サービスとトラフィック転送のプロバイダーが破壊される場合があります。
Humans may actively participate in the network structure and operations or be observers at any point of the network lifecycle. Humans could be users of wireless devices or people operating wireless networks.
人間は、ネットワークの構造と操作に積極的に参加したり、ネットワークライフサイクルの任意の時点でオブザーバーになることがあります。人間は、ワイヤレスデバイスのユーザーまたはワイヤレスネットワークを運営しているユーザーになる可能性があります。
1. Over-the-Air (OTA) observers: The transmitting or receiving MAC address is usually not encrypted in wireless exchanges using IEEE 802 technologies, and any protocol-compatible device in range of the signal can read the frame header. As such, OTA observers are able to read the MAC addresses of individual transmissions. Some wireless technologies also support techniques to establish distances or positions, allowing the observer, in some cases, to uniquely associate the MAC address with a physical device and its associated location. An OTA observer may have a legitimate reason to monitor a particular device, for example, for IT support operations. However, another actor might also monitor the same device to obtain PII or PCI.
1. オーバーザエア（OTA）オブザーバー：MACアドレスの送信または受信は通常、IEEE 802テクノロジーを使用してワイヤレス交換で暗号化されず、信号の範囲のプロトコル互換デバイスはフレームヘッダーを読み取ることができます。そのため、OTAオブザーバーは、個々の送信のMACアドレスを読むことができます。一部のワイヤレステクノロジーは、距離または位置を確立するための技術もサポートし、場合によっては、MACアドレスを物理デバイスとそれに関連する場所に一意に関連付けることができます。OTAオブザーバーには、たとえばITサポート操作など、特定のデバイスを監視する正当な理由がある場合があります。ただし、別のアクターも同じデバイスを監視してPIIまたはPCIを取得する場合があります。
2. Wireless access network operators: Some wireless access networks host devices that meet specific requirements, such as device type (e.g., IoT-only networks and factory operational networks). Therefore, operators can attempt to identify the devices (or the users) connecting to the networks under their care. They often use the MAC address to represent an identified device.
2. ワイヤレスアクセスネットワークオペレーター：一部のワイヤレスアクセスネットワークは、デバイスタイプ（IoTのみのネットワークや工場の運用ネットワークなど）などの特定の要件を満たすデバイスをホストします。したがって、オペレーターは、ケアの下でネットワークに接続するデバイス（またはユーザー）を特定しようとします。多くの場合、MACアドレスを使用して識別されたデバイスを表します。
3. Network access providers: Wireless access networks are often considered beyond the first two layers of the OSI model. For example, a law enforcement agency (e.g., the FBI in the United States) may legally require the network access provider to identify communications from a subject. In this context, the operating access networks need to identify the devices used by the subjects and cross-reference the data generated by the devices in the network. In other contexts, the operating access networks assign resources based on contractual conditions (e.g., fee and bandwidth fair share). In these scenarios, the operators may use the MAC address to identify the devices and the users of their networks.
3. ネットワークアクセスプロバイダー：ワイヤレスアクセスネットワークは、OSIモデルの最初の2つのレイヤーを超えて考慮されることがよくあります。たとえば、法執行機関（米国のFBIなど）は、ネットワークアクセスプロバイダーが主題からの通信を特定することを法的に要求する場合があります。これに関連して、操作アクセスネットワークは、被験者が使用するデバイスを識別し、ネットワーク内のデバイスによって生成されたデータを相互参照する必要があります。他のコンテキストでは、操作アクセスネットワークは、契約条件（たとえば、料金や帯域幅の公正な共有）に基づいてリソースを割り当てます。これらのシナリオでは、オペレーターはMACアドレスを使用して、ネットワークのデバイスとユーザーを識別できます。
4. Over-the-Wired internal (OTWi) observers: Because the device wireless MAC address continues to be present over the wire if the infrastructure connection device (e.g., access point) functions as a Layer 2 bridge, observers may be positioned over the wire and may read transmission MAC addresses. Such capability supposes that the observer has access to the wired segment of the broadcast domain where the frames are exchanged. A broadcast domain is a logical segment of a network in which devices can send, receive, and monitor data frames from all other devices within the same segment. In most networks, such capability requires physical access to an infrastructure wired device in the broadcast domain (e.g., switch closet) and is therefore not accessible to all.
4. オーバーザワイヤード内部（OTWI）オブザーバー：インフラストラクチャ接続デバイス（アクセスポイントなど）がレイヤー2ブリッジとして機能する場合、デバイスワイヤレスMACアドレスはワイヤ上に存在し続けるため、オブザーバーはワイヤ上に配置され、伝送MACアドレスを読み取ることができます。このような機能は、オブザーバーがフレームが交換されるブロードキャストドメインの有線セグメントにアクセスできることを想定しています。ブロードキャストドメインは、デバイスが同じセグメント内の他のすべてのデバイスからデータフレームを送信、受信、監視できるネットワークの論理セグメントです。ほとんどのネットワークでは、このような機能には、ブロードキャストドメイン内のインフラストラクチャワイヤードデバイス（スイッチクローゼットなど）への物理的なアクセスが必要であるため、すべての人がアクセスできません。
5. Over-the-Wired external (OTWe) observers: Beyond the broadcast domain, frame headers are removed by a routing device, and a new Layer 2 header is added before the frame is transmitted to the next segment. The device MAC address is not visible anymore unless a mechanism copies the MAC address into a field that can be read while the packet travels to the next segment (e.g., IPv6 addresses built from the MAC address prior to the use of the methods defined in [RFC8981] and [RFC7217]). Therefore, unless this last condition exists, OTWe observers are not able to see the device MAC address.
5. オーバーザワイヤード外部（OTWE）オブザーバー：ブロードキャストドメインを超えて、フレームヘッダーはルーティングデバイスによって削除され、フレームが次のセグメントに送信される前に新しいレイヤー2ヘッダーが追加されます。マックアドレスが次のセグメントに移動している間にメカニズムが読み取られているフィールドにメカニズムをコピーしない限り、デバイスMACアドレスが表示されなくなります（たとえば、[RFC8981]および[RFC7217]で定義された方法を使用する前にMACアドレスから構築されたIPv6アドレス）。したがって、この最後の条件が存在しない限り、OTWEオブザーバーはデバイスMACアドレスを見ることができません。
The surface of PII exposures that can drive MAC address randomization depends on (1) the environment where the device operates, (2) the presence and nature of other devices in the environment, and (3) the type of network the device is communicating through. Consequently, a device can use an identifier (such as a MAC address) that can persist over time if trust with the environment is established, or it can use an identifier that is temporary if an identifier is required for a service in an environment where trust has not been established. Note that trust is not binary. It is useful to distinguish what trust a personal device may establish with the different entities at play in a network domain where a MAC address may be visible:
MACアドレスのランダム化を駆動できるPII露出の表面は、（1）デバイスが動作する環境、（2）環境内の他のデバイスの存在と性質、および（3）デバイスが通信しているネットワークのタイプに依存します。したがって、環境との信頼が確立されている場合、デバイスは識別子（MACアドレスなど）を使用できます。これは、環境との信頼が確立されている場合、または信頼が確立されていない環境で識別子が必要な場合に一時的な識別子を使用できます。信頼はバイナリではないことに注意してください。MACアドレスが表示される場合があるネットワークドメインで、個人デバイスがさまざまなエンティティをプレイしていることで確立できるものを区別することは有用です。
1. Full trust: The device establishes a trust relationship and shares its persistent MAC address with the access network devices (e.g., access point and WLAN controller). The network provides necessary security measures to prevent observers or network actors from accessing PII. The device (or its user) also has confidence that its MAC address is not shared beyond the Layer 2 broadcast domain boundary.
1. 完全な信頼：デバイスは信頼関係を確立し、アクセスネットワークデバイス（アクセスポイントやWLANコントローラーなど）と永続的なMACアドレスを共有します。ネットワークは、オブザーバーまたはネットワークアクターがPIIにアクセスするのを防ぐために必要なセキュリティ対策を提供します。デバイス（またはそのユーザー）は、MACアドレスがレイヤー2ブロードキャストドメイン境界を越えて共有されていないことにも自信があります。
2. Selective trust: Depending on the predefined privacy policies, a device may decide to use one pseudo-persistent MAC address for a set of network elements and another pseudo-persistent MAC address for another set of network elements. Examples of privacy policies can be a combination of Service Set Identifier (SSID) and Basic Service Set Identifier (BSSID), a particular time of day, or a preset time duration.
2. 選択的信頼：事前に定義されたプライバシーポリシーに応じて、デバイスは、ネットワーク要素のセットに1つの擬似型MACアドレスを使用し、別のネットワーク要素のセットに別の擬似型MACアドレスを使用することを決定する場合があります。プライバシーポリシーの例は、サービスセット識別子（SSID）と基本的なサービスセット識別子（BSSID）の組み合わせ、特定の時間、またはプリセット期間の組み合わせです。
3. Zero trust: A device may randomize its MAC address with any local entity reachable through the AP. It may generate a temporary MAC address to each of them. That temporary MAC address may or may not be the same for different services.
3. ゼロトラスト：デバイスは、APを介して到達可能なローカルエンティティでMACアドレスをランダム化する場合があります。それぞれに一時的なMACアドレスを生成する場合があります。その一時的なMacアドレスは、異なるサービスで同じである場合と同じ場合があります。
The trust relationship depends on the relationship between the user of a personal device and the operator of a network service that the personal device may use. It is useful to observe the typical trust structure of common environments:
信頼関係は、個人デバイスのユーザーと、個人デバイスが使用できるネットワークサービスのオペレーターとの関係に依存します。共通環境の典型的な信頼構造を観察することは有用です。
(A) Residential settings under the control of the user: This is a typical home network with Wi-Fi in the LAN and Internet in the WAN. In this environment, traffic over the Internet does not expose the MAC address of the internal device if it is not copied to another field before routing happens. The wire segment within the broadcast domain is under the control of the user and is usually not at risk of hosting an eavesdropper. Full trust is typically established at this level among users and with the network elements. Note that "Full trust" in this context is referring to the MAC address persistency. It does not extend to full trust between applications or devices. The device trusts the access point and all Layer 2 domain entities beyond the access point, where the Wi-Fi transmissions can be detected, but there is no guarantee that an eavesdropper will not observe the communications. As such, even in this environment, it is common to assume that attackers may still be able to monitor unencrypted information such as MAC addresses. If a device decides to not fully trust the network, it might apply any necessary policy to protect its identity. Most users connecting to a residential network only expect simple Internet connectivity services, so the network services are simple. If users have issues connecting to the network or accessing the Internet, they expect limited to no technical support.
（a）ユーザーの管理下にある住宅環境：これは、LANにWi-FiとWANのインターネットを備えた典型的なホームネットワークです。この環境では、ルーティングが発生する前に別のフィールドにコピーされていない場合、インターネット上のトラフィックは内部デバイスのMACアドレスを公開しません。ブロードキャストドメイン内のワイヤセグメントはユーザーの制御下にあり、通常、盗聴者をホストするリスクがありません。通常、完全な信頼は、ユーザー間でこのレベルでネットワーク要素を使用して確立されます。このコンテキストでの「完全な信頼」は、MACアドレスの持続性を指していることに注意してください。アプリケーションまたはデバイス間の完全な信頼に拡張されていません。デバイスは、Wi-Fi送信を検出できるアクセスポイントを超えてアクセスポイントとすべてのレイヤー2ドメインエンティティを信頼しますが、盗聴者が通信を観察しないという保証はありません。そのため、この環境でさえ、攻撃者はMACアドレスなどの暗号化されていない情報を監視できる可能性があると仮定するのが一般的です。デバイスがネットワークを完全に信頼しないことを決定した場合、そのアイデンティティを保護するために必要なポリシーを適用する可能性があります。住宅ネットワークに接続するほとんどのユーザーは、単純なインターネット接続サービスのみを期待しているため、ネットワークサービスは簡単です。ユーザーがネットワークに接続したり、インターネットにアクセスしたりするのに問題がある場合、技術サポートが制限されないと予想されます。
(B) Managed residential settings: Examples of this type of environment include shared living facilities and other collective environments where an operator manages the network for the residents. The OTA exposure is similar to (A). The operator may be requested to provide IT support to the residents and may need to identify device activity in real time or analyze logs. The infrastructure is shared and covers a larger area than in (A); residents may connect to the network from different locations. For example, they may regularly connect to the network from their own apartments and occasionally connect from common areas. The device may decide to use different pseudo-persistent MAC addresses as described in Section 4. As such, the degree of trust is "Selective trust". In this environment, the network services will be slightly more complex than in (A). The network may be segmented by locations and multiple SSIDs. Users' devices should be able to join the network without pre-certification or pre-approval. In most cases, users only need simple connectivity; thus, network support will be slightly (but not significantly) more complicated than in (A).
（b）管理された住宅環境：このタイプの環境の例には、共有の生活施設や、オペレーターが住民のネットワークを管理する他の集団環境が含まれます。OTA暴露は（a）に似ています。オペレーターは、居住者にITサポートを提供するように要求される場合があり、リアルタイムでデバイスのアクティビティを特定したり、ログを分析する必要があります。インフラストラクチャは共有され、（a）よりも大きな領域をカバーしています。居住者は、さまざまな場所からネットワークに接続できます。たとえば、彼らは自分のアパートから定期的にネットワークに接続し、時には共通エリアから接続する場合があります。デバイスは、セクション4で説明されているように、異なる擬似能力のあるMACアドレスを使用することを決定する場合があります。そのため、信頼の程度は「選択的信頼」です。この環境では、ネットワークサービスは（a）よりもわずかに複雑になります。ネットワークは、場所と複数のSSIDによってセグメント化される場合があります。ユーザーのデバイスは、事前認定や事前承認なしにネットワークに参加できる必要があります。ほとんどの場合、ユーザーは単純な接続のみが必要です。したがって、ネットワークサポートは（a）よりもわずかに複雑になります。
(C) Public guest networks: Public hotspots in shopping malls, hotels, stores, train stations, and airports are typical examples of this environment. In this environment, trust is commonly not established with any element of the Layer 2 broadcast domain. Users do not anticipate a public guest network using the MAC address information to identify their location and network activity. They do not trust the network and do not want the network to memorize them permanently. The degree of trust is "Zero trust". Devices in this network should avoid using a long-lived MAC address to prevent fingerprinting. For example, the device may use a different MAC address every time it attaches to a new Wi-Fi access point. Some guest network operators may legally abide to identify devices. They should not use the MAC address for such a function. Most users connecting to a public guest network only expect simple Internet connectivity services, so the network services are simple. If users have issues connecting to the network or accessing the Internet, they expect limited to no technical support. Thus, the network support level is low.
（c）パブリックゲストネットワーク：ショッピングモール、ホテル、店舗、鉄道駅、空港のパブリックホットスポットは、この環境の典型的な例です。この環境では、信頼は一般に、レイヤー2ブロードキャストドメインの要素では確立されていません。ユーザーは、MACアドレス情報を使用してパブリックゲストネットワークが位置とネットワークのアクティビティを特定することを予想していません。彼らはネットワークを信頼せず、ネットワークがそれらを永久に記憶することを望んでいません。信頼度は「ゼロトラスト」です。このネットワークのデバイスは、指紋を防ぐために長寿命のMACアドレスを使用しないようにする必要があります。たとえば、デバイスは、新しいWi-Fiアクセスポイントに接続するたびに、別のMacアドレスを使用できます。一部のゲストネットワークオペレーターは、デバイスを識別するために合法的に順守する場合があります。このような関数にMACアドレスを使用しないでください。パブリックゲストネットワークに接続するほとんどのユーザーは、単純なインターネット接続サービスのみを期待しているため、ネットワークサービスは簡単です。ユーザーがネットワークに接続したり、インターネットにアクセスしたりするのに問題がある場合、技術サポートが制限されないと予想されます。したがって、ネットワークサポートレベルは低いです。
(D) Enterprises with Bring-Your-Own-Device (BYOD): This type of network is similar to (B) except that the onboarding devices are subjected to pre-approval and pre-certification. The devices are usually personal devices and are not under the control of the corporate IT team. Compared to residential networks, enterprise networks usually provide more sophisticated network services including, but not limited to, application-based and identity-based network policies. Changing the MAC address may interrupt network services if the services are based on that MAC address. Thus, network operations will be more complex, so the network support level is high.
（d）持ち込み義務（BYOD）を持つエンタープライズ：このタイプのネットワークは、（b）オンボーディングデバイスが事前承認と事前認定の対象となることを除いて（b）に似ています。デバイスは通常、個人のデバイスであり、コーポレートITチームの管理下にありません。住宅ネットワークと比較して、エンタープライズネットワークは通常、アプリケーションベースのネットワークポリシーを含むがこれらに限定されない、より洗練されたネットワークサービスを提供します。MACアドレスを変更すると、サービスがそのMacアドレスに基づいている場合、ネットワークサービスを中断する場合があります。したがって、ネットワーク操作はより複雑になるため、ネットワークサポートレベルが高くなります。
(E) Managed enterprises: This type of network is similar to (D). The main difference is that the devices are owned and managed by the enterprise. Because both the network and the devices are owned and managed by the enterprise, the degree of trust is "Full trust". Network services and the network support level are the same as in (D).
（e）マネージドエンタープライズ：このタイプのネットワークは（d）に似ています。主な違いは、デバイスがエンタープライズによって所有および管理されていることです。ネットワークとデバイスの両方がエンタープライズによって所有および管理されているため、信頼度は「完全な信頼」です。ネットワークサービスとネットワークサポートレベルは（d）と同じです。
Table 1 summarizes the environments described above.
表1は、上記の環境をまとめたものです。
+=======================+===========+=======+========+=============+
| Use Cases | Degree of |Network|Network | Network |
| | Trust |Admin |Services| Support |
| | | | | Expectation |
+=======================+===========+=======+========+=============+
| (A) Residential | Full |User |Simple | Low |
| settings under the | trust | | | |
| control of the user | | | | |
+-----------------------+-----------+-------+--------+-------------+
| (B) Managed | Selective |IT |Medium | Medium |
| residential settings | trust | | | |
+-----------------------+-----------+-------+--------+-------------+
| (C) Public guest | Zero |ISP |Simple | Low |
| networks | trust | | | |
+-----------------------+-----------+-------+--------+-------------+
| (D) Enterprises with | Selective |IT |Complex | High |
| Bring-Your-Own-Device | trust | | | |
| (BYOD) | | | | |
+-----------------------+-----------+-------+--------+-------------+
| (E) Managed | Full |IT |Complex | High |
| enterprises | trust | | | |
+-----------------------+-----------+-------+--------+-------------+
Table 1: Use Cases
表1：ユースケース
Existing technical frameworks that address some of the requirements of the use cases listed above are discussed in Appendix A.
上記のユースケースの要件のいくつかに対処する既存の技術フレームワークについては、付録Aで説明します。
Different network environments provide different levels of network services, from simple to complex. At its simplest level, a network can provide a wireless connecting device with basic IP communication service (e.g., DHCPv4 [RFC2131] or Stateless Address Autoconfiguration (SLAAC) [RFC4862]) and an ability to connect to the Internet (e.g., DNS service or relay and routing in and out through a local gateway). The network can also offer more advanced services, such as managed instant messaging service, file storage, printing, and/or local web service. Larger and more complex networks can also incorporate more advanced services, from AAA to Augmented Reality (AR) or Virtual Reality (VR) applications. To the network, its top priority is to provide the best quality of experience to its users. Often the network contains policies that help to make a forwarding decision based on the network conditions, the device, and the user identity associated to the device. For example, in a hospital private network, the network may contain a policy to give highest priority to doctors' Voice-Over-IP packets. In another example, an enterprise network may contain a policy to allow applications from a group of authenticated devices to use Explicit Congestion Notification (ECN) [RFC3168] for congestion and/or Differentiated Services Code Point (DSCP) [RFC8837] for classification to signal the network for a specific network policy. In this configuration, the network is required to associate the data packets to an identity to validate the legitimacy of the marking. Before RCM, many network systems used a MAC address as a persistent identity to create an association between user and device. After implementing RCM, the association is broken.
ネットワーク環境が異なると、シンプルから複雑なものまで、さまざまなレベルのネットワークサービスが提供されます。その最も単純なレベルでは、ネットワークは、基本的なIP通信サービス（DHCPV4 [RFC2131]などのワイヤレス接続デバイスまたはステートレスアドレスAutoconFiguration（SLAAC）[RFC4862]）を備えたワイヤレス接続デバイスを提供し、インターネットに接続する能力（DNSサービスまたはローカルゲートウェイを介したルーティング）を提供できます。ネットワークは、マネージドインスタントメッセージングサービス、ファイルストレージ、印刷、および/またはローカルWebサービスなど、より高度なサービスを提供することもできます。AAAから拡張現実（AR）またはバーチャルリアリティ（VR）アプリケーションまで、より大きくて複雑なネットワークには、より高度なサービスを組み込むこともできます。ネットワークにとって、その最優先事項は、ユーザーに最高の経験を提供することです。多くの場合、ネットワークには、ネットワーク条件、デバイス、およびデバイスに関連付けられたユーザーIDに基づいて転送決定を下すのに役立つポリシーが含まれています。たとえば、病院のプライベートネットワークでは、ネットワークには、医師のナレーションIPパケットを最優先事項にするためのポリシーが含まれている場合があります。別の例では、エンタープライズネットワークには、認証されたデバイスのグループからのアプリケーションが、特定のネットワークポリシーのネットワークを信号に合わせて分類するために、輻輳および/または差別化サービスコードポイント（DSCP）[RFC8837]に明示的なうっ血通知（ECN）[RFC3168]を使用できるようにするポリシーを含める場合があります。この構成では、ネットワークは、マーキングの正当性を検証するためにデータパケットをIDに関連付ける必要があります。RCMの前に、多くのネットワークシステムは、MACアドレスを永続的なIDとして使用して、ユーザーとデバイスの間に関連性を作成しました。RCMを実装した後、協会は壊れています。
Wireless access points and controllers use the MAC address to validate the device connection context, including protocol capabilities, confirmation that authentication was completed, quality of service or security profiles, and encryption keying material. Some advanced access points and controllers also include upper layer functions whose purpose is covered below. A device changing its MAC address, without another recorded device identity, would cause the access point and the controller to lose the relation between a connection context and the corresponding device. As such, the Layer 2 infrastructure does not know that the device (with its new MAC address) is authorized to communicate through the network. The encryption keying material is not identified anymore (causing the access point to fail to decrypt the device packets and fail to select the right key to send encrypted packets to the device). In short, the entire context needs to be rebuilt, and a new session restarted. The time consumed by this procedure breaks any flow that needs continuity or short delay between packets on the device (e.g., real-time audio, video, AR/VR, etc.). For example, [IEEE_802.11i] recognizes that a device may leave and rejoin the network after a short time window. As such, the standard suggests that the infrastructure should keep the context for a device for a while after the device was last seen. The device should maintain the same MAC address in such a scenario.
ワイヤレスアクセスポイントとコントローラーは、MACアドレスを使用して、プロトコル機能、認証が完了したこと、サービスの品質またはセキュリティプロファイル、暗号化キーイング材料を含むデバイス接続コンテキストを検証します。いくつかの高度なアクセスポイントとコントローラーには、目的を以下にカバーする上層関数も含まれています。別の記録されたデバイスIDがない場合、MACアドレスを変更するデバイスは、アクセスポイントとコントローラーが接続コンテキストと対応するデバイスとの関係を失います。そのため、レイヤー2のインフラストラクチャは、デバイス（新しいMacアドレス付き）がネットワークを介して通信することを許可されていることを知りません。暗号化キーイング材料はもはや識別されません（アクセスポイントがデバイスパケットを解読できず、暗号化されたパケットをデバイスに送信する適切なキーを選択できません）。要するに、コンテキスト全体を再構築する必要があり、新しいセッションが再開されました。この手順で消費される時間は、デバイス上のパケット間の連続性または短い遅延（リアルタイムオーディオ、ビデオ、AR/VRなど）間の短い遅延を必要とするフローを破壊します。たとえば、[IEEE_802.11i]は、デバイスが短い時間枠の後にネットワークを離れて再参加できることを認識しています。そのため、標準は、インフラストラクチャがデバイスが最後に見られてからしばらくの間、デバイスのコンテキストを維持する必要があることを示唆しています。このようなシナリオでは、デバイスは同じMACアドレスを維持する必要があります。
Some network equipment such as multi-layer routers and Wi-Fi access points, which serve both Layer 2 and Layer 3 in the same device, rely on ARP [RFC826] and NDP [RFC4861] to build the MAC-to-IP table for packet forwarding. The size of the MAC address cache in the Layer 2 switch is finite. If new entries are created faster than the old entries are flushed by the idle timer, it is possible to cause an unintentional denial-of-service attack. For example, the default timeout of the MAC address cache in Linux is set to 300 seconds. Aggressive MAC randomization from many devices in a short time interval (e.g., less than 300 seconds) may cause the Layer 2 switch to exhaust its resources, holding in memory traffic for a device whose entry can no longer be found. For the RCM device, these effects translate into session discontinuity and disrupt the active sessions. The discontinuity impact may vary. Real-time applications such as video conference may experience short interruption while non-real-time applications such as video streaming may experience minimal or no impact. The device should carefully balance when to change the MAC address after analyzing the nature of the running applications and its privacy policy.
同じデバイスでレイヤー2とレイヤー3の両方を提供するマルチレイヤールーターやWi-Fiアクセスポイントなどの一部のネットワーク機器は、ARP [RFC826]とNDP [RFC4861]に依存して、パケット転送用のMAC-IPテーブルを構築します。レイヤー2スイッチのMACアドレスキャッシュのサイズは有限です。古いエントリがアイドルタイマーによってフラッシュされるよりも速く新しいエントリが作成される場合、意図しないサービス拒否攻撃を引き起こす可能性があります。たとえば、LinuxのMACアドレスキャッシュのデフォルトのタイムアウトは300秒に設定されています。短時間の間隔で多くのデバイスからの積極的なMACランダム化（たとえば、300秒未満）により、レイヤー2がリソースを使い果たし、エントリが見つからないデバイスのメモリトラフィックを保持する可能性があります。RCMデバイスの場合、これらの効果はセッションの不連続性に変換され、アクティブセッションが破壊されます。不連続の影響は異なる場合があります。ビデオ会議などのリアルタイムアプリケーションは、短い中断が発生する可能性がありますが、ビデオストリーミングなどの非現実的なアプリケーションは、最小限または影響がない場合があります。実行中のアプリケーションの性質とそのプライバシーポリシーを分析した後、デバイスはMACアドレスを変更するタイミングを慎重にバランスさせる必要があります。
In wireless contexts, IEEE 802.1X authenticators [IEEE_802.1X] rely on the device and user identity validation provided by a AAA server to change the interface from a blocking state to a forwarding state. The MAC address is used to verify that the device is in the authorized list and to retrieve the associated key used to decrypt the device traffic. A change in MAC address causes the port to be closed to the device data traffic until the AAA server confirms the validity of the new MAC address. Consequently, MAC address randomization can disrupt the device traffic and strain the AAA server.
ワイヤレスコンテキストでは、IEEE 802.1x Authenticators [IEEE_802.1x]は、AAAサーバーが提供するデバイスとユーザーIDの検証に依存して、インターフェイスをブロッキング状態から転送状態に変更します。MACアドレスは、デバイスが承認されたリストにあることを確認し、デバイスのトラフィックを復号化するために使用される関連キーを取得するために使用されます。MACアドレスの変更により、AAAサーバーが新しいMacアドレスの有効性を確認するまで、ポートがデバイスデータトラフィックに閉じられます。その結果、MACアドレスのランダム化は、デバイスのトラフィックを破壊し、AAAサーバーに負担をかける可能性があります。
Without a unique identification of the device, DHCPv4 servers [RFC2131] lose track of which IP address is validly assigned. Unless the RCM device releases the IP address before changing its MAC address, DHCPv4 servers are at risk of scope exhaustion, causing new devices (and RCM devices) to fail to obtain a new IP address. Even if the RCM device releases the IP address before changing the MAC address, the DHCPv4 server typically holds the released IP address for a certain duration, in case the leaving MAC returns. As the DHCPv4 server [RFC2131] cannot know if the release is due to a temporary disconnection or a MAC randomization, the risk of scope address exhaustion exists even in cases where the IP address is released.
デバイスの一意の識別がなければ、DHCPV4サーバー[RFC2131]は、どのIPアドレスが有効に割り当てられているかを追跡します。MACアドレスを変更する前にRCMデバイスがIPアドレスをリリースしない限り、DHCPV4サーバーはスコープの消耗のリスクがあり、新しいデバイス（およびRCMデバイス）が新しいIPアドレスの取得に失敗します。MACアドレスを変更する前にRCMデバイスがIPアドレスをリリースした場合でも、DHCPV4サーバーは通常、リリースされたIPアドレスを特定の期間保持します。DHCPV4サーバー[RFC2131]は、リリースが一時的な切断またはMACランダム化によるものかどうかを知ることができないため、IPアドレスがリリースされた場合でもスコープアドレスの疲労のリスクが存在します。
Network devices with self-assigned IPv6 addresses (e.g., with SLAAC [RFC4862]) and devices using static IP addresses rely on mechanisms like Optimistic Duplicate Address Detection (DAD) [RFC4429] and NDP [RFC4861] for peer devices to establish the association between the target IP address and a MAC address, and these peers may cache this association in memory. Changing the MAC address, even at the disconnection-reconnection phase, without changing the IP address may disrupt the stability of these mappings for these peers if the change occurs within the caching period. Note that this behavior is against standard operation and existing privacy recommendations. Implementations must avoid changing the MAC address while maintaining the previously assigned IP address without consulting the network.
自己割り当てされたIPv6アドレス（例：SLAAC [RFC4862]を使用）および静的IPアドレスを使用したデバイスを備えたネットワークデバイスは、楽観的な複製アドレス検出（DAD）[RFC4429]やNDP [RFC4861]などのメカニズムに依存しています。IPアドレスを変更せずに、切断された再接続フェーズでさえ、Macアドレスを変更すると、キャッシュ期間内に変更が発生した場合、これらのピアのこれらのマッピングの安定性が破壊される可能性があります。この動作は、標準的な運用と既存のプライバシーの推奨に反していることに注意してください。実装は、ネットワークを参照せずに以前に割り当てられたIPアドレスを維持しながらMACアドレスを変更しないようにする必要があります。
Routers keep track of which MAC address is on which interface so that they can form the proper Data Link header when forwarding a packet to a segment where MAC addresses are used. MAC address randomization can cause MAC address cache exhaustion but also the need for frequent Address Resolution Protocol (ARP) [RFC826], Reverse Address Resolution Protocol (RARP) [RFC903], and Neighbor Solicitation and Neighbor Advertisement [RFC4861] exchanges.
ルーターは、Macアドレスがどのインターフェイスであるかを追跡するため、Macアドレスが使用されるセグメントにパケットを転送するときに適切なデータリンクヘッダーを形成できるようにします。MACアドレスのランダム化は、MACアドレスのキャッシュ疲労を引き起こす可能性がありますが、頻繁なアドレス解像度プロトコル（ARP）[RFC826]、逆住所解像度プロトコル（RARP）[RFC903]、および近隣の勧誘と近隣広告[RFC4861]交換の必要性も発生する可能性があります。
In residential settings (environment type A in Section 5), policies can be in place to control the traffic of some devices (e.g., parental control or blocklist filters). These policies are often based on the device MAC address. MAC address randomization removes the possibility for such control.
住宅環境（セクション5の環境タイプA）では、一部のデバイス（親の制御やブロックリストフィルターなど）のトラフィックを制御するためのポリシーを整えることができます。これらのポリシーは、多くの場合、デバイスMACアドレスに基づいています。MACアドレスランダム化は、そのような制御の可能性を削除します。
In residential settings (environment type A) and in enterprises (environment types D and E), device recognition and ranging may be used for IoT-related functionalities (e.g., door unlock, preferred light and temperature configuration, etc.) These functions often rely on the detection of the device wireless MAC address. MAC address randomization breaks the services based on such models.
住宅環境（環境タイプA）およびエンタープライズ（環境タイプDおよびE）では、IoT関連の機能（例：ドアロック解除、優先光および温度構成など）にデバイスの認識と範囲を使用することができます。MACアドレスランダム化は、そのようなモデルに基づいてサービスを破壊します。
In managed residential settings (environment type B) and in enterprises (environment types D and E), the network operator is often requested to provide IT support. With MAC address randomization, real-time support is only possible if the user can provide the current MAC address. Service improvement support is not possible if the MAC address that the device had at the time of the reported issue (in the past) is not known at the time the issue is reported.
管理された住宅環境（環境タイプB）およびエンタープライズ（環境タイプDおよびE）では、ネットワークオペレーターがITサポートを提供するためにしばしば要求されます。MACアドレスのランダム化により、ユーザーが現在のMACアドレスを提供できる場合にのみ、リアルタイムサポートが可能です。報告された問題の時点でデバイスが持っていたMACアドレス（過去に）が発行された時点では不明な場合、サービス改善のサポートは不可能です。
In managed enterprise environments, policies are associated with each group of objects, including IoT devices. MAC address randomization may prevent an IoT device from being identified properly and thus lead to network quarantine and disruption of operations.
マネージドエンタープライズ環境では、ポリシーはIoTデバイスを含む各グループのグループに関連付けられています。MACアドレスのランダム化により、IoTデバイスが適切に識別されないようにするため、ネットワーク検疫と操作の混乱につながる可能性があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
Privacy considerations are discussed throughout this document.
このドキュメント全体でプライバシーに関する考慮事項について説明します。
[DOCSIS] CableLabs, "Cable Modem Operations Support System
Interface Specification", Data-Over-Cable Service
Interface Specifications, DOCSIS 4.0, Version I06, March
2022, <https://www.cablelabs.com/specifications/CM-SP-CM-
OSSIv4.0?v=I06>.
[IEEE_802] IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture", IEEE Std 802-2014,
DOI 10.1109/IEEESTD.2014.6847097, 30 June 2014,
<https://ieeexplore.ieee.org/document/6847097>.
[IEEE_802.11]
IEEE, "IEEE Standard for Information Technology--
Telecommunications and Information Exchange between
Systems - Local and Metropolitan Area Networks--Specific
Requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", IEEE
Std 802.11-2020, DOI 10.1109/IEEESTD.2021.9363693, 26
February 2021,
<https://ieeexplore.ieee.org/document/9363693>.
[IEEE_802.11bh]
IEEE, "IEEE Standard for Information Technology--
Telecommunications and Information Exchange Between
Systems Local and Metropolitan Area Networks--Specific
Requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 1:
Operation with Randomized and Changing MAC Addresses",
IEEE Std 802.11bh-2024, DOI 10.1109/IEEESTD.2025.11023005,
3 June 2025,
<https://ieeexplore.ieee.org/document/11023005>.
[IEEE_802.11i]
IEEE, "IEEE 802.11i-2004 - Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) specifications:
Amendment 6: Medium Access Control (MAC) Security
Enhancements", IEEE Std 802.11i-2004,
DOI 10.1109/10.1109/IEEESTD.2004.94585, 24 July 2004,
<https://ieeexplore.ieee.org/document/1318903>.
[IEEE_802.1X]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks--Port-Based Network Access Control", IEEE Std
802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, 28 February
2020, <https://ieeexplore.ieee.org/document/9018454>.
[IEEE_802.3]
IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2022,
DOI 10.1109/IEEESTD.2022.9844436, 29 July 2022,
<https://ieeexplore.ieee.org/document/9844436>.
[IEEE_802E]
IEEE, "IEEE Recommended Practice for Privacy
Considerations for IEEE 802(R) Technologies", IEEE Std
802E-2020, DOI 10.1109/IEEESTD.2020.9018454, 13 November
2020, <https://ieeexplore.ieee.org/document/9257130>.
[RADIUS] DeKok, A., "Deprecating Insecure Practices in RADIUS",
Work in Progress, Internet-Draft, draft-ietf-radext-
deprecating-radius-06, 25 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-
deprecating-radius-06>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile", RFC 3539,
DOI 10.17487/RFC3539, June 2003,
<https://www.rfc-editor.org/info/rfc3539>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<https://www.rfc-editor.org/info/rfc4429>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, DOI 10.17487/RFC6614, May 2012,
<https://www.rfc-editor.org/info/rfc6614>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.
[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982,
<https://www.rfc-editor.org/info/rfc826>.
[RFC8837] Jones, P., Dhesikan, S., Jennings, C., and D. Druta,
"Differentiated Services Code Point (DSCP) Packet Markings
for WebRTC QoS", RFC 8837, DOI 10.17487/RFC8837, January
2021, <https://www.rfc-editor.org/info/rfc8837>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>.
[RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
Reverse Address Resolution Protocol", STD 38, RFC 903,
DOI 10.17487/RFC0903, June 1984,
<https://www.rfc-editor.org/info/rfc903>.
[WBA-OPENROAMING]
Tomas, B., Grayson, M., Canpolat, N., Cockrell, B. A., and
S. Gundavelli, "WBA OpenRoaming Wireless Federation", Work
in Progress, Internet-Draft, draft-tomas-openroaming-05,
15 April 2025, <https://datatracker.ietf.org/doc/html/
draft-tomas-openroaming-05>.
In a typical enterprise Wi-Fi environment, IEEE 802.1X authentication [IEEE_802.1X] coupled with WPA2 or WPA3 [IEEE_802.11i] encryption schemes are commonly used for onboarding a Wi-Fi device. This allows the mutual identification of the client device or the user of the device and an authentication authority. The authentication exchange does not occur in clear text, and the user or device identity can be concealed from unauthorized observers. However, in most cases, the authentication authority is under the control of the same entity as the network access provider. This may lead to exposing the user or device identity to the network owner.
典型的なエンタープライズWi-Fi環境では、IEEE 802.1x認証[IEEE_802.1x]とWPA2またはWPA3 [IEEE_802.11i]暗号化スキームと組み合わせて、Wi-Fiデバイスの搭乗に一般的に使用されます。これにより、クライアントデバイスまたはデバイスのユーザーと認証機関の相互識別が可能になります。認証交換は明確なテキストでは発生せず、ユーザーまたはデバイスのアイデンティティは不正なオブザーバーから隠すことができます。ただし、ほとんどの場合、認証機関はネットワークアクセスプロバイダーと同じエンティティを管理しています。これにより、ユーザーまたはデバイスのIDがネットワーク所有者にさらされる可能性があります。
This scheme is well-adapted to an enterprise environment, where a level of trust is established between the user and the enterprise network operator. In this scheme, MAC address randomization can occur through brief disconnections and reconnections (under the rules of [IEEE_802.11bh]). Authentication may then need to reoccur, with an associated cost of service disruption, an additional load on the enterprise infrastructure, and an associated benefit of limiting the exposure of a continuous MAC address to external observers. The adoption of this scheme is limited outside of the enterprise environment by the requirement to install an authentication profile on the end device, which would be recognized and accepted by a local authentication authority and its authentication server. Such a server is uncommon in a home environment, and the procedure to install a profile is cumbersome for most untrained users. The likelihood that a user or device profile would match a profile recognized by a public Wi-Fi authentication authority is also fairly limited. This may restrict the adoption of this scheme for public Wi-Fi as well. Similar limitations are found in the hospitality environment. The hospitality environment refers to space provided by the hospitality industry, which includes but is not limited to hotels, stadiums, restaurants, concert halls, and hospitals.
このスキームは、ユーザーとエンタープライズネットワークオペレーターの間にレベルの信頼が確立されているエンタープライズ環境によく適合しています。このスキームでは、MACアドレスのランダム化は、短い切断と再接続（[IEEE_802.11bh]のルールの下で）によって発生する可能性があります。認証は、関連するサービスの破壊、エンタープライズインフラストラクチャへの追加の負荷、および連続MACアドレスの外部オブザーバーへの露出を制限するという関連する利点により、再発する必要があります。このスキームの採用は、エンドデバイスに認証プロファイルをインストールする要件により、エンタープライズ環境以外で制限されています。これは、ローカル認証機関とその認証サーバーによって認識および受け入れられます。このようなサーバーは家庭環境では珍しく、プロファイルをインストールする手順は、ほとんどの訓練を受けていないユーザーにとって面倒です。ユーザーまたはデバイスプロファイルが、公開Wi-Fi認証機関によって認識されたプロファイルと一致する可能性もかなり制限されています。これにより、このスキームの採用が公共のWi-Fiにも制限される可能性があります。ホスピタリティ環境でも同様の制限があります。ホスピタリティ環境とは、ホスピタリティ業界が提供するスペースを指します。これには、ホテル、スタジアム、レストラン、コンサートホール、病院が含まれますがこれらに限定されません。
In order to alleviate some of the limitations listed above, the Wireless Broadband Alliance (WBA) OpenRoaming standard introduces an intermediate trusted relay between local venues (places where some public Wi-Fi is available) and sources of identity [WBA-OPENROAMING]. The federation structure extends the type of authorities that can be used as identity sources (compared to the typical enterprise-based IEEE 802.1X scheme for Wi-Fi [IEEE_802.1X]) and facilitates the establishment of trust between local networks and an identity provider. Such a procedure increases the likelihood that one or more identity profiles for the user or the device will be recognized by a local network. At the same time, authentication does not occur to the local network. This may offer the possibility for the user or the device to keep their identity obfuscated from the local network operator, unless that operator specifically expresses the requirement to disclose such identity (in which case the user has the option to accept or decline the connection and associated identity exposure).
上記の制限の一部を緩和するために、ワイヤレスブロードバンドアライアンス（WBA）OpenRoaming Standardは、地元の会場（公開Wi-Fiが利用可能な場所）とIDソース[WBA-Openroaming]の間の中間信頼できるリレーを導入します。連邦構造は、アイデンティティソースとして使用できるタイプの当局を拡張します（典型的なエンタープライズベースのIEEE 802.1xスキームのWi-Fi [IEEE_802.1x]）。このような手順により、ユーザーまたはデバイスの1つ以上のIDプロファイルがローカルネットワークによって認識される可能性が高くなります。同時に、ローカルネットワークでは認証は発生しません。これにより、ユーザーまたはデバイスが、そのオペレーターがそのようなアイデンティティを開示する要件を明確に表明しない限り、ユーザーまたはデバイスが現地ネットワークオペレーターから観測される可能性を提供する場合があります（この場合、ユーザーは接続および関連するアイデンティティの露出を受け入れるか拒否するオプションがあります）。
The OpenRoaming scheme seems well-adapted to public Wi-Fi and hospitality environments. It defines a framework to protect the identity from unauthorized entities while permitting mutual authentication between the device or the user and a trusted identity provider. Just like the standard IEEE 802.1X scheme for Wi-Fi [IEEE_802.1X], authentication allows for the establishment of WPA2 or WPA3 keys [IEEE_802.11i] that can then be used to encrypt the communication between the device and the access point. The encryption adds extra protection to prevent the network traffic from being eavesdropped.
OpenRoamingスキームは、公共のWi-Fiおよびホスピタリティ環境によく適応しているようです。デバイスまたはユーザーと信頼できるIDプロバイダーとの間の相互認証を許可しながら、不正なエンティティからIDを保護するフレームワークを定義します。Wi-Fi [IEEE_802.1x]の標準IEEE 802.1xスキームと同様に、認証により、デバイスとアクセスポイント間の通信を暗号化するために使用できるWPA2またはWPA3キー[IEEE_802.11i]の確立が可能になります。暗号化は、ネットワークトラフィックが盗聴されるのを防ぐために追加の保護を追加します。
MAC address randomization can occur through brief disconnections and reconnections (under the rules of [IEEE_802.11bh]). Authentication may then need to reoccur, with an associated cost of service disruption, an additional load on the venue and identity provider infrastructure, and an associated benefit of limiting the exposure of a continuous MAC address to external observers. Limitations of this scheme include the requirement to first install one or more profiles on the client device. This scheme also requires the local network to support RADSEC [RFC6614] and the relay function, which may not be common in small hotspot networks and home environments.
MACアドレスのランダム化は、短い切断と再接続（[IEEE_802.11bh]のルールの下で）によって発生する可能性があります。認証は、関連するサービスの破壊、会場およびIDプロバイダーのインフラストラクチャの追加の負荷、および継続的なMACアドレスの外部オブザーバーへの露出を制限するという関連する利点により、再発する必要がある場合があります。このスキームの制限には、最初にクライアントデバイスに1つ以上のプロファイルをインストールするための要件が含まれます。また、このスキームでは、ローカルネットワークがRadSec [RFC6614]とリレー関数をサポートする必要があります。リレー関数は、小さなホットスポットネットワークやホーム環境では一般的ではない場合があります。
It is worth noting that, as part of collaborations between the IETF MADINAS Working Group and WBA around OpenRoaming, some RADIUS privacy enhancements have been proposed in the IETF RADEXT Working Group. For instance, [RADIUS] describes good practices in the use of Chargeable-User-Identity (CUI) between different visited networks, making it better suited for public Wi-Fi and hospitality use cases.
IETF MadinasワーキンググループとOpenroaming周辺のWBAとのコラボレーションの一環として、IETF Radextワーキンググループでいくつかの半径プライバシーの強化が提案されていることに注意してください。たとえば、[RADIUS]は、異なる訪問ネットワーク間で請求可能なユーザーアイデンティティ（CUI）の使用における良い慣行を説明しており、公共のWi-Fiおよびホスピタリティユースケースにより適しています。
Most client OS vendors offer RCM schemes that are enabled by default (or easy to enable) on client devices. With these schemes, the device changes its MAC address, when not associated, after having used a given MAC address for a semi-random duration window. These schemes also allow for the device to manifest a different MAC address in different SSIDs.
ほとんどのクライアントOSベンダーは、クライアントデバイスでデフォルトで有効になっている（または有効にすることができる）RCMスキームを提供します。これらのスキームを使用すると、特定のMACアドレスを半ランダム期間ウィンドウに使用した後、関連付けられていない場合、デバイスはMACアドレスを変更します。また、これらのスキームにより、デバイスは異なるSSIDで異なるMACアドレスを明らかにすることもできます。
Such a randomization scheme enables the device to limit the duration of exposure of a single MAC address to observers. In [IEEE_802.11bh], MAC address randomization is not allowed during a given association session, and MAC address randomization can only occur through disconnection and reconnection. Authentication may then need to reoccur, with an associated cost of service disruption and additional load on the venue and identity provider infrastructure, directly proportional to the frequency of the randomization. The scheme is also not intended to protect from the exposure of other identifiers to the venue network (e.g., DHCP option 012 [host name] visible to the network between the AP and the DHCPv4 server).
このようなランダム化スキームにより、デバイスは、単一のMACアドレスの露出の期間をオブザーバーに制限できます。[IEEE_802.11BH]では、特定の関連セッション中にMACアドレスのランダム化は許可されておらず、MACアドレスのランダム化は切断と再接続によってのみ発生する可能性があります。その場合、認証は、ランダム化の頻度に直接比例して、関連するサービスコストの破壊と追加の負荷とIDプロバイダーインフラストラクチャの追加の負荷を伴う必要がある場合があります。このスキームは、他の識別子の会場ネットワークへの露出から保護することも意図されていません（例：DHCPオプション012 [ホスト名] APとDHCPV4サーバーの間のネットワークに表示されます）。
Jerome Henry
Cisco Systems
United States of America
Email: jerhenry@cisco.com
Yiu L. Lee
Comcast
1800 Arch Street
Philadelphia, PA 19103
United States of America
Email: yiu_lee@comcast.com