draft-ietf-ipwave-ipv6-over-80211ocb-36.txt		draft-ietf-ipwave-ipv6-over-80211ocb-37.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 10, 2019 Moulay Ismail University		Expires: October 11, 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 8, 2019		April 9, 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-36		draft-ietf-ipwave-ipv6-over-80211ocb-37
	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 10, 2019.		This Internet-Draft will expire on October 11, 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 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Communication Scenarios where IEEE 802.11-OCB Links are Used 4		3. Communication Scenarios where IEEE 802.11-OCB Links are Used 4
	4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 4		4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 5
	4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 4		4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5
	4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5		4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5
	4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5		4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5
	4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7		4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7
	4.4. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7		4.4. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7
	4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 8		4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 8
	4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 8		4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 8
	4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 8		4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 8
	4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 8		4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10		5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10
	5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 10		5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 10
	5.2. MAC Address and Interface ID Generation . . . . . . . . . 10		5.2. MAC Address and Interface ID Generation . . . . . . . . . 11
	5.3. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 11		5.3. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . 15		9.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 17		Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 17
	Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 27		Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 27
	Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 27		Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 27
	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 . . . 32		become a 802.11-OCB driver . . . 32
	Appendix E. Protocol Layering . . . . . . . . . . . . . . . . . 33		Appendix E. Protocol Layering . . . . . . . . . . . . . . . . . 33
	Appendix F. Design Considerations . . . . . . . . . . . . . . . 34		Appendix F. Design Considerations . . . . . . . . . . . . . . . 34
	Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 34		Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 34
	Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 34		Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 34
	H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 35		H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 35
	H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 38		H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 38
	Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 40		Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 40
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41		Appendix J. Neighbor Discovery (ND) Potential Issues in Wireless
			Links . . . . . . . . . . . . . . . . . . . . . . . 41
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
	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 9, line 15 ¶		skipping to change at page 9, line 15 ¶
	cases, the exclusive use of IPv6 link-local addresses is RECOMMENDED.		cases, the exclusive use of IPv6 link-local addresses is RECOMMENDED.
	Additionally, even if the timing requirements are not very strict		Additionally, even if the timing requirements are not very strict
	(e.g. the moving subnet formed by two following vehicles is stable, a		(e.g. the moving subnet formed by two following vehicles is stable, a
	fixed IP-RSU is absent), the subnet is disconnected from the Internet		fixed IP-RSU is absent), the subnet is disconnected from the Internet
	(a default route is absent), and the addressing peers are equally		(a default route is absent), and the addressing peers are equally
	qualified (impossible to determine that some vehicle owns and		qualified (impossible to determine that some vehicle owns and
	distributes addresses to others) the use of link-local addresses is		distributes addresses to others) the use of link-local addresses is
	RECOMMENDED.		RECOMMENDED.
	The Neighbor Discovery protocol (ND) [RFC4861] MUST be used over		The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be used
	802.11-OCB links.		over 802.11-OCB links. Transmitting ND packets may prove to have
			some performance issues. These issues may be exacerbated in OCB
			mode. Solutions for these problems SHOULD consider the OCB mode of
			operation. The best of current knowledge indicates the kinds of
			issues that may arise with ND in OCB mode; they are described in
			Appendix J.
	Protocols like Mobile IPv6 [RFC6275] and DNAv6 [RFC6059], which		Protocols like Mobile IPv6 [RFC6275] and DNAv6 [RFC6059], which
	depend on timely movement detection, might need additional tuning		depend on timely movement detection, might need additional tuning
	work to handle the lack of link-layer notifications during handover.		work to handle the lack of link-layer notifications during handover.
	This is for further study.		This is for further study.
	5. Security Considerations		5. Security Considerations
	Any security mechanism at the IP layer or above that may be carried		Any security mechanism at the IP layer or above that may be carried
	out for the general case of IPv6 may also be carried out for IPv6		out for the general case of IPv6 may also be carried out for IPv6
	skipping to change at page 17, line 12 ¶		skipping to change at page 17, line 12 ¶
	http://ieeexplore.ieee.org/document/7435228/ accessed on		http://ieeexplore.ieee.org/document/7435228/ accessed on
	August 17th, 2017.".		August 17th, 2017.".
	[IEEE-802.11-2016]		[IEEE-802.11-2016]
	"IEEE Standard 802.11-2016 - IEEE Standard for Information		"IEEE Standard 802.11-2016 - IEEE Standard for Information
	Technology - Telecommunications and information exchange		Technology - Telecommunications and information exchange
	between systems Local and metropolitan area networks -		between systems Local and metropolitan area networks -
	Specific requirements - Part 11: Wireless LAN Medium		Specific requirements - Part 11: Wireless LAN Medium
	Access Control (MAC) and Physical Layer (PHY)		Access Control (MAC) and Physical Layer (PHY)
	Specifications. Status - Active Standard. Description		Specifications. Status - Active Standard. Description
	retrieved freely on September 12th, 2017, at URL		retrieved freely; the document itself is also freely
			available, but with some difficulty (requires
			registration); description and document retrieved on April
			8th, 2019, starting from URL
	https://standards.ieee.org/findstds/		https://standards.ieee.org/findstds/
	standard/802.11-2016.html".		standard/802.11-2016.html".
	[IEEE-802.11p-2010]		[IEEE-802.11p-2010]
	"IEEE Std 802.11p (TM)-2010, IEEE Standard for Information		"IEEE Std 802.11p (TM)-2010, IEEE Standard for Information
	Technology - Telecommunications and information exchange		Technology - Telecommunications and information exchange
	between systems - Local and metropolitan area networks -		between systems - Local and metropolitan area networks -
	Specific requirements, Part 11: Wireless LAN Medium Access		Specific requirements, Part 11: Wireless LAN Medium Access
	Control (MAC) and Physical Layer (PHY) Specifications,		Control (MAC) and Physical Layer (PHY) Specifications,
	Amendment 6: Wireless Access in Vehicular Environments;		Amendment 6: Wireless Access in Vehicular Environments;
	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.
			-37: added a section about issues on ND wireless; added the qualifier
			'baseline' to using ND on 802.11-OCB; improved the description of the
			reference to 802.11-2016 document, with a qualifier about the
			difficulty of accessing it, even though it is free.
	-36: removed a phrase about the IID formation and MAC generation, but		-36: removed a phrase about the IID formation and MAC generation, but
	left in the section 5.2 that describes how it happens.		left in the section 5.2 that describes how it happens.
	-35: addressing the the intarea review: clarified a small apparent		-35: addressing the the intarea review: clarified a small apparent
	contradiction between two parts of text that use the old MAC-based		contradiction between two parts of text that use the old MAC-based
	IIDs (clarified by using qualifiers from each other: transition time,		IIDs (clarified by using qualifiers from each other: transition time,
	and ll addresses); sequenced closer the LL and Stateless Autoconf		and ll addresses); sequenced closer the LL and Stateless Autoconf
	sections, instead of spacing them; shortened the paragraph of Opaque		sections, instead of spacing them; shortened the paragraph of Opaque
	IIDs; moved the privacy risks of in-clear IIDs in the security		IIDs; moved the privacy risks of in-clear IIDs in the security
	section; removed a short phrase duplicating the idea of privacy		section; removed a short phrase duplicating the idea of privacy
	skipping to change at page 41, line 32 ¶		skipping to change at page 41, line 32 ¶
	carried, but it may only operate when the vehicle or hand- carried		carried, but it may only operate when the vehicle or hand- carried
	unit is stationary. Furthermore, an RSU operating under the		unit is stationary. Furthermore, an RSU operating under the
	respectgive part is restricted to the location where it is licensed		respectgive part is restricted to the location where it is licensed
	to operate. However, portable or hand-held RSUs are permitted to		to operate. However, portable or hand-held RSUs are permitted to
	operate where they do not interfere with a site-licensed operation.		operate where they do not interfere with a site-licensed operation.
	A RSU broadcasts data to OBUs or exchanges data with OBUs in its		A RSU broadcasts data to OBUs or exchanges data with OBUs in its
	communications zone. An RSU also provides channel assignments and		communications zone. An RSU also provides channel assignments and
	operating instructions to OBUs in its communications zone, when		operating instructions to OBUs in its communications zone, when
	required. - [CFR 90.7 - Definitions].		required. - [CFR 90.7 - Definitions].
			Appendix J. Neighbor Discovery (ND) Potential Issues in Wireless Links
			IPv6 Neighbor Discovery (IPv6 ND) [RFC4861][RFC4862] was designed for
			point-to-point and transit links such as Ethernet, with the
			expectation of a cheap and reliable support for multicast from the
			lower layer. Section 3.2 of RFC 4861 indicates that the operation on
			Shared Media and on non-broadcast multi-access (NBMA) networks
			require additional support, e.g., for Address Resolution (AR) and
			duplicate address detection (DAD), which depend on multicast. An
			infrastructureless radio network such as OCB shares properties with
			both Shared Media and NBMA networks, and then adds its own
			complexity, e.g., from movement and interference that allow only
			transient and non-transitive reachability between any set of peers.
			The uniqueness of an address within a scoped domain is a key pillar
			of IPv6 and the base for unicast IP communication. RFC 4861 details
			the DAD method to avoid that an address is duplicated. For a link
			local address, the scope is the link, whereas for a global address
			the scope is much larger. The underlying assumption for DAD to
			operate correctly is that the node that owns an IPv6 address can
			reach any other node within the scope at the time it claims its
			address, which is done by sending a NS multicast message, and can
			hear any future claim for that address by another party within the
			scope for the duration of the address ownership.
			In the case of OCB, there is a potentially a need to define a scope
			that is compatible with DAD, and that cannot be the set of nodes that
			a transmitter can reach at a particular time, because that set varies
			all the time and does not meet the DAD requirements for a link local
			address that could possibly be used anytime, anywhere. The generic
			expectation of a reliable multicast is not ensured, and the operation
			of DAD and AR (Address Resolution) as specificed by RFC 4861 cannot
			be guaranteed. Moreoever, multicast transmissions that rely on
			broadcast are not only unreliable but are also often detrimental to
			unicast traffic (see [draft-ietf-mboned-ieee802-mcast-problems]).
			Early experiences indicate that it should be possible to exchange
			IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR
			(Address Resolution). In the absence of a correct DAD operation, a
			node that relies only on IPv6 ND for AR and DAD over OCB should
			ensure that the addresses that it uses are unique by means others
			than DAD. It must be noted that deriving an IPv6 address from a
			globally unique MAC address has this property but may yield privacy
			issues.
			RFC 8505 provides a more recent approach to IPv6 ND and in particular
			DAD. RFC 8505 is designed to fit wireless and otherwise constrained
			networks whereby multicast and/or continuous access to the medium may
			not be guaranteed. RFC 8505 Section 5.6 "Link-Local Addresses and
			Registration" indicates that the scope of uniqueness for a link local
			address is restricted to a pair of nodes that use it to communicate,
			and provides a method to assert the uniqueness and resolve the link-
			Layer address using a unicast exchange.
			RFC 8505 also enables a router (acting as a 6LR) to own a prefix and
			act as a registrar (acting as a 6LBR) for addresses within the
			associated subnet. A peer host (acting as a 6LN) registers an
			address derived from that prefix and can use it for the lifetime of
			the registration. The prefix is advertised as not onlink, which
			means that the 6LN uses the 6LR to relay its packets within the
			subnet, and participation to the subnet is constrained to the time of
			reachability to the 6LR. Note that RSU that provides internet
			connectivity MAY announce a default router preference [RFC 4191],
			whereas a car that does not provide that connectivity MUST NOT do so.
			This operation presents similarities with that of an access point,
			but at Layer-3. This is why RFC 8505 well-suited for wireless in
			general.
			Support of RFC 8505 is may be implemented on OCB. OCB nodes that
			support RFC 8505 would support the 6LN operation in order to act as a
			host, and may support the 6LR and 6LBR operations in order to act as
			a router and in particular own a prefix that can be used by RFC
			8505-compliant hosts for address autoconfiguration and registration.
	Authors' Addresses		Authors' Addresses
	Alexandre Petrescu		Alexandre Petrescu
	CEA, LIST		CEA, LIST
	CEA Saclay		CEA Saclay
	Gif-sur-Yvette , Ile-de-France 91190		Gif-sur-Yvette , Ile-de-France 91190
	France		France
	Phone: +33169089223		Phone: +33169089223
	Email: Alexandre.Petrescu@cea.fr		Email: Alexandre.Petrescu@cea.fr
End of changes. 11 change blocks.
	11 lines changed or deleted		100 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/