draft-ietf-ipwave-ipv6-over-80211ocb-08.txt		draft-ietf-ipwave-ipv6-over-80211ocb-09.txt
	Network Working Group A. Petrescu		Network Working Group A. Petrescu
	Internet-Draft CEA, LIST		Internet-Draft CEA, LIST
	Intended status: Standards Track N. Benamar		Intended status: Standards Track N. Benamar
	Expires: March 23, 2018 Moulay Ismail University		Expires: April 9, 2018 Moulay Ismail University
	J. Haerri		J. Haerri
	Eurecom		Eurecom
	C. Huitema
	Private Octopus Inc.
	J. Lee		J. Lee
	Sangmyung University		Sangmyung University
	T. Ernst		T. Ernst
	YoGoKo		YoGoKo
	T. Li		October 6, 2017
	Peloton Technology
	September 19, 2017
	Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode		Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode
	Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)		Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
	draft-ietf-ipwave-ipv6-over-80211ocb-08.txt		draft-ietf-ipwave-ipv6-over-80211ocb-09.txt
	Abstract		Abstract
	In order to transmit IPv6 packets on IEEE 802.11 networks running		In order to transmit IPv6 packets on IEEE 802.11 networks running
	outside the context of a basic service set (OCB, earlier "802.11p")		outside the context of a basic service set (OCB, earlier "802.11p")
	there is a need to define a few parameters such as the supported		there is a need to define a few parameters such as the supported
	Maximum Transmission Unit size on the 802.11-OCB link, the header		Maximum Transmission Unit size on the 802.11-OCB link, the header
	format preceding the IPv6 header, the Type value within it, and		format preceding the IPv6 header, the Type value within it, and
	others. This document describes these parameters for IPv6 and IEEE		others. This document describes these parameters for IPv6 and IEEE
	802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB		802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
	similarly to other known 802.11 and Ethernet layers - by using an		similarly to other known 802.11 and Ethernet layers - by using an
	Ethernet Adaptation Layer.		Ethernet Adaptation Layer.
	In addition, the document lists what is different in 802.11-OCB
	(802.11p) links compared to more 'traditional' 802.11a/b/g/n links,
	where IPv6 protocols operate without issues. Most notably, the
	operation outside the context of a BSS (OCB) impacts IPv6 handover
	behaviour and IPv6 security.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 23, 2018.		This Internet-Draft will expire on April 9, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Communication Scenarios where IEEE 802.11-OCB Links are Used 7		3. Communication Scenarios where IEEE 802.11-OCB Links are Used 4
	4. Aspects introduced by the OCB mode to 802.11 . . . . . . . . 7		4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 5
	5. Layering of IPv6 over 802.11-OCB as over Ethernet . . . . . . 11		4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5
	5.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 11		4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5
	5.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 11		4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 6
	5.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 12		4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 8
	5.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 14		4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 8
	5.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 14		4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 8
	5.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 14		4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 8
	5.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 15		4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 8
	5.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 16		4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 9
	5.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 17		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		9.1. Normative References . . . . . . . . . . . . . . . . . . 11
	10.1. Normative References . . . . . . . . . . . . . . . . . . 19		9.2. Informative References . . . . . . . . . . . . . . . . . 14
	10.2. Informative References . . . . . . . . . . . . . . . . . 22		Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 16
	Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 23		Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 20
	Appendix B. Changes Needed on a software driver 802.11a to		Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 20
	become a 802.11-OCB driver . . . 28		Appendix D. Changes Needed on a software driver 802.11a to
			become a 802.11-OCB driver . . . 25
			Appendix E. EPD . . . . . . . . . . . . . . . . . . . . . . . . 26
			Appendix F. Design Considerations . . . . . . . . . . . . . . . 26
			F.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 27
			F.2. Reliability Requirements . . . . . . . . . . . . . . . . 27
			F.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 28
			F.4. MAC Address Generation . . . . . . . . . . . . . . . . . 29
	Appendix C. Design Considerations . . . . . . . . . . . . . . . 29		Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 29
	C.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 29		Appendix H. Implementation Status . . . . . . . . . . . . . . . 29
	C.2. Reliability Requirements . . . . . . . . . . . . . . . . 30		H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 30
	C.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 30		H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 33
	C.4. MAC Address Generation . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
	Appendix D. IEEE 802.11 Messages Transmitted in OCB mode . . . . 32
	Appendix E. Implementation Status . . . . . . . . . . . . . . . 32
	E.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 33
	E.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 35
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
	1. Introduction		1. Introduction
	This document describes the transmission of IPv6 packets on IEEE Std		This document describes the transmission of IPv6 packets on IEEE Std
	802.11-OCB networks (a.k.a 802.11p) [IEEE-802.11-2016]. This		802.11-OCB networks [IEEE-802.11-2016] (a.k.a "802.11p" see
	involves the layering of IPv6 networking on top of the IEEE 802.11		Appendix B). This involves the layering of IPv6 networking on top of
	MAC layer (with an LLC layer). Compared to running IPv6 over the		the IEEE 802.11 MAC layer, with an LLC layer. Compared to running
	Ethernet MAC layer, there is no modification expected to IEEE Std		IPv6 over the Ethernet MAC layer, there is no modification expected
	802.11 MAC and Logical Link sublayers: IPv6 works fine directly over		to IEEE Std 802.11 MAC and Logical Link sublayers: IPv6 works fine
	802.11-OCB too (with an LLC layer).		directly over 802.11-OCB too, with an LLC layer.
	The term "802.11p" is an earlier definition. The behaviour of
	"802.11p" networks is rolled in the document IEEE Std 802.11-2016.
	In that document the term 802.11p disappears. Instead, each 802.11p
	feature is conditioned by the Management Information Base (MIB)
	attribute "OCBActivated". 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 basic service set 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.
	The IPv6 network layer operates on 802.11-OCB in the same manner as		The IPv6 network layer operates on 802.11-OCB in the same manner as
	it operates on 802.11 WiFi, with a few particular exceptions. The		operating on Ethernet, but there are two kinds of exceptions:
	IPv6 network layer operates on WiFi by involving an Ethernet
	Adaptation Layer; this Ethernet Adaptation Layer maps 802.11 headers
	to Ethernet II headers. The operation of IP on Ethernet is described
	in [RFC1042], [RFC2464] and [I-D.hinden-6man-rfc2464bis]. The
	situation of IPv6 networking layer on Ethernet Adaptation Layer is
	illustrated below:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv6 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Ethernet Adaptation Layer |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 802.11 WiFi MAC |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 802.11 WiFi PHY |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	(in the above figure, a WiFi profile is represented; this is used
	also for OCB profile.)
	A more theoretical and detailed view of layer stacking, and
	interfaces between the IP layer and 802.11-OCB layers, is illustrated
	below. The IP layer operates on top of the EtherType Protocol
	Discrimination (EPD); this Discrimination layer is described in IEEE
	Std 802.3-2012; the interface between IPv6 and EPD is the LLC_SAP
	(Link Layer Control Service Access Point).
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	In addition to the description of interface between IP and MAC using
	"Ethernet Adaptation Layer" and "Ethernet Protocol Discrimination
	(EPD)" it is worth mentioning that SNAP [RFC1042] is used to carry
	the IPv6 Ethertype.
	However, there may be some deployment considerations helping optimize
	the performances of running IPv6 over 802.11-OCB (e.g. in the case of
	handovers between 802.11-OCB-enabled access routers, or the
	consideration of using the IP security architecture [RFC4301]).
	There are currently no specifications for handover between OCB links
	since these are currently specified as LLC-1 links (i.e.
	connectionless). Any handovers must be performed above the Data Link
	Layer. To realize handovers between OCB links there is a need for
	specific indicators to assist in the handover process. The
	indicators may be IP Router Advertisements, or 802.11-OCB's Time
	Advertisements, or application-layer data. However, this document
	does not describe handover behaviour.
	The OCB operation is stripped off of all existing 802.11 link-layer
	security mechanisms. There is no encryption applied below the
	network layer running on 802.11-OCB. At application layer, the IEEE
	1609.2 document [IEEE-1609.2] does provide security services for
	certain applications to use; application-layer mechanisms are out-of-
	scope of this document. On another hand, a security mechanism
	provided at networking layer, such as IPsec [RFC4301], may provide
	data security protection to a wider range of applications. See the
	section Security Considerations of this document, Section 6
	We briefly introduce the vehicular communication scenarios where IEEE
	802.11-OCB links are used. This is followed by a description of
	differences in specification terms, between 802.11-OCB and
	802.11a/b/g/n - we answer the question of what are the aspects
	introduced by OCB mode to 802.11; the same aspects, but expressed in
	terms of requirements to implementation, are listed in Appendix B.)
	The document then concentrates on the parameters of layering IP over		o Exceptions due to different operation of IPv6 network layer on
	802.11-OCB as over Ethernet: value of MTU, the Frame Format which		802.11 than on Ethernet. To satisfy these exceptions, this
	includes a description of an Ethernet Adaptation Layer, the forming		document describes an Ethernet Adaptation Layer between Ethernet
	of Link-Local Addresses the rules for forming Interface Identifiers		headers and 802.11 headers. The Ethernet Adaptation Layer is
	for Stateless Autoconfiguration, the mechanisms for Address Mapping.		described Section 4.2.1. The operation of IP on Ethernet is
	These are precisely the same as IPv6 over Ethernet [RFC2464]. A		described in [RFC1042], [RFC2464] and
	reference is made to ad-hoc networking characteristics of the subnet		[I-D.hinden-6man-rfc2464bis].
	structure in OCB mode.
	As an example, these characteristics of layering IPv6 straight over		o Exceptions due to the OCB nature of 802.11-OCB compared to 802.11.
	LLC over 802.11-OCB MAC are illustrated by dissecting an IPv6 packet		This has impacts on security, privacy, subnet structure and
	captured over a 802.11-OCB link; this is described in the section		handover behaviour. For security and privacy recommendations see
	Appendix E.		Section 5 and Section 4.5. The subnet structure is described in
			Section 4.6; a new Group ID is requested to be used in such
			subnets, see section Section 6. The handover behaviour on OCB
			links is not described in this document.
	In the published literature, many documents describe aspects related		In the published literature, many documents describe aspects and
	to running IPv6 over 802.11-OCB:		problems related to running IPv6 over 802.11-OCB:
	[I-D.jeong-ipwave-vehicular-networking-survey].		[I-D.ietf-ipwave-vehicular-networking-survey].
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
			WiFi: Wireless Fidelity.
	OBRU (On-Board Router Unit): an OBRU is almost always situated in a		OBRU (On-Board Router Unit): an OBRU is almost always situated in a
	vehicle; it is a computer with at least two IP interfaces; at least		vehicle; it is a computer with at least two IP interfaces; at least
	one IP interface runs in OCB mode of 802.11. It MAY be an IP Router.		one IP interface runs in OCB mode of 802.11. It MAY be an IP Router.
	RSRU (Road-Side Router Unit): an RSRU is almost always situated in a		RSRU (Road-Side Router Unit): an RSRU is almost always situated in a
	box fixed along the road. An RSRU has at least two distinct IP-		box fixed along the road. An RSRU has at least two distinct IP-
	enabled interfaces; at least one interface is operated in mode OCB of		enabled interfaces; at least one interface is operated in mode OCB of
	IEEE 802.11 and is IP-enabled. An RSRU is similar to a Wireless		IEEE 802.11 and is IP-enabled. An RSRU is similar to a Wireless
	Termination Point (WTP), as defined in [RFC5415], or an Access Point		Termination Point (WTP), as defined in [RFC5415], or an Access Point
	(AP), as defined in IEEE documents, or an Access Network Router (ANR)		(AP), as defined in IEEE documents, or an Access Network Router (ANR)
	defined in [RFC3753], with one key particularity: the wireless PHY/		defined in [RFC3753], with one key particularity: the wireless PHY/
	MAC layer of at least one of its IP-enabled interfaces is configured		MAC layer of at least one of its IP-enabled interfaces is configured
	to operate in 802.11-OCB mode. The RSRU communicates with the On		to operate in 802.11-OCB mode. The RSRU communicates with the On
	board Unit (OBRU) in the vehicle over 802.11 wireless link operating		board Unit (OBRU) in the vehicle over 802.11 wireless link operating
	in OCB mode. An RSRU MAY be connected to the Internet, and MAY be an		in OCB mode. An RSRU MAY be connected to the Internet, and MAY be an
	IP Router. When it is connected to the Internet, the term V2I		IP Router. When it is connected to the Internet, the term V2I
	(Vehicle to Internet) is relevant.		(Vehicle to Internet) is relevant.
	RSU (Road-Side Unit): an RSU operates in 802.11-OCB mode. A RSU		RSU (Road-Side Unit): an RSU operates in 802.11-OCB mode. A RSU
	broadcasts data to OBUs or exchanges data with OBUs in its		broadcasts data to OBUs or exchanges data with OBUs in its
	communications zone. An RSU may provides channel assignments and		communications zone. An RSU may provide channel assignments and
	operating instructions to OBUs in its communications zone, when		operating instructions to OBUs in its communications zone, when
	required. The basic functional blocks of an RSU are: internal		required. The basic functional blocks of an RSU are: internal
	computer processing, permanent storage capability, an integrated GPS		computer processing, permanent storage capability, an integrated GPS
	receiver for positioning and timing and an interface that supports		receiver for positioning and timing and an interface that supports
	both IPv4 and IPv6 connectivity, compliant with 802.3at. An OCB		both IPv4 and IPv6 connectivity, compliant with 802.3at. An OCB
	interface of an RSU MAY be IP-enabled simultaneously to being WAVE-		interface of an RSU MAY be IP-enabled simultaneously to being WAVE-
	enabled or GeoNetworking-enabled (MAY support simultaneously		enabled or GeoNetworking-enabled (MAY support simultaneously
	EtherTypes 0x86DD for IPv6 _and_ 0x88DC for WAVE and 0x8947 for		EtherTypes 0x86DD for IPv6 _and_ 0x88DC for WAVE and 0x8947 for
	GeoNetworking).		GeoNetworking).
	skipping to change at page 7, line 25 ¶		skipping to change at page 5, line 19 ¶
	vehicular networks, STAs can be RSRUs and/or OBRUs. While 802.11-OCB		vehicular networks, STAs can be RSRUs and/or OBRUs. While 802.11-OCB
	is clearly specified, and the use of IPv6 over such link is not		is clearly specified, and the use of IPv6 over such link is not
	radically new, the operating environment (vehicular networks) brings		radically new, the operating environment (vehicular networks) brings
	in new perspectives.		in new perspectives.
	The 802.11-OCB links form and terminate; nodes connected to these		The 802.11-OCB links form and terminate; nodes connected to these
	links peer, and discover each other; the nodes are mobile. However,		links peer, and discover each other; the nodes are mobile. However,
	the precise description of how links discover each other, peer and		the precise description of how links discover each other, peer and
	manage mobility is not given in this document.		manage mobility is not given in this document.
	4. Aspects introduced by the OCB mode to 802.11		4. IPv6 over 802.11-OCB
	In the IEEE 802.11-OCB mode, all nodes in the wireless range can
	directly communicate with each other without involving authentication
	or association procedures. At link layer, it is necessary to set the
	same channel number (or frequency) on two stations that need to
	communicate with each other. Stations STA1 and STA2 can exchange IP
	packets if they are set on the same channel. At IP layer, they then
	discover each other by using the IPv6 Neighbor Discovery protocol.
	Briefly, the IEEE 802.11-OCB mode has the following properties:
	o The use by each node of a 'wildcard' BSSID (i.e., each bit of the
	BSSID is set to 1)
	o No IEEE 802.11 Beacon frames are transmitted
	o No authentication is required in order to be able to communicate
	o No association is needed in order to be able to communicate
	o No encryption is provided in order to be able to communicate
	o Flag dot11OCBActivated is set to true
	All the nodes in the radio communication range (OBRU and RSRU)
	receive all the messages transmitted (OBRU and RSRU) within the radio
	communications range. The eventual conflict(s) are resolved by the
	MAC CDMA function.
	The following message exchange diagram 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. For information, the names of
	these messages as currently specified by the 802.11 standard are
	listed in Appendix D.
	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 -------->|
	(a) 802.11 Infrastructure mode (b) 802.11-OCB mode
	The interface 802.11-OCB was specified in IEEE Std 802.11p (TM) -2010
	[IEEE-802.11p-2010] as an amendment to IEEE Std 802.11 (TM) -2007,
	titled "Amendment 6: Wireless Access in Vehicular Environments".
	Since then, this amendment has been included in IEEE 802.11(TM) -2012
	and -2016 [IEEE-802.11-2016].
	In document 802.11-2016, anything qualified specifically as
	"OCBActivated", or "outside the context of a basic service" set to be
	true, then it is actually referring to OCB aspects introduced to
	802.11.
	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 which 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 just like 'a, b, g' and 'n' are, 'p' is
	concerned more with MAC modifications, and a little 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 OFDM at 5.4GHz and
	5.9GHz.
	The 802.11-OCB links are specified to be compatible as much as
	possible with the behaviour 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 the WiFi and Ethernet
	layers do (802.11a/b/g/n and 802.3). A packet sent by an OBRU may be
	received by one or multiple RSRUs. The link-layer resolution is
	performed by using the IPv6 Neighbor Discovery protocol.
	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 layered on top of LLC on
	top of 802.3 (for Ethernet)) it is useful to analyze the differences
	between 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 little to the PHY layer), there
	are only a few characteristics which may be important for an
	implementation transmitting IPv6 packets on 802.11-OCB links.
	The most important 802.11-OCB point which 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: 20 MHz channel;
	modulation 64-QAM; codint rate R is 3/4); in practice of IP-over-
	802.11-OCB a commonly observed figure is 12Mbit/s; this bandwidth
	allows the operation of a wide range of protocols relying on IPv6.
	o Operation Outside the Context of a BSS (OCB): the (earlier
	802.11p) 802.11-OCB links are operated without a Basic Service Set
	(BSS). This means that the frames IEEE 802.11 Beacon, Association
	Request/Response, Authentication Request/Response, and similar,
	are not used. The used identifier of BSS (BSSID) has a
	hexadecimal value always 0xffffffffffff (48 '1' bits, represented
	as MAC address ff:ff:ff:ff:ff:ff, or otherwise the 'wildcard'
	BSSID), as opposed to an arbitrary BSSID value set by
	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.
	o Timing Advertisement: is a new message defined in 802.11-OCB,
	which 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 as delivered by a GNSS system (Galileo, GPS,
	...) or by a cellular system. This message is optional for
	implementation.
	o Frequency range: this is a characteristic of the PHY layer, with
	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, 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.9GHz". The 5.9GHz band is different from the
	2.4GHz and 5GHz bands used by Wireless LAN. However, as with
	Wireless LAN, the operation of 802.11-OCB in "5.9GHz" bands is
	exempt from owning a license in EU (in US the 5.9GHz is a licensed
	band of spectrum; for the fixed infrastructure an explicit FCC
	autorization is required; for an onboard device a 'licensed-by-
	rule' concept applies: rule certification conformity is required);
	however technical conditions are different than those of the bands
	"2.4GHz" or "5GHz". On one hand, the allowed power levels, and
	implicitly the maximum allowed distance between vehicles, is of
	33dBm 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 1km, compared to approximately 50m. On the other
	hand, specific conditions related to congestion avoidance, jamming
	avoidance, and radar detection are imposed on the use of DSRC (in
	US) and on the use of frequencies for Intelligent Transportation
	Systems (in EU), compared to Wireless LAN (802.11a/b/g/n).
	o 'Half-rate' encoding: as the frequency range, this parameter is
	related to PHY, and thus has not much impact on the interface
	between the IP layer and the MAC layer.
	o 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 exists a strong
	need for dynamic change of these addresses (as opposed to the non-
	vehicular settings - real wall protection - where fixed MAC
	addresses do not currently pose some privacy risks). This is
	further described in section Section 6. A relevant function is
	described in IEEE 1609.3-2016 [IEEE-1609.3], clause 5.5.1 and IEEE
	1609.4-2016 [IEEE-1609.4], clause 6.7.
	Other aspects particular to 802.11-OCB, which are also particular to
	802.11 (e.g. the 'hidden node' operation), may have an influence on
	the use of transmission of IPv6 packets on 802.11-OCB networks. The
	OCB subnet structure is described in section Section 5.6.
	5. Layering of IPv6 over 802.11-OCB as over Ethernet
	5.1. Maximum Transmission Unit (MTU)		4.1. Maximum Transmission Unit (MTU)
	The default MTU for IP packets on 802.11-OCB is 1500 octets. It is		The default MTU for IP packets on 802.11-OCB is 1500 octets. It is
	the same value as IPv6 packets on Ethernet links, as specified in		the same value as IPv6 packets on Ethernet links, as specified in
	[RFC2464]. This value of the MTU respects the recommendation that		[RFC2464]. This value of the MTU respects the recommendation that
	every link in the Internet must have a minimum MTU of 1280 octets		every link on the Internet must have a minimum MTU of 1280 octets
	(stated in [RFC8200], and the recommendations therein, especially		(stated in [RFC8200], and the recommendations therein, especially
	with respect to fragmentation). If IPv6 packets of size larger than		with respect to fragmentation). If IPv6 packets of size larger than
	1500 bytes are sent on an 802.11-OCB interface card then the IP stack		1500 bytes are sent on an 802.11-OCB interface card then the IP stack
	will fragment. In case there are IP fragments, the field "Sequence		will fragment. In case there are IP fragments, the field "Sequence
	number" of the 802.11 Data header containing the IP fragment field is		number" of the 802.11 Data header containing the IP fragment field is
	increased.		increased.
	Non-IP packets such as WAVE Short Message Protocol (WSMP) can be		Non-IP packets such as WAVE Short Message Protocol (WSMP) can be
	delivered on 802.11-OCB links. Specifications of these packets are		delivered on 802.11-OCB links. Specifications of these packets are
	out of scope of this document, and do not impose any limit on the MTU		out of scope of this document, and do not impose any limit on the MTU
	size, allowing an arbitrary number of 'containers'. Non-IP packets		size, allowing an arbitrary number of 'containers'. Non-IP packets
	such as ETSI GeoNetworking packets have an MTU of 1492 bytes. The		such as ETSI GeoNetworking packets have an MTU of 1492 bytes. The
	operation of IPv6 over GeoNetworking is specified at		operation of IPv6 over GeoNetworking is specified at
	[ETSI-IPv6-GeoNetworking].		[ETSI-IPv6-GeoNetworking].
	5.2. Frame Format		4.2. Frame Format
	IP packets are transmitted over 802.11-OCB as standard Ethernet		IP packets are transmitted over 802.11-OCB as standard Ethernet
	packets. As with all 802.11 frames, an Ethernet adaptation layer is		packets. As with all 802.11 frames, an Ethernet adaptation layer is
	used with 802.11-OCB as well. This Ethernet Adaptation Layer		used with 802.11-OCB as well. This Ethernet Adaptation Layer
	performing 802.11-to-Ethernet is described in Section 5.2.1. The		performing 802.11-to-Ethernet is described in Section 4.2.1. The
	Ethernet Type code (EtherType) for IPv6 is 0x86DD (hexadecimal 86DD,		Ethernet Type code (EtherType) for IPv6 is 0x86DD (hexadecimal 86DD,
	or otherwise #86DD).		or otherwise #86DD).
	The Frame format for transmitting IPv6 on 802.11-OCB networks is the		The Frame format for transmitting IPv6 on 802.11-OCB networks is the
	same as transmitting IPv6 on Ethernet networks, and is described in		same as transmitting IPv6 on Ethernet networks, and is described in
	section 3 of [RFC2464]. The frame format for transmitting IPv6		section 3 of [RFC2464].
	packets over Ethernet is illustrated below:
	0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Destination |
	+- -+
	| Ethernet |
	+- -+
	| Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source |
	+- -+
	| Ethernet |
	+- -+
	| Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv6 |
	+- -+
	| header |
	+- -+
	| and |
	+- -+
	/ payload ... /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	(Each tic mark represents one bit.)
	Ethernet II Fields:
	Destination Ethernet Address
	the MAC destination address.
	Source Ethernet Address
	the MAC source address.
	1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1		1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1
	binary representation of the EtherType value 0x86DD.		is the binary representation of the EtherType value 0x86DD.
	IPv6 header and payload
	the IPv6 packet containing IPv6 header and payload.
	5.2.1. Ethernet Adaptation Layer		4.2.1. Ethernet Adaptation Layer
	In general, an 'adaptation' layer is inserted between a MAC layer and		An 'adaptation' layer is inserted between a MAC layer and the
	the Networking layer. This is used to transform some parameters		Networking layer. This is used to transform some parameters between
	between their form expected by the IP stack and the form provided by		their form expected by the IP stack and the form provided by the MAC
	the MAC layer. For example, an 802.15.4 adaptation layer may perform		layer.
	fragmentation and reassembly operations on a MAC whose maximum Packet
	Data Unit size is smaller than the minimum MTU recognized by the IPv6
	Networking layer. Other examples involve link-layer address
	transformation, packet header insertion/removal, and so on.
	An Ethernet Adaptation Layer makes an 802.11 MAC look to IP		An Ethernet Adaptation Layer makes an 802.11 MAC look to IP
	Networking layer as a more traditional Ethernet layer. At reception,		Networking layer as a more traditional Ethernet layer. At reception,
	this layer takes as input the IEEE 802.11 Data Header and the		this layer takes as input the IEEE 802.11 Data Header and the
	Logical-Link Layer Control Header and produces an Ethernet II Header.		Logical-Link Layer Control Header and produces an Ethernet II Header.
	At sending, the reverse operation is performed.		At sending, the reverse operation is performed.
	+--------------------+------------+-------------+---------+-----------+		+--------------------+------------+-------------+---------+-----------+
	| 802.11 Data Header | LLC Header | IPv6 Header | Payload |.11 Trailer|		| 802.11 Data Header | LLC Header | IPv6 Header | Payload |.11 Trailer|
	+--------------------+------------+-------------+---------+-----------+		+--------------------+------------+-------------+---------+-----------+
	\ / \ /		\ / \ /
	----------------------------- --------		----------------------------- --------
	^---------------------------------------------/		\---------------------------------------------/
	|		^
	802.11-to-Ethernet Adaptation Layer		|
	|		802.11-to-Ethernet Adaptation Layer
	v		|
			v
	+---------------------+-------------+---------+		+---------------------+-------------+---------+
	| Ethernet II Header | IPv6 Header | Payload |		| Ethernet II Header | IPv6 Header | Payload |
	+---------------------+-------------+---------+		+---------------------+-------------+---------+
	The Receiver and Transmitter Address fields in the 802.11 Data Header		The Receiver and Transmitter Address fields in the 802.11 Data Header
	contain the same values as the Destination and the Source Address		contain the same values as the Destination and the Source Address
	fields in the Ethernet II Header, respectively. The value of the		fields in the Ethernet II Header, respectively. The value of the
	Type field in the LLC Header is the same as the value of the Type		Type field in the LLC Header is the same as the value of the Type
	field in the Ethernet II Header.		field in the Ethernet II Header.
	The ".11 Trailer" contains solely a 4-byte Frame Check Sequence.		The ".11 Trailer" contains solely a 4-byte Frame Check Sequence.
	The Ethernet Adaptation Layer performs operations in relation to IP		Additionally, the Ethernet Adaptation Layer performs operations in
	fragmentation and MTU. One of these operations is briefly described		relation to IP fragmentation and MTU. One of these operations is
	in section Section 5.1.		briefly described in section Section 4.1.
	In OCB mode, IPv6 packets can be transmitted either as "IEEE 802.11		In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11
	Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in		Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in
	the figure below. Some commercial OCB products use 802.11 Data, and		the figure below.
	others 802.11 QoS data. In the future, both could be used.
	+--------------------+-------------+-------------+---------+-----------+		+--------------------+-------------+-------------+---------+-----------+
	| 802.11 Data Header | LLC Header | IPv6 Header | Payload |.11 Trailer|		| 802.11 Data Header | LLC Header | IPv6 Header | Payload |.11 Trailer|
	+--------------------+-------------+-------------+---------+-----------+		+--------------------+-------------+-------------+---------+-----------+
	or		or
	+--------------------+-------------+-------------+---------+-----------+		+--------------------+-------------+-------------+---------+-----------+
	| 802.11 QoS Data Hdr| LLC Header | IPv6 Header | Payload |.11 Trailer|		| 802.11 QoS Data Hdr| LLC Header | IPv6 Header | Payload |.11 Trailer|
	+--------------------+-------------+-------------+---------+-----------+		+--------------------+-------------+-------------+---------+-----------+
	skipping to change at page 14, line 27 ¶		skipping to change at page 7, line 31 ¶
	802.11 Data header is 0x0020. The value of the field "Type/Subtype"		802.11 Data header is 0x0020. The value of the field "Type/Subtype"
	in the 802.11 QoS header is 0x0028.		in the 802.11 QoS header is 0x0028.
	The mapping between qos-related fields in the IPv6 header (e.g.		The mapping between qos-related fields in the IPv6 header (e.g.
	"Traffic Class", "Flow label") and fields in the "802.11 QoS Data		"Traffic Class", "Flow label") and fields in the "802.11 QoS Data
	Header" (e.g. "QoS Control") are not specified in this document.		Header" (e.g. "QoS Control") are not specified in this document.
	Guidance for a potential mapping is provided in		Guidance for a potential mapping is provided in
	[I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB		[I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB
	mode.		mode.
	5.3. Link-Local Addresses		The placement of IPv6 networking layer on Ethernet Adaptation Layer
			is illustrated below:
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IPv6 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Ethernet Adaptation Layer |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 802.11 WiFi MAC |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 802.11 WiFi PHY |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			(in the above figure, a WiFi profile is represented; this is used
			also for OCB profile.)
			Other alternative views of layering are EtherType Protocol
			Discrimination (EPD), see Appendix E, and SNAP see [RFC1042].
			4.3. Link-Local Addresses
	The link-local address of an 802.11-OCB interface is formed in the		The link-local address of an 802.11-OCB interface is formed in the
	same manner as on an Ethernet interface. This manner is described in		same manner as on an Ethernet interface. This manner is described in
	section 5 of [RFC2464]. Additionally, if stable identifiers are		section 5 of [RFC2464]. Additionally, if stable identifiers are
	needed, it is recommended to follow the Recommendation on Stable IPv6		needed, it is recommended to follow the Recommendation on Stable IPv6
	Interface Identifiers [RFC8064]. Additionally, if semantically		Interface Identifiers [RFC8064]. Additionally, if semantically
	opaque Interface Identifiers are needed, a potential method for		opaque Interface Identifiers are needed, a potential method for
	generating semantically opaque Interface Identifiers with IPv6		generating semantically opaque Interface Identifiers with IPv6
	Stateless Address Autoconfiguration is given in [RFC7217].		Stateless Address Autoconfiguration is given in [RFC7217].
	5.4. Address Mapping		4.4. Address Mapping
	For unicast as for multicast, there is no change from the unicast and		For unicast as for multicast, there is no change from the unicast and
	multicast address mapping format of Ethernet interfaces, as defined		multicast address mapping format of Ethernet interfaces, as defined
	by sections 6 and 7 of [RFC2464].		by sections 6 and 7 of [RFC2464].
	5.4.1. Address Mapping -- Unicast		4.4.1. Address Mapping -- Unicast
	The procedure for mapping IPv6 unicast addresses into Ethernet link-		The procedure for mapping IPv6 unicast addresses into Ethernet link-
	layer addresses is described in [RFC4861]. The Source/Target Link-		layer addresses is described in [RFC4861].
	layer Address option has the following form when the link-layer is
	Ethernet.
	0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	+- Ethernet -+
	| |
	+- Address -+
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Option fields:
	Type
	1 for Source Link-layer address.
	2 for Target Link-layer address.
	Length
	1 (in units of 8 octets).
	Ethernet Address
	The 48 bit Ethernet IEEE 802 address, in canonical bit order.
	5.4.2. Address Mapping -- Multicast
	IPv6 protocols often make use of IPv6 multicast addresses in the
	destination field of IPv6 headers. For example, an ICMPv6 link-
	scoped Neighbor Advertisement is sent to the IPv6 address ff02::1
	denoted "all-nodes" address. When transmitting these packets on
	802.11-OCB links it is necessary to map the IPv6 address to a MAC
	address.
	The same mapping requirement applies to the link-scoped multicast
	addresses of other IPv6 protocols as well. In DHCPv6, the
	"All_DHCP_Servers" IPv6 multicast address ff02::1:2, and in OSPF the
	"All_SPF_Routers" IPv6 multicast address ff02::5, need to be mapped
	on a multicast MAC address.
	An IPv6 packet with a multicast destination address DST, consisting
	of the sixteen octets DST[1] through DST[16], is transmitted to the
	IEEE 802.11-OCB MAC multicast address whose first two octets are the
	value 0x3333 and whose last four octets are the last four octets of
	DST.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		4.4.2. Address Mapping -- Multicast
	|0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DST[13] | DST[14] |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DST[15] | DST[16] |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	A Group ID named TBD, of length 112bits is requested to IANA; this		A Group ID named TBD, of length 112bits is requested to IANA; this
	Group ID signifies "All 80211OCB Interfaces Address". Only the least		Group ID signifies "All 80211OCB Interfaces Address". Only the least
	32 significant bits of this "All 80211OCB Interfaces Address" will be		32 significant bits of this "All 80211OCB Interfaces Address" will be
	mapped to and from a MAC multicast address.		mapped to and from a MAC multicast address.
	Transmitting IPv6 packets to multicast destinations over 802.11 links		Transmitting IPv6 packets to multicast destinations over 802.11 links
	proved to have some performance issues		proved to have some performance issues
	[I-D.perkins-intarea-multicast-ieee802]. These issues may be		[I-D.perkins-intarea-multicast-ieee802]. These issues may be
	exacerbated in OCB mode. Solutions for these problems should		exacerbated in OCB mode. Solutions for these problems should
	consider the OCB mode of operation.		consider the OCB mode of operation.
	5.5. Stateless Autoconfiguration		4.5. Stateless Autoconfiguration
	The Interface Identifier for an 802.11-OCB interface is formed using		The Interface Identifier for an 802.11-OCB interface is formed using
	the same rules as the Interface Identifier for an Ethernet interface;		the same rules as the Interface Identifier for an Ethernet interface;
	this is described in section 4 of [RFC2464]. No changes are needed,		this is described in section 4 of [RFC2464]. No changes are needed,
	but some care must be taken when considering the use of the SLAAC		but some care must be taken when considering the use of the Stateless
	procedure.		Address Auto-Configuration procedure.
	The bits in the the interface identifier have no generic meaning and		The bits in the interface identifier have no generic meaning and the
	the identifier should be treated as an opaque value. The bits		identifier should be treated as an opaque value. The bits
	'Universal' and 'Group' in the identifier of an 802.11-OCB interface		'Universal' and 'Group' in the identifier of an 802.11-OCB interface
	are significant, as this is an IEEE link-layer address. The details		are significant, as this is an IEEE link-layer address. The details
	of this significance are described in [RFC7136].		of this significance are described in [RFC7136].
	As with all Ethernet and 802.11 interface identifiers ([RFC7721]),		As with all Ethernet and 802.11 interface identifiers ([RFC7721]),
	the identifier of an 802.11-OCB interface may involve privacy, MAC		the identifier of an 802.11-OCB interface may involve privacy, MAC
	address spoofing and IP address hijacking risks. A vehicle embarking		address spoofing and IP address hijacking risks. A vehicle embarking
	an On-Board Unit whose egress interface is 802.11-OCB may expose		an On-Board Unit whose egress interface is 802.11-OCB may expose
	itself to eavesdropping and subsequent correlation of data; this may		itself to eavesdropping and subsequent correlation of data; this may
	reveal data considered private by the vehicle owner; there is a risk		reveal data considered private by the vehicle owner; there is a risk
	of being tracked; see the privacy considerations described in		of being tracked; see the privacy considerations described in
	Appendix C.		Appendix F.
	If stable Interface Identifiers are needed in order to form IPv6		If stable Interface Identifiers are needed in order to form IPv6
	addresses on 802.11-OCB links, it is recommended to follow the		addresses on 802.11-OCB links, it is recommended to follow the
	recommendation in [RFC8064]. Additionally, if semantically opaque		recommendation in [RFC8064]. Additionally, if semantically opaque
	Interface Identifiers are needed, a potential method for generating		Interface Identifiers are needed, a potential method for generating
	semantically opaque Interface Identifiers with IPv6 Stateless Address		semantically opaque Interface Identifiers with IPv6 Stateless Address
	Autoconfiguration is given in [RFC7217].		Autoconfiguration is given in [RFC7217].
	5.6. Subnet Structure		4.6. Subnet Structure
	A subnet is formed by the external 802.11-OCB interfaces of vehicles		A subnet is formed by the external 802.11-OCB interfaces of vehicles
	that are in close range (not their on-board interfaces). This		that are in close range (not their on-board interfaces). This
	ephemeral subnet structure is strongly influenced by the mobility of		ephemeral subnet structure is strongly influenced by the mobility of
	vehicles: the 802.11 hidden node effects appear. On another hand,		vehicles: the 802.11 hidden node effects appear. On another hand,
	the structure of the internal subnets in each car is relatively		the structure of the internal subnets in each car is relatively
	stable.		stable.
	For routing purposes, a prefix exchange mechanism could be needed
	between neighboring vehicles.
	The 802.11 networks in OCB mode may be considered as 'ad-hoc'		The 802.11 networks in OCB mode may be considered as 'ad-hoc'
	networks. The addressing model for such networks is described in		networks. The addressing model for such networks is described in
	[RFC5889].		[RFC5889].
	An addressing model involves several types of addresses, like		An addressing model involves several types of addresses, like
	Globally-unique Addresses (GUA), Link-Local Addresses (LL) and Unique		Globally-unique Addresses (GUA), Link-Local Addresses (LL) and Unique
	Local Addresses (ULA). The subnet structure in 'ad-hoc' networks may		Local Addresses (ULA). The subnet structure in 'ad-hoc' networks may
	have characteristics that lead to difficulty of using GUAs derived		have characteristics that lead to difficulty of using GUAs derived
	from a received prefix, but the LL addresses may be easier to use		from a received prefix, but the LL addresses may be easier to use
	since the prefix is constant.		since the prefix is constant.
	6. Security Considerations		5. Security Considerations
	Any security mechanism at the IP layer or above that may be carried		Any security mechanism at the IP layer or above that may be carried
	out for the general case of IPv6 may also be carried out for IPv6		out for the general case of IPv6 may also be carried out for IPv6
	operating over 802.11-OCB.		operating over 802.11-OCB.
			The OCB operation is stripped off of all existing 802.11 link-layer
			security mechanisms. There is no encryption applied below the
			network layer running on 802.11-OCB. At application layer, the IEEE
			1609.2 document [IEEE-1609.2] does provide security services for
			certain applications to use; application-layer mechanisms are out-of-
			scope of this document. On another hand, a security mechanism
			provided at networking layer, such as IPsec [RFC4301], may provide
			data security protection to a wider range of applications.
	802.11-OCB does not provide any cryptographic protection, because it		802.11-OCB does not provide any cryptographic protection, because it
	operates outside the context of a BSS (no Association Request/		operates outside the context of a BSS (no Association Request/
	Response, no Challenge messages). Any attacker can therefore just		Response, no Challenge messages). Any attacker can therefore just
	sit in the near range of vehicles, sniff the network (just set the		sit in the near range of vehicles, sniff the network (just set the
	interface card's frequency to the proper range) and perform attacks		interface card's frequency to the proper range) and perform attacks
	without needing to physically break any wall. Such a link is less		without needing to physically break any wall. Such a link is less
	protected than commonly used links (wired link or protected 802.11).		protected than commonly used links (wired link or protected 802.11).
	The potential attack vectors are: MAC address spoofing, IP address		The potential attack vectors are: MAC address spoofing, IP address
	and session hijacking and privacy violation.		and session hijacking and privacy violation.
	skipping to change at page 18, line 23 ¶		skipping to change at page 10, line 42 ¶
	possibility of attacker sniffers deployed along routes which listen		possibility of attacker sniffers deployed along routes which listen
	for IP packets of vehicles passing by. For this reason, in the		for IP packets of vehicles passing by. For this reason, in the
	802.11-OCB deployments, there is a strong necessity to use protection		802.11-OCB deployments, there is a strong necessity to use protection
	tools such as dynamically changing MAC addresses. This may help		tools such as dynamically changing MAC addresses. This may help
	mitigate privacy risks to a certain level. On another hand, it may		mitigate privacy risks to a certain level. On another hand, it may
	have an impact in the way typical IPv6 address auto-configuration is		have an impact in the way typical IPv6 address auto-configuration is
	performed for vehicles (SLAAC would rely on MAC addresses amd would		performed for vehicles (SLAAC would rely on MAC addresses amd would
	hence dynamically change the affected IP address), in the way the		hence dynamically change the affected IP address), in the way the
	IPv6 Privacy addresses were used, and other effects.		IPv6 Privacy addresses were used, and other effects.
	7. IANA Considerations		6. IANA Considerations
	A Group ID named TBD, of length 112bits is requested to IANA; this		A Group ID named TBD, of length 112bits is requested to IANA; this
	Group ID signifies "All 80211OCB Interfaces Address".		Group ID signifies "All 80211OCB Interfaces Address".
	8. Contributors		7. Contributors
			Christian Huitema, Tony Li.
	Romain Kuntz contributed extensively about IPv6 handovers between		Romain Kuntz contributed extensively about IPv6 handovers between
	links running outside the context of a BSS (802.11-OCB links).		links running outside the context of a BSS (802.11-OCB links).
	Tim Leinmueller contributed the idea of the use of IPv6 over		Tim Leinmueller contributed the idea of the use of IPv6 over
	802.11-OCB for distribution of certificates.		802.11-OCB for distribution of certificates.
	Marios Makassikis, Jose Santa Lozano, Albin Severinson and Alexey		Marios Makassikis, Jose Santa Lozano, Albin Severinson and Alexey
	Voronov provided significant feedback on the experience of using IP		Voronov provided significant feedback on the experience of using IP
	messages over 802.11-OCB in initial trials.		messages over 802.11-OCB in initial trials.
	Michelle Wetterwald contributed extensively the MTU discussion,		Michelle Wetterwald contributed extensively the MTU discussion,
	offered the ETSI ITS perspective, and reviewed other parts of the		offered the ETSI ITS perspective, and reviewed other parts of the
	document.		document.
	9. Acknowledgements		8. Acknowledgements
	The authors would like to thank Witold Klaudel, Ryuji Wakikawa,		The authors would like to thank Witold Klaudel, Ryuji Wakikawa,
	Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan		Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan
	Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray		Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray
	Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan,		Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan,
	Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne,		Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne,
	Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark,		Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark,
	Bob Moskowitz, Andrew (Dryden?), Georg Mayer, Dorothy Stanley, Sandra		Bob Moskowitz, Andrew (Dryden?), Georg Mayer, Dorothy Stanley, Sandra
	Cespedes, Mariano Falcitelli, Sri Gundavelli and William Whyte.		Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun,
	Their valuable comments clarified particular issues and generally		Margaret Cullen and William Whyte. Their valuable comments clarified
	helped to improve the document.		particular issues and generally helped to improve the document.
	Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB		Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB
	drivers for linux and described how.		drivers for linux and described how.
	For the multicast discussion, the authors would like to thank Owen		For the multicast discussion, the authors would like to thank Owen
	DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and		DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and
	participants to discussions in network working groups.		participants to discussions in network working groups.
	The authours would like to thank participants to the Birds-of-		The authours would like to thank participants to the Birds-of-
	a-Feather "Intelligent Transportation Systems" meetings held at IETF		a-Feather "Intelligent Transportation Systems" meetings held at IETF
	in 2016.		in 2016.
	10. References		9. References
	10.1. Normative References		9.1. Normative References
	[I-D.ietf-tsvwg-ieee-802-11]		[I-D.ietf-tsvwg-ieee-802-11]
	Szigeti, T., Henry, J., and F. Baker, "Diffserv to IEEE		Szigeti, T., Henry, J., and F. Baker, "Diffserv to IEEE
	802.11 Mapping", draft-ietf-tsvwg-ieee-802-11-09 (work in		802.11 Mapping", draft-ietf-tsvwg-ieee-802-11-09 (work in
	progress), September 2017.		progress), September 2017.
	[RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission		[RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission
	of IP datagrams over IEEE 802 networks", STD 43, RFC 1042,		of IP datagrams over IEEE 802 networks", STD 43, RFC 1042,
	DOI 10.17487/RFC1042, February 1988,		DOI 10.17487/RFC1042, February 1988,
	<https://www.rfc-editor.org/info/rfc1042>.		<https://www.rfc-editor.org/info/rfc1042>.
	skipping to change at page 20, line 5 ¶		skipping to change at page 12, line 27 ¶
	<https://www.rfc-editor.org/info/rfc2464>.		<https://www.rfc-editor.org/info/rfc2464>.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	DOI 10.17487/RFC2818, May 2000,		DOI 10.17487/RFC2818, May 2000,
	<https://www.rfc-editor.org/info/rfc2818>.		<https://www.rfc-editor.org/info/rfc2818>.
	[RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related		[RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related
	Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004,		Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004,
	<https://www.rfc-editor.org/info/rfc3753>.		<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>.
	[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,		[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
	"SEcure Neighbor Discovery (SEND)", RFC 3971,		"SEcure Neighbor Discovery (SEND)", RFC 3971,
	DOI 10.17487/RFC3971, March 2005,		DOI 10.17487/RFC3971, March 2005,
	<https://www.rfc-editor.org/info/rfc3971>.		<https://www.rfc-editor.org/info/rfc3971>.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,		DOI 10.17487/RFC4086, June 2005,
	<https://www.rfc-editor.org/info/rfc4086>.		<https://www.rfc-editor.org/info/rfc4086>.
	skipping to change at page 20, line 38 ¶		skipping to change at page 13, line 9 ¶
	December 2005, <https://www.rfc-editor.org/info/rfc4301>.		December 2005, <https://www.rfc-editor.org/info/rfc4301>.
	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,		[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
	DOI 10.17487/RFC4302, December 2005,		DOI 10.17487/RFC4302, December 2005,
	<https://www.rfc-editor.org/info/rfc4302>.		<https://www.rfc-editor.org/info/rfc4302>.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, DOI 10.17487/RFC4303, December 2005,		RFC 4303, DOI 10.17487/RFC4303, December 2005,
	<https://www.rfc-editor.org/info/rfc4303>.		<https://www.rfc-editor.org/info/rfc4303>.
	[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
	for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
	<https://www.rfc-editor.org/info/rfc4429>.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	DOI 10.17487/RFC4861, September 2007,		DOI 10.17487/RFC4861, September 2007,
	<https://www.rfc-editor.org/info/rfc4861>.		<https://www.rfc-editor.org/info/rfc4861>.
	[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast		[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
	Extensions to the Security Architecture for the Internet		Extensions to the Security Architecture for the Internet
	Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008,		Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008,
	<https://www.rfc-editor.org/info/rfc5374>.		<https://www.rfc-editor.org/info/rfc5374>.
	skipping to change at page 21, line 19 ¶		skipping to change at page 13, line 33 ¶
	<https://www.rfc-editor.org/info/rfc5415>.		<https://www.rfc-editor.org/info/rfc5415>.
	[RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing		[RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing
	Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889,		Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889,
	September 2010, <https://www.rfc-editor.org/info/rfc5889>.		September 2010, <https://www.rfc-editor.org/info/rfc5889>.
	[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility		[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
	Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July		Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
	2011, <https://www.rfc-editor.org/info/rfc6275>.		2011, <https://www.rfc-editor.org/info/rfc6275>.
	[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
	Bormann, "Neighbor Discovery Optimization for IPv6 over
	Low-Power Wireless Personal Area Networks (6LoWPANs)",
	RFC 6775, DOI 10.17487/RFC6775, November 2012,
	<https://www.rfc-editor.org/info/rfc6775>.
	[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6		[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
	Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,		Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
	February 2014, <https://www.rfc-editor.org/info/rfc7136>.		February 2014, <https://www.rfc-editor.org/info/rfc7136>.
	[RFC7217] Gont, F., "A Method for Generating Semantically Opaque		[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
	Interface Identifiers with IPv6 Stateless Address		Interface Identifiers with IPv6 Stateless Address
	Autoconfiguration (SLAAC)", RFC 7217,		Autoconfiguration (SLAAC)", RFC 7217,
	DOI 10.17487/RFC7217, April 2014,		DOI 10.17487/RFC7217, April 2014,
	<https://www.rfc-editor.org/info/rfc7217>.		<https://www.rfc-editor.org/info/rfc7217>.
	skipping to change at page 22, line 5 ¶		skipping to change at page 14, line 10 ¶
	[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,		[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
	"Recommendation on Stable IPv6 Interface Identifiers",		"Recommendation on Stable IPv6 Interface Identifiers",
	RFC 8064, DOI 10.17487/RFC8064, February 2017,		RFC 8064, DOI 10.17487/RFC8064, February 2017,
	<https://www.rfc-editor.org/info/rfc8064>.		<https://www.rfc-editor.org/info/rfc8064>.
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,		(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,		DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.
	10.2. Informative References		9.2. Informative References
	[ETSI-IPv6-GeoNetworking]		[ETSI-IPv6-GeoNetworking]
	"ETSI EN 302 636-6-1 v1.2.1 (2014-05), ETSI, European		"ETSI EN 302 636-6-1 v1.2.1 (2014-05), ETSI, European
	Standard, Intelligent Transportation Systems (ITS);		Standard, Intelligent Transportation Systems (ITS);
	Vehicular Communications; Geonetworking; Part 6: Internet		Vehicular Communications; Geonetworking; Part 6: Internet
	Integration; Sub-part 1: Transmission of IPv6 Packets over		Integration; Sub-part 1: Transmission of IPv6 Packets over
	Geonetworking Protocols. Downloaded on September 9th,		Geonetworking Protocols. Downloaded on September 9th,
	2017, freely available from ETSI website at URL		2017, freely available from ETSI website at URL
	http://www.etsi.org/deliver/		http://www.etsi.org/deliver/
	etsi_en/302600_302699/30263601/01.02.01_60/		etsi_en/302600_302699/30263601/01.02.01_60/
	skipping to change at page 22, line 33 ¶		skipping to change at page 14, line 38 ¶
	September 9th, 2017, freely available from ETSI website at		September 9th, 2017, freely available from ETSI website at
	URL http://www.etsi.org/deliver/		URL http://www.etsi.org/deliver/
	etsi_ts/102900_102999/102940/01.02.01_60/		etsi_ts/102900_102999/102940/01.02.01_60/
	ts_102940v010201p.pdf".		ts_102940v010201p.pdf".
	[I-D.hinden-6man-rfc2464bis]		[I-D.hinden-6man-rfc2464bis]
	Crawford, M. and R. Hinden, "Transmission of IPv6 Packets		Crawford, M. and R. Hinden, "Transmission of IPv6 Packets
	over Ethernet Networks", draft-hinden-6man-rfc2464bis-02		over Ethernet Networks", draft-hinden-6man-rfc2464bis-02
	(work in progress), March 2017.		(work in progress), March 2017.
	[I-D.jeong-ipwave-vehicular-networking-survey]		[I-D.ietf-ipwave-vehicular-networking-survey]
	Jeong, J., Cespedes, S., Benamar, N., Haerri, J., and M.		Jeong, J., Cespedes, S., Benamar, N., Haerri, J., and M.
	Wetterwald, "Survey on IP-based Vehicular Networking for		Wetterwald, "Survey on IP-based Vehicular Networking for
	Intelligent Transportation Systems", draft-jeong-ipwave-		Intelligent Transportation Systems", draft-ietf-ipwave-
	vehicular-networking-survey-03 (work in progress), June		vehicular-networking-survey-00 (work in progress), July
	2017.		2017.
	[I-D.perkins-intarea-multicast-ieee802]		[I-D.perkins-intarea-multicast-ieee802]
	Perkins, C., Stanley, D., Kumari, W., and J. Zuniga,		Perkins, C., Stanley, D., Kumari, W., and J. Zuniga,
	"Multicast Considerations over IEEE 802 Wireless Media",		"Multicast Considerations over IEEE 802 Wireless Media",
	draft-perkins-intarea-multicast-ieee802-03 (work in		draft-perkins-intarea-multicast-ieee802-03 (work in
	progress), July 2017.		progress), July 2017.
	[I-D.petrescu-its-scenarios-reqs]		[I-D.petrescu-its-scenarios-reqs]
	Petrescu, A., Janneteau, C., Boc, M., and W. Klaudel,		Petrescu, A., Janneteau, C., Boc, M., and W. Klaudel,
	skipping to change at page 24, line 5 ¶		skipping to change at page 16, line 10 ¶
	document freely available at URL		document freely available at URL
	http://standards.ieee.org/getieee802/		http://standards.ieee.org/getieee802/
	download/802.11p-2010.pdf retrieved on September 20th,		download/802.11p-2010.pdf retrieved on September 20th,
	2013.".		2013.".
	Appendix A. ChangeLog		Appendix A. ChangeLog
	The changes are listed in reverse chronological order, most recent		The changes are listed in reverse chronological order, most recent
	changes appearing at the top of the list.		changes appearing at the top of the list.
			From draft-ietf-ipwave-ipv6-over-80211ocb-08 to draft-ietf-ipwave-
			ipv6-over-80211ocb-09
			o Significantly shortened the Address Mapping sections, by text
			copied from RFC2464, and rather referring to it.
			o Moved the EPD description to an Appendix on its own.
			o Shortened the Introduction and the Abstract.
			o Moved the tutorial section of OCB mode introduced to .11, into an
			appendix.
			o Removed the statement that suggests that for routing purposes a
			prefix exchange mechanism could be needed.
			o Removed refs to RFC3963, RFC4429 and RFC6775; these are about ND,
			MIP/NEMO and oDAD; they were referred in the handover discussion
			section, which is out.
			o Updated a reference from individual submission to now a WG item in
			IPWAVE: the survey document.
			o Added term definition for WiFi.
			o Updated the authorship and expanded the Contributors section.
			o Corrected typographical errors.
	From draft-ietf-ipwave-ipv6-over-80211ocb-07 to draft-ietf-ipwave-		From draft-ietf-ipwave-ipv6-over-80211ocb-07 to draft-ietf-ipwave-
	ipv6-over-80211ocb-08		ipv6-over-80211ocb-08
	o Removed the per-channel IPv6 prohibition text.		o Removed the per-channel IPv6 prohibition text.
	o Corrected typographical errors.		o Corrected typographical errors.
	From draft-ietf-ipwave-ipv6-over-80211ocb-06 to draft-ietf-ipwave-		From draft-ietf-ipwave-ipv6-over-80211ocb-06 to draft-ietf-ipwave-
	ipv6-over-80211ocb-07		ipv6-over-80211ocb-07
	skipping to change at page 28, line 5 ¶		skipping to change at page 20, line 35 ¶
	o Clarified the definition of a Road Side Unit.		o Clarified the definition of a Road Side Unit.
	o Removed the discussion about security of WSA (because is non-IP).		o Removed the discussion about security of WSA (because is non-IP).
	o Removed mentioning of the GeoNetworking discussion.		o Removed mentioning of the GeoNetworking discussion.
	o Moved references to scientific articles to a separate 'overview'		o Moved references to scientific articles to a separate 'overview'
	draft, and referred to it.		draft, and referred to it.
	Appendix B. Changes Needed on a software driver 802.11a to become a		Appendix B. 802.11p
			The term "802.11p" is an earlier definition. The behaviour of
			"802.11p" networks is rolled in the document IEEE Std 802.11-2016.
			In that document the term 802.11p disappears. Instead, each 802.11p
			feature is conditioned by the Management Information Base (MIB)
			attribute "OCBActivated". 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 basic service set 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.
			Appendix C. Aspects introduced by the OCB mode to 802.11
			In the IEEE 802.11-OCB mode, all nodes in the wireless range can
			directly communicate with each other without involving authentication
			or association procedures. At link layer, it is necessary to set the
			same channel number (or frequency) on two stations that need to
			communicate with each other. Stations STA1 and STA2 can exchange IP
			packets if they are set on the same channel. At IP layer, they then
			discover each other by using the IPv6 Neighbor Discovery protocol.
			Briefly, the IEEE 802.11-OCB mode has the following properties:
			o The use by each node of a 'wildcard' BSSID (i.e., each bit of the
			BSSID is set to 1)
			o No IEEE 802.11 Beacon frames are transmitted
			o No authentication is required in order to be able to communicate
			o No association is needed in order to be able to communicate
			o No encryption is provided in order to be able to communicate
			o Flag dot11OCBActivated is set to true
			All the nodes in the radio communication range (OBRU and RSRU)
			receive all the messages transmitted (OBRU and RSRU) within the radio
			communications range. The eventual conflict(s) are resolved by the
			MAC CDMA function.
			The following message exchange diagram 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. For information, the names of
			these messages as currently specified by the 802.11 standard are
			listed in Appendix G.
			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 -------->|
			(a) 802.11 Infrastructure mode (b) 802.11-OCB mode
			The interface 802.11-OCB was specified in IEEE Std 802.11p (TM) -2010
			[IEEE-802.11p-2010] as an amendment to IEEE Std 802.11 (TM) -2007,
			titled "Amendment 6: Wireless Access in Vehicular Environments".
			Since then, this amendment has been included in IEEE 802.11(TM) -2012
			and -2016 [IEEE-802.11-2016].
			In document 802.11-2016, anything qualified specifically as
			"OCBActivated", or "outside the context of a basic service" set to be
			true, then it is actually referring to OCB aspects introduced to
			802.11.
			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 which 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 just like 'a, b, g' and 'n' are, 'p' is
			concerned more with MAC modifications, and a little 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 OFDM at 5.4GHz and
			5.9GHz.
			The 802.11-OCB links are specified to be compatible as much as
			possible with the behaviour 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 the WiFi and Ethernet
			layers do (802.11a/b/g/n and 802.3). A packet sent by an OBRU may be
			received by one or multiple RSRUs. The link-layer resolution is
			performed by using the IPv6 Neighbor Discovery protocol.
			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 layered on top of LLC on
			top of 802.3 (for Ethernet)) it is useful to analyze the differences
			between 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 little to the PHY layer), there
			are only a few characteristics which may be important for an
			implementation transmitting IPv6 packets on 802.11-OCB links.
			The most important 802.11-OCB point which 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: 20 MHz channel;
			modulation 64-QAM; codint rate R is 3/4); in practice of IP-over-
			802.11-OCB a commonly observed figure is 12Mbit/s; this bandwidth
			allows the operation of a wide range of protocols relying on IPv6.
			o Operation Outside the Context of a BSS (OCB): the (earlier
			802.11p) 802.11-OCB links are operated without a Basic Service Set
			(BSS). This means that the frames IEEE 802.11 Beacon, Association
			Request/Response, Authentication Request/Response, and similar,
			are not used. The used identifier of BSS (BSSID) has a
			hexadecimal value always 0xffffffffffff (48 '1' bits, represented
			as MAC address ff:ff:ff:ff:ff:ff, or otherwise the 'wildcard'
			BSSID), as opposed to an arbitrary BSSID value set by
			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.
			o Timing Advertisement: is a new message defined in 802.11-OCB,
			which 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 as delivered by a GNSS system (Galileo, GPS,
			...) or by a cellular system. This message is optional for
			implementation.
			o Frequency range: this is a characteristic of the PHY layer, with
			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, 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.9GHz". The 5.9GHz band is different from the
			2.4GHz and 5GHz bands used by Wireless LAN. However, as with
			Wireless LAN, the operation of 802.11-OCB in "5.9GHz" bands is
			exempt from owning a license in EU (in US the 5.9GHz is a licensed
			band of spectrum; for the fixed infrastructure an explicit FCC
			autorization is required; for an onboard device a 'licensed-by-
			rule' concept applies: rule certification conformity is required);
			however technical conditions are different than those of the bands
			"2.4GHz" or "5GHz". On one hand, the allowed power levels, and
			implicitly the maximum allowed distance between vehicles, is of
			33dBm 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 1km, compared to approximately 50m. On the other
			hand, specific conditions related to congestion avoidance, jamming
			avoidance, and radar detection are imposed on the use of DSRC (in
			US) and on the use of frequencies for Intelligent Transportation
			Systems (in EU), compared to Wireless LAN (802.11a/b/g/n).
			o 'Half-rate' encoding: as the frequency range, this parameter is
			related to PHY, and thus has not much impact on the interface
			between the IP layer and the MAC layer.
			o 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 exists a strong
			need for dynamic change of these addresses (as opposed to the non-
			vehicular settings - real wall protection - where fixed MAC
			addresses do not currently pose some privacy risks). This is
			further described in section Section 5. A relevant function is
			described in IEEE 1609.3-2016 [IEEE-1609.3], clause 5.5.1 and IEEE
			1609.4-2016 [IEEE-1609.4], clause 6.7.
			Other aspects particular to 802.11-OCB, which are also particular to
			802.11 (e.g. the 'hidden node' operation), may have an influence on
			the use of transmission of IPv6 packets on 802.11-OCB networks. The
			OCB subnet structure is described in section Section 4.6.
			Appendix D. Changes Needed on a software driver 802.11a to become a
	802.11-OCB driver		802.11-OCB driver
	The 802.11p amendment modifies both the 802.11 stack's physical and		The 802.11p amendment modifies both the 802.11 stack's physical and
	MAC layers but all the induced modifications can be quite easily		MAC layers but all the induced modifications can be quite easily
	obtained by modifying an existing 802.11a ad-hoc stack.		obtained by modifying an existing 802.11a ad-hoc stack.
	Conditions for a 802.11a hardware to be 802.11-OCB compliant:		Conditions for a 802.11a hardware to be 802.11-OCB compliant:
	o The PHY entity shall be an orthogonal frequency division		o The PHY entity shall be an orthogonal frequency division
	multiplexing (OFDM) system. It must support the frequency bands		multiplexing (OFDM) system. It must support the frequency bands
	skipping to change at page 29, line 21 ¶		skipping to change at page 26, line 21 ¶
	Response) and for authentication (Authentication Request/Reply,		Response) and for authentication (Authentication Request/Reply,
	Challenge) are not called.		Challenge) are not called.
	* The beacon interval is always set to 0 (zero).		* The beacon interval is always set to 0 (zero).
	* Timing Advertisement frames, defined in the amendment, should		* Timing Advertisement frames, defined in the amendment, should
	be supported. The upper layer should be able to trigger such		be supported. The upper layer should be able to trigger such
	frames emission and to retrieve information contained in		frames emission and to retrieve information contained in
	received Timing Advertisements.		received Timing Advertisements.
	Appendix C. Design Considerations		Appendix E. EPD
			A more theoretical and detailed view of layer stacking, and
			interfaces between the IP layer and 802.11-OCB layers, is illustrated
			below. The IP layer operates on top of the EtherType Protocol
			Discrimination (EPD); this Discrimination layer is described in IEEE
			Std 802.3-2012; the interface between IPv6 and EPD is the LLC_SAP
			(Link Layer Control Service Access Point).
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 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 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Appendix F. Design Considerations
	The networks defined by 802.11-OCB are in many ways similar to other		The networks defined by 802.11-OCB are in many ways similar to other
	networks of the 802.11 family. In theory, the encapsulation of IPv6		networks of the 802.11 family. In theory, the encapsulation of IPv6
	over 802.11-OCB could be very similar to the operation of IPv6 over		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,		other networks of the 802.11 family. However, the high mobility,
	strong link asymmetry and very short connection makes the 802.11-OCB		strong link asymmetry and very short connection makes the 802.11-OCB
	link significantly different from other 802.11 networks. Also, the		link significantly different from other 802.11 networks. Also, the
	automotive applications have specific requirements for reliability,		automotive applications have specific requirements for reliability,
	security and privacy, which further add to the particularity of the		security and privacy, which further add to the particularity of the
	802.11-OCB link.		802.11-OCB link.
	C.1. Vehicle ID		F.1. Vehicle ID
	In automotive networks it is required that each node is represented		In automotive networks it is required that each node is represented
	uniquely. Accordingly, a vehicle must be identified by at least one		uniquely. Accordingly, a vehicle must be identified by at least one
	unique identifier. The current specification at ETSI and at IEEE		unique identifier. The current specification at ETSI and at IEEE
	1609 identifies a vehicle by its MAC address, which is obtained from		1609 identifies a vehicle by its MAC address, which is obtained from
	the 802.11-OCB Network Interface Card (NIC).		the 802.11-OCB Network Interface Card (NIC).
	In case multiple 802.11-OCB NICs are present in one car, implicitely		In case multiple 802.11-OCB NICs are present in one car, implicitely
	multiple vehicle IDs will be generated. Additionally, some software		multiple vehicle IDs will be generated. Additionally, some software
	generates a random MAC address each time the computer boots; this		generates a random MAC address each time the computer boots; this
	constitutes an additional difficulty.		constitutes an additional difficulty.
	A mechanim to uniquely identify a vehicle irrespectively to the		A mechanim to uniquely identify a vehicle irrespectively to the
	multiplicity of NICs, or frequent MAC address generation, is		multiplicity of NICs, or frequent MAC address generation, is
	necessary.		necessary.
	C.2. Reliability Requirements		F.2. Reliability Requirements
	This section may need to be moved out into a separate requirements		This section may need to be moved out into a separate requirements
	document.		document.
	The dynamically changing topology, short connectivity, mobile		The dynamically changing topology, short connectivity, mobile
	transmitter and receivers, different antenna heights, and many-to-		transmitter and receivers, different antenna heights, and many-to-
	many communication types, make IEEE 802.11-OCB links significantly		many communication types, make IEEE 802.11-OCB links significantly
	different from other IEEE 802.11 links. Any IPv6 mechanism operating		different from other IEEE 802.11 links. Any IPv6 mechanism operating
	on IEEE 802.11-OCB link MUST support strong link asymmetry, spatio-		on IEEE 802.11-OCB link MUST support strong link asymmetry, spatio-
	temporal link quality, fast address resolution and transmission.		temporal link quality, fast address resolution and transmission.
	skipping to change at page 30, line 44 ¶		skipping to change at page 28, line 21 ¶
	between transmitters and receivers without the support of a NTP		between transmitters and receivers without the support of a NTP
	server.		server.
	The IEEE 802.11-OCB link being asymmetric, IPv6 over IEEE 802.11-OCB		The IEEE 802.11-OCB link being asymmetric, IPv6 over IEEE 802.11-OCB
	MUST disable management mechanisms requesting acknowledgements or		MUST disable management mechanisms requesting acknowledgements or
	replies.		replies.
	The IEEE 802.11-OCB link having a short duration time, IPv6 over IEEE		The IEEE 802.11-OCB link having a short duration time, IPv6 over IEEE
	802.11-OCB SHOULD implement fast IPv6 mobility management mechanisms.		802.11-OCB SHOULD implement fast IPv6 mobility management mechanisms.
	C.3. Multiple interfaces		F.3. Multiple interfaces
	There are considerations for 2 or more IEEE 802.11-OCB interface		There are considerations for 2 or more IEEE 802.11-OCB interface
	cards per vehicle. For each vehicle taking part in road traffic, one		cards per vehicle. For each vehicle taking part in road traffic, one
	IEEE 802.11-OCB interface card could be fully allocated for Non IP		IEEE 802.11-OCB interface card could be fully allocated for Non IP
	safety-critical communication. Any other IEEE 802.11-OCB may be used		safety-critical communication. Any other IEEE 802.11-OCB may be used
	for other type of traffic.		for other type of traffic.
	The mode of operation of these other wireless interfaces is not		The mode of operation of these other wireless interfaces is not
	clearly defined yet. One possibility is to consider each card as an		clearly defined yet. One possibility is to consider each card as an
	independent network interface, with a specific MAC Address and a set		independent network interface, with a specific MAC Address and a set
	skipping to change at page 31, line 29 ¶		skipping to change at page 29, line 5 ¶
	are represented by many network interface, a single renumbering event		are represented by many network interface, a single renumbering event
	SHALL cause renumbering of all these interfaces. If one MAC changed		SHALL cause renumbering of all these interfaces. If one MAC changed
	and another stayed constant, external observers would be able to		and another stayed constant, external observers would be able to
	correlate old and new values, and the privacy benefits of		correlate old and new values, and the privacy benefits of
	randomization would be lost.		randomization would be lost.
	The privacy requirements of Non IP safety-critical communications		The privacy requirements of Non IP safety-critical communications
	imply that if a change of pseudonyme occurs, renumbering of all other		imply that if a change of pseudonyme occurs, renumbering of all other
	interfaces SHALL also occur.		interfaces SHALL also occur.
	C.4. MAC Address Generation		F.4. MAC Address Generation
	When designing the IPv6 over 802.11-OCB address mapping, we will		When designing the IPv6 over 802.11-OCB address mapping, we will
	assume that the MAC Addresses will change during well defined		assume that the MAC Addresses will change during well defined
	"renumbering events". The 48 bits randomized MAC addresses will have		"renumbering events". The 48 bits randomized MAC addresses will have
	the following characteristics:		the following characteristics:
	o Bit "Local/Global" set to "locally admninistered".		o Bit "Local/Global" set to "locally admninistered".
	o Bit "Unicast/Multicast" set to "Unicast".		o Bit "Unicast/Multicast" set to "Unicast".
	o 46 remaining bits set to a random value, using a random number		o 46 remaining bits set to a random value, using a random number
	generator that meets the requirements of [RFC4086].		generator that meets the requirements of [RFC4086].
	The way to meet the randomization requirements is to retain 46 bits		The way to meet the randomization requirements is to retain 46 bits
	from the output of a strong hash function, such as SHA256, taking as		from the output of a strong hash function, such as SHA256, taking as
	input a 256 bit local secret, the "nominal" MAC Address of the		input a 256 bit local secret, the "nominal" MAC Address of the
	interface, and a representation of the date and time of the		interface, and a representation of the date and time of the
	renumbering event.		renumbering event.
	Appendix D. IEEE 802.11 Messages Transmitted in OCB mode		Appendix G. IEEE 802.11 Messages Transmitted in OCB mode
	For information, at the time of writing, this is the list of IEEE		For information, at the time of writing, this is the list of IEEE
	802.11 messages that may be transmitted in OCB mode, i.e. when		802.11 messages that may be transmitted in OCB mode, i.e. when
	dot11OCBActivated is true in a STA:		dot11OCBActivated is true in a STA:
	o The STA may send management frames of subtype Action and, if the		o The STA may send management frames of subtype Action and, if the
	STA maintains a TSF Timer, subtype Timing Advertisement;		STA maintains a TSF Timer, subtype Timing Advertisement;
	o The STA may send control frames, except those of subtype PS-Poll,		o The STA may send control frames, except those of subtype PS-Poll,
	CF-End, and CF-End plus CFAck;		CF-End, and CF-End plus CFAck;
	o The STA may send data frames of subtype Data, Null, QoS Data, and		o The STA may send data frames of subtype Data, Null, QoS Data, and
	QoS Null.		QoS Null.
	Appendix E. Implementation Status		Appendix H. Implementation Status
	This section describes an example of an IPv6 Packet captured over a		This section describes an example of an IPv6 Packet captured over a
	IEEE 802.11-OCB link.		IEEE 802.11-OCB link.
	By way of example we show that there is no modification in the		By way of example we show that there is no modification in the
	headers when transmitted over 802.11-OCB networks - they are		headers when transmitted over 802.11-OCB networks - they are
	transmitted like any other 802.11 and Ethernet packets.		transmitted like any other 802.11 and Ethernet packets.
	We describe an experiment of capturing an IPv6 packet on an		We describe an experiment of capturing an IPv6 packet on an
	802.11-OCB link. In this experiment, the packet is an IPv6 Router		802.11-OCB link. In this experiment, the packet is an IPv6 Router
	skipping to change at page 33, line 9 ¶		skipping to change at page 30, line 24 ¶
	During several capture operations running from a few moments to		During several capture operations running from a few moments to
	several hours, no message relevant to the BSSID contexts were		several hours, no message relevant to the BSSID contexts were
	captured (no Association Request/Response, Authentication Req/Resp,		captured (no Association Request/Response, Authentication Req/Resp,
	Beacon). This shows that the operation of 802.11-OCB is outside the		Beacon). This shows that the operation of 802.11-OCB is outside the
	context of a BSSID.		context of a BSSID.
	Overall, the captured message is identical with a capture of an IPv6		Overall, the captured message is identical with a capture of an IPv6
	packet emitted on a 802.11b interface. The contents are precisely		packet emitted on a 802.11b interface. The contents are precisely
	similar.		similar.
	E.1. Capture in Monitor Mode		H.1. Capture in Monitor Mode
	The IPv6 RA packet captured in monitor mode is illustrated below.		The IPv6 RA packet captured in monitor mode is illustrated below.
	The radio tap header provides more flexibility for reporting the		The radio tap header provides more flexibility for reporting the
	characteristics of frames. The Radiotap Header is prepended by this		characteristics of frames. The Radiotap Header is prepended by this
	particular stack and operating system on the Host machine to the RA		particular stack and operating system on the Host machine to the RA
	packet received from the network (the Radiotap Header is not present		packet received from the network (the Radiotap Header is not present
	on the air). The implementation-dependent Radiotap Header is useful		on the air). The implementation-dependent Radiotap Header is useful
	for piggybacking PHY information from the chip's registers as data in		for piggybacking PHY information from the chip's registers as data in
	a packet understandable by userland applications using Socket		a packet understandable by userland applications using Socket
	interfaces (the PHY interface can be, for example: power levels, data		interfaces (the PHY interface can be, for example: power levels, data
	skipping to change at page 35, line 41 ¶		skipping to change at page 33, line 10 ¶
	the IEEE 802.11 data, the destination address is 33:33:00:00:00:01		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		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		broadcast address of ff:ff:ff:ff:ff:ff. Due to the short link
	duration between vehicles and the roadside infrastructure, there is		duration between vehicles and the roadside infrastructure, there is
	no need in IEEE 802.11-OCB to wait for the completion of association		no need in IEEE 802.11-OCB to wait for the completion of association
	and authentication procedures before exchanging data. IEEE		and authentication procedures before exchanging data. IEEE
	802.11-OCB enabled nodes use the wildcard BSSID (a value of all 1s)		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		and may start communicating as soon as they arrive on the
	communication channel.		communication channel.
	E.2. Capture in Normal Mode		H.2. Capture in Normal Mode
	The same IPv6 Router Advertisement packet described above (monitor		The same IPv6 Router Advertisement packet described above (monitor
	mode) is captured on the Host, in the Normal mode, and depicted		mode) is captured on the Host, in the Normal mode, and depicted
	below.		below.
	Ethernet II Header		Ethernet II Header
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Destination...		| Destination...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	...Destination | Source...		...Destination | Source...
	skipping to change at page 38, line 12 ¶		skipping to change at page 36, line 12 ¶
	Phone: +212670832236		Phone: +212670832236
	Email: benamar73@gmail.com		Email: benamar73@gmail.com
	Jerome Haerri		Jerome Haerri
	Eurecom		Eurecom
	Sophia-Antipolis 06904		Sophia-Antipolis 06904
	France		France
	Phone: +33493008134		Phone: +33493008134
	Email: Jerome.Haerri@eurecom.fr		Email: Jerome.Haerri@eurecom.fr
	Christian Huitema
	Private Octopus Inc.
	Friday Harbor, WA 98250
	U.S.A.
	Email: huitema@huitema.net
	Jong-Hyouk Lee		Jong-Hyouk Lee
	Sangmyung University		Sangmyung University
	31, Sangmyeongdae-gil, Dongnam-gu		31, Sangmyeongdae-gil, Dongnam-gu
	Cheonan 31066		Cheonan 31066
	Republic of Korea		Republic of Korea
	Email: jonghyouk@smu.ac.kr		Email: jonghyouk@smu.ac.kr
	Thierry Ernst		Thierry Ernst
	YoGoKo		YoGoKo
	France		France
	Email: thierry.ernst@yogoko.fr		Email: thierry.ernst@yogoko.fr
	Tony Li
	Peloton Technology
	1060 La Avenida St.
	Mountain View, California 94043
	United States
	Phone: +16503957356
	Email: tony.li@tony.li
End of changes. 66 change blocks.
	516 lines changed or deleted		398 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/