draft-ietf-ipwave-ipv6-over-80211ocb-28.txt		draft-ietf-ipwave-ipv6-over-80211ocb-29.txt
	IPWAVE Working Group A. Petrescu		IPWAVE 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, 2019 Moulay Ismail University		Expires: March 24, 2019 Moulay Ismail University
	J. Haerri		J. Haerri
	Eurecom		Eurecom
	J. Lee		J. Lee
	Sangmyung University		Sangmyung University
	T. Ernst		T. Ernst
	YoGoKo		YoGoKo
	September 19, 2018		September 20, 2018
	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-28		draft-ietf-ipwave-ipv6-over-80211ocb-29
	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
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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, 2019.		This Internet-Draft will expire on March 24, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	skipping to change at page 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 5		4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 5
	4.1. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 5		4.1. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 5
	4.2. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5		4.2. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5
	4.3. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5		4.3. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5
	4.3.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5		4.3.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5
	4.4. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7		4.4. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7
	4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7		4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7
	4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7		4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7
	4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 7		4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 7
	4.6. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7		4.6. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7
	4.7. Subnet Structure . . . . . . . . . . . . . . . . . . . . 8		4.7. Subnet Structure . . . . . . . . . . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10		5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10
	5.2. MAC Address and Interface ID Generation . . . . . . . . . 10		5.2. MAC Address and Interface ID Generation . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 16		Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 17
	Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 25		Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 26
	Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 25		Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 26
	Appendix D. Changes Needed on a software driver 802.11a to		Appendix D. Changes Needed on a software driver 802.11a to
	become a 802.11-OCB driver . . . 29		become a 802.11-OCB driver . . . 30
	Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 30		Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 31
	Appendix F. Design Considerations . . . . . . . . . . . . . . . 31		Appendix F. Design Considerations . . . . . . . . . . . . . . . 32
	Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 31		Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 32
	Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 32		Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 33
	H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 33		H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 34
	H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 35		H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 36
	Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 37		Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	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 [IEEE-802.11-2016] (a.k.a "802.11p" see		802.11-OCB networks [IEEE-802.11-2016] (a.k.a "802.11p" see
	Appendix B, Appendix C and Appendix D). This involves the layering		Appendix B, Appendix C and Appendix D). This involves the layering
	of IPv6 networking on top of the IEEE 802.11 MAC layer, with an LLC		of IPv6 networking on top of the IEEE 802.11 MAC layer, with an LLC
	layer. Compared to running IPv6 over the Ethernet MAC layer, there		layer. Compared to running IPv6 over the Ethernet MAC layer, there
	is no modification expected to IEEE Std 802.11 MAC and Logical Link		is no modification expected to IEEE Std 802.11 MAC and Logical Link
	sublayers: IPv6 works fine directly over 802.11-OCB too, with an LLC		sublayers: IPv6 works fine directly over 802.11-OCB too, with an LLC
	skipping to change at page 8, line 21 ¶		skipping to change at page 8, line 21 ¶
	The bits in the Interface Identifier have no generic meaning and the		The bits in the Interface Identifier have no generic meaning and 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]. If semantically		of this significance are described in [RFC7136]. 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].
			Semantically opaque Interface Identifiers, instead of meaningful
			Interface Identifiers derived from a valid and meaningful MAC address
			([RFC2464], section 4), MAY be needed in order to avoid certain
			privacy risks.
			A valid MAC address includes a unique identifier pointing to a
			company together with its postal address, and a unique number within
			that company MAC space (see the oui.txt file). The calculation
			operation of the MAC address back from a given meaningful Interface
			Identifier is straightforward ([RFC2464], section 4). The Interface
			Identifier is part of an IPv6 address that is stored in IPv6 packets.
			The IPv6 packets can be captured in the Internet easily. For these
			reasons, an attacker may realize many attacks on privacy. One such
			attack on 802.11-OCB is to capture, store and correlate Company ID
			information of many cars in public areas (e.g. listen for Router
			Advertisements, or other IPv6 application data packets, and record
			the value of the source address in these packets). Further
			correlation of this information with other data captured by other
			means, or other visual information (car color, others) MAY constitute
			privacy risks.
			In order to avoid these risks, opaque Interface Identifiers MAY be
			formed according to rules described in [RFC7217]. These opaque
			Interface Identifiers are formed starting from identifiers different
			than the MAC addresses, and from cryptographically strong material.
			Thus, privacy sensitive information is absent from Interface IDs, and
			it is impossible to calculate the initial value from which the
			Interface ID was calculated.
			Some applications that use IPv6 packets on 802.11-OCB links (among
			other link types) may benefit from IPv6 addresses whose Interface
			Identifiers don't change too often. It is RECOMMENDED to use the
			mechanisms described in RFC 7217 to permit the use of Stable
			Interface Identifiers that do not change within one subnet prefix. A
			possible source for the Net-Iface Parameter is a virtual interface
			name, or logical interface name, that is decided by a local
			administrator.
	The way Interface Identifiers are used MAY involve risks to privacy,		The way Interface Identifiers are used MAY involve risks to privacy,
	as described in Section 5.1.		as described in Section 5.1.
	4.7. Subnet Structure		4.7. 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 by their in-vehicle interfaces). This		that are in close range (not by their in-vehicle interfaces). This
	subnet MUST use at least the link-local prefix fe80::/10 and the		subnet MUST use at least the link-local prefix fe80::/10 and the
	interfaces MUST be assigned IPv6 addresses of type link-local. This		interfaces MUST be assigned IPv6 addresses of type link-local. This
	subnet MAY NOT have any other prefix than the link-local prefix.		subnet MAY NOT have any other prefix than the link-local prefix.
	skipping to change at page 16, line 22 ¶		skipping to change at page 17, 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.
			-29:
			o
	-28:		-28:
	o Created a new section 'Pseudonym Handling'.		o Created a new section 'Pseudonym Handling'.
	o removed the 'Vehicle ID' appendix.		o removed the 'Vehicle ID' appendix.
	o improved the address generation from random MAC address.		o improved the address generation from random MAC address.
	o shortened Term IP-RSU definition.		o shortened Term IP-RSU definition.
End of changes. 10 change blocks.
	24 lines changed or deleted		66 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/