draft-ietf-ipwave-ipv6-over-80211ocb-12.txt   draft-ietf-ipwave-ipv6-over-80211ocb-13.txt 
Network Working Group A. Petrescu Network 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: July 4, 2018 Moulay Ismail University Expires: August 8, 2018 Moulay Ismail University
J. Haerri J. Haerri
Eurecom Eurecom
J. Lee J. Lee
Sangmyung University Sangmyung University
T. Ernst T. Ernst
YoGoKo YoGoKo
December 31, 2017 February 4, 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-12.txt draft-ietf-ipwave-ipv6-over-80211ocb-13.txt
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 July 4, 2018. This Internet-Draft will expire on August 8, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 5 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 5
4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 5 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 5
4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5 4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5
4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 6 4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 6
4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 8 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 8
4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 8 4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 9
4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 8 4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 9
4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 8 4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 9
4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 9 4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 9
4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 9 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 16
Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 22 Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 23
Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 22 Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 23
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 . . . 27 become a 802.11-OCB driver . . . 27
Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 28 Appendix E. EtherType Protocol Discrimination (EPD) . . . . . . 28
Appendix F. Design Considerations . . . . . . . . . . . . . . . 29 Appendix F. Design Considerations . . . . . . . . . . . . . . . 29
F.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 29 F.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 29
F.2. Reliability Requirements . . . . . . . . . . . . . . . . 29 F.2. Reliability Requirements . . . . . . . . . . . . . . . . 30
F.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 30 F.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 30
F.4. MAC Address Generation . . . . . . . . . . . . . . . . . 31 F.4. MAC Address Generation . . . . . . . . . . . . . . . . . 31
Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 31 Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 31
Appendix H. Implementation Status . . . . . . . . . . . . . . . 31 Appendix H. Implementation Status . . . . . . . . . . . . . . . 32
H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 32 H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 33
H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 35 H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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). This involves the layering of IPv6 networking on top of Appendix B). This involves the layering of IPv6 networking on top of
the IEEE 802.11 MAC layer, with an LLC layer. Compared to running the IEEE 802.11 MAC layer, with an LLC layer. Compared to running
IPv6 over the Ethernet MAC layer, there is no modification expected IPv6 over the Ethernet MAC layer, there is no modification expected
skipping to change at page 3, line 51 skipping to change at page 3, line 51
[I-D.ietf-ipwave-vehicular-networking-survey]. [I-D.ietf-ipwave-vehicular-networking-survey].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
WiFi: Wireless Fidelity. WiFi: Wireless Fidelity.
OBRU (On-Board Router Unit): an OBRU is almost always situated in a IP-OBU (Internet Protocol On-Board Unit): an IP-OBU is a computer
vehicle; it is a computer with at least two IP real or virtual situated in a vehicle such as an automobile, bicycle, or similar. It
interfaces; at least one IP interface runs in OCB mode of 802.11. It has at least one IP interface that runs in mode OCB of 802.11, and
MAY be an IP Router. that has an "OBU" transceiver.
OBU (On-Board Unit): term defined outside the IETF. OBU (On-Board Unit): a term defined outside the IETF. An On-Board
Unit is a DSRC transceiver that is normally mounted in or on a
vehicle, or which in some instances may be a portable unit. An OBU
can be operational while a vehicle or person is either mobile or
stationary. The OBUs receive and contend for time to transmit on one
or more radio frequency (RF) channels. Except where specifically
excluded, OBU operation is permitted wherever vehicle operation or
human passage is permitted. The OBUs mounted in vehicles are
licensed by rule under part 95 of this chapter and communicate with
Roadside Units (RSUs) and other OBUs. Portable OBUs are also
licensed by rule under part 95 of this chapter. OBU operations in
the Unlicensed National Information Infrastructure (UNII) Bands
follow the rules in those bands. - [CFR 90.7 - Definitions]. The US
Federal Communications Commission (FCC) Dedicated Short Range
Communication (DSRC) is defined in the Code of Federal Regulations
(CFR) 47, Parts 90 and 95. At the time of the writing of this
Internet Draft, the last update of this document was dated October
1st, 2010.
RSRU (Road-Side Router Unit): an RSRU is almost always situated in a IP-RSU (IP Road-Side Unit): an IP-RSU is situated along the road. An
box fixed along the road. An RSRU has at least two distinct IP- IP-RSU has at least two distinct IP-enabled interfaces; at least one
enabled interfaces; at least one interface is operated in mode OCB of interface is operated in mode OCB of IEEE 802.11 and is IP-enabled.
IEEE 802.11 and is IP-enabled. An RSRU is similar to a Wireless An IP-RSU is similar to a Wireless Termination Point (WTP), as
Termination Point (WTP), as defined in [RFC5415], or an Access Point defined in [RFC5415], or an Access Point (AP), as defined in IEEE
(AP), as defined in IEEE documents, or an Access Network Router (ANR) documents, or an Access Network Router (ANR) defined in [RFC3753],
defined in [RFC3753], with one key particularity: the wireless PHY/ with one key particularity: the wireless PHY/MAC layer of at least
MAC layer of at least one of its IP-enabled interfaces is configured one of its IP-enabled interfaces is configured to operate in
to operate in 802.11-OCB mode. The RSRU communicates with the OBRU 802.11-OCB mode. The RSRU communicates with the IP-OBU in the
in the vehicle over 802.11 wireless link operating in OCB mode. An vehicle over 802.11 wireless link operating in OCB mode.
RSRU MAY be connected to the Internet, and MAY be an IP Router. When
it is connected to the Internet, the term V2I (Vehicle to Internet)
is relevant.
RSU (Road-Side Unit): an RSU operates in 802.11-OCB mode. A RSU RSU (Road-Side Unit): a term defined outside of IETF. A Roadside
broadcasts data to OBUs or exchanges data with OBUs in its Unit is a DSRC transceiver that is mounted along a road or pedestrian
communications zone. An RSU may provide channel assignments and passageway. An RSU may also be mounted on a vehicle or is hand
operating instructions to OBUs in its communications zone, when carried, but it may only operate when the vehicle or hand- carried
required. The basic functional blocks of an RSU are: internal unit is stationary. Furthermore, an RSU operating under this part is
computer processing, permanent storage capability, an integrated GPS restricted to the location where it is licensed to operate. However,
receiver for positioning and timing and an interface that supports portable or hand-held RSUs are permitted to operate where they do not
both IPv4 and IPv6 connectivity, compliant with 802.3at. An OCB interfere with a site-licensed operation. A RSU broadcasts data to
interface of an RSU MAY be IP-enabled simultaneously to being WAVE- OBUs or exchanges data with OBUs in its communications zone. An RSU
enabled or GeoNetworking-enabled (MAY support simultaneously also provides channel assignments and operating instructions to OBUs
EtherTypes 0x86DD for IPv6 _and_ 0x88DC for WAVE and 0x8947 for in its communications zone, when required. - [CFR 90.7 -
GeoNetworking). The difference between RSU and RSRU is that an RSU Definitions]. At the time of the writing of this Internet Draft, the
is likely to have one single OCB interface which is likely not IP last update of this document was dated October 1st, 2010.
enabled, whereas an RSRU is likely to have one or more OCB interfaces
which are almost always IP-enabled; moreover, an RSRU does IP
forwarding, whereas an RSU does not.
OCB (outside the context of a basic service set - BSS): A mode of OCB (outside the context of a basic service set - BSS): A mode of
operation in which a STA is not a member of a BSS and does not operation in which a STA is not a member of a BSS and does not
utilize IEEE Std 802.11 authentication, association, or data utilize IEEE Std 802.11 authentication, association, or data
confidentiality. confidentiality.
802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB
attribute dot11OCBActivited is true. The OCB mode requires attribute dot11OCBActivited is true. The OCB mode requires
transmission of QoS data frames (IEEE Std 802.11e), half-clocked transmission of QoS data frames (IEEE Std 802.11e), half-clocked
operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band.
skipping to change at page 5, line 16 skipping to change at page 5, line 28
The IEEE 802.11-OCB Networks are used for vehicular communications, The IEEE 802.11-OCB Networks are used for vehicular communications,
as 'Wireless Access in Vehicular Environments'. The IP communication as 'Wireless Access in Vehicular Environments'. The IP communication
scenarios for these environments have been described in several scenarios for these environments have been described in several
documents; in particular, we refer the reader to documents; in particular, we refer the reader to
[I-D.ietf-ipwave-vehicular-networking-survey], that lists some [I-D.ietf-ipwave-vehicular-networking-survey], that lists some
scenarios and requirements for IP in Intelligent Transportation scenarios and requirements for IP in Intelligent Transportation
Systems. Systems.
The link model is the following: STA --- 802.11-OCB --- STA. In The link model is the following: STA --- 802.11-OCB --- STA. In
vehicular networks, STAs can be RSRUs and/or OBRUs. While 802.11-OCB vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. While
is clearly specified, and the use of IPv6 over such link is not 802.11-OCB is clearly specified, and the use of IPv6 over such link
radically new, the operating environment (vehicular networks) brings is not radically new, the operating environment (vehicular networks)
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. Maximum Transmission Unit (MTU) 4.1. Maximum Transmission Unit (MTU)
The default MTU for IP packets on 802.11-OCB is 1500 octets. It is The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. It
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). If IPv6 packets of size larger than with respect to fragmentation). If IPv6 packets of size larger than
1500 bytes are sent on an 802.11-OCB interface card then the IP stack 1500 bytes are sent on an 802.11-OCB interface card then the IP stack
will fragment. In case there are IP fragments, the field "Sequence will fragment. In case there are IP fragments, the field "Sequence
number" of the 802.11 Data header containing the IP fragment field is number" of the 802.11 Data header containing the IP fragment field is
increased. increased.
Non-IP packets such as WAVE Short Message Protocol (WSMP) can be Non-IP packets such as WAVE Short Message Protocol (WSMP) can be
skipping to change at page 9, line 28 skipping to change at page 9, line 46
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].
As with all Ethernet and 802.11 interface identifiers ([RFC7721]), As with all Ethernet and 802.11 interface identifiers ([RFC7721]),
the identifier of an 802.11-OCB interface may involve privacy, MAC the identifier of an 802.11-OCB interface may involve privacy, MAC
address spoofing and IP address hijacking risks. A vehicle embarking address spoofing and IP address hijacking risks. A vehicle embarking
an OBU or an OBRU whose egress interface is 802.11-OCB may expose 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 itself to eavesdropping and subsequent correlation of data; this may
reveal data considered private by the vehicle owner; there is a risk reveal data considered private by the vehicle owner; there is a risk
of being tracked; see the privacy considerations described in of being tracked; see the privacy considerations described in
Appendix F. Appendix F.
If stable Interface Identifiers are needed in order to form IPv6 If stable Interface Identifiers are needed in order to form IPv6
addresses on 802.11-OCB links, it is recommended to follow the addresses on 802.11-OCB links, it is recommended to follow the
recommendation in [RFC8064]. Additionally, if semantically opaque recommendation in [RFC8064]. Additionally, if semantically opaque
Interface Identifiers are needed, a potential method for generating Interface Identifiers are needed, a potential method for generating
semantically opaque Interface Identifiers with IPv6 Stateless Address semantically opaque Interface Identifiers with IPv6 Stateless Address
skipping to change at page 11, line 9 skipping to change at page 11, line 30
As with all Ethernet and 802.11 interface identifiers, there may As with all Ethernet and 802.11 interface identifiers, there may
exist privacy risks in the use of 802.11-OCB interface identifiers. exist privacy risks in the use of 802.11-OCB interface identifiers.
Moreover, in outdoors vehicular settings, the privacy risks are more Moreover, in outdoors vehicular settings, the privacy risks are more
important than in indoors settings. New risks are induced by the important than in indoors settings. New risks are induced by the
possibility of attacker sniffers deployed along routes which listen possibility of attacker sniffers deployed along routes which listen
for IP packets of vehicles passing by. For this reason, in the for IP packets of vehicles passing by. For this reason, in the
802.11-OCB deployments, there is a strong necessity to use protection 802.11-OCB deployments, there is a strong necessity to use protection
tools such as dynamically changing MAC addresses. This may help tools such as dynamically changing MAC addresses. This may help
mitigate privacy risks to a certain level. On another hand, it may mitigate privacy risks to a certain level. On another hand, it may
have an impact in the way typical IPv6 address auto-configuration is have an impact in the way typical IPv6 address auto-configuration is
performed for vehicles (SLAAC would rely on MAC addresses amd would performed for vehicles (SLAAC would rely on MAC addresses and would
hence dynamically change the affected IP address), in the way the hence dynamically change the affected IP address), in the way the
IPv6 Privacy addresses were used, and other effects. IPv6 Privacy addresses were used, and other effects.
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.
skipping to change at page 16, line 33 skipping to change at page 17, line 5
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.
From draft-ietf-ipwave-ipv6-over-80211ocb-12 to draft-ietf-ipwave-
ipv6-over-80211ocb-13
o Substituted "IP-OBU" for "OBRU", and "IP-RSU" for "RSRU"
throughout and improved OBU-related definitions in the Terminology
section.
From draft-ietf-ipwave-ipv6-over-80211ocb-11 to draft-ietf-ipwave- From draft-ietf-ipwave-ipv6-over-80211ocb-11 to draft-ietf-ipwave-
ipv6-over-80211ocb-12 ipv6-over-80211ocb-12
o Improved the appendix about "MAC Address Generation" by expressing o Improved the appendix about "MAC Address Generation" by expressing
the technique to be an optional suggestion, not a mandatory the technique to be an optional suggestion, not a mandatory
mechanism. mechanism.
From draft-ietf-ipwave-ipv6-over-80211ocb-10 to draft-ietf-ipwave- From draft-ietf-ipwave-ipv6-over-80211ocb-10 to draft-ietf-ipwave-
ipv6-over-80211ocb-11 ipv6-over-80211ocb-11
skipping to change at page 23, line 25 skipping to change at page 23, line 51
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
o No association is needed in order to be able to communicate o No association is needed in order to be able to communicate
o No encryption is provided in order to be able to communicate o No encryption is provided in order to be able to communicate
o Flag dot11OCBActivated is set to true o Flag dot11OCBActivated is set to true
All the nodes in the radio communication range (OBRU and RSRU) All the nodes in the radio communication range (IP-OBU and IP-RSU)
receive all the messages transmitted (OBRU and RSRU) within the radio receive all the messages transmitted (IP-OBU and IP-RSU) within the
communications range. The eventual conflict(s) are resolved by the radio communications range. The eventual conflict(s) are resolved by
MAC CDMA function. the MAC CDMA function.
The message exchange diagram in Figure 4 illustrates a comparison The message exchange diagram in Figure 4 illustrates a comparison
between traditional 802.11 and 802.11 in OCB mode. The 'Data' between traditional 802.11 and 802.11 in OCB mode. The 'Data'
messages can be IP packets such as HTTP or others. Other 802.11 messages can be IP packets such as HTTP or others. Other 802.11
management and control frames (non IP) may be transmitted, as management and control frames (non IP) may be transmitted, as
specified in the 802.11 standard. For information, the names of specified in the 802.11 standard. For information, the names of
these messages as currently specified by the 802.11 standard are these messages as currently specified by the 802.11 standard are
listed in Appendix G. listed in Appendix G.
STA AP STA1 STA2 STA AP STA1 STA2
skipping to change at page 25, line 9 skipping to change at page 25, line 19
and 'n' are, 'p' is concerned more with MAC modifications, and a and 'n' are, 'p' is concerned more with MAC modifications, and a
little with PHY modifications; the others are mainly about PHY little with PHY modifications; the others are mainly about PHY
modifications. It is possible in practice to combine a 'p' MAC with modifications. It is possible in practice to combine a 'p' MAC with
an 'a' PHY by operating outside the context of a BSS with OFDM at an 'a' PHY by operating outside the context of a BSS with OFDM at
5.4GHz and 5.9GHz. 5.4GHz and 5.9GHz.
The 802.11-OCB links are specified to be compatible as much as The 802.11-OCB links are specified to be compatible as much as
possible with the behaviour of 802.11a/b/g/n and future generation possible with the behaviour of 802.11a/b/g/n and future generation
IEEE WLAN links. From the IP perspective, an 802.11-OCB MAC layer IEEE WLAN links. From the IP perspective, an 802.11-OCB MAC layer
offers practically the same interface to IP as the WiFi and Ethernet offers practically the same interface to IP as the WiFi and Ethernet
layers do (802.11a/b/g/n and 802.3). A packet sent by an OBRU may be layers do (802.11a/b/g/n and 802.3). A packet sent by an IP-OBU may
received by one or multiple RSRUs. The link-layer resolution is be received by one or multiple IP-RSUs. The link-layer resolution is
performed by using the IPv6 Neighbor Discovery protocol. performed by using the IPv6 Neighbor Discovery protocol.
To support this similarity statement (IPv6 is layered on top of LLC To support this similarity statement (IPv6 is layered on top of LLC
on top of 802.11-OCB, in the same way that IPv6 is layered on top of on top of 802.11-OCB, in the same way that IPv6 is layered on top of
LLC on top of 802.11a/b/g/n (for WLAN) or layered on top of LLC on LLC on top of 802.11a/b/g/n (for WLAN) or layered on top of LLC on
top of 802.3 (for Ethernet)) it is useful to analyze the differences top of 802.3 (for Ethernet)) it is useful to analyze the differences
between 802.11-OCB and 802.11 specifications. During this analysis, between 802.11-OCB and 802.11 specifications. During this analysis,
we note that whereas 802.11-OCB lists relatively complex and numerous we note that whereas 802.11-OCB lists relatively complex and numerous
changes to the MAC layer (and very little to the PHY layer), there changes to the MAC layer (and very little to the PHY layer), there
are only a few characteristics which may be important for an are only a few characteristics which may be important for an
skipping to change at page 32, line 13 skipping to change at page 32, line 28
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 6, the packet is an 802.11-OCB link. In topology depicted in Figure 6, the packet is an
IPv6 Router Advertisement. This packet is emitted by a Router on its IPv6 Router Advertisement. This packet is emitted by a Router on its
802.11-OCB interface. The packet is captured on the Host, using a 802.11-OCB interface. The packet is captured on the Host, using a
network protocol analyzer (e.g. Wireshark); the capture is performed network protocol analyzer (e.g. Wireshark); the capture is performed
in two different modes: direct mode and 'monitor' mode. The topology in two different modes: direct mode and 'monitor' mode. The topology
used during the capture is depicted below. used during the capture is depicted below.
The packet is captured on the Host. The Host is an IP-OBU containing
an 802.11 interface in format PCI express (an ITRI product). The
kernel runs the ath5k software driver with modifications for OCB
mode. The capture tool is Wireshark. The file format for save and
analyze is 'pcap'. The packet is generated by the Router. The
Router is an IP-RSU (ITRI product).
+--------+ +-------+ +--------+ +-------+
| | 802.11-OCB Link | | | | 802.11-OCB Link | |
---| Router |--------------------------------| Host | ---| Router |--------------------------------| Host |
| | | | | | | |
+--------+ +-------+ +--------+ +-------+
Figure 6: Topology for capturing IP packets on 802.11-OCB Figure 6: Topology for capturing IP packets on 802.11-OCB
During several capture operations running from a few moments to During several capture operations running from a few moments to
several hours, no message relevant to the BSSID contexts were several hours, no message relevant to the BSSID contexts were
 End of changes. 25 change blocks. 
65 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/