draft-ietf-ipwave-ipv6-over-80211ocb-50.txt		draft-ietf-ipwave-ipv6-over-80211ocb-51.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 21, 2020 Eurecom		Expires: January 25, 2020 Eurecom
	J. Lee		J. Lee
	Sangmyung University		Sangmyung University
	T. Ernst		T. Ernst
	YoGoKo		YoGoKo
	July 20, 2019		July 24, 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 (IPv6-over-80211-OCB)		the Context of a Basic Service Set
	draft-ietf-ipwave-ipv6-over-80211ocb-50		draft-ietf-ipwave-ipv6-over-80211ocb-51
	Abstract		Abstract
	This document provides methods and settings, and describes		This document provides methods and settings, for using IPv6 to
	limitations, for using IPv6 to communicate among nodes in range of		communicate among nodes within range of one another over a single
	one another over a single IEEE 802.11-OCB link. This support does		IEEE 802.11-OCB link. Support for these methods and settings require
	only require minimal changes to existing stacks. Optimizations and		minimal changes to existing stacks. This document also describes
			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.
	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 January 21, 2020.		This Internet-Draft will expire on January 25, 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 2, line 30 ¶		skipping to change at page 2, line 33 ¶
	4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 5		4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 5
	4.4. Stateless Autoconfiguration . . . . . . . . . . . . . . . 5		4.4. Stateless Autoconfiguration . . . . . . . . . . . . . . . 5
	4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 6		4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 6
	4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 6		4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 6
	4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 6		4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 6
	4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 7		4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 8		5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 8
	5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 9		5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 9
	5.2. MAC Address and Interface ID Generation . . . . . . . . . 9		5.2. MAC Address and Interface ID Generation . . . . . . . . . 9
	5.3. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 10		5.3. Pseudonymization impact on confidentiality and trust . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . 14
	Appendix A. 802.11p . . . . . . . . . . . . . . . . . . . . . . 16		Appendix A. 802.11p . . . . . . . . . . . . . . . . . . . . . . 16
	Appendix B. Aspects introduced by the OCB mode to 802.11 . . . . 16		Appendix B. Aspects introduced by the OCB mode to 802.11 . . . . 16
	Appendix C. Changes Needed on a software driver 802.11a to		Appendix C. Changes Needed on a software driver 802.11a to
	become a 802.11-OCB driver . . . . . . . . . . . . . 21		become a 802.11-OCB driver . . . . . . . . . . . . . 20
	Appendix D. Protocol Layering . . . . . . . . . . . . . . . . . 22		Appendix D. Protocol Layering . . . . . . . . . . . . . . . . . 21
	Appendix E. Design Considerations . . . . . . . . . . . . . . . 23		Appendix E. Design Considerations . . . . . . . . . . . . . . . 22
	Appendix F. IEEE 802.11 Messages Transmitted in OCB mode . . . . 23		Appendix F. IEEE 802.11 Messages Transmitted in OCB mode . . . . 22
	Appendix G. Examples of Packet Formats . . . . . . . . . . . . . 23		Appendix G. Examples of Packet Formats . . . . . . . . . . . . . 23
	G.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 24		G.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 24
	G.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 27		G.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 26
	Appendix H. Extra Terminology . . . . . . . . . . . . . . . . . 29		Appendix H. Extra Terminology . . . . . . . . . . . . . . . . . 28
	Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless		Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless
	Links . . . . . . . . . . . . . . . . . . . . . . . 30		Links . . . . . . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	This document provides a baseline with limitations for using IPv6 to		This document provides a baseline for using IPv6 to communicate among
	communicate among nodes in range of one another over a single IEEE		nodes in range of one another over a single IEEE 802.11-OCB link
	802.11-OCB link [IEEE-802.11-2016] (a.k.a., "802.11p" see Appendix A,		[IEEE-802.11-2016] (a.k.a., "802.11p" see Appendix A, Appendix B and
	Appendix B and Appendix C) with minimal changes to existing stacks.		Appendix C) with minimal changes to existing stacks. Moreover, the
	Moreover, the document identifies limitations of such usage.		document identifies limitations of such usage. Concretely, the
	Concretely, the document describes the layering of IPv6 networking on		document describes the layering of IPv6 networking on top of the IEEE
	top of the IEEE Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer		Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer with a frame
	with a frame translation underneath. The resulting stack inherits		translation underneath. The resulting stack inherits from IPv6 over
	from IPv6 over Ethernet [RFC2464], but operates over 802.11-OCB to		Ethernet [RFC2464], but operates over 802.11-OCB to provide at least
	provide at least P2P (Point to Point) connectivity using IPv6 ND and		P2P (Point to Point) connectivity using IPv6 ND and link-local
	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.
	This has impacts on security, privacy, subnet structure and		This has impacts on security, privacy, subnet structure and
	skipping to change at page 4, line 44 ¶		skipping to change at page 4, line 45 ¶
	are assumed to be P2P and multiple links can be on one radio		are assumed to be P2P and multiple links can be on one radio
	interface. While 802.11-OCB is clearly specified, and a legacy IPv6		interface. While 802.11-OCB is clearly specified, and a legacy IPv6
	stack can operate on such links, the use of the operating environment		stack can operate on such links, the use of the operating environment
	(vehicular networks) brings in new perspectives.		(vehicular networks) brings in new perspectives.
	4. IPv6 over 802.11-OCB		4. IPv6 over 802.11-OCB
	4.1. Maximum Transmission Unit (MTU)		4.1. Maximum Transmission Unit (MTU)
	The default MTU for IP packets on 802.11-OCB is inherited from		The default MTU for IP packets on 802.11-OCB is inherited from
	[RFC2464] and is, as such, 1500 octets. This value of the MTU		[RFC2464] and is, as such, 1500 octets. As noted in [RFC8200], every
	respects the recommendation that every link on the Internet must have		link on the Internet must have a minimum MTU of 1280 octets, as well
	a minimum MTU of 1280 octets (stated in [RFC8200], and the		as follow the other recommendations, especially with regard to
	recommendations therein, especially with respect to fragmentation).		fragmentation.
	4.2. Frame Format		4.2. Frame Format
	IP packets MUST be transmitted over 802.11-OCB media as QoS Data		IP packets MUST be transmitted over 802.11-OCB media as QoS Data
	frames whose format is specified in IEEE 802.11 spec		frames whose format is specified in IEEE 802.11 spec
	[IEEE-802.11-2016].		[IEEE-802.11-2016].
	The IPv6 packet transmitted on 802.11-OCB are immediately preceded by		The IPv6 packet transmitted on 802.11-OCB are immediately preceded by
	a Logical Link Control (LLC) header and an 802.11 header. In the LLC		a Logical Link Control (LLC) header and an 802.11 header. In the LLC
	header, and in accordance with the EtherType Protocol Discrimination		header, and in accordance with the EtherType Protocol Discrimination
	skipping to change at page 5, line 36 ¶		skipping to change at page 5, line 36 ¶
	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.
	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 A		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
	The steps a host takes in deciding how to autoconfigure its		The steps a host takes in deciding how to autoconfigure its
	interfaces in IPv6 are described in [RFC4862]. This section		interfaces in IPv6 are described in [RFC4862]. This section
	describes the formation of Interface Identifiers for IPv6 addresses		describes the formation of Interface Identifiers for IPv6 addresses
	of type 'Global' or 'Unique Local'. Interface Identifiers for IPv6		of type 'Global' or 'Unique Local'. Interface Identifiers for IPv6
	address of type 'Link-Local' are discussed in Section 4.3.		address of type 'Link-Local' are discussed in Section 4.3.
	skipping to change at page 8, line 31 ¶		skipping to change at page 8, line 31 ¶
	document [IEEE-1609.2] provides security services for certain		document [IEEE-1609.2] provides security services for certain
	applications to use; application-layer mechanisms are out of scope of		applications to use; application-layer mechanisms are out of scope of
	this document. On another hand, a security mechanism provided at		this document. On another hand, a security mechanism provided at
	networking layer, such as IPsec [RFC4301], may provide data security		networking layer, such as IPsec [RFC4301], may provide data security
	protection to a wider range of applications.		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). 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 carda€™s frequency to the proper		setting an interface card's frequency to the proper range). Also, an
	range). Also, an attacker may not heed to legal limits for radio		attacker may not heed to legal limits for radio power and can use a
	power and can use a very sensitive directional antenna; if attackers		very sensitive directional antenna; if attackers wishe to attack a
	wishe to attack a given exchange they do not necessarily need to be		given exchange they do not necessarily need to be in close physical
	in close physical proximity. Hence, such a link is less protected		proximity. Hence, such a link is less protected than commonly used
	than commonly used links (wired link or protected 802.11).		links (wired link or protected 802.11).
	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.A 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]),
	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 hijacking risks. A vehicle embarking an IP-		address spoofing and IP hijacking risks. A vehicle embarking an IP-
	OBU whose egress interface is 802.11-OCB may expose itself to		OBU whose egress interface is 802.11-OCB may expose itself to
	eavesdropping and subsequent correlation of data. This may reveal		eavesdropping and subsequent correlation of data. This may reveal
	skipping to change at page 10, line 21 ¶		skipping to change at page 10, line 21 ¶
	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 may
	be used with input a 256 bit local secret, the 'nominal' MAC Address		be used with input a 256 bit local secret, the 'nominal' MAC Address
	of the interface, and a representation of the date and time of the		of the interface, and a representation of the date and time of the
	renumbering event.		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. Pseudonym Handling		5.3. Pseudonymization impact on confidentiality and trust
	The demand for privacy protection of vehicles' and drivers'
	identities, which could be granted by using a pseudonym or alias
	identity at the same time, may hamper the required confidentiality of
	messages and trust between participants - especially in safety
	critical vehicular communication.
	o Particular challenges arise when the pseudonymization mechanism
	used relies on (randomized) re-addressing.
	o A proper pseudonymization tool operated by a trusted third party
	may be needed to ensure both aspects simultaneously (privacy
	protection on one hand and trust between participants on another
	hand).
	o This is discussed in Section 4.4 and Section 5 of this document.
	o Pseudonymity is also discussed in		Vehicles 'and drivers' privacy relies on pseudonymization mechanisms
	[I-D.ietf-ipwave-vehicular-networking] in its sections 4.2.4 and		such as the ones described in Section 5.2. This pseudonymization
	5.1.2.		means that upper-layer protocols and applications SHOULD NOT rely on
			layer-2 or layer-3 addresses to assume that the other participant can
			be trusted.
	6. IANA Considerations		6. IANA Considerations
	No request to IANA.		No request to IANA.
	7. Contributors		7. Contributors
	Christian Huitema, Tony Li.		Christian Huitema, Tony Li.
	Romain Kuntz contributed extensively about IPv6 handovers between		Romain Kuntz contributed extensively about IPv6 handovers between
	skipping to change at page 11, line 28 ¶		skipping to change at page 11, line 17 ¶
	The authors would like to thank Alexandre Petrescu for initiating		The authors would like to thank Alexandre Petrescu for initiating
	this work and for being the lead author until the version 43 of this		this work and for being the lead author until the version 43 of this
	draft.		draft.
	The authors would like to thank Pascal Thubert for reviewing,		The authors would like to thank Pascal Thubert for reviewing,
	proofreading and suggesting modifications of this document.		proofreading and suggesting modifications of this document.
	The authors would like to thank Mohamed Boucadair for proofreading		The authors would like to thank Mohamed Boucadair for proofreading
	and suggesting modifications of this document.		and suggesting modifications of this document.
			The authors would like to thank Eric Vyncke for reviewing suggesting
			modifications of this document.
	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, Abdussalam Baryun,		Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun,
	Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in		Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in
	't Velt, Katrin Sjoberg, Roland Bless, Tijink Jasja, Kevin Smith,		't Velt, Katrin Sjoberg, Roland Bless, Tijink Jasja, Kevin Smith,
End of changes. 17 change blocks.
	61 lines changed or deleted		52 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/