[要約] 要約：RFC 8691は、基本サービスセットのコンテキスト外で動作するIEEE Std 802.11ネットワーク上のIPv6の基本的なサポートに関する仕様です。 目的：このRFCの目的は、基本サービスセットのコンテキスト外でのIPv6の使用を可能にし、IEEE Std 802.11ネットワーク上でのIPv6通信の基本的なサポートを提供することです。
Internet Engineering Task Force (IETF) N. Benamar
Request for Comments: 8691 Moulay Ismail University of Meknes
Category: Standards Track J. Härri
ISSN: 2070-1721 EURECOM
J. Lee
Sangmyung University
T. Ernst
YoGoKo
December 2019
Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11
IEEE Std 802.11を介した基本サービスセットのコンテキスト外で動作するIPv6ネットワークの基本サポート
Abstract
概要
This document provides methods and settings for using IPv6 to communicate among nodes within range of one another over a single IEEE 802.11-OCB link. Support for these methods and settings require minimal changes to existing stacks. This document also describes limitations associated with using these methods. Optimizations and usage of IPv6 over more complex scenarios are not covered in this specification and are a subject for future work.
このドキュメントでは、IPv6を使用して、単一のIEEE 802.11-OCBリンクを介して相互の範囲内にあるノード間で通信するための方法と設定について説明します。これらのメソッドと設定のサポートには、既存のスタックへの最小限の変更が必要です。このドキュメントでは、これらの方法の使用に関連する制限についても説明します。より複雑なシナリオでのIPv6の最適化と使用は、この仕様ではカバーされておらず、将来の作業の対象となります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8691.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8691で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Communication Scenarios Where IEEE 802.11-OCB Links Are Used
4. IPv6 over 802.11-OCB
4.1. Maximum Transmission Unit (MTU)
4.2. Frame Format
4.3. Link-Local Addresses
4.4. Stateless Autoconfiguration
4.5. Address Mapping
4.5.1. Address Mapping -- Unicast
4.5.2. Address Mapping -- Multicast
4.6. Subnet Structure
5. Security Considerations
5.1. Privacy Considerations
5.1.1. Privacy Risks of Meaningful Information in Interface
IDs
5.2. MAC Address and Interface ID Generation
5.3. Pseudonymization Impact on Confidentiality and Trust
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. 802.11p
Appendix B. Aspects Introduced by OCB Mode to 802.11
Appendix C. Changes Needed on an 802.11a Software Driver to Become
an 802.11-OCB Driver
Appendix D. Protocol Layering
Appendix E. Design Considerations
Appendix F. IEEE 802.11 Messages Transmitted in OCB Mode
Appendix G. Examples of Packet Formats
G.1. Capture in Monitor Mode
G.2. Capture in Normal Mode
Appendix H. Extra Terminology
Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless
Links
Acknowledgements
Contributors
Authors' Addresses
This document provides a baseline for using IPv6 to communicate among nodes in range of one another over a single IEEE 802.11-OCB link [IEEE-802.11-2016] (a.k.a., 802.11p; see Appendices A, B, and C) with minimal changes to existing stacks. Moreover, the document identifies the limitations of such usage. Concretely, the document describes the layering of IPv6 networking on top of the IEEE Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer with a frame translation underneath. The resulting stack is derived from IPv6 over Ethernet [RFC2464] but operates over 802.11-OCB to provide at least P2P (point-to-point) connectivity using IPv6 Neighbor Discovery (ND) and link-local addresses.
このドキュメントは、IPv6を使用して、単一のIEEE 802.11-OCBリンク[IEEE-802.11-2016]（別名、802.11p;付録A、B、Cを参照）を介して相互の範囲内のノード間で通信するための最小限の変更でのベースラインを提供します既存のスタックに。さらに、ドキュメントはそのような使用の制限を識別します。具体的には、このドキュメントでは、IEEE Std 802.11 MACレイヤーまたはフレーム変換が下にあるIEEE Std 802.3 MACレイヤーの上にIPv6ネットワーキングを重ねることについて説明しています。結果のスタックはIPv6 over Ethernet [RFC2464]から派生しますが、802.11-OCBを介して動作し、IPv6近隣探索（ND）およびリンクローカルアドレスを使用して少なくともP2P（ポイントツーポイント）接続を提供します。
The IPv6 network layer operates on 802.11-OCB in the same manner as operating on the Ethernet with the following exceptions:
IPv6ネットワークレイヤーは、次の例外を除いて、イーサネットでの動作と同じ方法で802.11-OCBで動作します。
* Exceptions due to the different operation of the IPv6 network layer on 802.11 compared to the Ethernet. The operation of IP on Ethernet is described in [RFC1042] and [RFC2464].
* イーサネットと比較して802.11でのIPv6ネットワーク層の動作が異なるための例外。イーサネット上のIPの動作は、[RFC1042]と[RFC2464]で説明されています。
* Exceptions due to the OCB nature of 802.11-OCB compared to 802.11. This has impacts on security, privacy, subnet structure, and movement detection. Security and privacy recommendations are discussed in Sections 4.4 and 5. The subnet structure is described in Section 4.6. The movement detection on OCB links is not described in this document. Likewise, ND extensions and IP Wireless Access in Vehicular Environments (IPWAVE) optimizations for vehicular communications are not in scope of this document. The expectation is that further specifications will be edited to cover more complex vehicular networking scenarios.
* 802.11と比較した802.11-OCBのOCB性質による例外。これは、セキュリティ、プライバシー、サブネット構造、および動きの検出に影響を与えます。セキュリティとプライバシーの推奨事項については、セクション4.4および5で説明しています。サブネット構造については、セクション4.6で説明しています。 OCBリンクでの動きの検出については、このドキュメントでは説明していません。同様に、ND拡張機能と車両環境でのIPワイヤレスアクセス（IPWAVE）による車両通信の最適化は、このドキュメントの範囲外です。より複雑な車両ネットワーキングのシナリオをカバーするために、さらなる仕様が編集されることが期待されています。
The reader may refer to [IPWAVE] for an overview of problems related to running IPv6 over 802.11-OCB. It is out of scope of this document to reiterate those problems.
読者は、802.11-OCBでIPv6を実行することに関連する問題の概要について、[IPWAVE]を参照する場合があります。これらの問題を繰り返すことは、このドキュメントの範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The document makes uses of the following terms:
このドキュメントでは、次の用語を使用しています。
IP-OBU (Internet Protocol On-Board Unit): An IP-OBU denotes a computer situated in a vehicle such as a car, bicycle, or similar. It has at least one IP interface that runs in mode OCB of 802.11 and has an "OBU" transceiver. See the definition of the term "OBU" in Appendix H.
IP-OBU（インターネットプロトコルオンボードユニット）：IP-OBUは、自動車、自転車などの車両に設置されたコンピューターを指します。 802.11のモードOCBで実行され、「OBU」トランシーバーを備えたIPインターフェイスが少なくとも1つあります。付録Hの「OBU」という用語の定義を参照してください。
IP-RSU (IP Roadside Unit): An IP-RSU is situated along the road. It has at least two distinct IP-enabled interfaces. The wireless PHY/MAC layer of at least one of its IP-enabled interfaces is configured to operate in 802.11-OCB mode. An IP-RSU communicates with the IP-OBU over an 802.11 wireless link operating in OCB mode. An IP-RSU is similar to an Access Network Router (ANR), defined in [RFC3753], and a Wireless Termination Point (WTP), defined in [RFC5415].
IP-RSU（IP Roadside Unit）：IP-RSUは道路沿いにあります。少なくとも2つの異なるIP対応インターフェースがあります。 IP対応インターフェイスの少なくとも1つのワイヤレスPHY / MAC層は、802.11-OCBモードで動作するように構成されています。 IP-RSUは、OCBモードで動作する802.11ワイヤレスリンクを介してIP-OBUと通信します。 IP-RSUは、[RFC3753]で定義されているアクセスネットワークルーター（ANR）と[RFC5415]で定義されているワイヤレスターミネーションポイント（WTP）に似ています。
OCB (outside the context of a Basic Service Set - BSS): This is a mode of operation in which a station (STA) is not a member of a BSS and does not utilize IEEE Std 802.11 authentication, association, or data confidentiality.
OCB（基本サービスセット-BSSのコンテキスト外）：これは、ステーション（STA）がBSSのメンバーではなく、IEEE Std 802.11認証、関連付け、またはデータ機密性を利用しない動作モードです。
802.11-OCB: This refers to the mode specified in IEEE Std 802.11-2016 when the MIB attribute dot11OCBActivited is 'true'.
802.11-OCB：これは、MIB属性dot11OCBActivitedが「true」の場合にIEEE Std 802.11-2016で指定されたモードを指します。
IEEE 802.11-OCB networks are used for vehicular communications as 'Wireless Access in Vehicular Environments'. In particular, we refer the reader to [IPWAVE], which lists some scenarios and requirements for IP in Intelligent Transportation Systems (ITS).
IEEE 802.11-OCBネットワークは、「車両環境でのワイヤレスアクセス」として車両通信に使用されます。特に、読者に[IPWAVE]を紹介します。[IPWAVE]には、インテリジェント交通システム（ITS）におけるIPのシナリオと要件がいくつか記載されています。
The link model is the following: STA --- 802.11-OCB --- STA. In
vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. All links
are assumed to be P2P, and multiple links can be on one radio
interface. While 802.11-OCB is clearly specified and a legacy IPv6
stack can operate on such links, the use of the operating environment
(vehicular networks) brings in new perspectives.
The default MTU for IP packets on 802.11-OCB is inherited from [RFC2464] and, as such, is 1500 octets. As noted in [RFC8200], every link on the Internet must have a minimum MTU of 1280 octets and must follow the other recommendations, especially with regard to fragmentation.
802.11-OCBのIPパケットのデフォルトMTUは[RFC2464]から継承されているため、1500オクテットです。 [RFC8200]で述べられているように、インターネット上のすべてのリンクは1280オクテットの最小MTUを持ち、特に断片化に関して他の推奨事項に従う必要があります。
IP packets MUST be transmitted over 802.11-OCB media as QoS data frames whose format is specified in an IEEE 802.11 spec [IEEE-802.11-2016].
IPパケットは、IEEE 802.11仕様[IEEE-802.11-2016]で指定された形式のQoSデータフレームとして802.11-OCBメディアを介して送信する必要があります。
The IPv6 packet transmitted on 802.11-OCB is immediately preceded by a Logical Link Control (LLC) header and an 802.11 header. In the LLC header and in accordance with EtherType Protocol Discrimination (EPD; see Appendix D), the value of the Type field MUST be set to 0x86DD (IPv6). The mapping to the 802.11 data service SHOULD use a 'priority' value of 1 (QoS with a 'Background' user priority), reserving higher priority values for safety-critical and time-sensitive traffic, including the ones listed in [ETSI-sec-archi].
802.11-OCBで送信されるIPv6パケットの直前には、論理リンク制御（LLC）ヘッダーと802.11ヘッダーがあります。 LLCヘッダーでは、EtherType Protocol Discrimination（EPD、付録Dを参照）に従って、Typeフィールドの値を0x86DD（IPv6）に設定する必要があります。 802.11データサービスへのマッピングは、「優先度」値1（「バックグラウンド」ユーザー優先度のQoS）を使用する必要があり（SHOT）、[ETSI-sec -archi]。
To simplify the Application Programming Interface (API) between the operating system and the 802.11-OCB media, device drivers MAY implement IPv6 over Ethernet as per [RFC2464] and then a frame translation from 802.3 to 802.11 in order to minimize the code changes.
オペレーティングシステムと802.11-OCBメディア間のアプリケーションプログラミングインターフェイス（API）を簡素化するために、デバイスドライバーは[RFC2464]に従ってイーサネット上でIPv6を実装し、コードの変更を最小限に抑えるために802.3から802.11へのフレーム変換を実装できます（MAY）。
There are several types of IPv6 addresses [RFC4291] [RFC4193] that may be assigned to an 802.11-OCB interface. Among these types of addresses, only the IPv6 link-local addresses can be formed using an EUI-64 identifier, particularly during transition time (the period of time before an interface starts using an address different from the LL one).
802.11-OCBインターフェースに割り当てられるIPv6アドレスにはいくつかのタイプがあります[RFC4291] [RFC4193]。これらのタイプのアドレスの中で、特に移行時間（インターフェイスがLLアドレスとは異なるアドレスの使用を開始する前の期間）の間は、EUI-64識別子を使用してIPv6リンクローカルアドレスのみを形成できます。
If the IPv6 link-local address is formed using an EUI-64 identifier, then the mechanism for forming that address is the same mechanism as that used to form an IPv6 link-local address on Ethernet links. Moreover, regardless of whether the interface identifier is derived from the EUI-64 identifier, its length is 64 bits, as is the case for the Ethernet [RFC2464].
IPv6リンクローカルアドレスがEUI-64識別子を使用して形成される場合、そのアドレスを形成するメカニズムは、イーサネットリンク上でIPv6リンクローカルアドレスを形成するために使用されるメカニズムと同じです。さらに、インターフェイス識別子がEUI-64識別子から派生したものかどうかに関係なく、その長さはイーサネット[RFC2464]の場合と同様に64ビットです。
The steps a host takes in deciding how to autoconfigure its interfaces in IPv6 are described in [RFC4862]. This section describes the formation of Interface Identifiers for 'Global' or 'Unique Local' IPv6 addresses. Interface Identifiers for 'link-local' IPv6 addresses are discussed in Section 4.3.
ホストがIPv6でインターフェースを自動構成する方法を決定する際に実行する手順は、[RFC4862]で説明されています。このセクションでは、「グローバル」または「ユニークローカル」IPv6アドレスのインターフェース識別子の形成について説明します。 「リンクローカル」IPv6アドレスのインターフェース識別子については、セクション4.3で説明します。
The RECOMMENDED method for forming stable Interface Identifiers (IIDs) is described in [RFC8064]. The method of forming IIDs described in Section 4 of [RFC2464] MAY be used during transition time, particularly for IPv6 link-local addresses. Regardless of the method used to form the IID, its length is 64 bits, similarly to IPv6 over Ethernet [RFC2464].
安定したインターフェース識別子（IID）を形成するための推奨される方法は、[RFC8064]で説明されています。 [RFC2464]のセクション4で説明されているIIDを形成する方法は、特にIPv6リンクローカルアドレスの場合、移行時に使用できます。 IIDの形成に使用された方法に関係なく、その長さはIPv6 over Ethernet [RFC2464]と同様に64ビットです。
The bits in the IID have no specific meaning, and the identifier should be treated as an opaque value. The bits 'Universal' and 'Group' in the identifier of an 802.11-OCB interface, which is an IEEE link-layer address, are significant. The details of this significance are described in [RFC7136].
IIDのビットには特定の意味はなく、識別子は不透明な値として扱われる必要があります。 IEEEリンク層アドレスである802.11-OCBインターフェイスの識別子のビット「ユニバーサル」と「グループ」は重要です。この重要性の詳細は[RFC7136]で説明されています。
Semantically opaque IIDs, instead of meaningful IIDs derived from a valid and meaningful MAC address ([RFC2464], Section 4), help avoid certain privacy risks (see the risks mentioned in Section 5.1.1). If semantically opaque IIDs are needed, they may be generated using the method for generating semantically opaque IIDs with IPv6 Stateless Address Autoconfiguration given in [RFC7217]. Typically, an opaque IID is formed starting from identifiers different from the MAC addresses and from cryptographically strong material. Thus, privacy-sensitive information is absent from Interface IDs because it is impossible to calculate back the initial value from which the Interface ID was first generated.
有効で意味のあるMACアドレスから派生した意味のあるIID（[RFC2464]、セクション4）ではなく、意味的に不透明なIIDは、特定のプライバシーリスクを回避するのに役立ちます（セクション5.1.1で言及されているリスクを参照）。セマンティックに不透明なIIDが必要な場合は、[RFC7217]で規定されているIPv6ステートレスアドレス自動構成でセマンティックに不透明なIIDを生成する方法を使用してそれらを生成できます。通常、不透明なIIDは、MACアドレスとは異なる識別子から、および暗号学的に強力な素材から形成されます。したがって、インターフェイスIDが最初に生成されたときの初期値を計算することは不可能であるため、プライバシーID情報はインターフェイスIDにありません。
Some applications that use IPv6 packets on 802.11-OCB links (among other link types) may benefit from IPv6 addresses whose IIDs don't change too often. It is RECOMMENDED to use the mechanisms described in [RFC7217] to permit the use of stable IIDs that do not change within one subnet prefix. A possible source for the Net_Iface parameter is a virtual interface name or logical interface name that is decided by a local administrator.
（他のリンクタイプの中でも）802.11-OCBリンクでIPv6パケットを使用する一部のアプリケーションは、IIDがあまり頻繁に変更されないIPv6アドレスの恩恵を受ける場合があります。 [RFC7217]で説明されているメカニズムを使用して、1つのサブネットプレフィックス内で変更されない安定したIIDの使用を許可することをお勧めします。 Net_Ifaceパラメーターの可能なソースは、ローカル管理者が決定する仮想インターフェース名または論理インターフェース名です。
Unicast and multicast address mapping MUST follow the procedures specified for Ethernet interfaces described in Sections 6 and 7 of [RFC2464].
ユニキャストおよびマルチキャストアドレスマッピングは、[RFC2464]のセクション6および7で説明されているイーサネットインターフェイスに指定された手順に従う必要があります。
This document is scoped for Address Resolution (AR) and Duplicate Address Detection (DAD) per [RFC4862].
このドキュメントは、[RFC4862]によるアドレス解決（AR）および重複アドレス検出（DAD）を対象としています。
The multicast address mapping is performed according to the method specified in Section 7 of [RFC2464]. The meaning of the value "33-33" mentioned there is defined in Section 2.3.1 of [RFC7042].
マルチキャストアドレスマッピングは、[RFC2464]のセクション7で指定された方法に従って実行されます。そこで言及されている値「33-33」の意味は、[RFC7042]のセクション2.3.1で定義されています。
Transmitting IPv6 packets to multicast destinations over 802.11 links proved to have some performance issues [IEEE802-MCAST]. These issues may be exacerbated in OCB mode. Future improvement to this specification should consider solutions for these problems.
802.11リンクを介してIPv6パケットをマルチキャスト宛先に送信すると、いくつかのパフォーマンスの問題があることが判明しました[IEEE802-MCAST]。これらの問題は、OCBモードで悪化する可能性があります。この仕様の将来の改善では、これらの問題の解決策を検討する必要があります。
When vehicles are in close range, a subnet may be formed over 802.11-OCB interfaces (not by their in-vehicle interfaces). A Prefix List conceptual data structure ([RFC4861], Section 5.1) is maintained for each 802.11-OCB interface.
車両が至近距離にある場合、（車載インターフェースではなく）802.11-OCBインターフェースを介してサブネットが形成される場合があります。プレフィックスリストの概念的なデータ構造（[RFC4861]、セクション5.1）は、802.11-OCBインターフェースごとに維持されます。
The IPv6 Neighbor Discovery protocol (ND) requires reflexive properties (bidirectional connectivity), which is generally, though not always, the case for P2P OCB links. IPv6 ND also requires transitive properties for DAD and AR, so an IPv6 subnet can be mapped on an OCB network only if all nodes in the network share a single physical broadcast domain. The extension to IPv6 ND operating on a subnet that covers multiple OCB links and does not fully overlap (i.e., non-broadcast multi-access (NBMA)) is not in scope of this document. Finally, IPv6 ND requires permanent connectivity of all nodes in the subnet to defend their addresses -- in other words, very stable network conditions.
IPv6近隣探索プロトコル（ND）には、再帰プロパティ（双方向接続）が必要です。これは、常にではありませんが、一般的にP2P OCBリンクの場合です。 IPv6 NDにはDADおよびARの推移的なプロパティも必要であるため、ネットワーク内のすべてのノードが単一の物理ブロードキャストドメインを共有する場合にのみ、IPv6サブネットをOCBネットワークにマッピングできます。複数のOCBリンクをカバーし、完全にオーバーラップしないサブネットで動作するIPv6 NDへの拡張（つまり、非ブロードキャストマルチアクセス（NBMA））は、このドキュメントの範囲外です。最後に、IPv6 NDでは、アドレスを保護するためにサブネット内のすべてのノードの永続的な接続、つまり、非常に安定したネットワーク状態が必要です。
The structure of this subnet is ephemeral in that it is strongly influenced by the mobility of vehicles: the hidden terminal effects appear, and the 802.11 networks in OCB mode may be considered ad hoc networks with an addressing model, as described in [RFC5889]. On the other hand, the structure of the internal subnets in each vehicle is relatively stable.
[RFC5889]で説明されているように、このサブネットの構造は一時的なものであり、車両の移動性に強く影響されます。隠れた端末効果が現れ、OCBモードの802.11ネットワークは、アドレッシングモデルを持つアドホックネットワークと見なされる場合があります。一方、各車両の内部サブネットの構造は比較的安定しています。
As recommended in [RFC5889], when the timing requirements are very strict (e.g., fast-drive-through IP-RSU coverage), no on-link subnet prefix should be configured on an 802.11-OCB interface. In such cases, the exclusive use of IPv6 link-local addresses is RECOMMENDED.
[RFC5889]で推奨されているように、タイミング要件が非常に厳しい場合（たとえば、高速ドライブスルーIP-RSUカバレッジ）、802.11-OCBインターフェイスでリンク上のサブネットプレフィックスを構成する必要はありません。このような場合、IPv6リンクローカルアドレスの排他的な使用が推奨されます。
Additionally, even if the timing requirements are not very strict (e.g., the moving subnet formed by two following vehicles is stable, a fixed IP-RSU is absent), the subnet is disconnected from the Internet (i.e., a default route is absent), and the addressing peers are equally qualified (that is, it is impossible to determine whether some vehicle owns and distributes addresses to others), the use of link-local addresses is RECOMMENDED.
さらに、タイミング要件がそれほど厳しくなくても（たとえば、後続の2台の車両によって形成される移動サブネットが安定していて、固定IP-RSUがない場合）、サブネットはインターネットから切断されます（つまり、デフォルトルートがありません）。 、およびアドレッシングピアが同等に修飾されている（つまり、一部の車両がアドレスを所有し、他の車両にアドレスを配布するかどうかを判断することができない）場合、リンクローカルアドレスの使用が推奨されます。
The baseline ND protocol [RFC4861] MUST be supported over 802.11-OCB links. Transmitting ND packets may prove to have some performance issues, as mentioned in Section 4.5.2 and Appendix I. These issues may be exacerbated in OCB mode. Solutions for these problems should consider the OCB mode of operation. Future solutions to OCB should consider solutions for avoiding broadcast. The best of current knowledge indicates the kinds of issues that may arise with ND in OCB mode; they are described in Appendix I.
ベースラインNDプロトコル[RFC4861]は、802.11-OCBリンクを介してサポートされる必要があります。セクション4.5.2および付録Iで述べたように、NDパケットを送信すると、いくつかのパフォーマンスの問題が発生する可能性があります。これらの問題は、OCBモードで悪化する可能性があります。これらの問題の解決策は、OCBの動作モードを考慮する必要があります。 OCBの将来のソリューションでは、ブロードキャストを回避するためのソリューションを検討する必要があります。現在の最良の知識は、OCBモードのNDで発生する可能性のある問題の種類を示しています。それらは付録Iで説明されています。
Protocols like Mobile IPv6 [RFC6275] [RFC3963] and DNAv6 [RFC6059], which depend on timely movement detection, might need additional tuning work to handle the lack of link-layer notifications during handover. This topic is left for further study.
モバイルIPv6 [RFC6275] [RFC3963]やDNAv6 [RFC6059]などのプロトコルは、タイムリーな動きの検出に依存しているため、ハンドオーバー中にリンク層通知の欠如を処理するために追加の調整作業が必要になる場合があります。このトピックは、さらに調査するために残されています。
Any security mechanism at the IP layer or above that may be implemented for the general case of IPv6 may also be implemented for IPv6 operating over 802.11-OCB.
IPv6の一般的なケースに実装できるIP層以上のセキュリティメカニズムは、802.11-OCBで動作するIPv6にも実装できます。
The OCB operation does not use existing 802.11 link-layer security mechanisms. There is no encryption applied below the network layer running on 802.11-OCB. At the application layer, the IEEE 1609.2 document [IEEE-1609.2] provides security services for certain applications to use; application-layer mechanisms are out of scope of this document. On the other hand, a security mechanism provided at the networking layer, such as IPsec [RFC4301], may provide data security protection to a wider range of applications.
OCB操作は、既存の802.11リンク層セキュリティメカニズムを使用しません。 802.11-OCBで実行されているネットワーク層の下に適用される暗号化はありません。アプリケーション層では、IEEE 1609.2ドキュメント[IEEE-1609.2]は、特定のアプリケーションが使用するセキュリティサービスを提供します。アプリケーション層のメカニズムはこのドキュメントの範囲外です。一方、IPsec [RFC4301]などのネットワーク層で提供されるセキュリティメカニズムは、幅広いアプリケーションにデータセキュリティ保護を提供します。
802.11-OCB does not provide any cryptographic protection because it operates outside the context of a BSS (no Association Request/ Response or Challenge messages). Therefore, an attacker can sniff or inject traffic while within range of a vehicle or IP-RSU (by setting an interface card's frequency to the proper range). Also, an attacker may not adhere to the legal limits for radio power and can use a very sensitive directional antenna; if attackers wish to attack a given exchange, they do not necessarily need to be in close physical proximity. Hence, such a link is less protected than commonly used links (a wired link or the aforementioned 802.11 links with link-layer security).
802.11-OCBはBSSのコンテキスト外で動作するため（アソシエーション要求/応答またはチャレンジメッセージなし）、暗号保護は提供されません。したがって、攻撃者は、車両またはIP-RSUの範囲内でトラフィックを傍受または注入できます（インターフェースカードの周波数を適切な範囲に設定することにより）。また、攻撃者は無線電力の法的制限を遵守せず、非常に敏感な指向性アンテナを使用できます。攻撃者が特定の交換を攻撃する場合、必ずしも物理的に近接している必要はありません。したがって、このようなリンクは、一般的に使用されるリンク（有線リンクまたは前述のリンク層セキュリティを備えた802.11リンク）よりも保護されていません。
Therefore, any node can join a subnet and directly communicate with any nodes on the subset, including potentially impersonating another node. This design allows for a number of threats outlined in Section 3 of [RFC6959]. While not widely deployed, SEND [RFC3971] [RFC3972] is a solution that can address spoof-based attack vectors.
したがって、任意のノードがサブネットに参加し、サブセット上の任意のノードと直接通信することができます。この設計により、[RFC6959]のセクション3で概説されているいくつかの脅威が可能になります。 SEND [RFC3971] [RFC3972]は広く展開されていませんが、なりすましベースの攻撃ベクトルに対処できるソリューションです。
As with all Ethernet and 802.11 interface identifiers [RFC7721], the identifier of an 802.11-OCB interface may involve privacy, MAC address spoofing, and IP hijacking risks. A vehicle embarking an IP-OBU whose egress interface is 802.11-OCB may expose itself to eavesdropping and subsequent correlation of data. This may reveal data considered private by the vehicle owner; there is a risk of being tracked. In outdoor public environments, where vehicles typically circulate, the privacy risks are greater than in indoor settings. It is highly likely that attacker sniffers are deployed along routes that listen for IEEE frames, including IP packets, of vehicles passing by. For this reason, in 802.11-OCB deployments, there is a strong necessity to use protection tools such as dynamically changing MAC addresses (Section 5.2), semantically opaque Interface Identifiers, and stable Interface Identifiers (Section 4.4). An example of a change policy is to change the MAC address of the OCB interface each time the system boots up. This may help mitigate privacy risks to a certain level. Furthermore, for privacy concerns, [RFC8065] recommends using an address-generation scheme rather than generating addresses from a fixed link-layer address. However, there are some specificities related to vehicles. Since roaming is an important characteristic of moving vehicles, the use of the same Link-Local Address over time can indicate the presence of the same vehicle in different places and thus lead to location tracking. Hence, a vehicle should get hints about a change of environment (e.g., engine running, GPS, etc.) and renew the IID in its LLAs.
すべてのイーサネットおよび802.11インターフェース識別子[RFC7721]と同様に、802.11-OCBインターフェースの識別子には、プライバシー、MACアドレススプーフィング、およびIPハイジャックのリスクが伴う可能性があります。出力インターフェースが802.11-OCBであるIP-OBUを使用している車両は、盗聴やその後のデータの相関関係にさらされる可能性があります。これにより、車両の所有者が非公開と見なしたデータが明らかになる場合があります。追跡されるリスクがあります。車両が一般的に循環する屋外の公共環境では、プライバシーのリスクは屋内の場合よりも高くなります。通過する車両のIEEEパケット（IPパケットを含む）をリッスンするルートに沿って攻撃者スニファが配置されている可能性が非常に高いです。このため、802.11-OCBの展開では、動的に変更するMACアドレス（セクション5.2）、意味的に不透明なインターフェイス識別子、安定したインターフェイス識別子（セクション4.4）などの保護ツールを使用する必要性が高くなります。変更ポリシーの例は、システムが起動するたびにOCBインターフェイスのMACアドレスを変更することです。これにより、プライバシーリスクを特定のレベルまで軽減することができます。さらに、プライバシーの懸念から、[RFC8065]は、固定リンク層アドレスからアドレスを生成するのではなく、アドレス生成スキームを使用することを推奨しています。ただし、車両に関連するいくつかの特殊性があります。ローミングは移動する車両の重要な特性であるため、時間の経過に伴う同じリンクローカルアドレスの使用は、異なる場所に同じ車両が存在することを示し、位置追跡につながる可能性があります。したがって、車両は環境の変化（エンジンの稼働、GPSなど）についてのヒントを得て、LLAのIIDを更新する必要があります。
The privacy risks of using MAC addresses displayed in Interface Identifiers are important. IPv6 packets can be captured easily on the Internet and on-link on public roads. For this reason, an attacker may realize many attacks on privacy. One such attack on 802.11-OCB is to capture, store, and correlate company ID information present in the MAC addresses of a large number of cars (e.g., listening for Router Advertisements or other IPv6 application data packets, and recording the value of the source address in these packets). Further correlation of this information with other data captured by other means or other visual information (e.g., car color) may constitute privacy risks.
インターフェイス識別子に表示されるMACアドレスを使用するプライバシーリスクは重要です。 IPv6パケットは、インターネット上や公道上のリンク上で簡単にキャプチャできます。このため、攻撃者はプライバシーに対する多くの攻撃に気付く可能性があります。 802.11-OCBに対するそのような攻撃の1つは、多数の車のMACアドレスに存在する企業ID情報（たとえば、ルーターアドバタイズメントまたはその他のIPv6アプリケーションデータパケットをリッスンし、ソースの値を記録すること）をキャプチャ、保存、および関連付けることです。これらのパケットのアドレス）。この情報と、他の手段でキャプチャされた他のデータまたは他の視覚的情報（車の色など）とのさらなる相関は、プライバシーリスクを構成する可能性があります。
In 802.11-OCB networks, the MAC addresses may change during well-defined renumbering events. At the moment the MAC address is changed on an 802.11-OCB interface, all the Interface Identifiers of IPv6 addresses assigned to that interface MUST change.
802.11-OCBネットワークでは、明確に定義された再番号付けイベント中にMACアドレスが変更される場合があります。現時点で、MACアドレスが802.11-OCBインターフェイスで変更されている場合、そのインターフェイスに割り当てられているIPv6アドレスのすべてのインターフェイス識別子を変更する必要があります。
Implementations should use a policy dictating when the MAC address is changed on the 802.11-OCB interface. For more information on the motivation of this policy, please refer to the privacy discussion in Appendix B.
実装では、802.11-OCBインターフェイスでMACアドレスがいつ変更されるかを示すポリシーを使用する必要があります。このポリシーの動機の詳細については、付録Bのプライバシーに関する議論を参照してください。
A 'randomized' MAC address has the following characteristics:
「ランダム化された」MACアドレスには、次の特性があります。
* The "Local/Global" bit is set to "locally administered".
* 「ローカル/グローバル」ビットが「ローカル管理」に設定されている。
* The "Unicast/Multicast" bit is set to "Unicast".
* 「ユニキャスト/マルチキャスト」ビットは「ユニキャスト」に設定されます。
* The 46 remaining bits are set to a random value using a random number generator that meets the requirements of [RFC4086].
* 残りの46ビットは、[RFC4086]の要件を満たす乱数ジェネレータを使用してランダムな値に設定されます。
To meet the randomization requirements for the 46 remaining bits, a hash function may be used. For example, the hash function defined in [SHA256] may be used with the input of a 256-bit local secret, the 'nominal' MAC address of the interface, and a representation of the date and time of the renumbering event.
残りの46ビットのランダム化要件を満たすために、ハッシュ関数を使用できます。たとえば、[SHA256]で定義されているハッシュ関数は、256ビットのローカルシークレットの入力、インターフェイスの「公称」MACアドレス、および番号変更イベントの日時の表現とともに使用できます。
A randomized Interface ID has the same characteristics of a randomized MAC address except for the length in bits.
ランダム化されたインターフェイスIDは、ビット単位の長さを除いて、ランダム化されたMACアドレスと同じ特性を持っています。
Vehicle and drivers privacy relies on pseudonymization mechanisms such as the ones described in Section 5.2. This pseudonymization means that upper-layer protocols and applications SHOULD NOT rely on layer-2 or layer-3 addresses to assume that the other participant can be trusted.
車両とドライバーのプライバシーは、セクション5.2で説明されているような仮名化メカニズムに依存しています。この仮名化は、上位層のプロトコルとアプリケーションが、レイヤー2またはレイヤー3のアドレスに依存して他の参加者が信頼できると想定してはならないことを意味します。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[IEEE-802.11-2016] 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 Standard 802.11-2016, December 2016, <https://standards.ieee.org/findstds/ standard/802.11-2016.html>.
[IEEE-802.11-2016] IEEE、「IEEE Standard for Information technology-Telecommunications and information exchange between system Local and metropolitan area network--Specific requirements-Part 11：Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY）Specifications "、IEEE標準802.11-2016、2016年12月、<https://standards.ieee.org/findstds/ standard / 802.11-2016.html>。
[RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, DOI 10.17487/RFC1042, February 1988, <https://www.rfc-editor.org/info/rfc1042>.
[RFC1042] Postel、J。およびJ. Reynolds、「IEEE 802ネットワークを介したIPデータグラムの送信に関する標準」、STD 43、RFC 1042、DOI 10.17487 / RFC1042、1988年2月、<https：//www.rfc-editor .org / info / rfc1042>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, <https://www.rfc-editor.org/info/rfc2464>.
[RFC2464] Crawford、M。、「Transmission of IPv6 Packets over Ethernet Networks」、RFC 2464、DOI 10.17487 / RFC2464、1998年12月、<https://www.rfc-editor.org/info/rfc2464>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<https：//www.rfc-editor .org / info / rfc4086>。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4191] Draves、R。およびD. Thaler、「デフォルトのルーター設定とより具体的なルート」、RFC 4191、DOI 10.17487 / RFC4191、2005年11月、<https://www.rfc-editor.org/info/rfc4191 >。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<https://www.rfc-editor.org/info/rfc4193>。
[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>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https://www.rfc-editor.org/info/rfc4291>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<https://www.rfc-editor.org/info/rfc4301>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：/ /www.rfc-editor.org/info/rfc4861>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<https://www.rfc-editor.org/info / rfc4862>。
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, DOI 10.17487/RFC5415, March 2009, <https://www.rfc-editor.org/info/rfc5415>.
[RFC5415] Calhoun、P.、Ed。、Montemurro、M.、Ed。、and D. Stanley、Ed。、 "Control And Provisioning of Wireless Access Points（CAPWAP）Protocol Specification"、RFC 5415、DOI 10.17487 / RFC5415、 2009年3月、<https://www.rfc-editor.org/info/rfc5415>。
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, DOI 10.17487/RFC6059, November 2010, <https://www.rfc-editor.org/info/rfc6059>.
[RFC6059] Krishnan、S。およびG. Daley、「IPv6でネットワーク接続を検出するための簡単な手順」、RFC 6059、DOI 10.17487 / RFC6059、2010年11月、<https://www.rfc-editor.org/info/rfc6059 >。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6275] Perkins、C.、Ed。、Johnson、D。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 6275、DOI 10.17487 / RFC6275、2011年7月、<https：//www.rfc-editor。 org / info / rfc6275>。
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <https://www.rfc-editor.org/info/rfc7042>.
[RFC7042] Eastlake 3rd、D。およびJ. Abley、「IANAの考慮事項とIEEE 802パラメータのIETFプロトコルおよびドキュメントの使用法」、BCP 141、RFC 7042、DOI 10.17487 / RFC7042、2013年10月、<https：//www.rfc -editor.org/info/rfc7042>。
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <https://www.rfc-editor.org/info/rfc7136>.
[RFC7136] Carpenter、B。およびS. Jiang、「Significance of IPv6 Interface Identifiers」、RFC 7136、DOI 10.17487 / RFC7136、2014年2月、<https://www.rfc-editor.org/info/rfc7136>。
[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>.
[RFC7217] Gont、F。、「IPv6ステートレスアドレス自動構成（SLAAC）を使用してセマンティックに不透明なインターフェース識別子を生成する方法」、RFC 7217、DOI 10.17487 / RFC7217、2014年4月、<https://www.rfc-editor.org / info / rfc7217>。
[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>.
[RFC8064] Gont、F.、Cooper、A.、Thaler、D。、およびW. Liu、「Recommendation on Stable IPv6 Interface Identifiers」、RFC 8064、DOI 10.17487 / RFC8064、2017年2月、<https：// www。 rfc-editor.org/info/rfc8064>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https://www.rfc-editor.org / info / rfc8200>。
[CFR-90] e-CFR, "Electronic Code of Federal Regulations", Title 47, Part 90 - PRIVATE LAND MOBILE RADIO SERVICES, <https://www.ecfr.gov/cgi-bin/text-idx?node=pt47.5.90&rgn=div5>.
[CFR-90] e-CFR、「連邦規制の電子コード」、タイトル47、パート90-プライベートランドモバイルラジオサービス、<https://www.ecfr.gov/cgi-bin/text-idx?node= pt47.5.90＆rgn = div5>。
[CFR-90.7] e-CFR, "Electronic Code of Federal Regulations", Title 47, CFR 90.7 - Definitions, <https://www.ecfr.gov/cgi-bin/ text-idx?node=pt47.5.90&rgn=div5#se47.5.90_17>.
[CFR-90.7] e-CFR、「連邦規制の電子コード」、タイトル47、CFR 90.7-定義、<https://www.ecfr.gov/cgi-bin/ text-idx？node = pt47.5.90＆rgn = div5＃se47.5.90_17>。
[CFR-95] e-CFR, "Electronic Code of Federal Regulations", Title 47, CFR 95 - PERSONAL RADIO SERVICES, <https://www.ecfr.gov/ cgi-bin/text-idx?node=pt47.5.95&rgn=div5>.
[CFR-95] e-CFR、「連邦規制の電子コード」、タイトル47、CFR 95-個人用無線サービス、<https://www.ecfr.gov/ cgi-bin / text-idx？node = pt47。 5.95＆rgn = div5>。
[ETSI-sec-archi] "Intelligent Transport Systems (ITS); Security; ITS communications security architecture and security management", ETSI TS 102 940 V1.2.1, November 2016, <http://www.etsi.org/deliver/ etsi_ts/102900_102999/102940/01.02.01_60/ ts_102940v010201p.pdf>.
[ETSI-sec-archi]「インテリジェントトランスポートシステム（ITS）;セキュリティ; ITS通信セキュリティアーキテクチャとセキュリティ管理」、ETSI TS 102940 V1.2.1、2016年11月、<http://www.etsi.org/deliver/ etsi_ts / 102900_102999 / 102940 / 01.02.01_60 / ts_102940v010201p.pdf>。
[IEEE-1609.2] IEEE, "IEEE Standard for Wireless Access in Vehicular Environments--Security Services for Applications and Management Messages", DOI 10.1109/IEEESTD.2016.7426684, IEEE Standard 1609.2-2016, March 2016, <http://ieeexplore.ieee.org/document/7426684>.
[IEEE-1609.2] IEEE、「車両環境におけるワイヤレスアクセスのIEEE標準-アプリケーションと管理メッセージのセキュリティサービス」、DOI 10.1109 / IEEESTD.2016.7426684、IEEE標準1609.2-2016、2016年3月、<http：// ieeexplore。 ieee.org/document/7426684>。
[IEEE-1609.3] IEEE, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) -- Networking Services", DOI 10.1109/IEEESTD.2016.7458115, IEEE Standard 1609.3-2016, April 2016, <http://ieeexplore.ieee.org/document/7458115>.
[IEEE-1609.3] IEEE、「車両環境におけるワイヤレスアクセスのIEEE標準（WAVE）-ネットワーキングサービス」、DOI 10.1109 / IEEESTD.2016.7458115、IEEE標準1609.3-2016、2016年4月、<http://ieeexplore.ieee。 org / document / 7458115>。
[IEEE-1609.4] IEEE, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) -- Multi-Channel Operation", DOI 10.1109/IEEESTD.2016.7435228, IEEE Standard 1609.4-2016, March 2016, <http://ieeexplore.ieee.org/document/7435228>.
[IEEE-1609.4] IEEE、「車両環境におけるワイヤレスアクセスのIEEE標準（WAVE）-マルチチャネル操作」、DOI 10.1109 / IEEESTD.2016.7435228、IEEE標準1609.4-2016、2016年3月、<http：// ieeexplore。 ieee.org/document/7435228>。
[IEEE-802.11-2007] 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", DOI 10.1109/IEEESTD.2007.373646, IEEE Standard 802.11-2007, June 2007, <https://ieeexplore.ieee.org/document/4248378>.
[IEEE-802.11-2007] 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 "、DOI 10.1109 / IEEESTD.2007.373646、IEEE Standard 802.11-2007、June 2007、<https://ieeexplore.ieee.org/document/4248378>。
[IEEE-802.11-2012] 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", DOI 10.1109/IEEESTD.2012.6178212, IEEE Standard 802.11-2012, March 2012, <https://ieeexplore.ieee.org/document/6419735>.
[IEEE-802.11-2012] IEEE、「IEEE Standard for Information technology-Telecommunications and information exchange between system Local and metropolitan area network--Specific requirements Part 11：Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY）Specifications "、DOI 10.1109 / IEEESTD.2012.6178212、IEEE標準802.11-2012、2012年3月、<https://ieeexplore.ieee.org/document/6419735>。
[IEEE-802.11p-2010] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Amendment 6: Wireless Access in Vehicular Environments", DOI 10.1109/IEEESTD.2010.5514475, IEEE Standard 802.11p-2010, July 2010, <https://standards.ieee.org/standard/802_11p-2010.html>.
[IEEE-802.11p-2010] IEEE、「IEEE Standard for Information technology-Telecommunications and information exchange between system-Local and metropolitan area network-Specific requirements、Part 11：Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY）仕様、修正6：車両環境でのワイヤレスアクセス」、DOI 10.1109 / IEEESTD.2010.5514475、IEEE標準802.11p-2010、2010年7月、<https://standards.ieee.org/standard/802_11p-2010.html>。
[IEEE-802.3-2012] IEEE, "IEEE Standard for Ethernet", DOI 10.1109/IEEESTD.2012.6419735, IEEE Standard 802.3-2012, December 2012, <https://ieeexplore.ieee.org/document/6419735>.
[IEEE-802.3-2012] IEEE、「IEEE Standard for Ethernet」、DOI 10.1109 / IEEESTD.2012.6419735、IEEE Standard 802.3-2012、2012年12月、<https://ieeexplore.ieee.org/document/6419735>。
[IEEE802-MCAST] Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Zuniga, "Multicast Considerations over IEEE 802 Wireless Media", Work in Progress, Internet-Draft, draft-ietf-mboned-ieee802-mcast-problems-11, 11 December 2019, <https://tools.ietf.org/html/draft-ietf-mboned-ieee802- mcast-problems-11>.
[IEEE802-MCAST] Perkins、C.、McBride、M.、Stanley、D.、Kumari、W。、およびJ. Zuniga、「IEEE 802ワイヤレスメディア上のマルチキャストに関する考慮事項」、進行中の作業、インターネットドラフト、ドラフト- ietf-mboned-ieee802-mcast-problems-11、2019年12月11日、<https://tools.ietf.org/html/draft-ietf-mboned-ieee802- mcast-problems-11>。
[IPWAVE] Jeong, J., "IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases", Work in Progress, Internet-Draft, draft-ietf-ipwave-vehicular-networking-12, 3 October 2019, <https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-12>.
[IPWAVE] Jeong、J。、「車両環境でのIPワイヤレスアクセス（IPWAVE）：問題の説明と使用例」、進行中の作業、インターネットドラフト、draft-ietf-ipwave-vehicular-networking-12、2019年10月3日、 <https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-12>。
[RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004, <https://www.rfc-editor.org/info/rfc3753>.
[RFC3753]マナー、J。、エド。およびM. Kojo、編、「モビリティ関連用語」、RFC 3753、DOI 10.17487 / RFC3753、2004年6月、<https://www.rfc-editor.org/info/rfc3753>。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, DOI 10.17487/RFC3963, January 2005, <https://www.rfc-editor.org/info/rfc3963>.
[RFC3963] Devarapalli、V。、脇川、R.、Petrescu、A。、およびP. Thubert、「Network Mobility（NEMO）Basic Support Protocol」、RFC 3963、DOI 10.17487 / RFC3963、2005年1月、<https：// www.rfc-editor.org/info/rfc3963>。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <https://www.rfc-editor.org/info/rfc3971>.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B。、およびP. Nikander、「SEcure Neighbor Discovery（SEND）」、RFC 3971、DOI 10.17487 / RFC3971、2005年3月、<https：/ /www.rfc-editor.org/info/rfc3971>。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, <https://www.rfc-editor.org/info/rfc3972>.
[RFC3972] Aura、T。、「Cryptographically Generated Addresses（CGA）」、RFC 3972、DOI 10.17487 / RFC3972、2005年3月、<https://www.rfc-editor.org/info/rfc3972>。
[RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, September 2010, <https://www.rfc-editor.org/info/rfc5889>.
[RFC5889] Baccelli、E.、Ed。 M.タウンズリー編、「アドホックネットワークのIPアドレッシングモデル」、RFC 5889、DOI 10.17487 / RFC5889、2010年9月、<https://www.rfc-editor.org/info/rfc5889>。
[RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address Validation Improvement (SAVI) Threat Scope", RFC 6959, DOI 10.17487/RFC6959, May 2013, <https://www.rfc-editor.org/info/rfc6959>.
[RFC6959] McPherson、D.、Baker、F。、およびJ. Halpern、「Source Address Validation Improvement（SAVI）Threat Scope」、RFC 6959、DOI 10.17487 / RFC6959、2013年5月、<https：//www.rfc- editor.org/info/rfc6959>。
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <https://www.rfc-editor.org/info/rfc7721>.
[RFC7721] Cooper、A.、Gont、F。、およびD. Thaler、「IPv6アドレス生成メカニズムのセキュリティとプライバシーに関する考慮事項」、RFC 7721、DOI 10.17487 / RFC7721、2016年3月、<https：//www.rfc- editor.org/info/rfc7721>。
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, February 2017, <https://www.rfc-editor.org/info/rfc8065>.
[RFC8065]ターラー、D。、「IPv6アダプテーションレイヤーメカニズムのプライバシーに関する考慮事項」、RFC 8065、DOI 10.17487 / RFC8065、2017年2月、<https://www.rfc-editor.org/info/rfc8065>。
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, <https://www.rfc-editor.org/info/rfc8505>.
[RFC8505] Thubert、P.、Ed。、Nordmark、E.、Chakrabarti、S。、およびC. Perkins、「Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network（6LoWPAN）Neighbor Discovery」、RFC 8505、DOI 10.17487 / RFC8505、2018年11月、<https://www.rfc-editor.org/info/rfc8505>。
[SHA256] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4, FIPS 180-4, August 2015, <https://csrc.nist.gov/publications/detail/fips/180/4/ final>.
[SHA256]米国国立標準技術研究所、「Secure Hash Standard（SHS）」、DOI 10.6028 / NIST.FIPS.180-4、FIPS 180-4、2015年8月、<https://csrc.nist.gov/publications / detail / fips / 180/4 / final>。
The term "802.11p" is an earlier definition. The behavior of "802.11p" networks is rolled in [IEEE-802.11-2016]. In that document, the term "802.11p" disappears. Instead, each 802.11p feature is conditioned by the IEEE Management Information Base (MIB) attribute "OCBActivated" [IEEE-802.11-2016]. Whenever OCBActivated is set to "true", the IEEE Std 802.11-OCB state is activated. For example, an 802.11 STAtion operating outside the context of a BSS has the OCBActivated flag set. Such a station, when it has the flag set, uses a BSS identifier equal to ff:ff:ff:ff:ff:ff.
「802.11p」という用語は以前の定義です。 「802.11p」ネットワークの動作は、[IEEE-802.11-2016]に組み込まれています。そのドキュメントでは、「802.11p」という用語は消えています。代わりに、各802.11p機能は、IEEE管理情報ベース（MIB）属性「OCBActivated」[IEEE-802.11-2016]によって条件付けられています。 OCBActivatedが「true」に設定されると、IEEE Std 802.11-OCB状態がアクティブになります。たとえば、BSSのコンテキスト外で動作する802.11 STAtionには、OCBActivatedフラグが設定されています。そのようなステーションは、フラグが設定されている場合、ff：ff：ff：ff：ff：ffに等しいBSS識別子を使用します。
In IEEE 802.11-OCB mode, all nodes in the wireless range can directly communicate with each other without involving authentication or association procedures. In OCB mode, the manner in which channels are selected and used is simplified compared to when in BSS mode. Contrary to BSS mode, at the link layer, it is necessary to statically set the same channel number (or frequency) on two stations that need to communicate with each other (in BSS mode, this channel set operation is performed automatically during 'scanning'). The manner in which stations set their channel number in OCB mode is not specified in this document. Stations STA1 and STA2 can exchange IP packets only if they are set to the same channel. At the IP layer, they then discover each other by using the IPv6 Neighbor Discovery protocol. The allocation of a particular channel for a particular use is defined statically in standards authored by ETSI in Europe, the FCC in the United States of America, and similar organizations in South Korea, Japan, and other parts of the world.
IEEE 802.11-OCBモードでは、無線範囲内のすべてのノードは、認証や関連付けの手順を伴うことなく、互いに直接通信できます。 OCBモードでは、BSSモードの場合と比較して、チャネルの選択と使用の方法が簡略化されます。 BSSモードとは異なり、リンク層では、互いに通信する必要がある2つのステーションに同じチャネル番号（または周波数）を静的に設定する必要があります（BSSモードでは、このチャネルセット操作は「スキャン」中に自動的に実行されます）。ステーションがOCBモードでチャネル番号を設定する方法は、このドキュメントでは指定されていません。ステーションSTA1とSTA2は、同じチャネルに設定されている場合にのみ、IPパケットを交換できます。次に、IP層で、IPv6近隣探索プロトコルを使用して互いを発見します。特定の用途に対する特定のチャネルの割り当ては、ヨーロッパのETSI、アメリカ合衆国のFCC、および韓国、日本、その他の地域の同様の組織が作成した標準で静的に定義されています。
Briefly, the IEEE 802.11-OCB mode has the following properties:
簡単に言えば、IEEE 802.11-OCBモードには次の特性があります。
* The use by each node of a 'wildcard' BSS identifier (BSSID) (i.e., each bit of the BSSID is set to 1).
* 各ノードによる「ワイルドカード」BSS ID（BSSID）の使用（つまり、BSSIDの各ビットが1に設定されます）。
* No IEEE 802.11 beacon frames are transmitted.
* IEEE 802.11ビーコンフレームは送信されません。
* No authentication is required in order to be able to communicate.
* 通信するために認証は必要ありません。
* No association is needed in order to be able to communicate.
* 通信できるようにするために関連付けは必要ありません。
* No encryption is provided in order to be able to communicate.
* 通信できるようにするための暗号化は提供されていません。
* Flag dot11OCBActivated is set to "true".
* フラグdot11OCBActivatedは「true」に設定されています。
All the nodes in the radio communication range (IP-OBU and IP-RSU) receive all the messages transmitted (IP-OBU and IP-RSU) within the radio communication range. The MAC CDMA function resolves any eventual conflict(s).
無線通信範囲内のすべてのノード（IP-OBUおよびIP-RSU）は、無線通信範囲内で送信されたすべてのメッセージ（IP-OBUおよびIP-RSU）を受信します。 MAC CDMA機能は、最終的な競合を解決します。
The message exchange diagram in Figure 1 illustrates a comparison between traditional 802.11 and 802.11 in OCB mode. The 'Data' messages can be IP packets such as HTTP or others. Other 802.11 management and control frames (non-IP) may be transmitted, as specified in the 802.11 standard. The names of these messages as currently specified by the 802.11 standard are listed in Appendix F.
図1のメッセージ交換図は、従来の802.11とOCBモードの802.11の比較を示しています。 「データ」メッセージは、HTTPなどのIPパケットにすることができます。 802.11標準で指定されているように、他の802.11管理および制御フレーム（非IP）が送信される場合があります。 802.11規格で現在指定されているこれらのメッセージの名前は、付録Fにリストされています。
STA AP STA1 STA2
| | | |
|<------ Beacon -------| |<------ Data -------->|
| | | |
|---- Probe Req. ----->| |<------ Data -------->|
|<--- Probe Res. ------| | |
| | |<------ Data -------->|
|---- Auth Req. ------>| | |
|<--- Auth Res. -------| |<------ Data -------->|
| | | |
|---- Asso Req. ------>| |<------ Data -------->|
|<--- Asso Res. -------| | |
| | |<------ Data -------->|
|<------ Data -------->| | |
|<------ Data -------->| |<------ Data -------->|
(i) 802.11 Infrastructure mode (ii) 802.11-OCB mode
（i）802.11インフラストラクチャモード（ii）802.11-OCBモード
Figure 1: Difference between Messages Exchanged on 802.11 (Left) and 802.11-OCB (Right)
図1：802.11（左）と802.11-OCB（右）で交換されるメッセージの違い
The 802.11-OCB interface was specified in [IEEE-802.11p-2010], Amendment 6: Wireless Access in Vehicular Environments, as an amendment to [IEEE-802.11-2007]. Since then, this amendment has been integrated into [IEEE-802.11-2012] and [IEEE-802.11-2016].
802.11-OCBインターフェースは、[IEEE-802.11-2007]の修正として、[IEEE-802.11p-2010]の修正6：車両環境におけるワイヤレスアクセスで指定されました。それ以降、この修正は[IEEE-802.11-2012]および[IEEE-802.11-2016]に統合されました。
In [IEEE-802.11p-2010], anything qualified specifically as "OCBActivated" or "outside the context of a basic service" that is set to be "true" actually refers to OCB aspects introduced to 802.11.
[IEEE-802.11p-2010]では、特に「OCBActivated」または「基本サービスのコンテキスト外」として修飾され、「true」に設定されているものは、実際には802.11に導入されたOCBの側面を指します。
In order to delineate the aspects introduced by 802.11-OCB to 802.11, we refer to the earlier [IEEE-802.11p-2010]. The amendment is concerned with vehicular communications, where the wireless link is similar to that of Wireless LAN (using a PHY layer specified by 802.11a/b/g/n) but needs to cope with the high mobility factor inherent in scenarios of communications between moving vehicles and between vehicles and fixed infrastructure deployed along roads. While 'p' is a letter identifying the Amendment, just like 'a', 'b', 'g', and 'n' are, 'p' is concerned more with MAC modifications and is slightly concerned with PHY modifications; the others are mainly about PHY modifications. It is possible in practice to combine a 'p' MAC with an 'a' PHY by operating outside the context of a BSS with Orthogonal Frequency Division Multiplexing (OFDM) at 5.4 GHz and 5.9 GHz.
802.11-OCBによって802.11に導入された側面を説明するために、以前の[IEEE-802.11p-2010]を参照します。修正は、無線通信が無線LANの無線通信に類似している（802.11a / b / g / nで指定されたPHY層を使用する）車両通信に関係していますが、通信のシナリオに固有の高いモビリティ要因に対処する必要があります車両の移動、および車両と道路に沿って配置された固定インフラストラクチャの間での移動。 「p」は「a」、「b」、「g」、「n」と同様に修正条項を識別する文字ですが、「p」はMACの変更に関係し、PHYの変更に少し関係します。その他は主にPHYの変更に関するものです。実際には、5.4 GHzおよび5.9 GHzの直交周波数分割多重（OFDM）を備えたBSSのコンテキスト外で動作することにより、「p」MACを「a」PHYと組み合わせることが可能です。
The 802.11-OCB links are specified to be as compatible as possible with the behavior of 802.11a/b/g/n and future generation IEEE WLAN links. From the IP perspective, an 802.11-OCB MAC layer offers practically the same interface to IP as 802.11a/b/g/n and 802.3. A packet sent by an IP-OBU may be received by one or multiple IP-RSUs. The link-layer resolution is performed by using the IPv6 Neighbor Discovery protocol.
802.11-OCBリンクは、802.11a / b / g / nおよび将来の世代のIEEE WLANリンクの動作と可能な限り互換性があるように指定されています。 IPの観点から見ると、802.11-OCB MACレイヤーは、802.11a / b / g / nおよび802.3と実質的に同じIPへのインターフェイスを提供します。 IP-OBUによって送信されたパケットは、1つまたは複数のIP-RSUによって受信されます。リンク層の解決は、IPv6近隣探索プロトコルを使用して実行されます。
To support this similarity statement (IPv6 is layered on top of LLC on top of 802.11-OCB in the same way that IPv6 is layered on top of LLC on top of 802.11a/b/g/n (for WLAN) or on top of LLC on top of 802.3 (for Ethernet)), it is useful to analyze the differences between the 802.11-OCB and 802.11 specifications. During this analysis, we note that whereas 802.11-OCB lists relatively complex and numerous changes to the MAC layer (and very few to the PHY layer), there are only a few characteristics that may be important for an implementation transmitting IPv6 packets on 802.11-OCB links.
この類似性ステートメントをサポートするには（IPv6が802.11-OCBの上のLLCの上に、IPv6が802.11a / b / g / n（WLANの場合）またはLLCの上に階層化されるのと同じ方法で、またはLLC（802.3（イーサネット用））を使用する場合、802.11-OCB仕様と802.11仕様の違いを分析すると便利です。この分析中、802.11-OCBはMAC層に比較的複雑で多数の変更をリストしますが（PHY層にはほとんどありません）、802.11- OCBリンク。
The most important 802.11-OCB aspect that influences the IPv6 functioning is the OCB characteristic; an additional, less direct influence is the maximum bandwidth afforded by the PHY modulation/ demodulation methods and channel access specified by 802.11-OCB. The maximum bandwidth theoretically possible in 802.11-OCB is 54 Mbit/s (when using, for example, the following parameters: a 20 MHz channel; modulation of 64-QAM; a coding rate R of 3/4). With regard to IP over 802.11-OCB, in practice, a commonly observed figure is 12 Mbit/ s; this bandwidth allows the operation of a wide range of protocols relying on IPv6.
IPv6の機能に影響を与える最も重要な802.11-OCBの側面は、OCBの特性です。さらに直接的な影響が少ないのは、802.11-OCBで指定されているPHY変調/復調方式とチャネルアクセスによって提供される最大帯域幅です。 802.11-OCBで理論的に可能な最大帯域幅は54 Mbit / sです（たとえば、次のパラメーターを使用する場合：20 MHzチャネル、64-QAMの変調、3/4のコーディングレートR）。 IP over 802.11-OCBに関しては、実際には、一般的に観察される数値は12 Mbit / sです。この帯域幅により、IPv6に依存する幅広いプロトコルの動作が可能になります。
* Operation outside the context of a BSS (OCB): The 802.11-OCB links (previously 802.11p) are operated without a BSS. This means that IEEE 802.11 beacon, Association Request/Response, Authentication Request/Response, and similar frames are not used. The used identifier of BSS (BSSID) always has a hexadecimal value of 0xffffffffffff (48 '1' bits, represented as MAC address ff:ff:ff:ff:ff:ff; otherwise, the 'wildcard' BSSID), as opposed to an arbitrary BSSID value set by an administrator (e.g., 'My-Home-AccessPoint'). The OCB operation -- namely, the lack of beacon-based scanning and lack of authentication -- should be taken into account when the Mobile IPv6 protocol [RFC6275] and the protocols for IP layer security [RFC4301] are used. The way these protocols adapt to OCB is not described in this document.
* BSS（OCB）のコンテキスト外での操作：802.11-OCBリンク（以前の802.11p）は、BSSなしで操作されます。つまり、IEEE 802.11ビーコン、Association Request / Response、Authentication Request / Responseなどのフレームは使用されません。使用されるBSSの識別子（BSSID）は、常に16進値0xffffffffffff（48 '1'ビット、MACアドレスff：ff：ff：ff：ff：ffとして表されます。それ以外の場合は、 'ワイルドカード' BSSID）とは異なり、管理者が設定した任意のBSSID値（例： 'My-Home-AccessPoint'）。モバイルIPv6プロトコル[RFC6275]とIPレイヤーセキュリティのプロトコル[RFC4301]を使用する場合は、OCB操作（ビーコンベースのスキャンの欠如と認証の欠如）を考慮する必要があります。これらのプロトコルがOCBに適応する方法は、このドキュメントでは説明されていません。
* Timing Advertisement: This is a new message defined in 802.11-OCB that does not exist in 802.11a/b/g/n. This message is used by stations to inform other stations about the value of time. It is similar to the time delivered by a Global Navigation Satellite System (GNSS) (e.g., Galileo, GPS, etc.) or by a cellular system. This message is optional for implementation.
* タイミングアドバタイズメント：これは、802.11a / b / g / nには存在しない、802.11-OCBで定義された新しいメッセージです。このメッセージは、時間の値を他のステーションに通知するためにステーションによって使用されます。これは、全地球航法衛星システム（GNSS）（たとえば、Galileo、GPSなど）またはセルラーシステムによって配信される時間に似ています。このメッセージは、実装ではオプションです。
* Frequency range: This is a characteristic of the PHY layer; it has almost no impact on the interface between MAC and IP. However, it is worth considering that the frequency range is regulated by a regional authority (ARCEP, ECC/CEPT based on ENs from ETSI, FCC, etc.); as part of the regulation process, specific applications are associated with specific frequency ranges. In the case of 802.11-OCB, the regulator associates a set of frequency ranges or slots within a band to the use of applications of vehicular communications in a band known as "5.9 GHz". The 5.9 GHz band is different from the 2.4 GHz and 5 GHz bands used by Wireless LAN. However, as with Wireless LAN, the operation of 802.11-OCB in 5.9 GHz bands does not require a license in the EU (in the US, the 5.9 GHz is a licensed band of spectrum; for the fixed infrastructure, explicit FCC authorization is required; for an on-board device, a 'licensed-by-rule' concept applies, where rule certification conformity is required). Technical conditions are different from those of the "2.4 GHz" or "5 GHz" bands. The allowed power levels and, implicitly, the maximum allowed distance between vehicles is 33 dBm for 802.11-OCB (in Europe) compared to 20 dBm for Wireless LAN 802.11a/b/g/n; this leads to a maximum distance of approximately 1 km compared to approximately 50 m. Additionally, specific conditions related to congestion avoidance, jamming avoidance, and radar detection are imposed on the use of DSRC (in the US) and on the use of frequencies for Intelligent Transportation Systems (in the EU) compared to Wireless LAN (802.11a/b/g/n).
* 周波数範囲：これはPHY層の特性です。 MACとIP間のインターフェイスにはほとんど影響しません。ただし、周波数範囲は地域当局（ARCEP、ETSI、FCCなどのENに基づくECC / CEPT）によって規制されていることを考慮する価値があります。調整プロセスの一部として、特定のアプリケーションは特定の周波数範囲に関連付けられています。 802.11-OCBの場合、レギュレータは、帯域内の一連の周波数範囲またはスロットを、「5.9 GHz」と呼ばれる帯域での車両通信のアプリケーションの使用に関連付けます。 5.9 GHz帯域は、ワイヤレスLANで使用される2.4 GHzおよび5 GHz帯域とは異なります。ただし、ワイヤレスLANの場合と同様に、5.9 GHz帯域での802.11-OCBの運用には、EUでのライセンスは必要ありません（米国では、5.9 GHzはスペクトルのライセンス帯域です。固定インフラストラクチャでは、明示的なFCC承認が必要です。 ;オンボードデバイスの場合、「ルールによるライセンス」の概念が適用され、ルール認証への準拠が必要です）。 「2.4 GHz」または「5 GHz」帯域の技術条件とは異なります。許容電力レベルと暗黙的に車両間の最大許容距離は、ワイヤレスLAN 802.11a / b / g / nの20 dBmと比較して、802.11-OCB（ヨーロッパ）では33 dBmです。これにより、最大距離は約50 mと比較して約1 kmになります。さらに、輻輳回避、妨害回避、およびレーダー検出に関連する特定の条件が、ワイヤレスLAN（802.11a /）と比較して、DSRC（米国）の使用およびインテリジェント交通システム（EU）の周波数の使用に課されます。 b / g / n）。
* 'Half-rate' encoding: As the frequency range, this parameter is related to PHY and thus does not have much impact on the interface between the IP layer and the MAC layer.
* 「ハーフレート」エンコーディング：周波数範囲として、このパラメーターはPHYに関連しているため、IPレイヤーとMACレイヤーの間のインターフェイスにはあまり影響しません。
* In vehicular communications using 802.11-OCB links, there are strong privacy requirements with respect to addressing. While the 802.11-OCB standard does not specify anything in particular with respect to MAC addresses, in these settings, there is a strong need for a dynamic change of these addresses (as opposed to the non-vehicular settings -- real wall protection -- where fixed MAC addresses do not currently pose privacy risks). This is further described in Section 5. A relevant function is described in [IEEE-1609.3] and [IEEE-1609.4].
* 802.11-OCBリンクを使用した車両通信では、アドレス指定に関して強力なプライバシー要件があります。 802.11-OCB標準はMACアドレスに関して特に何も指定していませんが、これらの設定では、これらのアドレスの動的な変更が強く求められています（非車両設定-実際の壁保護-とは対照的に）。固定MACアドレスが現在プライバシーリスクを引き起こしていない場合）。これについては、セクション5で詳しく説明します。関連する機能については、[IEEE-1609.3]および[IEEE-1609.4]で説明しています。
Appendix C. Changes Needed on an 802.11a Software Driver to Become an 802.11-OCB Driver
付録C.802.11aソフトウェアドライバーが802.11-OCBドライバーになるために必要な変更
The 802.11p amendment modifies both the 802.11 stack's physical and MAC layers, but all the induced modifications can be quite easily obtained by modifying an existing 802.11a ad hoc stack.
802.11pの修正により、802.11スタックの物理層とMAC層の両方が変更されますが、既存の802.11aアドホックスタックを変更することで、誘発された変更をすべて簡単に取得できます。
The conditions for 802.11a hardware to be compliant with 802.11-OCB are as follows:
802.11aハードウェアが802.11-OCBに準拠するための条件は次のとおりです。
* The PHY entity shall be an OFDM system. It must support the frequency bands on which the regulator recommends the use of ITS communications -- for example, using an IEEE 802.11-OCB layer of 5875 MHz to 5925 MHz in France.
* PHYエンティティはOFDMシステムでなければならない。規制当局がITS通信の使用を推奨する周波数帯をサポートする必要があります。たとえば、フランスでは5875 MHz〜5925 MHzのIEEE 802.11-OCBレイヤーを使用します。
* The OFDM system must provide a "half-clocked" operation using 10 MHz channel spacings.
* OFDMシステムは、10 MHzチャネル間隔を使用して「ハーフクロック」動作を提供する必要があります。
* The chip transmit spectrum mask must be compliant with the "Transmit spectrum mask" from the IEEE 802.11p amendment (but experimental environments do not require compliance).
* チップの送信スペクトルマスクは、IEEE 802.11p修正の「送信スペクトルマスク」に準拠している必要があります（ただし、実験環境では準拠する必要はありません）。
* The chip should be able to transmit up to 44.8 dBm when used in the United States and up to 33 dBm in Europe; other regional conditions apply.
* このチップは、米国で使用した場合は最大44.8 dBm、ヨーロッパでは最大33 dBmを送信できる必要があります。他の地域条件が適用されます。
Changes needed on the network stack in OCB mode are as follows:
OCBモードのネットワークスタックで必要な変更は次のとおりです。
* Physical layer:
* 物理層：
- Orthogonal frequency-division multiple access The chip must use the Orthogonal Frequency Division Multiple Access (OFDMA) encoding mode.
- 直交周波数分割多元接続チップは、直交周波数分割多元接続（OFDMA）エンコードモードを使用する必要があります。
- The chip must be set to half-mode rate mode (the internal clock frequency is divided by two).
- チップはハーフモードレートモードに設定する必要があります（内部クロック周波数は2で分周されます）。
- The chip must use dedicated channels and should allow the use of higher emission powers. This may require modifications to the local computer file that describes regulatory domains rules if used by the kernel to enforce local specific restrictions. Such modifications to the local computer file must respect the location-specific regulatory rules.
- チップは専用チャネルを使用する必要があり、より高い放射電力を使用できる必要があります。これには、カーネルがローカル固有の制限を適用するために使用する場合、規制ドメインルールを記述するローカルコンピュータファイルの変更が必要になる場合があります。ローカルコンピュータファイルへのこのような変更は、場所固有の規制ルールを順守する必要があります。
* MAC layer:
* MACレイヤー：
- All management frames (beacons, join, leave, and others) emission and reception must be disabled, except for frames of subtype Action and Timing Advertisement (defined below).
- サブタイプのアクションとタイミングアドバタイズメント（以下で定義）のフレームを除き、すべての管理フレーム（ビーコン、参加、脱退など）の送信と受信を無効にする必要があります。
- No encryption key or method must be used.
- 暗号化キーまたはメソッドを使用する必要はありません。
- Packet emission and reception must be performed as in ad hoc mode using the wildcard BSSID (ff:ff:ff:ff:ff:ff).
- パケットの送信と受信は、ワイルドカードBSSID（ff：ff：ff：ff：ff：ff）を使用してアドホックモードと同じように実行する必要があります。
- The functions related to joining a BSS (Association Request/ Response) and authentication (Authentication Request/Reply, Challenge) are not called.
- BSS（Association Request / Response）への参加と認証（Authentication Request / Reply、Challenge）に関連する関数は呼び出されません。
- The beacon interval is always set to 0 (zero).
- ビーコン間隔は常に0（ゼロ）に設定されます。
- Timing Advertisement frames, defined in the amendment, should be supported. The upper layer should be able to trigger such frames emission and retrieve information contained in the received Timing Advertisements.
- 修正で定義されたタイミング広告フレームがサポートされるべきです。上位層は、このようなフレームの送信をトリガーし、受信したタイミングアドバタイズメントに含まれる情報を取得できる必要があります。
A more theoretical and detailed view of layer stacking and interfaces between the IP layer and 802.11-OCB layers is illustrated in Figure 2. The IP layer operates on top of EtherType Protocol Discrimination (EPD). This discrimination layer is described in [IEEE-802.3-2012]. The interface between IPv6 and EPD is the LLC_SAP (Link Layer Control Service Access Point).
IPレイヤーと802.11-OCBレイヤー間のレイヤースタッキングとインターフェイスのより理論的で詳細なビューを図2に示します。IPレイヤーは、EtherType Protocol Discrimination（EPD）の上で動作します。この識別層は、[IEEE-802.3-2012]で説明されています。 IPv6とEPDの間のインターフェースはLLC_SAP（リンク層制御サービスアクセスポイント）です。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 |
+-+-+-+-+-+-{ }+-+-+-+-+-+-+-+
{ LLC_SAP } 802.11-OCB
+-+-+-+-+-+-{ }+-+-+-+-+-+-+-+ Boundary
| EPD | | |
| | MLME | |
+-+-+-{ MAC_SAP }+-+-+-| MLME_SAP |
| MAC Sublayer | | | 802.11-OCB
| and ch. coord. | | SME | Services
+-+-+-{ PHY_SAP }+-+-+-+-+-+-+-| |
| | PLME | |
| PHY Layer | PLME_SAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EtherType Protocol Discrimination
図2：EtherTypeプロトコルの識別
The networks defined by 802.11-OCB are in many ways similar to other networks of the 802.11 family. In theory, the transportation of IPv6 over 802.11-OCB could be very similar to the operation of IPv6 over other networks of the 802.11 family. However, the high mobility, strong link asymmetry, and very short connection makes the 802.11-OCB link significantly different from other 802.11 networks. Also, automotive applications have specific requirements for reliability, security, and privacy, which further add to the particularity of the 802.11-OCB link.
802.11-OCBによって定義されたネットワークは、802.11ファミリの他のネットワークと多くの点で類似しています。理論的には、802.11-OCBを介したIPv6の転送は、802.11ファミリの他のネットワークを介したIPv6の動作と非常によく似ています。ただし、高いモビリティ、強力なリンクの非対称性、および非常に短い接続により、802.11-OCBリンクは他の802.11ネットワークとは大きく異なります。また、自動車用アプリケーションには、信頼性、セキュリティ、プライバシーに関する特定の要件があり、これは802.11-OCBリンクの特殊性をさらに高めます。
At the time of writing, this is the list of IEEE 802.11 messages that may be transmitted in OCB mode, i.e., when dot11OCBActivated is true in a STA:
これを書いている時点では、これはOCBモードで送信される可能性があるIEEE 802.11メッセージのリストです。つまり、STAでdot11OCBActivatedがtrueの場合です。
* The STA may send management frames of subtype Action and, if the STA maintains a TSF Timer, subtype Timing Advertisement.
* STAは、サブタイプアクションの管理フレームを送信できます。STAがTSFタイマーを維持している場合は、サブタイプタイミングアドバタイズメントを送信できます。
* The STA may send control frames except those of subtype PS-Poll, CF-End, and CF-End plus CFAck.
* STAは、サブタイプPS-Poll、CF-End、およびCF-EndとCFAckを除く制御フレームを送信できます。
* The STA MUST send data frames of subtype QoS Data.
* STAは、サブタイプQoSデータのデータフレームを送信する必要があります。
Appendix G. Examples of Packet Formats
付録G.パケット形式の例
This section describes an example of an IPv6 packet captured over an IEEE 802.11-OCB link.
このセクションでは、IEEE 802.11-OCBリンクを介してキャプチャされたIPv6パケットの例について説明します。
By way of example, we show that there is no modification in the headers when transmitted over 802.11-OCB networks -- they are transmitted like any other 802.11 and Ethernet packets.
例として、802.11-OCBネットワークを介して送信される場合、ヘッダーには変更がないことを示します。これらは、他の802.11およびイーサネットパケットのように送信されます。
We describe an experiment for capturing an IPv6 packet on an 802.11-OCB link. In the topology depicted in Figure 3, the packet is an IPv6 Router Advertisement. This packet is emitted by a router on its 802.11-OCB interface. The packet is captured on the host using a network protocol analyzer (e.g., Wireshark). The capture is performed in two different modes: direct mode and monitor mode. The topology used during the capture is depicted below.
802.11-OCBリンクでIPv6パケットをキャプチャする実験について説明します。図3に示すトポロジでは、パケットはIPv6ルーターアドバタイズメントです。このパケットは、802.11-OCBインターフェイスのルーターによって発信されます。パケットは、ネットワークプロトコルアナライザー（Wiresharkなど）を使用してホストでキャプチャされます。キャプチャは、ダイレクトモードとモニターモードの2つの異なるモードで実行されます。キャプチャ中に使用されるトポロジを以下に示します。
The packet is captured on the host. The host is an IP-OBU containing an 802.11 interface in Peripheral Component Interconnect (PCI) Express format (an Industrial Technology Research Institute (ITRI) product). The kernel runs the ath5k software driver with modifications for OCB mode. The capture tool is Wireshark. The file format for saving and analyzing is .pcap. The packet is generated by the router, which is an IP-RSU (an ITRI product).
パケットはホストでキャプチャされます。ホストは、Peripheral Component Interconnect（PCI）Express形式の802.11インターフェースを含むIP-OBU（産業技術研究所（ITRI）製品）です。カーネルは、OCBモード用に変更を加えたath5kソフトウェアドライバーを実行します。キャプチャツールはWiresharkです。保存および分析用のファイル形式は.pcapです。パケットは、IP-RSU（ITRI製品）であるルーターによって生成されます。
+--------+ +-------+
| | 802.11-OCB Link | |
---| Router |--------------------------------| Host |
| | | |
+--------+ +-------+
Figure 3: Topology for Capturing IP Packets on 802.11-OCB
図3：802.11-OCBでIPパケットをキャプチャするためのトポロジ
During several capture operations running from a few moments to several hours, no messages relevant to the BSSID contexts were captured (Association Request/Response, Authentication Req/Resp, or beacon). This shows that the operation of 802.11-OCB is outside the context of a BSSID.
数分から数時間の間に実行されるいくつかのキャプチャ操作中に、BSSIDコンテキストに関連するメッセージ（関連付け要求/応答、認証要求/応答、またはビーコン）はキャプチャされませんでした。これは、802.11-OCBの動作がBSSIDのコンテキスト外であることを示しています。
Overall, the captured message is identical to a capture of an IPv6 packet emitted on an 802.11b interface. The contents are exactly the same.
全体として、キャプチャされたメッセージは、802.11bインターフェイスで送信されたIPv6パケットのキャプチャと同じです。内容は全く同じです。
The IPv6 RA packet captured in monitor mode is illustrated below. The Radiotap header provides more flexibility for reporting the characteristics of frames. The Radiotap header is prepended by this particular stack and operating system on the host machine to the RA packet received from the network (the Radiotap header is not present on the air). The implementation-dependent Radiotap header is useful for piggybacking PHY information from the chip's registers as data in a packet that is understandable by userland applications using socket interfaces (the PHY interface can be, for example, power levels, data rate, or the ratio of signal to noise).
監視モードでキャプチャされたIPv6 RAパケットを以下に示します。 Radiotapヘッダーは、フレームの特性を報告するための柔軟性を提供します。 Radiotapヘッダーは、ホストマシン上のこの特定のスタックとオペレーティングシステムによって、ネットワークから受信したRAパケットの前に付加されます（Radiotapヘッダーは空中に存在しません）。実装に依存するRadiotapヘッダーは、チップのレジスターからのPHY情報を、ソケットインターフェイスを使用するユーザーランドアプリケーションで理解できるパケット内のデータとしてピギーバックするのに役立ちます（PHYインターフェイスは、たとえば、電力レベル、データレート、またはノイズへの信号）。
The packet present on the air is formed by the IEEE 802.11 Data header, Logical Link Control header, IPv6 Base header, and ICMPv6 header.
無線で存在するパケットは、IEEE 802.11データヘッダー、論理リンク制御ヘッダー、IPv6ベースヘッダー、およびICMPv6ヘッダーによって形成されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Header Revision| Header Pad | Header Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Present Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Rate | Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Radiotap Header v0
図4：Radiotapヘッダーv0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type/Subtype and Frame Ctrl | Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Receiver Address | Transmitter Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Transmitter Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSS ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... BSS ID | Frag Number and Seq Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IEEE 802.11 Data Header
図5：IEEE 802.11データヘッダー
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSAP |I| SSAP |C| Control Field | Org. Code...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Organizational Code | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Logical Link Control Header
図6：論理リンク制御ヘッダー
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: IPv6 Base Header
図7：IPv6ベースヘッダー
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O| Reserved | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 8: Router Advertisement
図8：ルーターアドバタイズメント
The value of the Data Rate field in the Radiotap header is set to 6 Mb/s. This indicates the rate at which this RA was received.
RadiotapヘッダーのData Rateフィールドの値は6 Mb / sに設定されています。これは、このRAが受信されたレートを示します。
The value of the Transmitter Address in the IEEE 802.11 Data header is set to a 48-bit value. The value of the destination address is 33:33:00:00:00:1 (all-nodes multicast address). The value of the BSS ID field is ff:ff:ff:ff:ff:ff, which is recognized by the network protocol analyzer as being "broadcast". The Fragment number and Sequence number fields together are set to 0x90C6.
IEEE 802.11データヘッダーの送信機アドレスの値は、48ビット値に設定されます。宛先アドレスの値は33：33：00：00：00：1（全ノードマルチキャストアドレス）です。 BSS IDフィールドの値はff：ff：ff：ff：ff：ffであり、ネットワークプロトコルアナライザーによって「ブロードキャスト」として認識されます。フラグメント番号とシーケンス番号フィールドを一緒に0x90C6に設定します。
The value of the Organization Code field in the Logical Link Control header is set to 0x0, recognized as "Encapsulated Ethernet". The value of the Type field is 0x86DD (hexadecimal 86DD; otherwise, #86DD), recognized as "IPv6".
論理リンク制御ヘッダーの組織コードフィールドの値は、「カプセル化イーサネット」として認識される0x0に設定されています。 Typeフィールドの値は0x86DD（16進数の86DD、それ以外の場合は＃86DD）であり、「IPv6」として認識されます。
A Router Advertisement is periodically sent by the router to multicast group address ff02::1. It is ICMP packet type 134. The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags, as described in [RFC4861].
ルーターアドバタイズは、ルーターによってマルチキャストグループアドレスff02 :: 1に定期的に送信されます。これはICMPパケットタイプ134です。IPv6近隣探索のルーターアドバタイズメッセージには、[RFC4861]で説明されているように、シングルビットフラグ用に予約された8ビットフィールドが含まれています。
The IPv6 header contains the link-local address of the router (source) configured via the EUI-64 algorithm, and the destination address is set to ff02::1.
IPv6ヘッダーには、EUI-64アルゴリズムを介して構成されたルーター（ソース）のリンクローカルアドレスが含まれ、宛先アドレスはff02 :: 1に設定されます。
The Ethernet Type field in the Logical Link Control header is set to 0x86dd, which indicates that the frame transports an IPv6 packet. In the IEEE 802.11 data, the destination address is 33:33:00:00:00:01, which is the corresponding multicast MAC address. The BSS ID is a broadcast address of ff:ff:ff:ff:ff:ff. Due to the short link duration between vehicles and the roadside infrastructure, there is no need in IEEE 802.11-OCB to wait for the completion of association and authentication procedures before exchanging data. IEEE 802.11-OCB enabled nodes use the wildcard BSSID (a value of all 1s) and may start communicating as soon as they arrive on the communication channel.
論理リンク制御ヘッダーのイーサネットタイプフィールドは0x86ddに設定されています。これは、フレームがIPv6パケットを転送することを示します。 IEEE 802.11データでは、宛先アドレスは33：33：00：00：00：01であり、これは対応するマルチキャストMACアドレスです。 BSS IDは、ff：ff：ff：ff：ff：ffのブロードキャストアドレスです。車両と路側インフラストラクチャ間のリンク期間が短いため、IEEE 802.11-OCBでは、データの交換前に関連付けと認証の手順が完了するのを待つ必要がありません。 IEEE 802.11-OCB対応ノードは、ワイルドカードBSSID（すべて1の値）を使用し、通信チャネルに到着するとすぐに通信を開始できます。
The same IPv6 Router Advertisement packet described above (monitor mode) is captured on the host in normal mode and is depicted below.
上記と同じIPv6ルーターアドバタイズパケット（モニターモード）は、通常モードのホストでキャプチャされ、以下に示されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Destination | Source...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Ethernet II Header
図9：イーサネットIIヘッダー
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: IPv6 Base Header
図10：IPv6ベースヘッダー
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O| Reserved | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 11: Router Advertisement
図11：ルーターアドバタイズメント
One notices that the Radiotap header, the IEEE 802.11 Data header, and the Logical Link Control headers are not present. On the other hand, a new header named the Ethernet II header is present.
Radiotapヘッダー、IEEE 802.11データヘッダー、および論理リンク制御ヘッダーが存在しないことに気づきます。一方、イーサネットIIヘッダーという名前の新しいヘッダーが存在します。
The Destination and Source addresses in the Ethernet II header contain the same values as the Receiver Address and Transmitter Address fields present in the IEEE 802.11 Data header in the monitor mode capture.
イーサネットIIヘッダーの宛先アドレスと送信元アドレスには、モニターモードキャプチャのIEEE 802.11データヘッダーにあるレシーバーアドレスフィールドとトランスミッターアドレスフィールドと同じ値が含まれています。
The value of the Type field in the Ethernet II header is 0x86DD (recognized as "IPv6"); this value is the same as the value of the Type field in the Logical Link Control header in the monitor mode capture.
イーサネットIIヘッダーのTypeフィールドの値は0x86DD（「IPv6」として認識）です。この値は、監視モードキャプチャの論理リンク制御ヘッダーのタイプフィールドの値と同じです。
The knowledgeable experimenter will no doubt notice the similarity of this Ethernet II header with a capture in normal mode on a pure Ethernet cable interface.
知識豊富な実験者は、このイーサネットIIヘッダーと、純粋なイーサネットケーブルインターフェイスでの通常モードのキャプチャとの類似性に気付くことでしょう。
A frame translation is inserted on top of a pure IEEE 802.11 MAC layer in order to adapt packets before delivering the payload data to the applications. It adapts 802.11 LLC/MAC headers to Ethernet II headers. Specifically, this adaptation consists of the elimination of the Radiotap, 802.11, and LLC headers and the insertion of the Ethernet II header. In this way, IPv6 runs straight over LLC over the 802.11-OCB MAC layer; this is further confirmed by the use of the unique Type 0x86DD.
ペイロードデータをアプリケーションに配信する前にパケットを適合させるために、フレーム変換が純粋なIEEE 802.11 MACレイヤーの上に挿入されます。 802.11 LLC / MACヘッダーをイーサネットIIヘッダーに適合させます。具体的には、この適応は、Radiotap、802.11、およびLLCヘッダーの削除とイーサネットIIヘッダーの挿入で構成されています。このように、IPv6は802.11-OCB MACレイヤーを介してLLC上で直接実行されます。これは、一意のタイプ0x86DDの使用によってさらに確認されます。
Appendix H. Extra Terminology
付録H.追加の用語
The following terms are defined outside the IETF. They are used to define the main terms in the terminology section (Section 2).
以下の用語は、IETFの外部で定義されています。これらは、用語セクション（セクション2）の主な用語を定義するために使用されます。
DSRC (Dedicated Short Range Communication): The US Federal Communications Commission (FCC) Dedicated Short Range Communication (DSRC) is defined in the Code of Federal Regulations (CFR) 47, Parts 90 [CFR-90] and 95 [CFR-95]. This Code is referenced in the definitions below. At the time of the writing of this document, the last update of this Code was dated December 6, 2019.
DSRC（専用短距離通信）：US Federal Communications Commission（FCC）専用短距離通信（DSRC）は、連邦規則（CFR）47、Parts 90 [CFR-90]および95 [CFR-95]のコードで定義されています。 。このコードは、以下の定義で参照されています。この文書の執筆時点で、このコードの最終更新日は2019年12月6日でした。
DSRCS (Dedicated Short-Range Communications Services): Radio techniques are used to transfer data over short distances between roadside and mobile units, between mobile units, and between portable and mobile units to perform operations related to the improvement of traffic flow, traffic safety, and other intelligent transportation service applications in a variety of environments. DSRCS systems may also transmit status and instructional messages related to the units involved. [CFR-90.7]
DSRCS（専用の短距離通信サービス）：無線技術を使用して、路側とモバイルユニット間、モバイルユニット間、およびポータブルユニットとモバイルユニット間で短距離のデータ転送を行い、交通流の改善、交通安全、さまざまな環境でのその他のインテリジェント輸送サービスアプリケーション。 DSRCSシステムは、関係するユニットに関連するステータスおよび指示メッセージを送信する場合もあります。 [CFR-90.7]
OBU (On-Board Unit): An On-Board Unit is a DSRCS transceiver that is normally mounted in or on a vehicle or may be a portable unit in some instances. An OBU can be operational while a vehicle or person is either mobile or stationary. The OBUs receive and contend for time to transmit on one or more radio frequency (RF) channels. Except where specifically excluded, OBU operation is permitted wherever vehicle operation or human passage is permitted. The OBUs mounted in vehicles are licensed by rule under part 95 of [CFR-95] and communicate with Roadside Units (RSUs) and other OBUs. Portable OBUs are also licensed by rule under part 95 of [CFR-95]. OBU operations in the Unlicensed National Information Infrastructure (U-NII) Bands follow the rules in those bands. [CFR-90.7]
OBU（オンボードユニット）：オンボードユニットは、DSRCSトランシーバーであり、通常は車両内または車両に取り付けられます。場合によっては、ポータブルユニットになることもあります。 OBUは、車両または人が移動中または静止しているときに使用できます。 OBUは、1つ以上の無線周波数（RF）チャネルで送信するための時間を受信して競合します。特に除外されている場合を除き、OBU操作は、車両の操作または人の通過が許可されている場所であればどこでも許可されます。車両に搭載されたOBUは、[CFR-95]のパート95に基づく規則により認可されており、路側機（RSU）およびその他のOBUと通信します。ポータブルOBUは、[CFR-95]のパート95に基づく規則によってもライセンスされています。 Unlicensed National Information Infrastructure（U-NII）バンドのOBUオペレーションは、それらのバンドのルールに従います。 [CFR-90.7]
RSU (Roadside Unit): A Roadside Unit is a DSRC transceiver that is mounted along a road or pedestrian passageway. An RSU may also be mounted on a vehicle or may be hand carried, but it may only operate when the vehicle or hand-carried unit is stationary. Perhaps Furthermore, an RSU is restricted to the location where it is licensed to operate. However, portable or handheld RSUs are permitted to operate where they do not interfere with a site-licensed operation. An RSU broadcasts data to OBUs or exchanges data with OBUs in its communications zone. An RSU also provides channel assignments and operating instructions to OBUs in its communications zone when required. [CFR-90.7]
RSU（Roadside Unit）：Roadside Unitは、道路または歩行者通路に沿って取り付けられるDSRCトランシーバーです。 RSUは、車両に搭載することも、持ち運びすることもできますが、車両または携帯ユニットが静止している場合にのみ動作します。おそらく、さらに、RSUは、その操作が許可されている場所に制限されます。ただし、ポータブルまたはハンドヘルドRSUは、サイトライセンスの操作に干渉しない場所で操作できます。 RSUはデータをOBUにブロードキャストするか、その通信ゾーン内のOBUとデータを交換します。 RSUは、必要に応じて、通信ゾーン内のOBUにチャネル割り当てと操作手順も提供します。 [CFR-90.7]
Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless Links
付録I.ワイヤレスリンクでの近隣探索（ND）の潜在的な問題
IPv6 Neighbor Discovery (IPv6 ND) [RFC4861] [RFC4862] was designed for point-to-point and transit links, such as Ethernet, with the expectation of cheap and reliable support for multicast from the lower layer. Section 3.2 of [RFC4861] indicates that the operation on shared media and on NBMA networks require additional support, e.g., for AR and DAD, which depend on multicast. An infrastructureless radio network such as OCB shares properties with both shared media and NBMA networks and then adds its own complexity, e.g., from movement and interference that allow only transient and non-transitive reachability between any set of peers.
IPv6近隣探索（IPv6 ND）[RFC4861] [RFC4862]は、イーサネットなどのポイントツーポイントおよびトランジットリンク用に設計されており、下位層からのマルチキャストに対する安価で信頼性の高いサポートが期待されています。 [RFC4861]のセクション3.2は、共有メディアとNBMAネットワークでの操作には、マルチキャストに依存するARやDADなどの追加のサポートが必要であることを示しています。 OCBなどのインフラストラクチャのない無線ネットワークは、共有メディアとNBMAネットワークの両方とプロパティを共有し、たとえば、ピアのセット間の一時的および非推移的な到達可能性のみを許可する移動や干渉など、独自の複雑さを追加します。
The uniqueness of an address within a scoped domain is a key pillar of IPv6 and is the basis for unicast IP communication. [RFC4861] details the DAD method to prevent an address from being duplicated. For a link-local address, the scope is the link, whereas for a globally reachable address, the scope is much larger. The underlying assumption for DAD to operate correctly is that the node that owns an IPv6 address can reach any other node within the scope at the time it claims its address, which is done by sending a Neighbor Solicitation (NS) multicast message, and can hear any future claim for that address by another party within the scope for the duration of the address ownership.
スコープドメイン内のアドレスの一意性は、IPv6の主要な柱であり、ユニキャストIP通信の基礎です。 [RFC4861]は、アドレスが重複しないようにするDADメソッドについて詳しく説明しています。リンクローカルアドレスの場合、スコープはリンクですが、グローバルに到達可能なアドレスの場合、スコープははるかに大きくなります。 DADが正しく動作するための基本的な前提は、IPv6アドレスを所有するノードがアドレスを要求するときに、スコープ内の他のノードに到達できることです。これは、近隣要請（NS）マルチキャストメッセージを送信することによって行われ、聞くことができます。アドレスの所有権の存続期間中、別の当事者によるそのアドレスの将来の主張。
In the case of OCB, there is a potentially a need to define a scope that is compatible with DAD. The scope cannot be the set of nodes that a transmitter can reach at a particular time because that set varies all the time and does not meet the DAD requirements for a link-local address that can be used anytime and anywhere. The generic expectation of a reliable multicast is not ensured, and the operation of DAD and AR as specified by [RFC4861] cannot be guaranteed. Moreover, multicast transmissions that rely on broadcast are not only unreliable but are also often detrimental to unicast traffic (see [IEEE802-MCAST]).
OCBの場合、DADと互換性のあるスコープを定義する必要が生じる可能性があります。そのセットは常に変化し、いつでもどこでも使用できるリンクローカルアドレスのDAD要件を満たさないため、トランスミッタが特定の時間に到達できるノードのセットをスコープにすることはできません。信頼できるマルチキャストの一般的な期待は保証されておらず、[RFC4861]で指定されているDADおよびARの動作は保証できません。さらに、ブロードキャストに依存するマルチキャスト送信は、信頼性が低いだけでなく、ユニキャストトラフィックにも有害です（[IEEE802-MCAST]を参照）。
Early experience indicates that it should be possible to exchange IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR (Address Resolution) in good conditions. In the absence of a correct DAD operation, a node that relies only on IPv6 ND for AR and DAD over OCB should ensure that the addresses that it uses are unique by means other than DAD. It must be noted that deriving an IPv6 address from a globally unique MAC address has this property but may yield privacy issues.
初期の経験では、DADとAR（アドレス解決）をIPv6 NDだけに頼りながら、OCBを介してIPv6パケットを交換することが可能であることが示されています。正しいDAD操作がない場合、ARおよびIPv6 over OCBのIPv6 NDのみに依存するノードは、使用するアドレスがDAD以外の方法で一意であることを確認する必要があります。グローバルに一意のMACアドレスからIPv6アドレスを取得することにはこの特性がありますが、プライバシーの問題が発生する可能性があることに注意する必要があります。
[RFC8505] provides a more recent approach to IPv6 ND, in particular DAD. [RFC8505] is designed to fit wireless and otherwise constrained networks whereby multicast and/or continuous access to the medium may not be guaranteed. [RFC8505], Section 5.6 ("Link-Local Addresses and Registration") indicates that the scope of uniqueness for a link-local address is restricted to a pair of nodes that uses it to communicate and provides a method to assert the uniqueness and resolve the link-layer address using a unicast exchange.
[RFC8505]は、IPv6 ND、特にDADへのより最近のアプローチを提供します。 [RFC8505]は、ワイヤレスやその他の制約のあるネットワークに適合するように設計されているため、メディアへのマルチキャストおよび/または継続的なアクセスは保証されません。 [RFC8505]、セクション5.6（「リンクローカルアドレスと登録」）は、リンクローカルアドレスの一意性の範囲が、通信に使用する一意のノードのペアに制限されていることを示し、一意性を表明して解決する方法を提供しますユニキャスト交換を使用するリンク層アドレス。
[RFC8505] also enables a router (acting as a 6LR) to own a prefix and act as a registrar (acting as a 6LBR) for addresses within the associated subnet. A peer host (acting as a 6LN) registers an address derived from that prefix and can use it for the lifetime of the registration. The prefix is advertised as not on-link, which means that the 6LN uses the 6LR to relay its packets within the subnet, and participation to the subnet is constrained to the time of reachability to the 6LR. Note that an RSU that provides internet connectivity MAY announce a default router preference [RFC4191], whereas a car that does not provide that connectivity MUST NOT do so. This operation presents similarities to that of an access point, but at Layer 3. This is why [RFC8505] is well suited for wireless in general.
[RFC8505]では、ルーター（6LRとして機能）がプレフィックスを所有し、関連付けられたサブネット内のアドレスのレジストラ（6LBRとして機能）として機能することもできます。ピアホスト（6LNとして機能）は、そのプレフィックスから派生したアドレスを登録し、登録の存続期間中それを使用できます。プレフィックスはリンク上ではないものとしてアドバタイズされます。つまり、6LNは6LRを使用してサブネット内でパケットをリレーし、サブネットへの参加は6LRへの到達可能時間に制限されます。インターネット接続を提供するRSUはデフォルトのルーター設定[RFC4191]を通知してもよいことに注意してください。一方、その接続を提供しない車は通知してはいけません（MUST NOT）。この操作は、アクセスポイントの操作と似ていますが、レイヤ3にあります。このため、[RFC8505]は一般的にワイヤレスに適しています。
Support of [RFC8505] may be implemented on OCB. OCB nodes that support [RFC8505] SHOULD support the 6LN operation in order to act as a host and may support the 6LR and 6LBR operations in order to act as a router and in particular to own a prefix that can be used by hosts that are compliant with [RFC8505] for address autoconfiguration and registration.
[RFC8505]のサポートは、OCBで実装できます。 [RFC8505]をサポートするOCBノードは、ホストとして機能するために6LN操作をサポートする必要があり、ルーターとして機能するため、特に準拠しているホストが使用できるプレフィックスを所有するために6LRおよび6LBR操作をサポートする必要があります[RFC8505]を使用して、アドレスの自動構成と登録を行います。
Acknowledgements
謝辞
The authors would like to thank Alexandre Petrescu for initiating this work and for being the lead author up to draft version 43 of this document.
著者は、この作業を開始し、このドキュメントのドラフトバージョン43までの筆頭著者であるAlexandre Petrescuに感謝します。
The authors would like to thank Pascal Thubert for reviewing, proofreading, and suggesting modifications for this document.
著者は、このドキュメントのレビュー、校正、および修正の提案を行ったPascal Thubertに感謝します。
The authors would like to thank Mohamed Boucadair for proofreading and suggesting modifications for this document.
著者は、このドキュメントの校正と修正を提案してくれたMohamed Boucadairに感謝します。
The authors would like to thank Eric Vyncke for reviewing the suggesting modifications of this document.
このドキュメントの提案された修正をレビューしてくれたEric Vynckeに感謝します。
The authors would like to thank Witold Klaudel, Ryuji Wakikawa, Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan, Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne, Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark, Bob Moskowitz, Andrew Dryden, Georg Mayer, Dorothy Stanley, Sandra Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun, Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in 't Velt, Katrin Sjoberg, Roland Bless, Tijink Jasja, Kevin Smith, Brian Carpenter, Julian Reschke, Mikael Abrahamsson, Dirk von Hugo, Lorenzo Colitti, Pascal Thubert, Ole Troan, Jinmei Tatuya, Joel Halpern, Eric Gray, and William Whyte. Their valuable comments clarified particular issues and generally helped to improve the document.
著者は、ウィトールド・クローデル、脇川龍二、エマニュエル・バチェリ、ジョン・ケニー、ジョン・モーリング、フランソワ・サイモン、ダン・ロマスカヌ、コンスタンティン・ハイト、ラルフ・ドロムス、リチャード・ディック・ロイ、レイ・ハンター、トム・クリハラ、ミカル・ソイカ、ヤン・デに感謝しますジョン、スレーシュクリシュナン、ディノファリナッチ、ビンセントパーク、ジェフーンポールジョン、グロリアグウィン、ハンスヨアヒムフィッシャー、ラスハウズリー、レックスブッデンベルク、エリックノードマーク、ボブモスコビッツ、アンドリュードライデン、ゲオルクメイヤー、ドロシースタンレー、サンドラチェスペデス、マリアスリガンダヴェッリ、アブドゥッサラムバリューン、マーガレットカレン、エリッククライン、カルロスジーザスベルナルドスカノ、ロナルドインヴェルト、カトリンシェーバーグ、ローランドブレス、ティジンクジャジャ、ケビンスミス、ブライアンカーペンター、ジュリアンレシュケ、ミカエルアブラハムソン、ディルクフォンコリーティ、ロレンド、Pascal Thubert、Ole Troan、Jinmei Tatuya、Joel Halpern、Eric Gray、William Whyte。彼らの貴重なコメントは特定の問題を明確にし、一般的に文書を改善するのに役立ちました。
Pierre Pfister, Rostislav Lisovy, and others wrote 802.11-OCB drivers for Linux.
Pierre Pfister、Rostislav Lisovy、その他はLinux用の802.11-OCBドライバを書いた。
For the multicast discussion, the authors would like to thank Owen DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman, and participants to discussions in network working groups.
マルチキャストディスカッションについて、著者はOwen DeLong、Joe Touch、Jen Linkova、Erik Kline、Brian Haberman、およびネットワークワーキンググループでのディスカッションへの参加者に感謝します。
The authors would like to thank the participants of the Birds-of-a-Feather "Intelligent Transportation Systems" meetings held at IETF in 2016.
著者は、2016年にIETFで開催された鳥の羽「インテリジェント輸送システム」会議の参加者に感謝します。
The human rights protocol considerations review was done by Amelia Andersdotter.
人権プロトコルの検討事項の検討は、アメリアアンダースドッターによって行われました。
The work of Jong-Hyouk Lee was supported by the National Research Foundation of Korea (NRF) grant funded by the Korea government (MSIT) (NRF-2018R1A4A1025632).
Lee Jong-Hyoukの作品は、韓国政府（MSIT）（NRF-2018R1A4A1025632）によって資金提供された韓国国立研究財団（NRF）助成金によってサポートされました。
The work of Jérôme Härri was supported by EURECOM industrial members, namely BMW Group, IABG, Monaco Telecom, Orange, SAP and Symantec. This RFC reflects the view of the IPWAVE WG and does not necessarily reflect the official policy or position of EURECOM industrial members.
JérômeHärriの仕事はEURECOMの産業メンバー、つまりBMW Group、IABG、Monaco Telecom、Orange、SAP、Symantecによってサポートされました。このRFCは、IPWAVE WGの見解を反映しており、必ずしもEURECOM産業メンバーの公式のポリシーや立場を反映しているわけではありません。
Contributors
貢献者
Christian Huitema and Tony Li contributed to this document.
Christian HuitemaとTony Liがこのドキュメントに貢献しました。
Romain Kuntz contributed extensively regarding IPv6 handovers between links running outside the context of a BSS (802.11-OCB links).
Romain Kuntzは、BSS（802.11-OCBリンク）のコンテキストの外で実行されているリンク間のIPv6ハンドオーバーに関して広範囲に貢献しました。
Tim Leinmueller contributed the idea of the use of IPv6 over 802.11-OCB for the distribution of certificates.
Tim Leinmuellerは、証明書の配布に802.11-OCBでIPv6を使用するという考えに貢献しました。
Marios Makassikis, Jose Santa Lozano, Albin Severinson, and Alexey Voronov provided significant feedback on the experience of using IP messages over 802.11-OCB in initial trials.
Marios Makassikis、Jose Santa Lozano、Albin Severinson、およびAlexey Voronovは、最初の試験で802.11-OCBを介してIPメッセージを使用した経験について重要なフィードバックを提供しました。
Michelle Wetterwald contributed extensively to the MTU discussion, offered the ETSI ITS perspective, and reviewed other parts of the document.
Michelle WetterwaldはMTUの議論に広く貢献し、ETSI ITSの見方を提供し、ドキュメントの他の部分をレビューしました。
Authors' Addresses
著者のアドレス
Nabil Benamar Moulay Ismail University of Meknes Morocco
ナビルベナマールムーレイイスマイル大学メクネスモロッコ
Phone: +212670832236
Email: n.benamar@est.umi.ac.ma
Jérôme Härri EURECOM 06904 Sophia-Antipolis France
JérômeHärriEURECOM 06904ソフィアアンティポリスフランス
Phone: +33493008134
Email: Jerome.Haerri@eurecom.fr
Jong-Hyouk Lee Sangmyung University 31, Sangmyeongdae-gil, Dongnam-gu Cheonan 31066 Republic of Korea
Jong-Hyouk Lee Sangmyung University 31、Songmyeongdae-gil、Dongnam-gu Cheonan 31066大韓民国
Email: jonghyouk@smu.ac.kr
Thierry ERNST YoGoKo 1137A Avenue des Champs-Blancs 35510 CESON-SEVIGNE France
ティエリーERNST YoGoKo 1137A Avenue des Champs-Blancs 35510 CESON-SEVIGNEフランス
Email: thierry.ernst@yogoko.fr