draft-ietf-ipwave-ipv6-over-80211ocb-48.txt		draft-ietf-ipwave-ipv6-over-80211ocb-49.txt
	IPWAVE Working Group N. Benamar		IPWAVE Working Group N. Benamar
	Internet-Draft Moulay Ismail University		Internet-Draft Moulay Ismail University of Meknes
	Intended status: Standards Track J. Haerri		Intended status: Standards Track J. Haerri
	Expires: January 7, 2020 Eurecom		Expires: January 9, 2020 Eurecom
	J. Lee		J. Lee
	Sangmyung University		Sangmyung University
	T. Ernst		T. Ernst
	YoGoKo		YoGoKo
	July 6, 2019		July 8, 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 (IPv6-over-80211-OCB)
	draft-ietf-ipwave-ipv6-over-80211ocb-48		draft-ietf-ipwave-ipv6-over-80211ocb-49
	Abstract		Abstract
	This document provides methods and settings, and describes		This document provides methods and settings, and describes
	limitations, for using IPv6 to communicate among nodes in range of		limitations, for using IPv6 to communicate among nodes in range of
	one another over a single IEEE 802.11-OCB link. This support does		one another over a single IEEE 802.11-OCB link. This support does
	only require minimal changes to existing stacks. Optimizations and		only require minimal changes to existing stacks. 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.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 7, 2020.		This Internet-Draft will expire on January 9, 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 36 ¶		skipping to change at page 2, line 36 ¶
	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. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . 15		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 . . . 21
	Appendix D. Protocol Layering . . . . . . . . . . . . . . . . . 22		Appendix D. Protocol Layering . . . . . . . . . . . . . . . . . 22
	Appendix E. Design Considerations . . . . . . . . . . . . . . . 23		Appendix E. Design Considerations . . . . . . . . . . . . . . . 23
	Appendix F. IEEE 802.11 Messages Transmitted in OCB mode . . . . 23		Appendix F. IEEE 802.11 Messages Transmitted in OCB mode . . . . 23
	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 . . . . . . . . . . . . . . . . . 27
	Appendix H. Extra Terminology . . . . . . . . . . . . . . . . . 29		Appendix H. Extra Terminology . . . . . . . . . . . . . . . . . 29
	Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless		Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless
	Links . . . . . . . . . . . . . . . . . . . . . . . 30		Links . . . . . . . . . . . . . . . . . . . . . . . 30
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
	1. Introduction		1. Introduction
	This document provides a baseline with limitations for using IPv6 to		This document provides a baseline with limitations for using IPv6 to
	communicate among nodes in range of one another over a single IEEE		communicate among nodes in range of one another over a single IEEE
	802.11-OCB link [IEEE-802.11-2016] (a.k.a., "802.11p" see Appendicies		802.11-OCB link [IEEE-802.11-2016] (a.k.a., "802.11p" see Appendix A,
	Appendix A, Appendix B and Appendix C) with minimal changes to		Appendix B and Appendix C) with minimal changes to existing stacks.
	existing stacks. Moreover, the document identifies limitations of		Moreover, the document identifies limitations of such usage.
	such usage. Concretly, the document describes the layering of IPv6		Concretly, the document describes the layering of IPv6 networking on
	networking on top of the IEEE Std 802.11 MAC layer or an IEEE Std		top of the IEEE Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer
	802.3 MAC layer with a frame translation underneath. The resulting		with a frame translation underneath. The resulting stack inherits
	stack inherits from IPv6 over Ethernet [RFC 2464], but operates over		from IPv6 over Ethernet [RFC 2464], but operates over 802.11-OCB to
	802.11-OCB to provide at least P2P (Point to Point) connectivity		provide at least P2P (Point to Point) connectivity using IPv6 ND and
	using IPv6 ND and link-local addresses.		link-local 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 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], [RFC2464] .		described in [RFC1042], [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
	movement detection. Security and privacy recommendations are		movement detection. Security and privacy recommendations are
	discussed in Section 5 and Section 4.4. The subnet structure is		discussed in Section 5 and Section 4.4. The subnet structure is
	described in Section 4.6. The movement detection on OCB links is		described in Section 4.6. The movement detection on OCB links is
	skipping to change at page 5, line 42 ¶		skipping to change at page 5, line 42 ¶
	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 A
	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 IP6 are described in [RFC4862]. This section describes		interfaces in IPv6 are described in [RFC4862]. This section
	the formation of Interface Identifiers for IPv6 addresses of type		describes the formation of Interface Identifiers for IPv6 addresses
	'Global' or 'Unique Local'. For Interface Identifiers for IPv6		of type 'Global' or 'Unique Local'. For Interface Identifiers for
	address of type 'Link-Local' are discussed in Section 4.3.		IPv6 address of type 'Link-Local' are discussed in Section 4.3.
	The RECOMMENDED method for forming stable Interface Identifiers		The RECOMMENDED method for forming stable Interface Identifiers
	(IIDs) is described in [RFC8064]. The method of forming IIDs		(IIDs) is described in [RFC8064]. The method of forming IIDs
	described in Section 4 of [RFC2464] MAY be used during transition		described in Section 4 of [RFC2464] MAY be used during transition
	time, in particular for IPv6 link-local addresses. Regardless of how		time, in particular for IPv6 link-local addresses. Regardless of how
	to form the IID, its length is 64 bits, as is the case of the IPv6		to form the IID, its length is 64 bits, as is the case of the IPv6
	over Ethernet [RFC2464].		over Ethernet [RFC2464].
	The bits in the IID have no specific meaning and the identifier		The bits in the IID have no specific meaning and the identifier
	should be treated as an opaque value. The bits 'Universal' and		should be treated as an opaque value. The bits 'Universal' and
	'Group' in the identifier of an 802.11-OCB interface are significant,		'Group' in the identifier of an 802.11-OCB interface are significant,
	as this is an IEEE link-layer address. The details of this		as this is an IEEE link-layer address. The details of this
	significance are described in [RFC7136].		significance are described in [RFC7136].
	Semantically opaque IIDs, instead of meaningful IIs derived from a		Semantically opaque IIDs, instead of meaningful IIDs derived from a
	valid and meaningful MAC address ([RFC2464], Section 4), help avoid		valid and meaningful MAC address ([RFC2464], Section 4), help avoid
	certain privacy risks (see the risks mentioned in Section 5.1.1). If		certain privacy risks (see the risks mentioned in Section 5.1.1). If
	semantically opaque IIDs are needed, they MAY be generated using the		semantically opaque IIDs are needed, they MAY be generated using the
	method for generating semantically opaque IIDs with IPv6 Stateless		method for generating semantically opaque IIDs with IPv6 Stateless
	Address Autoconfiguration given in [RFC7217]. Typically, an opaque		Address Autoconfiguration given in [RFC7217]. Typically, an opaque
	IID is formed starting from identifiers different than the MAC		IID is formed starting from identifiers different than the MAC
	addresses, and from cryptographically strong material. Thus, privacy		addresses, and from cryptographically strong material. Thus, privacy
	sensitive information is absent from Interface IDs, because it is		sensitive information is absent from Interface IDs, because it is
	impossible to calculate back the initial value from which the		impossible to calculate back the initial value from which the
	Interface ID was first generated.		Interface ID was first generated.
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 40 ¶
	4.5. Address Mapping		4.5. Address Mapping
	Unicast and multicast address mapping MUST follow the procedures		Unicast and multicast address mapping MUST follow the procedures
	specified for Ethernet interfaces specified in Sections 6 and 7 of		specified for Ethernet interfaces specified in Sections 6 and 7 of
	[RFC2464].		[RFC2464].
	4.5.1. Address Mapping -- Unicast		4.5.1. Address Mapping -- Unicast
	This document is scoped for Address Resolution (AR) and Duplicate		This document is scoped for Address Resolution (AR) and Duplicate
	Address Detection (DAD) per RFC 4861 [RFC4861].		Address Detection (DAD) per [RFC4862].
	4.5.2. Address Mapping -- Multicast		4.5.2. Address Mapping -- Multicast
	The multicast address mapping is performed according to the method		The multicast address mapping is performed according to the method
	specified in section 7 of [RFC2464]. The meaning of the value "3333"		specified in section 7 of [RFC2464]. The meaning of the value "3333"
	mentioned in that section 7 of [RFC2464] is defined in section 2.3.1		mentioned in that section 7 of [RFC2464] is defined in section 2.3.1
	of [RFC7042].		of [RFC7042].
	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
	skipping to change at page 12, line 20 ¶		skipping to change at page 12, line 20 ¶
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet		[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
	Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,		Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
	<https://www.rfc-editor.org/info/rfc2464>.		<https://www.rfc-editor.org/info/rfc2464>.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	DOI 10.17487/RFC2818, May 2000,
	<https://www.rfc-editor.org/info/rfc2818>.
	[RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related
	Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004,
	<https://www.rfc-editor.org/info/rfc3753>.
	[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
	Thubert, "Network Mobility (NEMO) Basic Support Protocol",
	RFC 3963, DOI 10.17487/RFC3963, January 2005,
	<https://www.rfc-editor.org/info/rfc3963>.
	[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
	"SEcure Neighbor Discovery (SEND)", RFC 3971,
	DOI 10.17487/RFC3971, March 2005,
	<https://www.rfc-editor.org/info/rfc3971>.
	[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
	RFC 3972, DOI 10.17487/RFC3972, March 2005,
	<https://www.rfc-editor.org/info/rfc3972>.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,		DOI 10.17487/RFC4086, June 2005,
	<https://www.rfc-editor.org/info/rfc4086>.		<https://www.rfc-editor.org/info/rfc4086>.
	[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast		[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
	Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,		Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
	<https://www.rfc-editor.org/info/rfc4193>.		<https://www.rfc-editor.org/info/rfc4193>.
	[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,		[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
	skipping to change at page 16, line 31 ¶		skipping to change at page 16, line 17 ¶
	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.".
			[RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related
			Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004,
			<https://www.rfc-editor.org/info/rfc3753>.
			[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
			Thubert, "Network Mobility (NEMO) Basic Support Protocol",
			RFC 3963, DOI 10.17487/RFC3963, January 2005,
			<https://www.rfc-editor.org/info/rfc3963>.
			[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
			"SEcure Neighbor Discovery (SEND)", RFC 3971,
			DOI 10.17487/RFC3971, March 2005,
			<https://www.rfc-editor.org/info/rfc3971>.
			[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
			RFC 3972, DOI 10.17487/RFC3972, March 2005,
			<https://www.rfc-editor.org/info/rfc3972>.
	Appendix A. 802.11p		Appendix A. 802.11p
	The term "802.11p" is an earlier definition. The behaviour of		The term "802.11p" is an earlier definition. The behaviour of
	"802.11p" networks is rolled in the document IEEE Std 802.11-2016.		"802.11p" networks is rolled in the document IEEE Std 802.11-2016.
	In that document the term 802.11p disappears. Instead, each 802.11p		In that document the term 802.11p disappears. Instead, each 802.11p
	feature is conditioned by the IEEE Management Information Base (MIB)		feature is conditioned by the IEEE Management Information Base (MIB)
	attribute "OCBActivated" [IEEE-802.11-2016]. Whenever OCBActivated		attribute "OCBActivated" [IEEE-802.11-2016]. Whenever OCBActivated
	is set to true the IEEE Std 802.11-OCB state is activated. For		is set to true the IEEE Std 802.11-OCB state is activated. For
	example, an 802.11 STAtion operating outside the context of a basic		example, an 802.11 STAtion operating outside the context of a basic
	service set has the OCBActivated flag set. Such a station, when it		service set has the OCBActivated flag set. Such a station, when it
	skipping to change at page 32, line 14 ¶		skipping to change at page 32, line 14 ¶
	Support of RFC 8505 may be implemented on OCB. OCB nodes that		Support of RFC 8505 may be implemented on OCB. OCB nodes that
	support RFC 8505 SHOULD support the 6LN operation in order to act as		support RFC 8505 SHOULD support the 6LN operation in order to act as
	a host, and may support the 6LR and 6LBR operations in order to act		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		as a router and in particular own a prefix that can be used by RFC
	8505-compliant hosts for address autoconfiguration and registration.		8505-compliant hosts for address autoconfiguration and registration.
	Authors' Addresses		Authors' Addresses
	Nabil Benamar		Nabil Benamar
	Moulay Ismail University		Moulay Ismail University of Meknes
	Morocco		Morocco
	Phone: +212670832236		Phone: +212670832236
	Email: n.benamar@est.umi.ac.ma		Email: n.benamar@est.umi.ac.ma
	Jerome Haerri		Jerome Haerri
	Eurecom		Eurecom
	Sophia-Antipolis 06904		Sophia-Antipolis 06904
	France		France
End of changes. 14 change blocks.
	45 lines changed or deleted		41 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/