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.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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を使用したスマートフォンを介して）、プライバシーが大きな懸念になりつつあります。このユビキタスな接続性は、プライバシーに関する適切な教育の欠如とともに、ユーザーの位置や盗聴の物理的およびオンライン活動を簡単に追跡/監視できます。これは、ユーザーが同意の有無にかかわらずインターネットを去る膨大なデジタルフットプリントや、コミュニケーションの保護に使用される（またはnull）認証と暗号化のメカニズムなど、多くの要因によるものです。デジタルフットプリントには、ソーシャルネットワークで共有された情報、さまざまな理由でブラウザーとサーバーが使用する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.
今日使用されているほとんどのモバイルデバイスはWi-Fi対応です（つまり、IEEE 802.11ワイヤレスローカルエリアネットワークインターフェイスが装備されています）。イーサネット（つまり、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アドレスは、普遍的またはローカルに管理することができます。普遍的およびローカルに管理されたアドレスは、アドレスの最も重要なバイト（U/Lビット）の2番目に少ない重要なビットを設定することにより区別されます。
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.
結果のMACアドレスがグローバルに一意であるように、NICを製造した組織によって割り当てられた次の3つのオクテット。
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.
MACアドレス（およびその他の情報）に永続的に（20分ごとに）報告されているいくつかのモバイルOSEのレポート[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のように、および新しいインターネットプロトコル仕様を開発する際に従うガイドライン（たとえば、[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]に接続する際に、携帯電話ユーザーにより良いプライバシーを提供するために、モバイルOSEによってさらに実装されています。
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_EXPERIENG_CSD]に影響を与えます。したがって、2019年に一般的に提供される多くのオペレーターサービスに対するランダム化されたMAC識別子の潜在的に大規模な取り込みのIEEE 802.11マッピング効果でのフォローオン作業[RCM_TIG_FINAL_REPORT]。2020年の夏、この作業は2つの新しい標準プロジェクトで発生しました。これらのプロジェクトの目的は、ユーザーのプライバシーを減らさないが、（1）拡張サービスセットのデバイスのMACアドレス（相互接続されたIEEE 802.11ワイヤレスアクセスポイントと単一の論理ネットワークを形成するステーションのグループ）が無作為化または変更された場合、最適なユーザーエクスペリエンスを可能にするメカニズムを開発することでした[RCM_USER_EXPerience_Experience_Par.1182.11 Privacyには、[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登録機関が会社IDを介して割り当てたアドレスのブロック内で、サブ割り当ての拡張されたローカル識別子の範囲を指定します。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_802E]は、新たに導入された識別子が永続的であるために説得力のある理由がない場合、一時的および一時的な識別子の使用を推奨します。この推奨事項は、RCMの取り組み[RCM_PRIVACY_CSD]の一部として、IEEE STD 802.11デバイス（Wi-Fiデバイスとも呼ばれる）のユーザープライバシーソリューションのレビューの基礎の一部です。IEEE STD 802.1AEDK-2023の付録I（「MACプライバシー保護」）[IEEE_802.1AEDK] Bridged Networksのプライバシーに関する考慮事項について説明します。
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のステートレスアドレスAutoconfiguration（SLAAC）を指定します。これは、通常、ローカルルーターとインターフェイス識別子（IID）によって宣伝されているネットワークプレフィックスで構成される1つ以上の「安定した」アドレスを構成するホストになります。[RFC8064]は、L3でデバイスの追跡を可能にする可能性があるため、インターフェイスのMACアドレスからIIDを生成しないように、元の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の安定したアドレス指定情報を埋め込むことに関連するプライバシーの問題を特定して説明します。これは、AutoConfiguration Enabledで宣伝されている各プレフィックスのランダム化IIDを使用してホストが一時アドレスを生成するIPv6 SLAACの拡張機能を説明します。アドレスを変更すると、同じホストによる複数のトランザクションに同じアドレスが採用されている場合、盗聴者やその他の情報コレクターが住所ベースのネットワーク活性相関を簡単に実行できる時間のウィンドウが制限されます。さらに、アクティブな通信の結果として明らかになるアドレスからアクセスできるものとして、ホストの露出のウィンドウを減らします。これらの一時的な住所は、短期間（数時間から日）に使用され、その後廃止されることを目的としています。非推奨のアドレスは、既に確立された接続に使用され続けることができますが、新しい接続の開始には使用されません。期限切れの一時的なアドレスを置き換えるために、新しい一時的なアドレスが定期的に生成されます。一時的なアドレスを生成するために、ノードは、（1）外部の観察者が現在のアドレスに基づいて将来のアドレス（または識別子）を予測することは困難であり、現在のアドレスのみを知っている以前のアドレス（または識別子）を決定することは困難であるという意味で、一時的なグローバルスコープアドレスのシーケンスを生成します。一時的なアドレスは、着信接続を聴くアプリケーションでは使用しないでください（これらは永続的/よく知られている識別子を待っているはずです）。ノードがネットワークを変更し、以前に訪問したものに戻ると、ノードが使用する一時的なアドレスが異なります。これは、アドレスが運用目的で使用される特定のネットワーク（フィルタリングや認証など）で問題になる可能性があります。[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を生成するために定義された方法は、入力として以下を取得するハッシュ関数の計算に基づいています。インターフェイスに関連する情報（場所）、訪問されたネットワークに関連付けられた安定した情報（例えば、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アドレスを生成するためのデフォルトスキームとしてノードを実装することを推奨します。
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]は、次のことを提案します。
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リレーを有効にして、サーバーがリレーまたはクライアントによって要求された象限で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、またはRouter広告）のいくつかのパッシブ観測を介して、有線イーサネット接続に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アドレスは、セッションごとに生成されます。セッションの定義方法は実装依存です。たとえば、セッションは、PNGMやPPGMなどのポータル、VPNなどにログインすることで定義される場合があり、主に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（特にモバイルのオス）は、いくつかのMACアドレスランダム化ポリシーを実装しています。OSESが実装するメカニズムとポリシーは時間とともに進化できるため、コンテンツは<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を実行します）かどうかを示しています。
+=================+===============+=========+=========+=====+
| 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:
Android 12から始まる[Privacy_android]によると、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