draft-ietf-ipwave-ipv6-over-80211ocb-41.txt		draft-ietf-ipwave-ipv6-over-80211ocb-42.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 18, 2019 Moulay Ismail University		Expires: October 19, 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 16, 2019		April 17, 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-41		draft-ietf-ipwave-ipv6-over-80211ocb-42
	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 18, 2019.		This Internet-Draft will expire on October 19, 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 8, line 44 ¶		skipping to change at page 8, line 44 ¶
	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). A		that are in close range (not by their in-vehicle interfaces). A
	Prefix List conceptual data structure ([RFC4861] section 5.1) is		Prefix List conceptual data structure ([RFC4861] section 5.1) is
	maintained for each 802.11-OCB interface.		maintained for each 802.11-OCB interface.
	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
	prefix should be configured on an 802.11-OCB interface. In such		prefix should be configured on an 802.11-OCB interface. In such
	skipping to change at page 11, line 35 ¶		skipping to change at page 11, line 35 ¶
	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. A MAC address		randomized MAC address, except the length in bits. A MAC address
	SHOULD be of length 48 decimal. An Interface ID SHOULD be of length		SHOULD be of length 48 decimal. An Interface ID SHOULD be of length
	64 decimal for all types of IPv6 addresses. In the particular case		specified in other documents.
	of IPv6 link-local addresses, the length of the Interface ID MAY be
	118 decimal.
	5.3. Pseudonym Handling		5.3. Pseudonym Handling
	The demand for privacy protection of vehicles' and drivers'		The demand for privacy protection of vehicles' and drivers'
	identities, which could be granted by using a pseudonym or alias		identities, which could be granted by using a pseudonym or alias
	identity at the same time, may hamper the required confidentiality of		identity at the same time, may hamper the required confidentiality of
	messages and trust between participants - especially in safety		messages and trust between participants - especially in safety
	critical vehicular communication.		critical vehicular communication.
	o Particular challenges arise when the pseudonymization mechanism		o Particular challenges arise when the pseudonymization mechanism
	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.
			-42: removed 118 len IID; points to 'other documents' for the length
			of Interface ID; removed 'directly using' phrase for LLs in a subnet.
	-41: updated a reference from draft-ietf-ipwave-vehicular-networking-		-41: updated a reference from draft-ietf-ipwave-vehicular-networking-
	survey to draft-ietf-ipwave-vehicular-networking; clarified the link-		survey to draft-ietf-ipwave-vehicular-networking; clarified the link-
	local text by eliminating link-local addresses and prefixes		local text by eliminating link-local addresses and prefixes
	altogether and referring to RFC4861 which requires the prefixes;		altogether and referring to RFC4861 which requires the prefixes;
	added a statement about the subnet being a not multi-link subnet.		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).
End of changes. 7 change blocks.
	10 lines changed or deleted		8 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/