draft-ietf-ipwave-ipv6-over-80211ocb-25.txt   draft-ietf-ipwave-ipv6-over-80211ocb-26.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: December 21, 2018 Moulay Ismail University Expires: March 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
June 19, 2018 September 7, 2018
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-25 draft-ietf-ipwave-ipv6-over-80211ocb-26
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 December 21, 2018. This Internet-Draft will expire on March 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5 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. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7 4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7
4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7 4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7
4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 7 4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 7
4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7 4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7
4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 8 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 9
5.2. MAC Address Generation . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 15
Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 24
Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 23 Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 24
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 . . . 28 become a 802.11-OCB driver . . . 28
Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 29 Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 29
Appendix F. Design Considerations . . . . . . . . . . . . . . . 30 Appendix F. Design Considerations . . . . . . . . . . . . . . . 30
F.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 30 F.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 30
F.2. Reliability Requirements . . . . . . . . . . . . . . . . 30 F.2. Reliability Requirements . . . . . . . . . . . . . . . . 31
F.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 31 F.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 31
F.4. MAC Address Generation . . . . . . . . . . . . . . . . . 32
Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 32 Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 32
Appendix H. Implementation Status . . . . . . . . . . . . . . . 32 Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 32
H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 33 H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 33
H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 36 H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 36
Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 38 Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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
skipping to change at page 7, line 7 skipping to change at page 7, line 7
| 802.11 PHY | | 802.11 PHY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Ethernet Adaptation Layer stacked with other layers Figure 2: Ethernet Adaptation Layer stacked with other layers
(in the above figure, a 802.11 profile is represented; this is used (in the above figure, a 802.11 profile is represented; this is used
also for 802.11-OCB profile.) also for 802.11-OCB profile.)
4.3. Link-Local Addresses 4.3. Link-Local Addresses
The link-local address of an 802.11-OCB interface is formed in the There are several types of IPv6 addresses [RFC4291], [RFC4193], that
same manner as on an Ethernet interface. This manner is described in MAY be assigned to an 802.11-OCB interface. Among these types of
section 5 of [RFC2464]. Additionally, if stable identifiers are addresses only the IPv6 link-local addresses MAY be formed using an
needed, it is RECOMMENDED to follow the Recommendation on Stable IPv6 EUI-64 identifier.
Interface Identifiers [RFC8064]. Additionally, if semantically
opaque Interface Identifiers are needed, a potential method for If the IPv6 link-local address is formed using an EUI-64 identifier,
generating semantically opaque Interface Identifiers with IPv6 then the mechanism of forming that address is the same mechanism as
Stateless Address Autoconfiguration is given in [RFC7217]. used to form an IPv6 link-local address on Ethernet links. This
mechanism is described in section 5 of [RFC2464].
4.4. Address Mapping 4.4. Address Mapping
Unicast and multicast address mapping MUST follow the procedures Unicast and multicast address mapping MUST follow the procedures
specified for Ethernet interfaces in sections 6 and 7 of [RFC2464]. specified for Ethernet interfaces in sections 6 and 7 of [RFC2464].
4.4.1. Address Mapping -- Unicast 4.4.1. Address Mapping -- Unicast
The procedure for mapping IPv6 unicast addresses into Ethernet link- The procedure for mapping IPv6 unicast addresses into Ethernet link-
layer addresses is described in [RFC4861]. layer addresses is described in [RFC4861].
skipping to change at page 7, line 41 skipping to change at page 7, line 42
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
[I-D.perkins-intarea-multicast-ieee802]. These issues may be [I-D.perkins-intarea-multicast-ieee802]. These issues may be
exacerbated in OCB mode. Solutions for these problems should exacerbated in OCB mode. Solutions for these problems should
consider the OCB mode of operation. consider the OCB mode of operation.
4.5. Stateless Autoconfiguration 4.5. Stateless Autoconfiguration
There are several types of IPv6 addresses [RFC4291], [RFC4193], that
MAY be assigned to an 802.11-OCB interface. This section describes
the formation of Interface Identifiers for IPv6 addresses of type
'Global' or 'Unique Local'. For Interface Identifiers for IPv6
address of type 'Link-Local' see Section 4.3.
The Interface Identifier for an 802.11-OCB interface is formed using The Interface Identifier for an 802.11-OCB interface is formed using
the same rules as the Interface Identifier for an Ethernet interface; the same rules as the Interface Identifier for an Ethernet interface;
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. time.
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]. If semantically
opaque Interface Identifiers are needed, a potential method for
As with all Ethernet and 802.11 interface identifiers ([RFC7721]), generating semantically opaque Interface Identifiers with IPv6
the identifier of an 802.11-OCB interface may involve privacy, MAC Stateless Address Autoconfiguration is given in [RFC7217].
address spoofing and IP address hijacking risks. A vehicle embarking
an OBU or an IP-OBU whose egress interface is 802.11-OCB may expose
itself to eavesdropping and subsequent correlation of data; this may
reveal data considered private by the vehicle owner; there is a risk
of being tracked; see the privacy considerations described in
Appendix F.
If stable Interface Identifiers are needed in order to form IPv6 The way Interface Identifiers are used MAY involve risks to privacy,
addresses on 802.11-OCB links, it is recommended to follow the as described in Section 5.1.
recommendation in [RFC8064]. Additionally, if semantically opaque
Interface Identifiers are needed, a potential method for generating
semantically opaque Interface Identifiers with IPv6 Stateless Address
Autoconfiguration is given in [RFC7217].
4.6. Subnet Structure 4.6. Subnet Structure
A subnet is formed by the external 802.11-OCB interfaces of vehicles A subnet is formed by the external 802.11-OCB interfaces of vehicles
that are in close range (not their on-board interfaces). This that are in close range (not by their in-vehicle interfaces). This
ephemeral subnet structure is strongly influenced by the mobility of subnet MUST use at least the link-local prefix fe80::/10 and the
vehicles: the 802.11 hidden node effects appear. On another hand, interfaces MUST be assigned IPv6 addresses of type link-local. This
the structure of the internal subnets in each car is relatively subnet MAY NOT have any other prefix than the link-local prefix.
stable.
The 802.11 networks in OCB mode may be considered as 'ad-hoc' The structure of this subnet is ephemeral, in that it is strongly
networks. The addressing model for such networks is described in influenced by the mobility of vehicles: the 802.11 hidden node
[RFC5889]. effects appear; the 802.11 networks in OCB mode may be considered as
'ad-hoc' networks with an addressing model as described in [RFC5889].
On another hand, the structure of the internal subnets in each car is
relatively stable.
The operation of the Neighbor Discovery protocol (ND) over 802.11-OCB As recommended in [RFC5889], when the timing requirements are very
links is different than over 802.11 links. In OCB, the link layer strict (e.g. fast drive through IP-RSU coverage), no on-link subnet
does not ensure that all associated members receive all messages, prefix should be configured on an 802.11-OCB interface. In such
because there is no association operation. Neighbor Discovery (ND) cases, the exclusive use of IPv6 link-local addresses is RECOMMENDED.
is used over 802.11-OCB.
The Neighbor Discovery protocol (ND) [RFC4861] is used over
802.11-OCB links.
The operation of the Mobile IPv6 protocol over 802.11-OCB links is The operation of the Mobile IPv6 protocol over 802.11-OCB links is
different than on other links. The Movement Detection operation different than on other links. The Movement Detection operation
(section 11.5.1 of [RFC6275]) can not rely on Neighbor Unreachability (section 11.5.1 of [RFC6275]) can not rely on Neighbor Unreachability
Detection operation of the Neighbor Discovery protocol, for the Detection operation of the Neighbor Discovery protocol, for the
reason mentioned in the previous paragraph. Also, the 802.11-OCB reason mentioned in the previous paragraph. Also, the 802.11-OCB
link layer is not a lower layer that can provide an indication that a link layer is not a lower layer that can provide an indication that a
link layer handover has occured. The operation of the Mobile IPv6 link layer handover has occured. The operation of the Mobile IPv6
protocol over 802.11-OCB is not specified in this document. protocol over 802.11-OCB is not specified in this document.
skipping to change at page 9, line 41 skipping to change at page 9, line 41
Within the IPsec Security Architecture [RFC4301], the IPsec AH and Within the IPsec Security Architecture [RFC4301], the IPsec AH and
ESP headers [RFC4302] and [RFC4303] respectively, its multicast ESP headers [RFC4302] and [RFC4303] respectively, its multicast
extensions [RFC5374], HTTPS [RFC2818] and SeND [RFC3971] protocols extensions [RFC5374], HTTPS [RFC2818] and SeND [RFC3971] protocols
can be used to protect communications. Further, the assistance of can be used to protect communications. Further, the assistance of
proper Public Key Infrastructure (PKI) protocols [RFC4210] is proper Public Key Infrastructure (PKI) protocols [RFC4210] is
necessary to establish credentials. More IETF protocols are necessary to establish credentials. More IETF protocols are
available in the toolbox of the IP security protocol designer. available in the toolbox of the IP security protocol designer.
Certain ETSI protocols related to security protocols in Intelligent Certain ETSI protocols related to security protocols in Intelligent
Transportation Systems are described in [ETSI-sec-archi]. Transportation Systems are described in [ETSI-sec-archi].
As with all Ethernet and 802.11 interface identifiers, there may 5.1. Privacy Considerations
exist privacy risks in the use of 802.11-OCB interface identifiers.
Moreover, in outdoors vehicular settings, the privacy risks are more As with all Ethernet and 802.11 interface identifiers ([RFC7721]),
important than in indoors settings. New risks are induced by the the identifier of an 802.11-OCB interface may involve privacy, MAC
possibility of attacker sniffers deployed along routes which listen address spoofing and IP address hijacking risks. A vehicle embarking
for IP packets of vehicles passing by. For this reason, in the an IP-OBU whose egress interface is 802.11-OCB may expose itself to
802.11-OCB deployments, there is a strong necessity to use protection eavesdropping and subsequent correlation of data; this may reveal
tools such as dynamically changing MAC addresses. This may help data considered private by the vehicle owner; there is a risk of
mitigate privacy risks to a certain level. On another hand, it may being tracked. In outdoors public environments, where vehicles
have an impact in the way typical IPv6 address auto-configuration is typically circulate, the privacy risks are more important than in
performed for vehicles (SLAAC would rely on MAC addresses and would indoors settings. It is highly likely that attacker sniffers are
hence dynamically change the affected IP address), in the way the deployed along routes which listen for IEEE frames, including IP
IPv6 Privacy addresses were used, and other effects. packets, of vehicles passing by. For this reason, in the 802.11-OCB
deployments, there is a strong necessity to use protection tools such
as dynamically changing MAC addresses. This may help mitigate
privacy risks to a certain level.
5.2. MAC Address Generation
In 802.11-OCB networks, the MAC addresses MAY change during well
defined renumbering events. In the moment the MAC address is changed
on an 802.11-OCB interface all the Interface Identifiers of IPv6
addresses assigned to that interface MUST change.
The policy dictating when the MAC address is changed on the
802.11-OCB interface is to-be-determined. For more information on
the motivation of this policy please refer to the privacy discussion
in Appendix C.
A 'randomized' MAC address has the following characteristics:
o Bit "Local/Global" set to "locally admninistered".
o Bit "Unicast/Multicast" set to "Unicast".
o The 46 remaining bits are set to a random value, using a random
number generator that meets the requirements of [RFC4086].
To meet the randomization requirements for the 46 remaining bits, a
hash function may be used. For example, the SHA256 hash function may
be used with input a 256 bit local secret, the "nominal" MAC Address
of the interface, and a representation of the date and time of the
renumbering event.
6. IANA Considerations 6. IANA Considerations
No request to IANA. No request to IANA.
7. Contributors 7. Contributors
Christian Huitema, Tony Li. Christian Huitema, Tony Li.
Romain Kuntz contributed extensively about IPv6 handovers between Romain Kuntz contributed extensively about IPv6 handovers between
skipping to change at page 11, line 45 skipping to change at page 12, line 27
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, "SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005, DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>. <https://www.rfc-editor.org/info/rfc3971>.
[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
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<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,
"Internet X.509 Public Key Infrastructure Certificate "Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210, Management Protocol (CMP)", RFC 4210,
DOI 10.17487/RFC4210, September 2005, DOI 10.17487/RFC4210, September 2005,
<https://www.rfc-editor.org/info/rfc4210>. <https://www.rfc-editor.org/info/rfc4210>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
skipping to change at page 15, line 10 skipping to change at page 15, line 40
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.
-26: moved text from SLAAC section and from Design Considerations
appendix about privacy into a new Privacy Condiderations subsection
of the Security section; reformulated the SLAAC and IID sections to
stress only LLs can use EUI-64; removed the "GeoIP" wireshark
explanation; reformulated SLAAC and LL sections; added brief mention
of need of use LLs; clarified text about MAC address changes; dropped
pseudonym discussion; changed title of section describing examples of
packet formats.
-25: added a reference to 'IEEE Management Information Base', instead -25: added a reference to 'IEEE Management Information Base', instead
of just 'Management Information Base'; added ref to further of just 'Management Information Base'; added ref to further
appendices in the introductory phrases; improved text for IID appendices in the introductory phrases; improved text for IID
formation for SLAAC, inserting recommendation for RFC8064 before formation for SLAAC, inserting recommendation for RFC8064 before
RFC2464. RFC2464.
From draft-ietf-ipwave-ipv6-over-80211ocb-23 to draft-ietf-ipwave- From draft-ietf-ipwave-ipv6-over-80211ocb-23 to draft-ietf-ipwave-
ipv6-over-80211ocb-24 ipv6-over-80211ocb-24
o Nit: wrote "IPWAVE Working Group" on the front page, instead of o Nit: wrote "IPWAVE Working Group" on the front page, instead of
skipping to change at page 27, line 49 skipping to change at page 28, line 20
strong privacy requirements with respect to addressing. While the strong privacy requirements with respect to addressing. While the
802.11-OCB standard does not specify anything in particular with 802.11-OCB standard does not specify anything in particular with
respect to MAC addresses, in these settings there exists a strong respect to MAC addresses, in these settings there exists a strong
need for dynamic change of these addresses (as opposed to the non- need for dynamic change of these addresses (as opposed to the non-
vehicular settings - real wall protection - where fixed MAC vehicular settings - real wall protection - where fixed MAC
addresses do not currently pose some privacy risks). This is addresses do not currently pose some privacy risks). This is
further described in Section 5. A relevant function is described further described in Section 5. A relevant function is described
in IEEE 1609.3-2016 [IEEE-1609.3], clause 5.5.1 and IEEE in IEEE 1609.3-2016 [IEEE-1609.3], clause 5.5.1 and IEEE
1609.4-2016 [IEEE-1609.4], clause 6.7. 1609.4-2016 [IEEE-1609.4], clause 6.7.
Other aspects particular to 802.11-OCB, which are also particular to
802.11 (e.g. the 'hidden node' operation), may have an influence on
the use of transmission of IPv6 packets on 802.11-OCB networks. The
OCB subnet structure is described in Section 4.6.
Appendix D. Changes Needed on a software driver 802.11a to become a Appendix D. Changes Needed on a software driver 802.11a to become a
802.11-OCB driver 802.11-OCB driver
The 802.11p amendment modifies both the 802.11 stack's physical and The 802.11p amendment modifies both the 802.11 stack's physical and
MAC layers but all the induced modifications can be quite easily MAC layers but all the induced modifications can be quite easily
obtained by modifying an existing 802.11a ad-hoc stack. obtained by modifying an existing 802.11a ad-hoc stack.
Conditions for a 802.11a hardware to be 802.11-OCB compliant: Conditions for a 802.11a hardware to be 802.11-OCB compliant:
o The PHY entity shall be an orthogonal frequency division o The PHY entity shall be an orthogonal frequency division
skipping to change at page 32, line 5 skipping to change at page 32, line 20
single packet. Treating each wireless interface as a separate single packet. Treating each wireless interface as a separate
network interface pushes such issues to the application layer. network interface pushes such issues to the application layer.
Certain privacy requirements imply that if these multiple interfaces Certain privacy requirements imply that if these multiple interfaces
are represented by many network interface, a single renumbering event are represented by many network interface, a single renumbering event
shall cause renumbering of all these interfaces. If one MAC changed shall cause renumbering of all these interfaces. If one MAC changed
and another stayed constant, external observers would be able to and another stayed constant, external observers would be able to
correlate old and new values, and the privacy benefits of correlate old and new values, and the privacy benefits of
randomization would be lost. randomization would be lost.
The privacy requirements of Non IP safety-critical communications
imply that if a change of pseudonyme occurs, renumbering of all other
interfaces shall also occur.
F.4. MAC Address Generation
In 802.11-OCB networks, the MAC addresses may change during well
defined renumbering events. A 'randomized' MAC address has the
following characteristics:
o Bit "Local/Global" set to "locally admninistered".
o Bit "Unicast/Multicast" set to "Unicast".
o The 46 remaining bits are set to a random value, using a random
number generator that meets the requirements of [RFC4086].
To meet the randomization requirements for the 46 remaining bits, a
hash function may be used. For example, the SHA256 hash function may
be used with input a 256 bit local secret, the "nominal" MAC Address
of the interface, and a representation of the date and time of the
renumbering event.
Appendix G. IEEE 802.11 Messages Transmitted in OCB mode Appendix G. IEEE 802.11 Messages Transmitted in OCB mode
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 may send data frames of subtype Data, Null, QoS Data, and
QoS Null. QoS Null.
Appendix H. Implementation Status Appendix H. 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.
We describe an experiment of capturing an IPv6 packet on an We describe an experiment of capturing an IPv6 packet on an
802.11-OCB link. In topology depicted in Figure 5, the packet is an 802.11-OCB link. In topology depicted in Figure 5, the packet is an
skipping to change at page 35, line 50 skipping to change at page 35, line 42
value of the Type field is 0x86DD (hexadecimal 86DD, or otherwise value of the Type field is 0x86DD (hexadecimal 86DD, or otherwise
#86DD), recognized as "IPv6". #86DD), recognized as "IPv6".
A Router Advertisement is periodically sent by the router to A Router Advertisement is periodically sent by the router to
multicast group address ff02::1. It is an icmp packet type 134. The multicast group address ff02::1. It is an icmp packet type 134. The
IPv6 Neighbor Discovery's Router Advertisement message contains an IPv6 Neighbor Discovery's Router Advertisement message contains an
8-bit field reserved for single-bit flags, as described in [RFC4861]. 8-bit field reserved for single-bit flags, as described in [RFC4861].
The IPv6 header contains the link local address of the router The IPv6 header contains the link local address of the router
(source) configured via EUI-64 algorithm, and destination address set (source) configured via EUI-64 algorithm, and destination address set
to ff02::1. Recent versions of network protocol analyzers (e.g. to ff02::1.
Wireshark) provide additional informations for an IP address, if a
geolocalization database is present. In this example, the
geolocalization database is absent, and the "GeoIP" information is
set to unknown for both source and destination addresses (although
the IPv6 source and destination addresses are set to useful values).
This "GeoIP" can be a useful information to look up the city,
country, AS number, and other information for an IP address.
The Ethernet Type field in the logical-link control header is set to The Ethernet Type field in the logical-link control header is set to
0x86dd which indicates that the frame transports an IPv6 packet. In 0x86dd which indicates that the frame transports an IPv6 packet. In
the IEEE 802.11 data, the destination address is 33:33:00:00:00:01 the IEEE 802.11 data, the destination address is 33:33:00:00:00:01
which is the corresponding multicast MAC address. The BSS id is a which is the corresponding multicast MAC address. The BSS id is a
broadcast address of ff:ff:ff:ff:ff:ff. Due to the short link broadcast address of ff:ff:ff:ff:ff:ff. Due to the short link
duration between vehicles and the roadside infrastructure, there is duration between vehicles and the roadside infrastructure, there is
no need in IEEE 802.11-OCB to wait for the completion of association no need in IEEE 802.11-OCB to wait for the completion of association
and authentication procedures before exchanging data. IEEE and authentication procedures before exchanging data. IEEE
802.11-OCB enabled nodes use the wildcard BSSID (a value of all 1s) 802.11-OCB enabled nodes use the wildcard BSSID (a value of all 1s)
 End of changes. 27 change blocks. 
101 lines changed or deleted 113 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/