draft-ietf-ipwave-ipv6-over-80211ocb-51.txt		draft-ietf-ipwave-ipv6-over-80211ocb-52.txt
	IPWAVE Working Group N. Benamar		IPWAVE Working Group N. Benamar
	Internet-Draft Moulay Ismail University of Meknes		Internet-Draft Moulay Ismail University of Meknes
	Intended status: Standards Track J. Haerri		Intended status: Standards Track J. Haerri
	Expires: January 25, 2020 Eurecom		Expires: February 10, 2020 Eurecom
	J. Lee		J. Lee
	Sangmyung University		Sangmyung University
	T. Ernst		T. Ernst
	YoGoKo		YoGoKo
	July 24, 2019		August 9, 2019
	Basic Support for IPv6 over IEEE Std 802.11 Networks Operating Outside		Basic Support for IPv6 over IEEE Std 802.11 Networks Operating Outside
	the Context of a Basic Service Set		the Context of a Basic Service Set
	draft-ietf-ipwave-ipv6-over-80211ocb-51		draft-ietf-ipwave-ipv6-over-80211ocb-52
	Abstract		Abstract
	This document provides methods and settings, for using IPv6 to		This document provides methods and settings, for using IPv6 to
	communicate among nodes within range of one another over a single		communicate among nodes within range of one another over a single
	IEEE 802.11-OCB link. Support for these methods and settings require		IEEE 802.11-OCB link. Support for these methods and settings require
	minimal changes to existing stacks. This document also describes		minimal changes to existing stacks. This document also describes
	limitations associated with using these methods. Optimizations and		limitations associated with using these methods. Optimizations and
	usage of IPv6 over more complex scenarios is not covered in this		usage of IPv6 over more complex scenarios is not covered in this
	specification and is subject of future work.		specification and is subject of future work.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 January 25, 2020.		This Internet-Draft will expire on February 10, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 3, line 16 ¶		skipping to change at page 3, line 16 ¶
	1. Introduction		1. Introduction
	This document provides a baseline for using IPv6 to communicate among		This document provides a baseline for using IPv6 to communicate among
	nodes in range of one another over a single IEEE 802.11-OCB link		nodes in range of one another over a single IEEE 802.11-OCB link
	[IEEE-802.11-2016] (a.k.a., "802.11p" see Appendix A, Appendix B and		[IEEE-802.11-2016] (a.k.a., "802.11p" see Appendix A, Appendix B and
	Appendix C) with minimal changes to existing stacks. Moreover, the		Appendix C) with minimal changes to existing stacks. Moreover, the
	document identifies limitations of such usage. Concretely, the		document identifies limitations of such usage. Concretely, the
	document describes the layering of IPv6 networking on top of the IEEE		document describes the layering of IPv6 networking on top of the IEEE
	Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer with a frame		Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer with a frame
	translation underneath. The resulting stack inherits from IPv6 over		translation underneath. The resulting stack is derived from IPv6
	Ethernet [RFC2464], but operates over 802.11-OCB to provide at least		over Ethernet [RFC2464], but operates over 802.11-OCB to provide at
	P2P (Point to Point) connectivity using IPv6 ND and link-local		least P2P (Point to Point) connectivity using IPv6 ND and link-local
	addresses.		addresses.
	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
	operating on Ethernet with the following exceptions:		operating on Ethernet with the following exceptions:
	o Exceptions due to different operation of IPv6 network layer on		o Exceptions due to different operation of IPv6 network layer on
	802.11 than on Ethernet. The operation of IP on Ethernet is		802.11 than on Ethernet. The operation of IP on Ethernet is
	described in [RFC1042] and [RFC2464].		described in [RFC1042] and [RFC2464].
	o Exceptions due to the OCB nature of 802.11-OCB compared to 802.11.		o Exceptions due to the OCB nature of 802.11-OCB compared to 802.11.
	skipping to change at page 5, line 31 ¶		skipping to change at page 5, line 31 ¶
	operating system and the 802.11-OCB media, device drivers MAY		operating system and the 802.11-OCB media, device drivers MAY
	implement IPv6-over-Ethernet as per [RFC2464] and then a frame		implement IPv6-over-Ethernet as per [RFC2464] and then a frame
	translation from 802.3 to 802.11 in order to minimize the code		translation from 802.3 to 802.11 in order to minimize the code
	changes.		changes.
	4.3. Link-Local Addresses		4.3. Link-Local Addresses
	There are several types of IPv6 addresses [RFC4291], [RFC4193], that		There are several types of IPv6 addresses [RFC4291], [RFC4193], that
	may be assigned to an 802.11-OCB interface. Among these types of		may be assigned to an 802.11-OCB interface. Among these types of
	addresses only the IPv6 link-local addresses can be formed using an		addresses only the IPv6 link-local addresses can be formed using an
	EUI-64 identifier, in particular during transition time.		EUI-64 identifier, in particular during transition time, (the time
			spent before an interface starts using a different address than the
			LL one).
	If the IPv6 link-local address is formed using an EUI-64 identifier,		If the IPv6 link-local address is formed using an EUI-64 identifier,
	then the mechanism of forming that address is the same mechanism as		then the mechanism of forming that address is the same mechanism as
	used to form an IPv6 link-local address on Ethernet links. Moreover,		used to form an IPv6 link-local address on Ethernet links. Moreover,
	whether or not the interface identifier is derived from the EUI-64		whether or not the interface identifier is derived from the EUI-64
	identifier, its length is 64 bits as is the case for Ethernet		identifier, its length is 64 bits as is the case for Ethernet
	[RFC2464].		[RFC2464].
	4.4. Stateless Autoconfiguration		4.4. Stateless Autoconfiguration
	skipping to change at page 7, line 4 ¶		skipping to change at page 7, line 7 ¶
	Address Detection (DAD) per [RFC4862].		Address Detection (DAD) per [RFC4862].
	4.5.2. Address Mapping -- Multicast		4.5.2. Address Mapping -- Multicast
	The multicast address mapping is performed according to the method		The multicast address mapping is performed according to the method
	specified in section 7 of [RFC2464]. The meaning of the value "3333"		specified in section 7 of [RFC2464]. The meaning of the value "3333"
	mentioned there is defined in section 2.3.1 of [RFC7042].		mentioned there is defined in section 2.3.1 of [RFC7042].
	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.ietf-mboned-ieee802-mcast-problems]. These issues may be		[I-D.ietf-mboned-ieee802-mcast-problems]. These issues may be
	exacerbated in OCB mode.A A future improvement to this specification		exacerbated in OCB mode. A future improvement to this specification
	should consider solutions for these problems.		should consider solutions for these problems.
	4.6. Subnet Structure		4.6. Subnet Structure
	When vehicles are in close range, a subnet may be formed over		When vehicles are in close range, a subnet may be formed over
	802.11-OCB interfaces (not by their in-vehicle interfaces). A Prefix		802.11-OCB interfaces (not by their in-vehicle interfaces). A Prefix
	List conceptual data structure ([RFC4861] Section 5.1) is maintained		List conceptual data structure ([RFC4861] Section 5.1) is maintained
	for each 802.11-OCB interface.		for each 802.11-OCB interface.
	IPv6 Neighbor Discovery protocol (ND) requires reflexive properties		IPv6 Neighbor Discovery protocol (ND) requires reflexive properties
	skipping to change at page 8, line 36 ¶		skipping to change at page 8, line 38 ¶
	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). Therefore, an attacker can sniff		Response, no Challenge messages). Therefore, an attacker can sniff
	or inject traffic while within range of a vehicle or IP-RSU (by		or inject traffic while within range of a vehicle or IP-RSU (by
	setting an interface card's frequency to the proper range). Also, an		setting an interface card's frequency to the proper range). Also, an
	attacker may not heed to legal limits for radio power and can use a		attacker may not heed to legal limits for radio power and can use a
	very sensitive directional antenna; if attackers wishe to attack a		very sensitive directional antenna; if attackers wishe to attack a
	given exchange they do not necessarily need to be in close physical		given exchange they do not necessarily need to be in close physical
	proximity. Hence, such a link is less protected than commonly used		proximity. Hence, such a link is less protected than commonly used
	links (wired link or protected 802.11).		links (wired link or aforementioned 802.11 links with link-layer
			security).
	Therefore, any node can join a subnet, directly communicate with any		Therefore, any node can join a subnet, directly communicate with any
	nodes on the subset to include potentially impersonating another		nodes on the subset to include potentially impersonating another
	node. This design allows for a number of threats outlined in		node. This design allows for a number of threats outlined in
	Section 3 of [RFC6959]. While not widely deployed, SeND [RFC3971],		Section 3 of [RFC6959]. While not widely deployed, SeND [RFC3971],
	[RFC3972] is a solution that can address Spoof-Based Attack Vectors.		[RFC3972] is a solution that can address Spoof-Based Attack Vectors.
	5.1. Privacy Considerations		5.1. Privacy Considerations
	As with all Ethernet and 802.11 interface identifiers ([RFC7721]),		As with all Ethernet and 802.11 interface identifiers ([RFC7721]),
	skipping to change at page 9, line 14 ¶		skipping to change at page 9, line 17 ¶
	being tracked. In outdoors public environments, where vehicles		being tracked. In outdoors public environments, where vehicles
	typically circulate, the privacy risks are more important than in		typically circulate, the privacy risks are more important than in
	indoors settings. It is highly likely that attacker sniffers are		indoors settings. It is highly likely that attacker sniffers are
	deployed along routes which listen for IEEE frames, including IP		deployed along routes which listen for IEEE frames, including IP
	packets, of vehicles passing by. For this reason, in the 802.11-OCB		packets, of vehicles passing by. For this reason, in the 802.11-OCB
	deployments, there is a strong necessity to use protection tools such		deployments, there is a strong necessity to use protection tools such
	as dynamically changing MAC addresses Section 5.2, semantically		as dynamically changing MAC addresses Section 5.2, semantically
	opaque Interface Identifiers and stable Interface Identifiers		opaque Interface Identifiers and stable Interface Identifiers
	Section 4.4. An example of change policy is to change the MAC		Section 4.4. An example of change policy is to change the MAC
	address of the OCB interface each time the system boots up. This may		address of the OCB interface each time the system boots up. This may
	help mitigate privacy risks to a certain level. Futhermore, for		help mitigate privacy risks to a certain level. Furthermore, for
	pricavy concerns, ([RFC8065]) recommends using an address generation		privacy concerns, ([RFC8065]) recommends using an address generation
	scheme rather than addresses generated from a fixed link-layer		scheme rather than addresses generated from a fixed link-layer
	address. However, there are some specificities related to vehicles.		address. However, there are some specificities related to vehicles.
	Since roaming is an important characteristic of moving vehicles, the		Since roaming is an important characteristic of moving vehicles, the
	use of the same Link-Local Address over time can indicate the		use of the same Link-Local Address over time can indicate the
	presence of the same vehicle in different places and thus leads to		presence of the same vehicle in different places and thus leads to
	location tracking. Hence, a vehicle should get hints about a change		location tracking. Hence, a vehicle should get hints about a change
	of environment (e.g. , engine running, GPS, etc..) and renew the IID		of environment (e.g. , engine running, GPS, etc..) and renew the IID
	in its LLAs.		in its LLAs.
	5.1.1. Privacy Risks of Meaningful info in Interface IDs		5.1.1. Privacy Risks of Meaningful info in Interface IDs
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 9 ¶
	on an 802.11-OCB interface all the Interface Identifiers of IPv6		on an 802.11-OCB interface all the Interface Identifiers of IPv6
	addresses assigned to that interface MUST change.		addresses assigned to that interface MUST change.
	Implementations should use a policy dictating when the MAC address is		Implementations should use a policy dictating when the MAC address is
	changed on the 802.11-OCB interface. For more information on the		changed on the 802.11-OCB interface. For more information on the
	motivation of this policy please refer to the privacy discussion in		motivation of this policy please refer to the privacy discussion in
	Appendix B.		Appendix B.
	A 'randomized' MAC address has the following characteristics:		A 'randomized' MAC address has the following characteristics:
	o Bit "Local/Global" set to "locally admninistered".		o Bit "Local/Global" set to "locally administered".
	o Bit "Unicast/Multicast" set to "Unicast".		o Bit "Unicast/Multicast" set to "Unicast".
	o The 46 remaining bits are set to a random value, using a random		o The 46 remaining bits are set to a random value, using a random
	number generator that meets the requirements of [RFC4086].		number generator that meets the requirements of [RFC4086].
	To meet the randomization requirements for the 46 remaining bits, a		To meet the randomization requirements for the 46 remaining bits, a
	hash function may be used. For example, the SHA256 hash function may		hash function may be used. For example, the [SHA256] hash function
	be used with input a 256 bit local secret, the 'nominal' MAC Address		may be used with input a 256 bit local secret, the 'nominal' MAC
	of the interface, and a representation of the date and time of the		Address of the interface, and a representation of the date and time
	renumbering event.		of the renumbering event.
	A randomized Interface ID has the same characteristics of a		A randomized Interface ID has the same characteristics of a
	randomized MAC address, except the length in bits.		randomized MAC address, except the length in bits.
	5.3. Pseudonymization impact on confidentiality and trust		5.3. Pseudonymization impact on confidentiality and trust
	Vehicles 'and drivers' privacy relies on pseudonymization mechanisms		Vehicles 'and drivers' privacy relies on pseudonymization mechanisms
	such as the ones described in Section 5.2. This pseudonymization		such as the ones described in Section 5.2. This pseudonymization
	means that upper-layer protocols and applications SHOULD NOT rely on		means that upper-layer protocols and applications SHOULD NOT rely on
	layer-2 or layer-3 addresses to assume that the other participant can		layer-2 or layer-3 addresses to assume that the other participant can
	skipping to change at page 14, line 35 ¶		skipping to change at page 14, line 35 ¶
	[I-D.ietf-ipwave-vehicular-networking]		[I-D.ietf-ipwave-vehicular-networking]
	Jeong, J., "IP Wireless Access in Vehicular Environments		Jeong, J., "IP Wireless Access in Vehicular Environments
	(IPWAVE): Problem Statement and Use Cases", draft-ietf-		(IPWAVE): Problem Statement and Use Cases", draft-ietf-
	ipwave-vehicular-networking-11 (work in progress), July		ipwave-vehicular-networking-11 (work in progress), July
	2019.		2019.
	[I-D.ietf-mboned-ieee802-mcast-problems]		[I-D.ietf-mboned-ieee802-mcast-problems]
	Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.		Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
	Zuniga, "Multicast Considerations over IEEE 802 Wireless		Zuniga, "Multicast Considerations over IEEE 802 Wireless
	Media", draft-ietf-mboned-ieee802-mcast-problems-06 (work		Media", draft-ietf-mboned-ieee802-mcast-problems-07 (work
	in progress), July 2019.		in progress), July 2019.
	[IEEE-1609.2]		[IEEE-1609.2]
	"IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access		"IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access
	in Vehicular Environments (WAVE) -- Security Services for		in Vehicular Environments (WAVE) -- Security Services for
	Applications and Management Messages. Example URL		Applications and Management Messages. Example URL
	http://ieeexplore.ieee.org/document/7426684/ accessed on		http://ieeexplore.ieee.org/document/7426684/ accessed on
	August 17th, 2017.".		August 17th, 2017.".
	[IEEE-1609.3]		[IEEE-1609.3]
	skipping to change at page 16, line 14 ¶		skipping to change at page 16, line 14 ¶
	[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy		[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
	Considerations for IPv6 Address Generation Mechanisms",		Considerations for IPv6 Address Generation Mechanisms",
	RFC 7721, DOI 10.17487/RFC7721, March 2016,		RFC 7721, DOI 10.17487/RFC7721, March 2016,
	<https://www.rfc-editor.org/info/rfc7721>.		<https://www.rfc-editor.org/info/rfc7721>.
	[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-		[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
	Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,		Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
	February 2017, <https://www.rfc-editor.org/info/rfc8065>.		February 2017, <https://www.rfc-editor.org/info/rfc8065>.
			[SHA256] "Secure Hash Standard (SHS), National Institute of
			Standards and Technology.
			https://csrc.nist.gov/CSRC/media/Publications/fips/180/2/
			archive/2002-08-01/documents/fips180-2.pdf".
	Appendix A. 802.11p		Appendix A. 802.11p
	The term "802.11p" is an earlier definition. The behaviour of		The term "802.11p" is an earlier definition. The behaviour of
	"802.11p" networks is rolled in the document IEEE Std 802.11-2016.		"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		In that document the term 802.11p disappears. Instead, each 802.11p
	feature is conditioned by the IEEE Management Information Base (MIB)		feature is conditioned by the IEEE Management Information Base (MIB)
	attribute "OCBActivated" [IEEE-802.11-2016]. Whenever OCBActivated		attribute "OCBActivated" [IEEE-802.11-2016]. Whenever OCBActivated
	is set to true the IEEE Std 802.11-OCB state is activated. For		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		example, an 802.11 STAtion operating outside the context of a basic
	service set has the OCBActivated flag set. Such a station, when it		service set has the OCBActivated flag set. Such a station, when it
	skipping to change at page 28, line 35 ¶		skipping to change at page 28, line 35 ¶
	to the applications. It adapts 802.11 LLC/MAC headers to Ethernet II		to the applications. It adapts 802.11 LLC/MAC headers to Ethernet II
	headers. In further detail, this adaptation consists in the		headers. In further detail, this adaptation consists in the
	elimination of the Radiotap, 802.11 and LLC headers, and in the		elimination of the Radiotap, 802.11 and LLC headers, and in the
	insertion of the Ethernet II header. In this way, IPv6 runs straight		insertion of the Ethernet II header. In this way, IPv6 runs straight
	over LLC over the 802.11-OCB MAC layer; this is further confirmed by		over LLC over the 802.11-OCB MAC layer; this is further confirmed by
	the use of the unique Type 0x86DD.		the use of the unique Type 0x86DD.
	Appendix H. Extra Terminology		Appendix H. Extra Terminology
	The following terms are defined outside the IETF. They are used to		The following terms are defined outside the IETF. They are used to
	define the main terms in the main terminology section Section 2.		define the main terms in the main terminology Section 2.
	DSRC (Dedicated Short Range Communication): a term defined outside		DSRC (Dedicated Short Range Communication): a term defined outside
	the IETF. The US Federal Communications Commission (FCC) Dedicated		the IETF. The US Federal Communications Commission (FCC) Dedicated
	Short Range Communication (DSRC) is defined in the Code of Federal		Short Range Communication (DSRC) is defined in the Code of Federal
	Regulations (CFR) 47, Parts 90 and 95. This Code is referred in the		Regulations (CFR) 47, Parts 90 and 95. This Code is referred in the
	definitions below. At the time of the writing of this Internet		definitions below. At the time of the writing of this Internet
	Draft, the last update of this Code was dated October 1st, 2010.		Draft, the last update of this Code was dated October 1st, 2010.
	DSRCS (Dedicated Short-Range Communications Services): a term defined		DSRCS (Dedicated Short-Range Communications Services): a term defined
	outside the IETF. The use of radio techniques to transfer data over		outside the IETF. The use of radio techniques to transfer data over
End of changes. 15 change blocks.
	20 lines changed or deleted		27 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/