< 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/