draft-ietf-ipwave-ipv6-over-80211ocb-30.txt   draft-ietf-ipwave-ipv6-over-80211ocb-31.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: March 28, 2019 Moulay Ismail University Expires: May 23, 2019 Moulay Ismail University
J. Haerri J. Haerri
Eurecom Eurecom
J. Lee J. Lee
Sangmyung University Sangmyung University
T. Ernst T. Ernst
YoGoKo YoGoKo
September 24, 2018 November 19, 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-30 draft-ietf-ipwave-ipv6-over-80211ocb-31
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 March 28, 2019. This Internet-Draft will expire on May 23, 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 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . . . . . 5 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 5
4.1. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 5 4.1. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 5
4.2. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5 4.2. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5
4.3. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5
4.3.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5 4.3.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 6
4.4. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7 4.4. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7
4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7 4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7
4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7 4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7
4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 7 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 8
4.6. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7 4.6. Stateless Autoconfiguration . . . . . . . . . . . . . . . 8
4.7. Subnet Structure . . . . . . . . . . . . . . . . . . . . 9 4.7. Subnet Structure . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 11
5.2. MAC Address and Interface ID Generation . . . . . . . . . 11 5.2. MAC Address and Interface ID Generation . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 26 Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 26
Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 26 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 . . . 30 become a 802.11-OCB driver . . . 31
Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 31 Appendix E. Protocol Layering . . . . . . . . . . . . . . . . . 32
Appendix F. Design Considerations . . . . . . . . . . . . . . . 32 Appendix F. Design Considerations . . . . . . . . . . . . . . . 33
Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 32 Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 33
Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 33 Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 33
H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 34 H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 34
H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 36 H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 37
Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 38 Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
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 5, line 9 skipping to change at page 5, line 9
brings in new perspectives. brings in new perspectives.
The mechanisms for forming and terminating, discovering, peering and The mechanisms for forming and terminating, discovering, peering and
mobility management for 802.11-OCB links are not described in this mobility management for 802.11-OCB links are not described in this
document. document.
4. IPv6 over 802.11-OCB 4. IPv6 over 802.11-OCB
4.1. Pseudonym Handling 4.1. Pseudonym Handling
Pseudonym. The demand for privacy protection of vehicles' and drivers'
identities, which could be granted by using a pseudonym or alias
identity at the same time, may hamper the required confidentiality of
messages and trust between participants - especially in safety
critical vehicular communication.
o Particular challenges arise when the pseudonymization mechanism
used relies on (randomized) re-addressing.
o A proper pseudonymization tool operated by a trusted third party
may be needed to ensure both aspects concurrently.
o This is discussed in Section 4.6 and Section 5.
o Pseudonymity is also discussed in
[I-D.ietf-ipwave-vehicular-networking-survey] in sections 4.2.4
and 5.1.2.
4.2. Maximum Transmission Unit (MTU) 4.2. Maximum Transmission Unit (MTU)
The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. It The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. It
is the same value as IPv6 packets on Ethernet links, as specified in is the same value as IPv6 packets on Ethernet links, as specified in
[RFC2464]. This value of the MTU respects the recommendation that [RFC2464]. This value of the MTU respects the recommendation that
every link on the Internet must have a minimum MTU of 1280 octets every link on the Internet must have a minimum MTU of 1280 octets
(stated in [RFC8200], and the recommendations therein, especially (stated in [RFC8200], and the recommendations therein, especially
with respect to fragmentation). with respect to fragmentation).
4.3. Frame Format 4.3. Frame Format
IP packets MUST be transmitted over 802.11-OCB media as QoS Data IP packets MUST be transmitted over 802.11-OCB media as QoS Data
frames whose format is specified in IEEE Std 802.11. frames whose format is specified in IEEE Std 802.11.
The IPv6 packet transmitted on 802.11-OCB MUST be immediately The IPv6 packet transmitted on 802.11-OCB MUST be immediately
preceded by a Logical Link Control (LLC) header and an 802.11 header. preceded by a Logical Link Control (LLC) header and an 802.11 header.
In the LLC header, and in accordance with the EtherType Protocol In the LLC header, and in accordance with the EtherType Protocol
Discrimination (EPD), the value of the Type field MUST be set to Discrimination (EPD, see Appendix E), the value of the Type field
0x86DD (IPv6). In the 802.11 header, the value of the Subtype sub- MUST be set to 0x86DD (IPv6). In the 802.11 header, the value of the
field in the Frame Control field MUST be set to 8 (i.e. 'QoS Data'); Subtype sub-field in the Frame Control field MUST be set to 8 (i.e.
the value of the Traffic Identifier (TID) sub-field of the QoS 'QoS Data'); the value of the Traffic Identifier (TID) sub-field of
Control field of the 802.11 header MUST be set to binary 001 (i.e. the QoS Control field of the 802.11 header MUST be set to binary 001
User Priority 'Background', QoS Access Category 'AC_BK'). (i.e. User Priority 'Background', QoS Access Category 'AC_BK').
To simplify the Application Programming Interface (API) between the To simplify the Application Programming Interface (API) between the
operating system and the 802.11-OCB media, device drivers MAY operating system and the 802.11-OCB media, device drivers MAY
implement an Ethernet Adaptation Layer that translates Ethernet II implement an Ethernet Adaptation Layer that translates Ethernet II
frames to the 802.11 format and vice versa. An Ethernet Adaptation frames to the 802.11 format and vice versa. An Ethernet Adaptation
Layer is described in Section 4.3.1. Layer is described in Section 4.3.1.
4.3.1. Ethernet Adaptation Layer 4.3.1. Ethernet Adaptation Layer
An 'adaptation' layer is inserted between a MAC layer and the An 'adaptation' layer is inserted between a MAC layer and the
skipping to change at page 9, line 18 skipping to change at page 9, line 40
administrator. administrator.
The way Interface Identifiers are used MAY involve risks to privacy, The way Interface Identifiers are used MAY involve risks to privacy,
as described in Section 5.1. as described in Section 5.1.
4.7. Subnet Structure 4.7. 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 by their in-vehicle interfaces). This that are in close range (not by their in-vehicle interfaces). This
subnet MUST use at least the link-local prefix fe80::/10 and the subnet MUST use at least the link-local prefix fe80::/10 and the
interfaces MUST be assigned IPv6 addresses of type link-local. This interfaces MUST be assigned IPv6 addresses of type link-local.
subnet MAY NOT have any other prefix than the link-local prefix.
The structure of this subnet is ephemeral, in that it is strongly The structure of this subnet is ephemeral, in that it is strongly
influenced by the mobility of vehicles: the 802.11 hidden node influenced by the mobility of vehicles: the 802.11 hidden node
effects appear; the 802.11 networks in OCB mode may be considered as effects appear; the 802.11 networks in OCB mode may be considered as
'ad-hoc' networks with an addressing model as described in [RFC5889]. 'ad-hoc' networks with an addressing model as described in [RFC5889].
On another hand, the structure of the internal subnets in each car is On another hand, the structure of the internal subnets in each car is
relatively stable. relatively stable.
As recommended in [RFC5889], when the timing requirements are very As recommended in [RFC5889], when the timing requirements are very
strict (e.g. fast drive through IP-RSU coverage), no on-link subnet strict (e.g. fast drive through IP-RSU coverage), no on-link subnet
skipping to change at page 9, line 42 skipping to change at page 10, line 14
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] is used over The Neighbor Discovery protocol (ND) [RFC4861] is used over
802.11-OCB links. The reliability of the ND protocol over 802.11-OCB 802.11-OCB links. Due to lack of link-layer acknowledgements in
is the reliability of the delivery of ND multicast messages. This 802.11-OCB for both unicast and multicast, we can expect higher
reliability is the same as the reliability of delivery of ND unicast loss than for 802.11 BSS. The ND retransmissions are
multicast messages over 802.11 links operated with a BSS ID. supposed to handle loss of unicast and/or multicast just as it does
for other link types.
The operation of the Mobile IPv6 protocol over 802.11-OCB links is Protocols like Mobile IPv6 [RFC6275] and DNAv6 [RFC6059], which
different than on other links. The Movement Detection operation depend on timely movement detection, might need additional tuning
(section 11.5.1 of [RFC6275]) can not rely on Neighbor Unreachability work to handle the lack of link-layer notifications during handover.
Detection operation of the Neighbor Discovery protocol, for the This is for further study.
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 handover has occured. The operation of the Mobile IPv6
protocol over 802.11-OCB is not specified in this document.
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
operating over 802.11-OCB. operating over 802.11-OCB.
The OCB operation is stripped off of all existing 802.11 link-layer The OCB operation is stripped off of all existing 802.11 link-layer
security mechanisms. There is no encryption applied below the security mechanisms. There is no encryption applied below the
network layer running on 802.11-OCB. At application layer, the IEEE network layer running on 802.11-OCB. At application layer, the IEEE
skipping to change at page 12, line 39 skipping to change at page 12, line 52
The authors would like to thank Witold Klaudel, Ryuji Wakikawa, The authors would like to thank Witold Klaudel, Ryuji Wakikawa,
Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan
Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray
Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan, Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan,
Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne, Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne,
Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark, Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark,
Bob Moskowitz, Andrew Dryden, Georg Mayer, Dorothy Stanley, Sandra Bob Moskowitz, Andrew Dryden, Georg Mayer, Dorothy Stanley, Sandra
Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun, Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun,
Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in
't Velt, Katrin Sjoberg, Roland Bless, Tijink Jasja, Kevin Smith, 't Velt, Katrin Sjoberg, Roland Bless, Tijink Jasja, Kevin Smith,
Brian Carpenter, Julian Reschke, Mikael Abrahamsson and William Brian Carpenter, Julian Reschke, Mikael Abrahamsson, Dirk von Hugo,
Whyte. Their valuable comments clarified particular issues and Lorenzo Colitti and William Whyte. Their valuable comments clarified
generally helped to improve the document. particular issues and generally helped to improve the document.
Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB
drivers for linux and described how. drivers for linux and described how.
For the multicast discussion, the authors would like to thank Owen For the multicast discussion, the authors would like to thank Owen
DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and
participants to discussions in network working groups. participants to discussions in network working groups.
The authors would like to thank participants to the Birds-of- The authors would like to thank participants to the Birds-of-
a-Feather "Intelligent Transportation Systems" meetings held at IETF a-Feather "Intelligent Transportation Systems" meetings held at IETF
skipping to change at page 14, line 41 skipping to change at page 15, line 9
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
Ed., "Control And Provisioning of Wireless Access Points Ed., "Control And Provisioning of Wireless Access Points
(CAPWAP) Protocol Specification", RFC 5415, (CAPWAP) Protocol Specification", RFC 5415,
DOI 10.17487/RFC5415, March 2009, DOI 10.17487/RFC5415, March 2009,
<https://www.rfc-editor.org/info/rfc5415>. <https://www.rfc-editor.org/info/rfc5415>.
[RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing
Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889,
September 2010, <https://www.rfc-editor.org/info/rfc5889>. September 2010, <https://www.rfc-editor.org/info/rfc5889>.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059,
DOI 10.17487/RFC6059, November 2010,
<https://www.rfc-editor.org/info/rfc6059>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>. 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802 IETF Protocol and Documentation Usage for IEEE 802
Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
October 2013, <https://www.rfc-editor.org/info/rfc7042>. October 2013, <https://www.rfc-editor.org/info/rfc7042>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
skipping to change at page 17, line 10 skipping to change at page 17, line 33
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.
-31: filled in the section titled "Pseudonym Handling"; removed a
'MAY NOT' phrase about possibility of having other prefix than the LL
on the link between cars; shortened and improved the paragraph about
Mobile IPv6, now with DNAv6; improved the ND text about ND
retransmissions with relationship to packet loss; changed the title
of an appendix from 'EPD' to 'Protocol Layering'; improved the
'Aspects introduced by OCB' appendix with a few phrases about the
channel use and references.
-30: a clarification on the reliability of ND over OCB and over -30: a clarification on the reliability of ND over OCB and over
802.11. 802.11.
-29: -29:
o o
-28: -28:
o Created a new section 'Pseudonym Handling'. o Created a new section 'Pseudonym Handling'.
skipping to change at page 26, line 28 skipping to change at page 27, line 14
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
has the flag set, uses a BSS identifier equal to ff:ff:ff:ff:ff:ff. has the flag set, uses a BSS identifier equal to ff:ff:ff:ff:ff:ff.
Appendix C. Aspects introduced by the OCB mode to 802.11 Appendix C. Aspects introduced by the OCB mode to 802.11
In the IEEE 802.11-OCB mode, all nodes in the wireless range can In the IEEE 802.11-OCB mode, all nodes in the wireless range can
directly communicate with each other without involving authentication directly communicate with each other without involving authentication
or association procedures. At link layer, it is necessary to set the or association procedures. In OCB mode, the manner in which channels
same channel number (or frequency) on two stations that need to are selected and used is simplified compared to when in BSS mode.
communicate with each other. The manner in which stations set their Contrary to BSS mode, at link layer, it is necessary to set
channel number is not specified in this document. Stations STA1 and statically the same channel number (or frequency) on two stations
STA2 can exchange IP packets if they are set on the same channel. At that need to communicate with each other (in BSS mode this channel
IP layer, they then discover each other by using the IPv6 Neighbor set operation is performed automatically during 'scanning'). The
Discovery protocol. manner in which stations set their channel number in OCB mode is not
specified in this document. Stations STA1 and STA2 can exchange IP
packets only if they are set on the same channel. At IP layer, they
then discover each other by using the IPv6 Neighbor Discovery
protocol. The allocation of a particular channel for a particular
use is defined statically in standards authored by ETSI (in Europe),
FCC in America, and similar organisations in South Korea, Japan and
other parts of the world.
Briefly, the IEEE 802.11-OCB mode has the following properties: Briefly, the IEEE 802.11-OCB mode has the following properties:
o The use by each node of a 'wildcard' BSSID (i.e., each bit of the o The use by each node of a 'wildcard' BSSID (i.e., each bit of the
BSSID is set to 1) BSSID is set to 1)
o No IEEE 802.11 Beacon frames are transmitted o No IEEE 802.11 Beacon frames are transmitted
o No authentication is required in order to be able to communicate o No authentication is required in order to be able to communicate
skipping to change at page 31, line 29 skipping to change at page 32, line 21
Response) and for authentication (Authentication Request/Reply, Response) and for authentication (Authentication Request/Reply,
Challenge) are not called. Challenge) are not called.
* The beacon interval is always set to 0 (zero). * The beacon interval is always set to 0 (zero).
* Timing Advertisement frames, defined in the amendment, should * Timing Advertisement frames, defined in the amendment, should
be supported. The upper layer should be able to trigger such be supported. The upper layer should be able to trigger such
frames emission and to retrieve information contained in frames emission and to retrieve information contained in
received Timing Advertisements. received Timing Advertisements.
Appendix E. EtherType Protocol Discrimination (EPD) Appendix E. Protocol Layering
A more theoretical and detailed view of layer stacking, and A more theoretical and detailed view of layer stacking, and
interfaces between the IP layer and 802.11-OCB layers, is illustrated interfaces between the IP layer and 802.11-OCB layers, is illustrated
in Figure 4. The IP layer operates on top of the EtherType Protocol in Figure 4. The IP layer operates on top of the EtherType Protocol
Discrimination (EPD); this Discrimination layer is described in IEEE Discrimination (EPD); this Discrimination layer is described in IEEE
Std 802.3-2012; the interface between IPv6 and EPD is the LLC_SAP Std 802.3-2012; the interface between IPv6 and EPD is the LLC_SAP
(Link Layer Control Service Access Point). (Link Layer Control Service Access Point).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 | | IPv6 |
 End of changes. 20 change blocks. 
48 lines changed or deleted 81 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/