draft-ietf-ipwave-ipv6-over-80211ocb-39.txt		draft-ietf-ipwave-ipv6-over-80211ocb-40.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 16, 2019 Moulay Ismail University		Expires: October 17, 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 14, 2019		April 15, 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-39		draft-ietf-ipwave-ipv6-over-80211ocb-40
	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 16, 2019.		This Internet-Draft will expire on October 17, 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 47 ¶		skipping to change at page 2, line 47 ¶
	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 . . . . . . . . . 11		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 . . . . . . . . . . . . . . . . . . . . . . 28
	Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 28		Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 28
	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 . . . . . . . . . . . . . 35
	H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 35		H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 36
	H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 38		H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 38
	Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 40		Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 40
	Appendix J. Neighbor Discovery (ND) Potential Issues in Wireless		Appendix J. Neighbor Discovery (ND) Potential Issues in Wireless
	Links . . . . . . . . . . . . . . . . . . . . . . . 41		Links . . . . . . . . . . . . . . . . . . . . . . . 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43		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
	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.
			-40: added a phrase in appendix to further described a condition
			where ND on OCB may not work; that phrase contains a placeholder; the
			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".
	-37: added a section about issues on ND wireless; added the qualifier		-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		'baseline' to using ND on 802.11-OCB; improved the description of the
	reference to 802.11-2016 document, with a qualifier about the		reference to 802.11-2016 document, with a qualifier about the
	skipping to change at page 42, line 20 ¶		skipping to change at page 42, line 20 ¶
	that is compatible with DAD, and that cannot be the set of nodes that		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		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		all the time and does not meet the DAD requirements for a link local
	address that could possibly be used anytime, anywhere. The generic		address that could possibly be used anytime, anywhere. The generic
	expectation of a reliable multicast is not ensured, and the operation		expectation of a reliable multicast is not ensured, and the operation
	of DAD and AR (Address Resolution) as specificed by RFC 4861 cannot		of DAD and AR (Address Resolution) as specificed by RFC 4861 cannot
	be guaranteed. Moreoever, multicast transmissions that rely on		be guaranteed. Moreoever, multicast transmissions that rely on
	broadcast are not only unreliable but are also often detrimental to		broadcast are not only unreliable but are also often detrimental to
	unicast traffic (see [draft-ietf-mboned-ieee802-mcast-problems]).		unicast traffic (see [draft-ietf-mboned-ieee802-mcast-problems]).
	Early experiences indicate that it should be possible to exchange		Early experience indicates that it should be possible to exchange
	IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR		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		(Address Resolution) in good conditions. However, this does not
			apply if TBD TBD TBD. In the absence of a correct DAD operation, a
	node that relies only on IPv6 ND for AR and DAD over OCB should		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		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		than DAD. It must be noted that deriving an IPv6 address from a
	globally unique MAC address has this property but may yield privacy		globally unique MAC address has this property but may yield privacy
	issues.		issues.
	RFC 8505 provides a more recent approach to IPv6 ND and in particular		RFC 8505 provides a more recent approach to IPv6 ND and in particular
	DAD. RFC 8505 is designed to fit wireless and otherwise constrained		DAD. RFC 8505 is designed to fit wireless and otherwise constrained
	networks whereby multicast and/or continuous access to the medium may		networks whereby multicast and/or continuous access to the medium may
	not be guaranteed. RFC 8505 Section 5.6 "Link-Local Addresses and		not be guaranteed. RFC 8505 Section 5.6 "Link-Local Addresses and
End of changes. 9 change blocks.
	9 lines changed or deleted		14 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/