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/