Internet Engineering Task Force (IETF) JC. Zúñiga
Request for Comments: 9724 Cisco
Category: Informational CJ. Bernardos, Ed.
ISSN: 2070-1721 UC3M
A. Andersdotter
Safespring AB
March 2025
Internet users are becoming more aware that their activity over the Internet leaves a vast digital footprint, that communications might not always be properly secured, and that their location and actions can be tracked. One of the main factors that eases tracking of Internet users is the wide use of long-lasting, and sometimes persistent, identifiers at various protocol layers. This document focuses on Media Access Control (MAC) addresses.
インターネットユーザーは、インターネット上での活動が膨大なデジタルフットプリントを残し、通信が常に適切に保護されているわけではないこと、そして自身の位置や行動が追跡され得ることを、より強く認識するようになっています。インターネットユーザーの追跡を容易にしている主な要因の1つは、さまざまなプロトコル層において、長期間、時には永続的に使用される識別子が広く使われていることです。このドキュメントは、メディアアクセス制御（MAC）アドレスに焦点を当てています。
There have been several initiatives within the IETF and the IEEE 802 standards committees to address some of the privacy issues involved. This document provides an overview of these activities to help coordinate standardization activities in these bodies.
IETFおよびIEEE 802標準委員会内では、関連するプライバシー問題の一部に対処するためのいくつかの取り組みが行われてきました。このドキュメントは、これらの機関における標準化活動の調整を支援するために、これらの活動の概要を提供します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準化過程（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 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/rfc9724.
このドキュメントの現在のステータス、正誤表（もしあれば）、およびフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9724で入手できます。
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ドキュメントに関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらの文書には、このドキュメントに関するあなたの権利と制限が記載されていますので、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、トラスト法的規定のセクション4.eに記載されている改訂BSDライセンスのテキストを含める必要があり、改訂BSDライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Background
2.1. MAC Address Usage
2.2. MAC Address Randomization
2.3. Privacy Workshop, Tutorial, and Experiments at IETF and
IEEE 802 Meetings
3. Activities Relating to Randomized and Changing MAC Addresses in
the IEEE 802
4. Recent Activities Related to MAC Address Randomization in the
WBA
5. IPv6 Address Randomization in the IETF
6. Taxonomy of MAC Address Selection Policies
6.1. Per-Vendor OUI MAC Address (PVOM)
6.2. Per-Device Generated MAC Address (PDGM)
6.3. Per-Boot Generated MAC Address (PBGM)
6.4. Per-Network Generated MAC Address (PNGM)
6.5. Per-Period Generated MAC Address (PPGM)
6.6. Per-Session Generated MAC Address (PSGM)
7. OS Current Practices
8. IANA Considerations
9. Security Considerations
10. Informative References
Acknowledgments
Authors' Addresses
Privacy is becoming a huge concern, as more and more devices are connecting to the Internet either directly (e.g., via Wi-Fi) or indirectly (e.g., via a smartphone using Bluetooth). This ubiquitous connectivity, together with the lack of proper education about privacy, makes it very easy to track/monitor the location of users and/or eavesdrop on their physical and online activities. This is due to many factors, such as the vast digital footprint that users leave on the Internet with or without their consent and the weak (or even null) authentication and encryption mechanisms used to secure communications. A digital footprint may include information shared on social networks, cookies used by browsers and servers for various reasons, connectivity logs that allow tracking of a user's Layer 2 (L2) address (i.e., MAC address) or Layer 3 (L3) address, web trackers, etc.
ますます多くのデバイスがインターネットに直接接続しているため（例えば、Wi-Fiを介して）または間接的に（例えば、Bluetoothを使用したスマートフォンを介して）、プライバシーが大きな懸念になりつつあります。このユビキタスな接続性は、プライバシーに関する適切な教育の欠如とともに、ユーザーの位置を追跡/監視したり、物理的およびオンラインでの活動を盗聴したりすることを非常に容易にします。これは、ユーザーが同意の有無にかかわらずインターネット上に残す膨大なデジタルフットプリントや、コミュニケーションの保護に使用される（あるいは皆無の）認証と暗号化のメカニズムなど、多くの要因によるものです。デジタルフットプリントには、ソーシャルネットワークで共有された情報、さまざまな理由でブラウザーとサーバーが使用するCookie、ユーザーのレイヤー2（L2）アドレス（つまり、MACアドレス）またはレイヤー3（L3）アドレスの追跡を可能にする接続ログ、Webトラッカーなどが含まれます。
Privacy concerns affect all layers of the protocol stack, from the lower layers involved in the access to the network (e.g., MAC/L2 and L3 addresses can be used to obtain the location of a user) to higher-layer protocol identifiers and user applications [CSCN2015]. In particular, IEEE 802 MAC addresses have historically been an easy target for tracking users [wifi_tracking].
プライバシーの懸念は、ネットワークへのアクセスに関与する下位層（MAC/L2およびL3アドレスを使用してユーザーの位置を取得することができる）から、上位層のプロトコル識別子やユーザーアプリケーション[CSCN2015]に至るまで、プロトコルスタックのすべてのレイヤーに影響を及ぼします。特に、IEEE 802 MACアドレスは、歴史的にユーザーを追跡するための簡単なターゲットでした[wifi_tracking]。
There have been several initiatives within the IETF and the IEEE 802 standards committees to address some of these privacy issues. This document provides an overview of these activities to help coordinate standardization activities within these bodies.
これらのプライバシーの問題のいくつかに対処するために、IETFおよびIEEE 802の標準委員会にはいくつかの取り組みがありました。このドキュメントは、これらの機関内での標準化活動の調整を支援するために、これらの活動の概要を提供します。
Most mobile devices used today are Wi-Fi enabled (i.e., they are equipped with an IEEE 802.11 wireless local area network interface). Like any other kind of network interface based on IEEE 802 such as Ethernet (i.e., IEEE 802.3), Wi-Fi interfaces have an L2 address (also referred to as a MAC address) that can be seen by anybody who can receive the radio signal transmitted by the network interface. The format of these addresses (for 48-bit MAC addresses) is shown in Figure 1.
イーサネット（つまり、IEEE 802.3）などのIEEE 802に基づいた他の種類のネットワークインターフェイスと同様に、Wi-Fiインターフェイスには、ネットワークインターフェイスが送信する無線信号を受信できる人であれば誰でも見ることができるL2アドレス（MACアドレスとも呼ばれます）があります。これらのアドレスの形式（48ビットMACアドレスの場合）を図1に示します。
+--------+--------+---------+--------+--------+---------+
| Organizationally Unique | Network Interface |
| Identifier (OUI) | Controller (NIC) Specific |
+--------+--------+---------+--------+--------+---------+
/ \
/ \
/ \ b0 (I/G bit):
/ \ 0: unicast
/ \ 1: multicast
/ \
/ \ b1 (U/L bit):
+--+--+--+--+--+--+--+--+ 0: globally unique (OUI enforced)
|b7|b6|b5|b4|b3|b2|b1|b0| 1: locally administered
+--+--+--+--+--+--+--+--+
Figure 1: IEEE 802 MAC Address Format (for 48-Bit Addresses)
図1：IEEE 802 MACアドレス形式（48ビットアドレス用）
MAC addresses can be either universally or locally administered. Universally and locally administered addresses are distinguished by setting the second least significant bit of the most significant byte of the address (the U/L bit).
MACアドレスは、普遍的に管理されるか、ローカルに管理されるかのいずれかです。普遍的に管理されたアドレスとローカルに管理されたアドレスは、アドレスの最上位バイトの最下位から2番目のビット（U/Lビット）を設定することによって区別されます。
A universally administered address is uniquely assigned to a device by its manufacturer. Most physical devices are provided with a universally administered address, which is composed of two parts:
普遍的に管理されたアドレスは、製造元によってデバイスに一意に割り当てられます。ほとんどの物理デバイスには、2つの部分で構成される普遍的に管理されたアドレスが提供されています。
Organizationally Unique Identifier (OUI):
組織固有識別子（OUI）：
The first three octets in transmission order, which identify the organization that issued the identifier.
送信順序における最初の3つのオクテットで、識別子を発行した組織を識別します。
Network Interface Controller (NIC) Specific:
ネットワークインターフェイスコントローラー（NIC）固有：
The following three octets, which are assigned by the organization that manufactured the NIC, in such a way that the resulting MAC address is globally unique.
NICを製造した組織によって割り当てられる続く3つのオクテットであり、結果として得られるMACアドレスがグローバルに一意になるように割り当てられます。
Locally administered addresses override the burned-in address, and they can be set up by either the network administrator or the Operating System (OS) of the device to which the address pertains. However, as explained in later sections of this document, there are new initiatives in the IEEE 802 and other organizations to specify ways in which these locally administered addresses should be assigned, depending on the use case.
ローカルに管理されたアドレスは、焼き付けられたアドレスを上書きし、ネットワーク管理者またはそのアドレスが属するデバイスのオペレーティングシステム（OS）のいずれかによって設定できます。ただし、このドキュメントの後のセクションで説明するように、IEEE 802および他の組織には、ユースケースに応じてこれらのローカルに管理されたアドレスを割り当てる方法を指定するための新しい取り組みがあります。
Since universally administered MAC addresses are by definition globally unique, when a device uses this MAC address over a shared medium to transmit data -- especially over the air -- it is relatively easy to track this device by simple medium observation. Since a device is usually directly associated to an individual, this poses a privacy concern [link_layer_privacy].
普遍的に管理されているMACアドレスは定義上グローバルに一意であるため、デバイスが共有媒体上でこのMACアドレスを使用してデータを送信する場合、特に無線空間では、単純な媒体の観測によってこのデバイスを追跡することは比較的容易です。デバイスは通常個人に直接関連付けられているため、これはプライバシーの懸念をもたらします[link_layer_privacy]。
MAC addresses can be easily observed by a third party, such as a passive device listening to communications in the same L2 network. In an 802.11 network, a device (also known as an IEEE 802.11 station or STA) exposes its MAC address in two different situations:
MACアドレスは、同じL2ネットワークで通信を聞くパッシブデバイスなど、サードパーティによって簡単に観察できます。802.11ネットワークでは、デバイス（IEEE 802.11ステーションまたはSTAとも呼ばれます）は、2つの異なる状況でMACアドレスを公開します。
* While actively scanning for available networks, the MAC address is used in the Probe Request frames sent by the device.
* 利用可能なネットワークを積極的にスキャンしている間、MACアドレスはデバイスから送信されたプローブリクエストフレームで使用されます。
* Once associated to a given Access Point (AP), the MAC address is used in frame transmission and reception, as one of the addresses used in the unicast address fields of an IEEE 802.11 frame.
* 特定のアクセスポイント（AP）に関連付けられると、MACアドレスは、IEEE 802.11フレームのユニキャストアドレスフィールドで使用されるアドレスの1つとして、フレームの送受信で使用されます。
One way to address this privacy concern is by using randomly generated MAC addresses. IEEE 802 addressing includes one bit to specify if the hardware address is locally or globally administered. This allows local addresses to be generated without the need for any global coordination mechanism to ensure that the generated address is still unique within the local network. This feature can be used to generate random addresses, which decouple the globally unique identifier from the device and therefore make it more difficult to track a user device from its MAC/L2 address [enhancing_location_privacy].
このプライバシーの懸念に対処する1つの方法は、ランダムに生成されたMACアドレスを使用することです。IEEE 802アドレス指定には、ハードウェアアドレスがローカルまたはグローバルに管理されているかどうかを指定するためのビットが含まれています。これにより、生成されたアドレスがローカルネットワーク内で依然として一意であることを保証するために、グローバルな調整メカニズムを必要とせずにローカルアドレスを生成できます。この機能を使用して、ランダムなアドレスを生成することができます。これにより、グローバルに一意の識別子がデバイスから切り離され、MAC/L2アドレス[enhancing_location_privacy]からユーザーデバイスを追跡することがより困難になります。
Note that there are reports [contact_tracing_paper] of some mobile OSes reporting persistently (every 20 minutes or so) on MAC addresses (as well as other information), which would defeat MAC address randomization. While these practices might have changed by now, it is important to highlight that privacy-preserving techniques should be conducted while considering all layers of the protocol stack.
いくつかのモバイルOSがMACアドレス（およびその他の情報）を（20分程度ごとに）継続的に報告しており、これがMACアドレスのランダム化を無効にしてしまうという報告[contact_tracing_paper]があることに注意してください。これらの慣行は今では変更されているかもしれませんが、プロトコルスタックのすべての層を考慮しながら、プライバシー保護技術を実施する必要があることを強調することが重要です。
As an outcome to the STRINT W3C/IAB Workshop [strint], a tutorial titled "Pervasive Surveillance of the Internet - Designing Privacy into Internet Protocols" [privacy_tutorial] was given at the IEEE 802 Plenary meeting in San Diego in July of 2014. The tutorial provided an update on the recent developments regarding Internet privacy, the actions undertaken by other Standards Development Organizations (SDOs) like the IETF, and guidelines that were being followed when developing new Internet protocol specifications (e.g., the considerations described in [RFC6973]). The tutorial highlighted some privacy concerns that apply specifically to link-layer technologies and provided suggestions on how IEEE 802 could help address them.
STRINT W3C/IABワークショップ[Strint]の結果として、「インターネットの広範な監視 - インターネットプロトコルへのプライバシーの設計」[プライバシー_tutorial]というタイトルのチュートリアルは、2014年7月にサンディエゴで開催されたIEEE 802全体会議で提供されました。このチュートリアルでは、インターネットプライバシーに関する最近の動向、IETFなどの他の標準化団体（SDO）による活動、および新しいインターネットプロトコル仕様を策定する際に従うべきガイドライン（例：[RFC6973]で説明されている考慮事項）に関する最新情報が提供されました。このチュートリアルでは、リンクレイヤーテクノロジーに特に適用されるプライバシーの懸念を強調し、IEEE 802がどのように対処するのに役立つかについての提案を提供しました。
Following the discussions and interest within the IEEE 802 community, on 18 July 2014, the IEEE 802 Executive Committee (EC) created the IEEE 802 EC Privacy Recommendation Study Group (SG) [ieee_privacy_ecsg]. The work and discussions from the group have generated multiple outcomes, such Project Authorization Requests (PARs) that resulted in the following documents:
IEEE 802コミュニティでの議論と関心に続いて、2014年7月18日に、IEEE 802執行委員会（EC）は、IEEE 802 ECプライバシー推奨研究グループ（SG）[IEEE_PRIVACY_ECSG]を設立しました。グループによる作業と議論は、以下のドキュメントにつながったプロジェクト承認リクエスト（PAR）など、複数の成果を生み出しました。
* "IEEE Recommended Practice for Privacy Considerations for IEEE 802(R) Technologies" [IEEE_802E]
* 「IEEE 802(R)技術のためのプライバシーに関する考慮事項についてのIEEE推奨プラクティス」[IEEE_802E]
* "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture - Amendment 2: Local Medium Access Control (MAC) Address Usage" [IEEE_802c]
* 「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：概要とアーキテクチャ - 修正2：ローカルミディアムアクセスコントロール（MAC）アドレスの使用法」[IEEE_802C]
In order to test the effects of MAC address randomization, experiments were conducted at the IETF and IEEE 802 meetings between November 2014 and March 2015 -- IETF 91, IETF 92, and the IEEE 802 Plenary in Berlin. The purpose of the experiments was to evaluate the use of MAC address randomization from two different perspectives: (1) the effect on the connectivity experience of the end user, as well as any effect on applications and OSes, and (2) the potential impact on the network infrastructure itself. Some of the findings were published in [CSCN2015].
MACアドレスのランダム化の効果をテストするために、2014年11月から2015年3月の間にIETFおよびIEEE 802会議で実験が行われました - IETF 91、IETF 92、およびベルリンのIEEE 802プレナリー。実験の目的は、2つの異なる視点からのMACアドレスランダム化の使用を評価することでした。（1）エンドユーザーの接続エクスペリエンスへの影響、およびアプリケーションとOSへの影響、および（2）ネットワークインフラストラクチャ自体への潜在的な影響。調査結果のいくつかは[CSCN2015]に掲載されました。
During the experiments, it was observed that the probability of address duplication in a network is negligible. The experiments also revealed that other protocol identifiers (e.g., the DHCP client identifier) can be correlated and can therefore still be used to track an individual. Hence, effective privacy tools should not work in isolation at a single layer; instead; they should be coordinated with other privacy features at higher layers.
実験中、ネットワーク内のアドレス重複の確率は無視できることが観察されました。実験では、他のプロトコル識別子（例：DHCPクライアント識別子）が相関しているため、個人の追跡に使用できることが明らかになりました。したがって、効果的なプライバシーツールは、単一層で単独で機能すべきではありません。そうではなく、上位レイヤーの他のプライバシー機能と調整する必要があります。
Since then, MAC address randomization has been further implemented by mobile OSes to provide better privacy for mobile phone users when connecting to public wireless networks [privacy_ios] [privacy_windows] [privacy_android].
それ以来、MACアドレスのランダム化は、パブリックワイヤレスネットワーク[Privacy_ios] [Privacy_Windows] [Privacy_android]に接続する際に、携帯電話ユーザーにより良いプライバシーを提供するために、モバイルOSによってさらに実装されています。
Practical experiences with Randomized and Changing MAC addresses (RCM) in devices (some of which are explained in Section 6) helped researchers fine-tune their understanding of attacks against randomization mechanisms [when_mac_randomization_fails]. Within the IEEE 802.11 group, these research experiences eventually formed the basis for a specified mechanism that randomizes MAC addresses, which was introduced in IEEE Std 802.11aq [IEEE_802.11aq] in 2018.
デバイスのランダム化および変更されるMACアドレス（RCM）の実用的な経験（その一部はセクション6で説明されています）は、研究者がランダム化メカニズムに対する攻撃の理解を精緻化するのに役立ちました[whin_mac_randomization_fails]。IEEE 802.11グループ内で、これらの研究経験は、2018年にIEEE STD 802.11aq [IEEE_802.11AQ]で導入されたMACアドレスをランダム化する指定されたメカニズムの基礎を最終的に形成しました。
More recent developments include turning on MAC address randomization in mobile OSes by default, which has an impact on the ability of network operators to customize services [rcm_user_experience_csd]. Therefore, follow-on work in the IEEE 802.11 mapped effects of a potentially large uptake of randomized MAC identifiers on a number of commonly offered operator services in 2019 [rcm_tig_final_report]. In the summer of 2020, this work emanated in two new standards projects. The purpose of these projects was to develop mechanisms that do not decrease user privacy but enable an optimal user experience when (1) the MAC address of a device in an Extended Service Set (a group of interconnected IEEE 802.11 wireless access points and stations that form a single logical network) is randomized or changes [rcm_user_experience_par] and (2) user privacy solutions described in IEEE Std 802.11 [rcm_privacy_par] apply.
最近の開発には、モバイルOSでMACアドレスのランダム化をデフォルトで有効にすることが含まれており、これはネットワークオペレーターがサービスをカスタマイズする能力に影響を与えます[rcm_user_experience_csd]。したがって、IEEE 802.11での後続の作業では、2019年に、一般的に提供されている多くのオペレーターサービスに対して、ランダム化されたMAC識別子が大規模に採用された場合の影響をマッピングしました[rcm_tig_final_report]。2020年の夏、この作業から2つの新しい標準化プロジェクトが生まれました。これらのプロジェクトの目的は、(1) 拡張サービスセット（単一の論理ネットワークを形成する相互接続されたIEEE 802.11ワイヤレスアクセスポイントとステーションのグループ）内のデバイスのMACアドレスがランダム化または変更される場合 [rcm_user_experience_par]、および (2) IEEE Std 802.11 [rcm_privacy_par] に記述されているユーザープライバシーソリューションが適用される場合に、ユーザーのプライバシーを低下させずに最適なユーザーエクスペリエンスを可能にするメカニズムを開発することでした。
IEEE Std 802 [IEEE_802], as of the amendment IEEE 802c-2017 [IEEE_802c], specifies a local MAC address space structure known as the Structured Local Address Plan (SLAP) [RFC8948]. The SLAP designates a range of Extended Local Identifiers for subassignment within a block of addresses assigned by the IEEE Registration Authority via a Company ID. A range of local MAC addresses is designated for Standard Assigned Identifiers to be specified by IEEE 802 standards. Another range of local MAC addresses is designated for Administratively Assigned Identifiers, which are subject to assignment by a network administrator.
IEEE Std 802 [IEEE_802]は、修正IEEE 802c-2017 [IEEE_802c]の時点で、構造化ローカルアドレスプラン（SLAP）[RFC8948]として知られるローカルMACアドレス空間構造を指定しています。SLAPは、IEEE登録機関がCompany ID（CID）を介して割り当てたアドレスブロック内で、サブ割り当て用の拡張ローカル識別子（Extended Local Identifier）の範囲を指定します。IEEE 802標準で指定される標準割り当て識別子には、ローカルMACアドレスの範囲が指定されています。ローカルMACアドレスの別の範囲は、ネットワーク管理者による割り当ての対象となる管理上割り当てられた識別子に指定されています。
IEEE Std 802E-2020 ("IEEE Recommended Practice for Privacy Considerations for IEEE 802(R) Technologies") [IEEE_802E] recommends the use of temporary and transient identifiers if there are no compelling reasons for a newly introduced identifier to be permanent. This recommendation is part of the basis for the review of user privacy solutions for IEEE Std 802.11 devices (also known as Wi-Fi devices) as part of the RCM efforts [rcm_privacy_csd]. Annex I of IEEE Std 802.1AEdk-2023 ("MAC Privacy Protection") [IEEE_802.1AEdk] discusses privacy considerations in bridged networks.
IEEE Std 802E-2020（「IEEE 802(R)技術のためのプライバシーに関する考慮事項についてのIEEE推奨プラクティス」）[IEEE_802E]は、新たに導入された識別子が永続的であるべき説得力のある理由がない場合、一時的および過渡的な識別子の使用を推奨します。この推奨事項は、RCMの取り組み[rcm_privacy_csd]の一部として、IEEE Std 802.11デバイス（Wi-Fiデバイスとも呼ばれる）のユーザープライバシーソリューションのレビューの基礎の一部です。IEEE Std 802.1AEdk-2023の付録I（「MACプライバシー保護」）[IEEE_802.1AEdk] は、ブリッジネットワークにおけるプライバシーの考慮事項について論じています。
As of 2024, two task groups in IEEE 802.11 are dealing with issues related to RCM:
2024年の時点で、IEEE 802.11の2つのタスクグループがRCMに関連する問題に対処しています。
* The IEEE 802.11bh task group, which is looking at mitigating the repercussions that RCM creates on 802.11 networks and related services.
* IEEE 802.11bhタスクグループ。これは、RCMが802.11ネットワークと関連サービスに及ぼす影響を緩和することを検討しています。
* The IEEE 802.11bi task group, which is chartered to define modifications to the IEEE Std 802.11 MAC specification [IEEE_802.11] to specify new mechanisms that address and improve user privacy.
* IEEE 802.11biタスクグループ。これは、ユーザーのプライバシーに対処し向上させる新しいメカニズムを指定するために、IEEE Std 802.11 MAC仕様[IEEE_802.11]への変更を定義することを目的としています。
In the Wireless Broadband Alliance (WBA), the Testing and Interoperability Work Group has been looking at issues related to MAC address randomization and has identified a list of potential impacts of these changes to existing systems and solutions, mainly related to Wi-Fi identification.
ワイヤレスブロードバンドアライアンス（WBA）では、テストと相互運用性のワークグループは、MACアドレスのランダム化に関連する問題を検討しており、主にWi-Fi識別に関連する既存のシステムおよびソリューションへのこれらの変更の潜在的な影響のリストを特定しています。
As part of this work, the WBA has documented a set of use cases that a Wi-Fi Identification Standard should address in order to scale and achieve longer-term sustainability of deployed services (see [wba_paper]).
この作業の一環として、WBAは、展開されたサービスの規模拡大と長期的な持続可能性を達成するために、Wi-Fi識別標準が対処すべき一連のユースケースを文書化しました（[wba_paper]を参照）。
[RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for IPv6, which typically results in hosts configuring one or more "stable" addresses composed of a network prefix advertised by a local router and an Interface Identifier (IID). [RFC8064] formally updated the original IPv6 IID selection mechanism to avoid generating the IID from the MAC address of the interface (via EUI64), as this potentially allowed for tracking of a device at L3. Additionally, the prefix part of an IP address provides meaningful insights of the physical location of the device in general, which together with the IID based on the MAC address, made it easier to perform global device tracking.
[RFC4862]は、IPv6のステートレスアドレス自動設定（SLAAC）を指定します。これは、通常、ローカルルーターとインターフェイス識別子（IID）によって広報されているネットワークプレフィックスで構成される1つ以上の「安定した」アドレスをホストが構成することになります。[RFC8064]は、L3でデバイスの追跡を可能にする可能性があるため、インターフェイスのMACアドレスからIIDを生成しないように（EUI64経由）、元のIPv6 IID選択メカニズムを正式に更新しました。さらに、IPアドレスのプレフィックス部分は、一般的なデバイスの物理的位置の意味のある洞察を提供します。これは、MACアドレスに基づいてIIDとともにグローバルデバイス追跡を実行しやすくしました。
[RFC8981] identifies and describes the privacy issues associated with embedding MAC stable addressing information into IPv6 addresses (as part of the IID). It describes an extension to IPv6 SLAAC that causes hosts to generate temporary addresses with randomized IIDs for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. These temporary addresses are meant to be used for a short period of time (hours to days) and then deprecated. Deprecated addresses can continue to be used for already-established connections but are not used to initiate new connections. New temporary addresses are generated periodically to replace temporary addresses that expire. To generate temporary addresses, a node produces a sequence of temporary global scope addresses from a sequence of IIDs that appear to be random in the sense that (1) it is difficult for an outside observer to predict a future address (or identifier) based on a current one and (2) it is difficult to determine previous addresses (or identifiers) knowing only the present one. Temporary addresses should not be used by applications that listen for incoming connections (as these are supposed to be waiting on permanent/well-known identifiers). If a node changes network and comes back to a previously visited one, the temporary addresses that the node would use will be different, which might be an issue in certain networks where addresses are used for operational purposes (e.g., filtering or authentication). [RFC7217], summarized next, partially addresses the problems aforementioned.
[RFC8981]は、IPv6アドレス（IIDの一部として）にMACの安定したアドレス指定情報を埋め込むことに関連するプライバシーの問題を特定して説明します。これは、自動設定が有効な状態で広報されている各プレフィックスのランダム化IIDを使用してホストが一時アドレスを生成するIPv6 SLAACの拡張機能を説明します。アドレスを時間の経過とともに変更することで、同じホストによる複数のトランザクションに同じアドレスが使用されている場合に、盗聴者やその他の情報収集者がアドレスベースのネットワーク活動の相関付けを容易に実行できる期間が制限されます。さらに、アクティブな通信の結果として明らかになるアドレスを介してアクセス可能であるという、ホストの露出期間を短縮します。これらの一時的なアドレスは、短期間（数時間から日）に使用され、その後廃止されることを目的としています。非推奨のアドレスは、既に確立された接続に使用され続けることができますが、新しい接続の開始には使用されません。期限切れの一時的なアドレスを置き換えるために、新しい一時的なアドレスが定期的に生成されます。一時的なアドレスを生成するために、ノードは、（1）外部の観察者が現在のアドレスに基づいて将来のアドレス（または識別子）を予測することは困難であり、現在のアドレスのみを知っている以前のアドレス（または識別子）を決定することは困難であるという意味でランダムに見えるIIDのシーケンスから、一時的なグローバルスコープアドレスのシーケンスを生成します。一時的なアドレスは、着信接続を待ち受けるアプリケーションでは使用すべきではありません（これらは永続的/よく知られている識別子を待っているはずです）。ノードがネットワークを変更し、以前に訪問したものに戻ると、ノードが使用する一時的なアドレスが異なります。これは、アドレスが運用目的で使用される特定のネットワーク（フィルタリングや認証など）で問題になる可能性があります。[RFC7217]、次に要約され、前述の問題に部分的に対処します。
[RFC7217] describes a method to generate IIDs that are stable for each network interface within each subnet but change as a host moves from one network to another. This method enables the "stability" properties of the IIDs specified in [RFC4291] to be kept, while still mitigating address-scanning attacks and preventing correlation of the activities of a host as it moves from one network to another. The method defined to generate the IPv6 IID is based on computing a hash function that takes the following as input: information that is stable and associated to the interface (e.g., a local IID), stable information associated to the visited network (e.g., the IEEE 802.11 Service Set Identifier (SSID)), the IPv6 prefix, a secret key, and some other additional information. This basically ensures that a different IID is generated when one of the input fields changes (such as the network or the prefix) but that the IID is the same within each subnet.
[RFC7217]は、各サブネット内の各ネットワークインターフェイスに安定しているが、ホストがあるネットワークから別のネットワークに移動すると変更されるIIDを生成する方法を説明します。この方法により、[RFC4291]で指定されたIIDの「安定性」特性を維持しつつ、アドレススキャン攻撃を緩和し、あるネットワークから別のネットワークに移動するホストの活動の相関を防ぐことができます。IPv6 IIDを生成するために定義された方法は、入力として、インターフェイスに関連付けられた安定した情報（例えば、ローカルIID）、訪問されたネットワークに関連付けられた安定した情報（例えば、IEEE 802.11サービスセット識別子（SSID））、IPv6のプレフィックス、秘密鍵、およびその他の追加情報を使用するハッシュ関数の計算に基づいています。これにより、基本的に、入力フィールドの1つが変更されたときに異なるIIDが生成されることが保証されます（ネットワークやプレフィックスなど）が、各サブネット内でIIDが同じであることが保証されます。
To mitigate the privacy threats posed by the use of MAC-derived IIDs, [RFC8064] recommends that nodes implement [RFC7217] as the default scheme for generating stable IPv6 addresses with SLAAC.
MAC由来のIIDの使用によってもたらされるプライバシーの脅威を軽減するために、[RFC8064]は、SLAACで安定したIPv6アドレスを生成するためのデフォルトスキームとして、ノードが[RFC7217]を実装することを推奨しています。
In addition to the documents above, [RFC8947] proposes a DHCPv6 extension that:
上記のドキュメントに加えて、[RFC8947]は次のDHCPv6拡張機能を提案しています。
allows a scalable approach to link-layer address assignments where preassigned link-layer address assignments (such as by a manufacturer) are not possible or are unnecessary.
（メーカーによるものなど）事前に割り当てられたリンク層アドレスの割り当てが不可能または不要な場合に、リンク層アドレス割り当てへのスケーラブルなアプローチを可能にします。
And [RFC8948] proposes DHCPv6 extensions that:
また、[RFC8948]は以下のDHCPv6拡張機能を提案しています。
enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server so that the server may allocate MAC addresses in the quadrant requested by the relay or client.
DHCPv6クライアントまたはDHCPv6リレーが、サーバーに希望するSLAP象限を示すことを可能にし、サーバーがリレーまたはクライアントによって要求された象限内のMACアドレスを割り当てることができるようにします。
In addition to MAC and IP addresses, some DHCP options that carry unique identifiers can also be used for tracking purposes. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses. [RFC7844] introduces anonymity profiles that are:
MACおよびIPアドレスに加えて、一意の識別子を運ぶいくつかのDHCPオプションは、追跡目的にも使用できます。これらの識別子は、デバイス管理者がリンク層アドレスやIPv6アドレスなどの他の潜在的な識別をランダム化する場合でも、デバイス追跡を有効にできます。[RFC7844]は、次の匿名性プロファイルを導入します。
designed for clients that wish to remain anonymous to the visited network
訪問先ネットワークに対して匿名のままでいることを希望するクライアント向けに設計されており、
and that:
また、
provide guidelines on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure of identifying information.
識別情報の開示を最小限に抑えるように設計された、DHCPまたはDHCPv6メッセージの構成に関するガイドラインを提供します。
[RFC7844] also indicates that the link-layer address, IP address, and DHCP identifier shall evolve in synchrony.
[RFC7844]は、リンク層アドレス、IPアドレス、およびDHCP識別子が同期して変化すべきであることも示しています。
This section documents different policies for MAC address selection. Some OSes might use a combination of multiple policies.
このセクションでは、MACアドレスの選択に関するさまざまなポリシーを文書化します。一部のOSは、複数のポリシーの組み合わせを使用する場合があります。
Note: The naming convention for the terms defined in this section aligns with 802.11/Wi-Fi terminology in that the "A" for "address" is not included in the acronym. For example, "PVOM" stands for "Per-Vendor OUI MAC address", and "PNGM" stands for "Per-Network Generated MAC address".
注：このセクションで定義されている用語の命名規則は、「アドレス」の「A」が頭字語に含まれていないという点で、802.11/Wi-Fi用語と一致しています。たとえば、「PVOM」は「ベンダーごとのOUI MACアドレス」の略で、「PNGM」は「ネットワークごとに生成されたMACアドレス」を表しています。
This form of MAC address selection is the historical default.
この形式のMACアドレス選択は、歴史的なデフォルトです。
The vendor obtains an OUI from the IEEE. This is a 24-bit prefix (including two upper bits that are set specifically) that is assigned to the vendor. The vendor generates a unique 24-bit value for the lower 24 bits, forming the 48-bit MAC address. It is not unusual for the 24-bit value to be used as an incrementing counter that was assigned at the factory and burnt into non-volatile storage.
ベンダーはIEEEからOUIを取得します。これは、ベンダーに割り当てられた24ビットのプレフィックス（特定の設定がなされた2つの上位ビットを含む）です。ベンダーは、48ビットのMACアドレスを形成する、24ビットの下部に一意の24ビット値を生成します。工場で割り当てられ、不揮発性ストレージに書き込まれた増分カウンターとして24ビット値を使用することは珍しいことではありません。
Note that IEEE Std 802.15.4 [IEEE_802.15.4] uses 64-bit MAC addresses, and the IEEE assigns 32-bit prefixes. The IEEE has indicated that there may be a future Ethernet specification that uses 64-bit MAC addresses.
IEEE STD 802.15.4 [IEEE_802.15.4]は64ビットMACアドレスを使用し、IEEEは32ビットのプレフィックスを割り当てることに注意してください。IEEEは、64ビットMACアドレスを使用する将来のイーサネット仕様がある可能性があることを示しています。
This form of MAC address is randomly generated by the device, usually upon first boot. The resulting MAC address is stored in non-volatile storage and is used for the rest of the device lifetime.
この形式のMACアドレスは、通常は最初の起動時にデバイスによってランダムに生成されます。結果として得られるMACアドレスは不揮発性ストレージに保存され、その後デバイスの寿命が尽きるまで使用されます。
This form of MAC address is randomly generated by the device each time the device is booted. The resulting MAC address is *not* stored in non-volatile storage. It does not persist across power cycles. This case may sometimes be a PDGM where the non-volatile storage is no longer functional (or has failed).
この形式のMACアドレスは、デバイスが起動するたびにデバイスによってランダムに生成されます。結果のMACアドレスは、不揮発性ストレージに *保存されません*。電源の再投入をまたいで保持されることはありません。このケースは、不揮発性ストレージが機能しなくなった（または故障した）PDGMである場合があります。
This form of MAC address is generated each time a new network attachment is created.
この形式のMACアドレスは、新しいネットワーク接続が作成されるたびに生成されます。
This is typically used with Wi-Fi networks (i.e., 802.11 networks) where the network is identified by an SSID Name. The generated address is stored in non-volatile storage, indexed by the SSID. Each time the device returns to a network with the same SSID, the device uses the saved MAC address.
これは通常、Wi-Fiネットワーク（つまり、802.11ネットワーク）で使用され、ネットワークはSSID名で識別されます。生成されたアドレスは、SSIDをインデックスとして不揮発性ストレージに保存されます。デバイスが同じSSIDを持つネットワークに戻るたびに、デバイスは保存されたMACアドレスを使用します。
It is possible to use PNGM for wired Ethernet connections through some passive observation of network traffic (such as spanning tree protocols [IEEE_802.1Q], the Link Layer Discovery Protocol (LLDP) [IEEE_802.1AB], DHCP, or Router Advertisements) to determine which network has been attached.
ネットワークトラフィック（スパニングツリープロトコル[IEEE_802.1Q]、リンク層発見プロトコル（LLDP）[IEEE_802.1AB]、DHCP、またはルーター広告など）の受動的な観測を通じて、どのネットワークに接続されたかを判断し、有線イーサネット接続にPNGMを使用することが可能です。
This form of MAC address is generated periodically, typically around every twelve hours. Like PNGM, it is used primarily with Wi-Fi.
この形式のMACアドレスは、通常12時間ごとに定期的に生成されます。PNGMと同様に、主にWi-Fiで使用されます。
When the MAC address changes, the station disconnects from the current session and reconnects using the new MAC address. This will involve a new 802.1x session, as well as obtaining or refreshing a new IP address (e.g., using DHCP or SLAAC).
MACアドレスが変更されると、ステーションは現在のセッションから切断され、新しいMACアドレスを使用して再接続します。これには、新しい802.1xセッションと、新しいIPアドレスの取得または更新（DHCPまたはSLAACの使用など）が含まれます。
If DHCP is used, then a new DHCP Unique Identifier (DUID) is generated so as to not link to the previous connection; this usually results in the allocation of new IP addresses.
DHCPを使用する場合、以前の接続にリンクしないように、新しいDHCP一意識別子（DUID）が生成されます。これにより、通常、新しいIPアドレスが割り当てられます。
This form of MAC address is generated on a per-session basis. How a session is defined is implementation-dependent, for example, a session might be defined by logging in to a portal, VPN, etc. Like PNGM and PPGM, it is used primarily with Wi-Fi.
この形式のMACアドレスは、セッションごとに生成されます。セッションの定義方法は実装依存です。たとえば、セッションは、ポータルやVPNなどへのログインによって定義される場合があります。PNGMやPPGMと同様に、主にWi-Fiで使用されます。
Since the address only changes when a new session is established, there is no disconnection/reconnection involved.
アドレスは新しいセッションが確立されたときにのみ変更されるため、切断/再接続は含まれません。
By default, most modern OSes (especially mobile ones) do implement some MAC address randomization policies. Since the mechanism and policies that OSes implement can evolve with time, the content is hosted at <https://wiki.ietf.org/en/group/madinas/RFC9724>. For completeness, a snapshot of the content at the time of publication of this document is included below. Note that the extensive testing reported in this document was conducted in 2021, but no significant changes have been detected at the time of publication of this document.
デフォルトでは、ほとんどの最新のOS（特にモバイルOS）は、いくつかのMACアドレスランダム化ポリシーを実装しています。OSが実装するメカニズムとポリシーは時間とともに進化する可能性があるため、コンテンツは<https://wiki.ietf.org/en/group/madinas/RFC9724>でホストされています。参考までに、このドキュメントの公開時点でのコンテンツのスナップショットを以下に示します。このドキュメントで報告された広範なテストは2021年に実施されましたが、この文書の公開時点では重要な変更は検出されていません。
Table 1 summarizes current practices for Android and iOS at the time of writing this document (the original source is available at [private_mac]) and also includes updates based on findings from the authors.
表1は、このドキュメントの執筆時点でのAndroidおよびiOSの現在の慣行をまとめたものであり（元のソースは[private_mac]で入手可能）、著者の調査結果に基づいた更新も含まれています。
+=============================================+===================+
| Android 10+ | iOS 14+ |
+=============================================+===================+
| The randomized MAC address is bound to the | The randomized |
| SSID. | MAC address is |
| | bound to the |
| | Basic SSID. |
+---------------------------------------------+-------------------+
| The randomized MAC address is stable across | The randomized |
| reconnections for the same network. | MAC address is |
| | stable across |
| | reconnections for |
| | the same network. |
+---------------------------------------------+-------------------+
| The randomized MAC address does not get re- | The randomized |
| randomized when the device forgets a Wi-Fi | MAC address is |
| network. | reset when the |
| | device forgets a |
| | Wi-Fi network. |
+---------------------------------------------+-------------------+
| MAC address randomization is enabled by | MAC address |
| default for all the new Wi-Fi networks. | randomization is |
| But if the device previously connected to a | enabled by |
| Wi-Fi network identifying itself with the | default for all |
| real MAC address, no randomized MAC address | the new Wi-Fi |
| will be used (unless manually enabled). | networks. |
+---------------------------------------------+-------------------+
Table 1: Android and iOS MAC Address Randomization Practices
表1：AndroidおよびiOSのMACアドレスランダム化の慣行
In September 2021, we performed some additional tests to evaluate how OSes that are widely used behave regarding MAC address randomization. Table 2 summarizes our findings; the rows in the table show whether the OS performs address randomization per network (PNGM according to the taxonomy introduced in Section 6), performs address randomization per new connection (PSGM), performs address randomization daily (PPGM with a period of 24 hours), supports configuration per SSID, supports address randomization for scanning, and supports address randomization for scanning by default.
2021年9月に、広く使用されているOSがMACアドレスのランダム化に関してどのように動作するかを評価するために、いくつかの追加テストを実行しました。表2に、調査結果をまとめます。表の行は、OSがネットワークごとにアドレスランダム化（セクション6で導入された分類法に従いPNGM）を実行するか、新しい接続ごとにアドレスランダム化（PSGM）を実行するか、毎日アドレスランダム化（24時間周期のPPGM）を実行するか、SSIDごとの設定をサポートするか、スキャン時のアドレスランダム化をサポートするか、そしてデフォルトでスキャン時のアドレスランダム化をサポートするかを示しています。
+=================+===============+=========+=========+=====+
| OS | Linux (Debian | Android | Windows | iOS |
| | "bookworm") | 10 | 10 | 14+ |
+=================+===============+=========+=========+=====+
| Random. per | Y | Y | Y | Y |
| net. (PNGM) | | | | |
+-----------------+---------------+---------+---------+-----+
| Random. per | Y | N | N | N |
| connec. (PSGM) | | | | |
+-----------------+---------------+---------+---------+-----+
| Random. daily | N | N | Y | N |
| (PPGM) | | | | |
+-----------------+---------------+---------+---------+-----+
| SSID config. | Y | N | N | N |
+-----------------+---------------+---------+---------+-----+
| Random. for | Y | Y | Y | Y |
| scan | | | | |
+-----------------+---------------+---------+---------+-----+
| Random. for | N | Y | N | Y |
| scan by default | | | | |
+-----------------+---------------+---------+---------+-----+
Table 2: Observed Behavior in Different OSes (as of September 2021)
表2：異なるOSで観察された挙動（2021年9月現在）
According to [privacy_android], starting with Android 12, Android uses non-persistent randomization in the following situations:
[privacy_android]によると、Android 12以降、Androidは次の状況で非永続的なランダム化を使用します。
* A network suggestion application specifies that non-persistent randomization be used for the network (through an API).
* ネットワーク提案アプリケーションが、ネットワークに対して非永続的なランダム化を使用することを指定する場合（APIを介して）。
* The network is an open network that hasn't encountered a captive portal, and an internal config option is set to do so (by default, it is not).
* ネットワークが、キャプティブポータルを検出していないオープンネットワークであり、そうするように内部構成オプションが設定されている場合（デフォルトでは設定されていません）。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
Privacy considerations regarding tracking the location of a user through the MAC address of a device are discussed throughout this document. Given the informational nature of this document, no protocols/solutions are specified, but the current state of affairs is documented.
このドキュメント全体で、デバイスのMACアドレスを介してユーザーの場所を追跡することに関するプライバシーに関する考慮事項について説明します。このドキュメントの情報提供という性質上、プロトコルやソリューションは指定されていませんが、現在の状況が文書化されています。
Any future specification in this area would need to look into security and privacy aspects, such as (but not limited to) the following:
この分野の将来の仕様は、以下などのセキュリティとプライバシーの側面を調査する必要があります。
* Mitigating the problem of location privacy while minimizing the impact on upper layers of the protocol stack
* プロトコルスタックの上層への影響を最小限に抑えながら、位置情報のプライバシーの問題を軽減する
* Providing the means for network operators to authenticate devices and authorize network access, despite the MAC addresses changing according some pattern
* MACアドレスが何らかのパターンに応じて変更されているにもかかわらず、ネットワークオペレーターがデバイスを認証し、ネットワークアクセスを認可する手段を提供する
* Providing the means for the device not to use MAC addresses that it is not authorized to use or that are currently in use
* デバイスが使用することが許可されていない、または現在使用されているMACアドレスを使用しないための手段を提供する
A major conclusion of the work in IEEE Std 802E [IEEE_802E] concerned the difficulty of defending privacy against adversaries of any sophistication. Individuals can be successfully tracked by fingerprinting, using aspects of their communication other than MAC addresses or other permanent identifiers.
IEEE Std 802E [IEEE_802E]の作業の主要な結論は、高度な能力を持つ攻撃者に対するプライバシーを守ることの難しさに関するものでした。個人は、MACアドレスやその他の永続的な識別子以外の通信の側面を使用したフィンガープリンティングによって、追跡される可能性があります。
[contact_tracing_paper]
Leith, D. J. and S. Farrell, "Contact Tracing App Privacy:
What Data Is Shared By Europe's GAEN Contact Tracing
Apps", IEEE INFOCOM 2021 - IEEE Conference on Computer
Communications, DOI 10.1109/INFOCOM42981.2021.9488728, May
2021, <https://ieeexplore.ieee.org/document/9488728>.
[CSCN2015] Bernardos, CJ., Zúñiga, JC., and P. O'Hanlon, "Wi-Fi
Internet Connectivity and Privacy: Hiding your tracks on
the wireless Internet", 2015 IEEE Conference on Standards
for Communications and Networking (CSCN),
DOI 10.1109/CSCN.2015.7390443, October 2015,
<https://doi.org/10.1109/CSCN.2015.7390443>.
[enhancing_location_privacy]
Gruteser, M. and D. Grunwald, "Enhancing Location Privacy
in Wireless LAN Through Disposable Interface Identifiers:
A Quantitative Analysis", Mobile Networks and
Applications, vol. 10, no. 3, pp. 315-325,
DOI 10.1007/s11036-005-6425-1, June 2005,
<https://doi.org/10.1007/s11036-005-6425-1>.
[IEEE_802] IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture", IEEE Std 802-2014,
DOI 10.1109/IEEESTD.2014.6847097, June 2014,
<https://doi.org/10.1109/IEEESTD.2014.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,
February 2021,
<https://doi.org/10.1109/IEEESTD.2021.9363693>.
[IEEE_802.11aq]
IEEE, "IEEE Standard for Information technology--
Telecommunications and information exchange between
systems Local and metropolitan area network--Specific
requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 5:
Preassociation Discovery", IEEE Std 802.11aq-2018,
DOI 10.1109/IEEESTD.2018.8457463, August 2018,
<https://doi.org/10.1109/IEEESTD.2018.8457463>.
[IEEE_802.15.4]
IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE
Std 802.15.4-2024, DOI 10.1109/IEEESTD.2024.10794632,
December 2024,
<https://doi.org/10.1109/IEEESTD.2024.10794632>.
[IEEE_802.1AB]
IEEE, "IEEE Standard for Local and metropolitan area
networks - Station and Media Access Control Connectivity
Discovery", IEEE Std 802.1AB-2016,
DOI 10.1109/IEEESTD.2016.7433915, March 2016,
<https://doi.org/10.1109/IEEESTD.2016.7433915>.
[IEEE_802.1AEdk]
IEEE, "IEEE Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security - Amendment
4: MAC Privacy protection", IEEE Std 802.1AEdk-2023,
DOI 10.1109/IEEESTD.2023.10225636, August 2023,
<https://doi.org/10.1109/IEEESTD.2023.10225636>.
[IEEE_802.1Q]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks--Bridges and Bridged Networks", IEEE Std 802.1Q-
2022, DOI 10.1109/IEEESTD.2022.10004498, December 2022,
<https://doi.org/10.1109/IEEESTD.2022.10004498>.
[IEEE_802c]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks:Overview and Architecture--Amendment 2: Local
Medium Access Control (MAC) Address Usage", IEEE Std 802c-
2017, DOI 10.1109/IEEESTD.2017.8016709, August 2017,
<https://doi.org/10.1109/IEEESTD.2017.8016709>.
[IEEE_802E]
IEEE, "IEEE Recommended Practice for Privacy
Considerations for IEEE 802(R) Technologies", IEEE Std
802E-2020, DOI 10.1109/IEEESTD.2020.9257130, November
2020, <https://doi.org/10.1109/IEEESTD.2020.9257130>.
[ieee_privacy_ecsg]
IEEE 802 LAN/MAN Standards Committee, "IEEE 802 EC Privacy
Recommendation Study Group",
<http://www.ieee802.org/PrivRecsg/>.
[link_layer_privacy]
O'Hanlon, P., Wright, J., and I. Brown, "Privacy at the
link-layer", W3C/IAB workshop on Strengthening the
Internet Against Pervasive Monitoring (STRINT), February
2014.
[privacy_android]
Android Open Source Project, "MAC randomization behavior",
Android OS Documentation,
<https://source.android.com/devices/tech/connect/wifi-mac-
randomization-behavior>.
[privacy_ios]
Apple Inc., "Use private Wi-Fi addresses on Apple
Devices", Apple Support,
<https://support.apple.com/en-us/102509>.
[privacy_tutorial]
Cooper, A., Hardie, T., Zuniga, JC., Chen, L., and P.
O'Hanlon, "Pervasive Surveillance of the Internet -
Designing Privacy into Internet Protocols", IEEE 802
Tutorial, 14 July 2014, <https://mentor.ieee.org/802-
ec/dcn/14/ec-14-0043-01-00EC-internet-privacy-
tutorial.pdf>.
[privacy_windows]
Microsoft Corporation, "How to use random hardware
addresses in Windows", Microsoft Support,
<https://support.microsoft.com/en-us/windows/how-to-use-
random-hardware-addresses-ac58de34-35fc-31ff-
c650-823fc48eb1bc>.
[private_mac]
Pantaleone, D., "Private MAC address on iOS 14", Wayback
Machine archive, September 2020,
<https://web.archive.org/web/20230905111429/
https://www.fing.com/news/private-mac-address-on-ios-14>.
[rcm_privacy_csd]
IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
Changing MAC Addresses Study Group CSD on user experience
mechanisms", doc.:IEEE 802.11-20/1346r4, 2020. Download
available at <https://mentor.ieee.org/802.11/
dcn/20/11-20-1346-04-0rcm-csd-draft-for-privacy-amendment-
of-rcm- project.docx>.
[rcm_privacy_par]
IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
Changing MAC Addresses Study Group PAR on privacy
mechanisms", doc.:IEEE 802.11-19/854r7, 2020. Download
available at <https://mentor.ieee.org/802.11/
dcn/20/11-20-0854-07-0rcm-par-proposal-for-privacy.docx>.
[rcm_tig_final_report]
IEEE 802.11 WG RCM TIG, "IEEE 802.11 Randomized And
Changing MAC Addresses Topic Interest Group Report",
doc.:IEEE 802.11-19/1442r9, 2019. Download available at
<https://mentor.ieee.org/802.11/ dcn/19/11-19-1442-09-
0rcm-rcm-tig-draft-report-outline.odt>.
[rcm_user_experience_csd]
IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
Changing MAC Addresses Study Group CSD on user experience
mechanisms", doc.:IEEE 802.11-20/1117r5, 2020. Download
available at <https://mentor.ieee.org/802.11/
dcn/20/11-20-1117-05-0rcm-rcm-sg-proposed-rcm-csd-
draft.docx>.
[rcm_user_experience_par]
IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
Changing MAC Addresses Study Group PAR on user experience
mechanisms", doc.:IEEE 802.11-20/742r6, 2020. Download
available at <https://mentor.ieee.org/802.11/
dcn/20/11-20-0742-06-0rcm-proposed-par-draft.docx>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[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>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[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>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016,
<https://www.rfc-editor.org/info/rfc7844>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>.
[RFC8947] Volz, B., Mrugalski, T., and CJ. Bernardos, "Link-Layer
Address Assignment Mechanism for DHCPv6", RFC 8947,
DOI 10.17487/RFC8947, December 2020,
<https://www.rfc-editor.org/info/rfc8947>.
[RFC8948] Bernardos, CJ. and A. Mourad, "Structured Local Address
Plan (SLAP) Quadrant Selection Option for DHCPv6",
RFC 8948, DOI 10.17487/RFC8948, December 2020,
<https://www.rfc-editor.org/info/rfc8948>.
[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>.
[strint] W3C/IAB, "STRINT Workshop: A W3C/IAB workshop on
Strengthening the Internet Against Pervasive Monitoring
(STRINT)", <https://www.w3.org/2014/strint/>.
[wba_paper]
Wireless Broadband Alliance, "Wi-Fi Device Identification
- A Way Through MAC Randomization", WBA White Paper, July
2022, <https://wballiance.com/resource/wi-fi-device-
identification-a-way-through-mac-randomization/>.
[when_mac_randomization_fails]
Martin, J., Mayberry, T., Donahue, C., Foppe, L., Brown,
L., Riggins, C., Rye, E., and D. Brown, "A Study of MAC
Address Randomization in Mobile Devices and When it
Fails", arXiv:1703.02874v2, DOI 10.48550/arXiv.1703.02874,
March 2017, <https://doi.org/10.48550/arXiv.1703.02874>.
[wifi_tracking]
Vincent, J., "London's bins are tracking your smartphone",
The Independent, 9 August 2013,
<https://www.independent.co.uk/life-style/gadgets-and-
tech/news/updated-london-s-bins-are-tracking-your-
smartphone-8754924.html>.
The authors would like to thank Guillermo Sanchez Illan for the extensive tests performed on different OSes to analyze their behavior regarding address randomization.
著者は、アドレスのランダム化に関する挙動を分析するために、さまざまなOSで実行された広範なテストについてGuillermo Sanchez Illanに感謝したいと思います。
The authors would also like to thank Jerome Henry, Hai Shalom, Stephen Farrell, Alan DeKok, Mathieu Cunche, Johanna Ansohn McDougall, Peter Yee, Bob Hinden, Behcet Sarikaya, David Farmer, Mohamed Boucadair, Éric Vyncke, Christian Amsüss, Roman Danyliw, Murray Kucherawy, and Paul Wouters for their reviews and comments on previous draft versions of this document. In addition, the authors would like to thank Michael Richardson for his contributions on the taxonomy section. Finally, the authors would like to thank the IEEE 802.1 Working Group for its review and comments (see <https://datatracker.ietf.org/liaison/1884/>).
著者はまた、ジェローム・ヘンリー、ハイ・シャローム、スティーブン・ファレル、アラン・デコック、マシュー・クンチェ、ヨハンナ・アンソーン・マクドゥーガル、ピーター・イー、ボブ・ヒンデン、ベーセット・サリカヤ、デイビッド・ファーマー、モハメド・ブーカデア、エリック・ヴィンケ、クリスチャン・アムスース、ローマン・ダニリュー、マレー・クチラウィ、およびポール・ワウターズに、このドキュメントの以前のドラフトバージョンに対するレビューとコメントについて感謝します。さらに、著者は、分類セクションへの貢献について、マイケル・リチャードソンに感謝したいと思います。最後に、著者は、IEEE 802.1ワーキンググループのレビューとコメントに感謝したいと思います（<https://datatracker.ietf.org/liaison/1884/>を参照）。
Juan Carlos Zúñiga
Cisco
Montreal QC
Canada
Email: juzuniga@cisco.com
Carlos J. Bernardos (editor)
Universidad Carlos III de Madrid
Av. Universidad, 30
28911 Leganes, Madrid
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Amelia Andersdotter
Safespring AB
Email: amelia.ietf@andersdotter.cc