draft-ietf-ipwave-ipv6-over-80211ocb-40.txt		draft-ietf-ipwave-ipv6-over-80211ocb-41.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: October 17, 2019 Moulay Ismail University		Expires: October 18, 2019 Moulay Ismail University
	J. Haerri		J. Haerri
	Eurecom		Eurecom
	J. Lee		J. Lee
	Sangmyung University		Sangmyung University
	T. Ernst		T. Ernst
	YoGoKo		YoGoKo
	April 15, 2019		April 16, 2019
	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-40		draft-ietf-ipwave-ipv6-over-80211ocb-41
	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 October 17, 2019.		This Internet-Draft will expire on October 18, 2019.
	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 43 ¶		skipping to change at page 3, line 43 ¶
	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
	movement detection. For security and privacy recommendations see		movement detection. For security and privacy recommendations see
	Section 5 and Section 4.4. The subnet structure is described in		Section 5 and Section 4.4. The subnet structure is described in
	Section 4.6. The movement detection on OCB links is not described		Section 4.6. The movement detection on OCB links is not described
	in this document.		in this document.
	In the published literature, many documents describe aspects and		In the published literature, many documents describe aspects and
	problems related to running IPv6 over 802.11-OCB:		problems related to running IPv6 over 802.11-OCB:
	[I-D.ietf-ipwave-vehicular-networking-survey].		[I-D.ietf-ipwave-vehicular-networking].
	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", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	IP-OBU (Internet Protocol On-Board Unit): an IP-OBU is a computer		IP-OBU (Internet Protocol On-Board Unit): an IP-OBU is a computer
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	attribute dot11OCBActivited is true. Note: compliance with standards		attribute dot11OCBActivited is true. Note: compliance with standards
	and regulations set in different countries when using the 5.9GHz		and regulations set in different countries when using the 5.9GHz
	frequency band is required.		frequency band is required.
	3. Communication Scenarios where IEEE 802.11-OCB Links are Used		3. Communication Scenarios where IEEE 802.11-OCB Links are Used
	The IEEE 802.11-OCB Networks are used for vehicular communications,		The IEEE 802.11-OCB Networks are used for vehicular communications,
	as 'Wireless Access in Vehicular Environments'. The IP communication		as 'Wireless Access in Vehicular Environments'. The IP communication
	scenarios for these environments have been described in several		scenarios for these environments have been described in several
	documents; in particular, we refer the reader to		documents; in particular, we refer the reader to
	[I-D.ietf-ipwave-vehicular-networking-survey], that lists some		[I-D.ietf-ipwave-vehicular-networking], that lists some scenarios and
	scenarios and requirements for IP in Intelligent Transportation		requirements for IP in Intelligent Transportation Systems.
	Systems.
	The link model is the following: STA --- 802.11-OCB --- STA. In		The link model is the following: STA --- 802.11-OCB --- STA. In
	vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. While		vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. While
	802.11-OCB is clearly specified, and the use of IPv6 over such link		802.11-OCB is clearly specified, and the use of IPv6 over such link
	is not radically new, the operating environment (vehicular networks)		is not radically new, the operating environment (vehicular networks)
	brings in new perspectives.		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)
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 40 ¶
	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. 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.
	4.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 by their in-vehicle interfaces). This		that are in close range (not by their in-vehicle interfaces). A
	subnet MUST use at least the link-local prefix and the interfaces		Prefix List conceptual data structure ([RFC4861] section 5.1) is
	MUST be assigned IPv6 address(es) of type link-local. All nodes in		maintained for each 802.11-OCB interface.
	the subnet MUST be able to communicate directly using their link-
	local unicast addresses.		All nodes in the subnet MUST be able to communicate directly using
			their link-local unicast addresses.
	The structure of this subnet is ephemeral, in that it is strongly		The structure of this subnet is ephemeral, in that it is strongly
	influenced by the mobility of vehicles: the hidden terminal effects		influenced by the mobility of vehicles: the hidden terminal effects
	appear; the 802.11 networks in OCB mode may be considered as 'ad-hoc'		appear; the 802.11 networks in OCB mode may be considered as 'ad-hoc'
	networks with an addressing model as described in [RFC5889]. On		networks with an addressing model as described in [RFC5889]. On
	another hand, the structure of the internal subnets in each car is		another hand, the structure of the internal subnets in each car is
	relatively stable.		relatively stable.
	As recommended in [RFC5889], when the timing requirements are very		As recommended in [RFC5889], when the timing requirements are very
	strict (e.g. fast drive through IP-RSU coverage), no on-link subnet		strict (e.g. fast drive through IP-RSU coverage), no on-link subnet
	skipping to change at page 12, line 10 ¶		skipping to change at page 12, line 10 ¶
	used relies on (randomized) re-addressing.		used relies on (randomized) re-addressing.
	o A proper pseudonymization tool operated by a trusted third party		o A proper pseudonymization tool operated by a trusted third party
	may be needed to ensure both aspects simultaneously (privacy		may be needed to ensure both aspects simultaneously (privacy
	protection on one hand and trust between participants on another		protection on one hand and trust between participants on another
	hand).		hand).
	o This is discussed in Section 4.4 and Section 5 of this document.		o This is discussed in Section 4.4 and Section 5 of this document.
	o Pseudonymity is also discussed in		o Pseudonymity is also discussed in
	[I-D.ietf-ipwave-vehicular-networking-survey] in its sections		[I-D.ietf-ipwave-vehicular-networking] in its sections 4.2.4 and
	4.2.4 and 5.1.2.		5.1.2.
	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 16, line 15 ¶		skipping to change at page 16, line 15 ¶
	[ETSI-sec-archi]		[ETSI-sec-archi]
	"ETSI TS 102 940 V1.2.1 (2016-11), ETSI Technical		"ETSI TS 102 940 V1.2.1 (2016-11), ETSI Technical
	Specification, Intelligent Transport Systems (ITS);		Specification, Intelligent Transport Systems (ITS);
	Security; ITS communications security architecture and		Security; ITS communications security architecture and
	security management, November 2016. Downloaded on		security management, November 2016. Downloaded on
	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.ietf-ipwave-vehicular-networking-survey]		[I-D.ietf-ipwave-vehicular-networking]
	Jeong, J., Cespedes, S., Benamar, N., Haerri, J., and M.		Jeong, J., "IP Wireless Access in Vehicular Environments
	Wetterwald, "Survey on IP-based Vehicular Networking for		(IPWAVE): Problem Statement and Use Cases", draft-ietf-
	Intelligent Transportation Systems", draft-ietf-ipwave-		ipwave-vehicular-networking-08 (work in progress), March
	vehicular-networking-survey-00 (work in progress), July		2019.
	2017.
	[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-04 (work		Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work
	in progress), November 2018.		in progress), November 2018.
	[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
	skipping to change at page 17, line 36 ¶		skipping to change at page 17, line 36 ¶
	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.
			-41: updated a reference from draft-ietf-ipwave-vehicular-networking-
			survey to draft-ietf-ipwave-vehicular-networking; clarified the link-
			local text by eliminating link-local addresses and prefixes
			altogether and referring to RFC4861 which requires the prefixes;
			added a statement about the subnet being a not multi-link subnet.
	-40: added a phrase in appendix to further described a condition		-40: added a phrase in appendix to further described a condition
	where ND on OCB may not work; that phrase contains a placeholder; the		where ND on OCB may not work; that phrase contains a placeholder; the
	placeholder is 'TBD' (To Be Defined).		placeholder is 'TBD' (To Be Defined).
	-39: removed a reference to an expired draft trying to update the		-39: removed a reference to an expired draft trying to update the
	IPv6-over-Ethernet spec 'RFC2464bis'; added text in the subnet		IPv6-over-Ethernet spec 'RFC2464bis'; added text in the subnet
	structure section saying nodes MUST be able to communicate directly		structure section saying nodes MUST be able to communicate directly
	using their link-local addresses.		using their link-local addresses.
	-38: removed the word "fe80::/10".		-38: removed the word "fe80::/10".
End of changes. 10 change blocks.
	21 lines changed or deleted		26 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/