draft-ietf-ipwave-ipv6-over-80211ocb-46.txt   draft-ietf-ipwave-ipv6-over-80211ocb-47.txt 
IPWAVE Working Group N. Benamar IPWAVE Working Group N. Benamar
Internet-Draft Moulay Ismail University Internet-Draft Moulay Ismail University
Intended status: Standards Track J. Haerri Intended status: Standards Track J. Haerri
Expires: December 9, 2019 Eurecom Expires: December 29, 2019 Eurecom
J. Lee J. Lee
Sangmyung University Sangmyung University
T. Ernst T. Ernst
YoGoKo YoGoKo
June 7, 2019 June 27, 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-46 draft-ietf-ipwave-ipv6-over-80211ocb-47
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 with minimal change to one another over a single IEEE 802.11-OCB link with minimal change to
existing stacks. Optimizations and usage of IPv6 over more complex existing stacks. Optimizations and usage of IPv6 over more complex
scenarios is not covered and is subject of future work. scenarios is not covered and is subject of future work.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 December 9, 2019. This Internet-Draft will expire on December 29, 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 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . 4
4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 4 4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 4
4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 5 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 5
4.4. Stateless Autoconfiguration . . . . . . . . . . . . . . . 5 4.4. Stateless Autoconfiguration . . . . . . . . . . . . . . . 5
4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 6 4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 6
4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 6 4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 6
4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 6 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 6
4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 7 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15
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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
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 Appendix A, 802.11-OCB link [IEEE-802.11-2016] (a.k.a "802.11p" see Appendix A,
Appendix B and Appendix C) with minimal change to existing stacks. Appendix B and Appendix C) with minimal change to existing stacks.
This document describes the layering of IPv6 networking on top of the This document describes the layering of IPv6 networking on top of the
IEEE Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer with a frame IEEE Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer with a frame
translation underneath. The resulting stack operates over 802.11-OCB translation underneath. The resulting stack inherits from IPv6 over
and provides at least P2P connectivity using IPv6 ND and link-local Ethernet [RFC 2464] and operates over 802.11-OCB providing at least
addresses. ND Extensions and IPWAVE optimizations for vehicular P2P connectivity using IPv6 ND and link-local addresses. ND
communications are not in scope. The expectation is that further Extensions and IPWAVE optimizations for vehicular communications are
specs will elaborate for more complex vehicular networking scenarios. not in scope. The expectation is that further specs will elaborate
for more complex vehicular networking scenarios.
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, but there are two kinds of exceptions: operating on Ethernet, but there are two kinds of 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
skipping to change at page 5, line 28 skipping to change at page 5, line 34
4.3. Link-Local Addresses 4.3. Link-Local Addresses
There are several types of IPv6 addresses [RFC4291], [RFC4193], that There are several types of IPv6 addresses [RFC4291], [RFC4193], that
MAY be assigned to an 802.11-OCB interface. Among these types of MAY be assigned to an 802.11-OCB interface. Among these types of
addresses only the IPv6 link-local addresses MAY be formed using an addresses only the IPv6 link-local addresses MAY be formed using an
EUI-64 identifier, in particular during transition time. EUI-64 identifier, in particular during transition time.
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. This used to form an IPv6 link-local address on Ethernet links. Moreover,
mechanism is described in section 5 of [RFC2464]. 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
[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 IP version 6 are described in [RFC4862]. This section interfaces in IP version 6 are described in [RFC4862]. This section
describes the formation of Interface Identifiers for IPv6 addresses describes the formation of Interface Identifiers for IPv6 addresses
of type 'Global' or 'Unique Local'. For Interface Identifiers for of type 'Global' or 'Unique Local'. For Interface Identifiers for
IPv6 address of type 'Link-Local' see Section 4.3. IPv6 address of type 'Link-Local' see 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. time, in particular for IPv6 link-local addresses. Regardless of how
to form the Interface Identifier, its length is 64 bits, as is the
case of the IPv6 over Ethernet specification [RFC2464].
The bits in the Interface Identifier have no generic meaning and the The bits in the Interface Identifier have no generic meaning and the
identifier should be treated as an opaque value. The bits identifier should be treated as an opaque value. The bits
'Universal' and 'Group' in the identifier of an 802.11-OCB interface 'Universal' and 'Group' in the identifier of an 802.11-OCB interface
are significant, as this is an IEEE link-layer address. The details are significant, as this is an IEEE link-layer address. The details
of this significance are described in [RFC7136]. of this significance are described in [RFC7136].
Semantically opaque Interface Identifiers, instead of meaningful Semantically opaque Interface Identifiers, instead of meaningful
Interface Identifiers derived from a valid and meaningful MAC address Interface Identifiers derived from a valid and meaningful MAC address
([RFC2464], section 4), help avoid certain privacy risks (see the ([RFC2464], section 4), help avoid certain privacy risks (see the
skipping to change at page 9, line 6 skipping to change at page 9, line 11
eavesdropping and subsequent correlation of data; this may reveal eavesdropping and subsequent correlation of data; this may reveal
data considered private by the vehicle owner; there is a risk of data considered private by the vehicle owner; there is a risk of
being tracked. In outdoors public environments, where vehicles being tracked. In outdoors public environments, where vehicles
typically circulate, the privacy risks are more important than in typically circulate, the privacy risks are more important than in
indoors settings. It is highly likely that attacker sniffers are indoors settings. It is highly likely that attacker sniffers are
deployed along routes which listen for IEEE frames, including IP deployed along routes which listen for IEEE frames, including IP
packets, of vehicles passing by. For this reason, in the 802.11-OCB packets, of vehicles passing by. For this reason, in the 802.11-OCB
deployments, there is a strong necessity to use protection tools such deployments, there is a strong necessity to use protection tools such
as dynamically changing MAC addresses Section 5.2, semantically as dynamically changing MAC addresses Section 5.2, semantically
opaque Interface Identifiers and stable Interface Identifiers opaque Interface Identifiers and stable Interface Identifiers
Section 4.4. This may help mitigate privacy risks to a certain Section 4.4. An example of change policy is to change the MAC
level. address of the OCB interface each time the system boots upThis may
help mitigate privacy risks to a certain level.
5.1.1. Privacy Risks of Meaningful info in Interface IDs 5.1.1. Privacy Risks of Meaningful info in Interface IDs
The privacy risks of using MAC addresses displayed in Interface The privacy risks of using MAC addresses displayed in Interface
Identifiers are important. The IPv6 packets can be captured easily Identifiers are important. The IPv6 packets can be captured easily
in the Internet and on-link in public roads. For this reason, an in the Internet and on-link in public roads. For this reason, an
attacker may realize many attacks on privacy. One such attack on attacker may realize many attacks on privacy. One such attack on
802.11-OCB is to capture, store and correlate Company ID information 802.11-OCB is to capture, store and correlate Company ID information
present in MAC addresses of many cars (e.g. listen for Router present in MAC addresses of many cars (e.g. listen for Router
Advertisements, or other IPv6 application data packets, and record Advertisements, or other IPv6 application data packets, and record
skipping to change at page 23, line 29 skipping to change at page 23, line 29
For information, at the time of writing, this is the list of IEEE For information, at the time of writing, this is the list of IEEE
802.11 messages that may be transmitted in OCB mode, i.e. when 802.11 messages that may be transmitted in OCB mode, i.e. when
dot11OCBActivated is true in a STA: dot11OCBActivated is true in a STA:
o The STA may send management frames of subtype Action and, if the o The STA may send management frames of subtype Action and, if the
STA maintains a TSF Timer, subtype Timing Advertisement; STA maintains a TSF Timer, subtype Timing Advertisement;
o The STA may send control frames, except those of subtype PS-Poll, o The STA may send control frames, except those of subtype PS-Poll,
CF-End, and CF-End plus CFAck; CF-End, and CF-End plus CFAck;
o The STA may send data frames of subtype Data, Null, QoS Data, and o The STA MUST send data frames of subtype QoS Data.
QoS Null.
Appendix G. Examples of Packet Formats Appendix G. Examples of Packet Formats
This section describes an example of an IPv6 Packet captured over a This section describes an example of an IPv6 Packet captured over a
IEEE 802.11-OCB link. IEEE 802.11-OCB link.
By way of example we show that there is no modification in the By way of example we show that there is no modification in the
headers when transmitted over 802.11-OCB networks - they are headers when transmitted over 802.11-OCB networks - they are
transmitted like any other 802.11 and Ethernet packets. transmitted like any other 802.11 and Ethernet packets.
skipping to change at page 31, line 22 skipping to change at page 31, line 22
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 experience indicates 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 good conditions. However, this does not (Address Resolution) in good conditions. In the absence of a correct
apply if TBD TBD TBD. In the absence of a correct DAD operation, a DAD operation, a node that relies only on IPv6 ND for AR and DAD over
node that relies only on IPv6 ND for AR and DAD over OCB should OCB should ensure that the addresses that it uses are unique by means
ensure that the addresses that it uses are unique by means others others than DAD. It must be noted that deriving an IPv6 address from
than DAD. It must be noted that deriving an IPv6 address from a 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
Registration" indicates that the scope of uniqueness for a link local Registration" indicates that the scope of uniqueness for a link local
address is restricted to a pair of nodes that use it to communicate, 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- and provides a method to assert the uniqueness and resolve the link-
Layer address using a unicast exchange. Layer address using a unicast exchange.
skipping to change at page 32, line 5 skipping to change at page 32, line 5
the registration. The prefix is advertised as not onlink, which the registration. The prefix is advertised as not onlink, which
means that the 6LN uses the 6LR to relay its packets within the 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 subnet, and participation to the subnet is constrained to the time of
reachability to the 6LR. Note that RSU that provides internet reachability to the 6LR. Note that RSU that provides internet
connectivity MAY announce a default router preference [RFC 4191], connectivity MAY announce a default router preference [RFC 4191],
whereas a car that does not provide that connectivity MUST NOT do so. whereas a car that does not provide that connectivity MUST NOT do so.
This operation presents similarities with that of an access point, This operation presents similarities with that of an access point,
but at Layer-3. This is why RFC 8505 well-suited for wireless in but at Layer-3. This is why RFC 8505 well-suited for wireless in
general. general.
Support of RFC 8505 is may be implemented on OCB. OCB nodes that Support of RFC 8505 may be implemented on OCB. OCB nodes that
support RFC 8505 would support the 6LN operation in order to act as a support RFC 8505 SHOULD support the 6LN operation in order to act as
host, and may support the 6LR and 6LBR operations in order to act as a host, and may support the 6LR and 6LBR operations in order to act
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
Morocco Morocco
Phone: +212670832236 Phone: +212670832236
Email: n.benamar@est.umi.ac.ma Email: n.benamar@est.umi.ac.ma
 End of changes. 13 change blocks. 
29 lines changed or deleted 33 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/