--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-06.txt 2017-09-17 12:13:12.981594220 -0700 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-07.txt 2017-09-17 12:13:13.073596410 -0700 @@ -1,139 +1,138 @@ Network Working Group A. Petrescu Internet-Draft CEA, LIST Intended status: Standards Track N. Benamar -Expires: March 16, 2018 Moulay Ismail University +Expires: March 21, 2018 Moulay Ismail University J. Haerri Eurecom C. Huitema Private Octopus Inc. J. Lee Sangmyung University T. Ernst YoGoKo T. Li Peloton Technology - September 12, 2017 + September 17, 2017 Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) - draft-ietf-ipwave-ipv6-over-80211ocb-06.txt + draft-ietf-ipwave-ipv6-over-80211ocb-07.txt Abstract - In order to transmit IPv6 packets on IEEE 802.11 networks run 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 Maximum - Transmission Unit size on the 802.11-OCB link, the header format - preceding the IPv6 header, the Type value within it, and others. - This document describes these parameters for IPv6 and IEEE 802.11-OCB - networks; it portrays the layering of IPv6 on 802.11-OCB similarly to - other known 802.11 and Ethernet layers - by using an Ethernet - Adaptation Layer. + In order to transmit IPv6 packets on IEEE 802.11 networks running + 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 + Maximum Transmission Unit size on the 802.11-OCB link, the header + format preceding the IPv6 header, the Type value within it, and + others. This document describes these parameters for IPv6 and IEEE + 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB + similarly to other known 802.11 and Ethernet layers - by using an + Ethernet Adaptation Layer. In addition, the document lists what is different in 802.11-OCB (802.11p) links compared to more 'traditional' 802.11a/b/g/n links, where IPv6 protocols operate without issues. Most notably, the - operation outside the context of a BSS (OCB) has impact on IPv6 - handover behaviour and on IPv6 security. + operation outside the context of a BSS (OCB) impacts IPv6 handover + behaviour and IPv6 security. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 16, 2018. + This Internet-Draft will expire on March 21, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 6 + 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 7 4. Aspects introduced by the OCB mode to 802.11 . . . . . . . . 7 5. Layering of IPv6 over 802.11-OCB as over Ethernet . . . . . . 11 5.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 11 - 5.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 11 + 5.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 12 5.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 13 5.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 14 - 5.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 14 + 5.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 15 5.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 15 5.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 15 5.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 16 5.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Changes Needed on a software driver 802.11a to - become a 802.11-OCB driver . . . 27 + become a 802.11-OCB driver . . . 28 Appendix C. Design Considerations . . . . . . . . . . . . . . . 29 C.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 29 - C.2. Reliability Requirements . . . . . . . . . . . . . . . . 29 - C.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 30 + C.2. Reliability Requirements . . . . . . . . . . . . . . . . 30 + C.3. Multiple interfaces . . . . . . . . . . . . . . . . . . . 31 C.4. MAC Address Generation . . . . . . . . . . . . . . . . . 31 - Appendix D. IEEE 802.11 Messages Transmitted in OCB mode . . . . 31 + Appendix D. IEEE 802.11 Messages Transmitted in OCB mode . . . . 32 Appendix E. Implementation Status . . . . . . . . . . . . . . . 32 - E.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 32 + E.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 33 E.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction This document describes the transmission of IPv6 packets on IEEE Std - 802.11-OCB networks (earlier known as 802.11p) [IEEE-802.11-2016]. - This involves the layering 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 is no modification required to the - standards: IPv6 works fine directly over 802.11-OCB too (with an LLC - layer). + 802.11-OCB networks (a.k.a 802.11p) [IEEE-802.11-2016]. This + involves the layering 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 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 layer). The term "802.11p" is an earlier definition. The behaviour of "802.11p" networks is rolled in the document IEEE Std 802.11-2016. In that document the term 802.11p disappears. Instead, each 802.11p - feature is conditioned by a flag in the Management Information Base. - That flag is named "OCBActivated". Whenever OCBActivated is set to - true the feature it relates to, or represents, an earlier 802.11p - feature. For example, an 802.11 STAtion operating outside the - context of a basic 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. + feature is conditioned by the Management Information Base (MIB) + attribute "OCBActivated". Whenever OCBActivated 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 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. The IPv6 network layer operates on 802.11-OCB in the same manner as it operates on 802.11 WiFi, with a few particular exceptions. The IPv6 network layer operates on WiFi by involving an Ethernet Adaptation Layer; this Ethernet Adaptation Layer maps 802.11 headers to Ethernet II headers. The operation of IP on Ethernet is described in [RFC1042], [RFC2464] and [I-D.hinden-6man-rfc2464bis]. The situation of IPv6 networking layer on Ethernet Adaptation Layer is illustrated below: @@ -181,33 +180,32 @@ the performances of running IPv6 over 802.11-OCB (e.g. in the case of handovers between 802.11-OCB-enabled access routers, or the consideration of using the IP security architecture [RFC4301]). There are currently no specifications for handover between OCB links since these are currently specified as LLC-1 links (i.e. connectionless). Any handovers must be performed above the Data Link Layer. To realize handovers between OCB links there is a need of specific indicators to assist in the handover process. The indicators may be IP Router Advertisements, or 802.11-OCB's Time - Advertisements, or higher layer messages such as the 'Basic Safety - Message' (in the US), or the 'Cooperative Awareness Message' (in the - EU), or the 'WAVE Routing Advertisement'. However, this document + Advertisements, or application-layer data. However, this document does not describe handover behaviour. - The OCB operation is stripping off 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 network layer running on 802.11-OCB. At application layer, the IEEE 1609.2 document [IEEE-1609.2] does provide security services for - certain applications to use. A security mechanism provided at - networking layer, such as IPsec [RFC4301], may provide data security - protection to a wider range of applications. See the section - Security Considerations of this document, Section 6 + certain applications to use; application-layer mechanisms are out-of- + scope of this document. On another hand, a security mechanism + provided at networking layer, such as IPsec [RFC4301], may provide + data security protection to a wider range of applications. See the + section Security Considerations of this document, Section 6 We briefly introduce the vehicular communication scenarios where IEEE 802.11-OCB links are used. This is followed by a description of differences in specification terms, between 802.11-OCB and 802.11a/b/g/n - we answer the question of what are the aspects introduced by OCB mode to 802.11; the same aspects, but expressed in terms of requirements to implementation, are listed in Appendix B.) The document then concentrates on the parameters of layering IP over 802.11-OCB as over Ethernet: value of MTU, the Frame Format which @@ -226,56 +224,72 @@ In the published literature, many documents describe aspects related to running IPv6 over 802.11-OCB: [I-D.jeong-ipwave-vehicular-networking-survey]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. - OBU (On-Board Unit): contrary to an RSU, an OBU is almost always - situated in a vehicle; it is a computer with at least two IP - interfaces; also, at least one IP interface runs in OCB mode of - 802.11. It may be an IP router. + OBRU (On-Board Router Unit): an OBRU is almost always situated in a + vehicle; it is a computer with at least two IP interfaces; at least + one IP interface runs in OCB mode of 802.11. It MAY be an IP Router. - RSU (Road Side Unit): It is a Wireless Termination Point (WTP), as - defined in [RFC5415], or an Access Point (AP), or an Access Network - Router (ANR) defined in [RFC3753], with one key particularity: the - wireless PHY/MAC layer is configured to operate in 802.11-OCB mode. - The RSU communicates with the On board Unit (OBU) in the vehicle over - 802.11 wireless link operating in OCB mode. An RSU 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. + RSRU (Road-Side Router Unit): an RSRU is almost always situated in a + box fixed along the road. An RSRU has at least two distinct IP- + enabled interfaces; at least one interface is operated in mode OCB of + IEEE 802.11 and is IP-enabled. An RSRU is similar to a Wireless + Termination Point (WTP), as defined in [RFC5415], or an Access Point + (AP), as defined in IEEE documents, or an Access Network Router (ANR) + defined in [RFC3753], with one key particularity: the wireless PHY/ + MAC layer of at least one of its IP-enabled interfaces is configured + to operate in 802.11-OCB mode. The RSRU communicates with the On + board Unit (OBRU) in the vehicle over 802.11 wireless link operating + in OCB mode. An 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 + broadcasts data to OBUs or exchanges data with OBUs in its + communications zone. An RSU may provides channel assignments and + operating instructions to OBUs in its communications zone, when + required. The basic functional blocks of an RSU are: internal + computer processing, permanent storage capability, an integrated GPS + receiver for positioning and timing and an interface that supports + both IPv4 and IPv6 connectivity, compliant with 802.3at. An OCB + interface of an RSU MAY be IP-enabled simultaneously to being WAVE- + enabled or GeoNetworking-enabled (MAY support simultaneously + EtherTypes 0x86DD for IPv6 _and_ 0x88DC for WAVE and 0x8947 for + GeoNetworking). 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 utilize IEEE Std 802.11 authentication, association, or data confidentiality. - 802.11-OCB, or 802.11-OCB: text in document IEEE 802.11-2016 that is - flagged by "dot11OCBActivated". The text flagged "dot11OCBActivated" - includes IEEE 802.11e for quality of service, 802.11j-2004 for half- - clocked operations and (what was known earlier as) 802.11p for - operation in the 5.9 GHz band and in mode OCB. + 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB + attribute dot11OCBActivited is true. The OCB mode requires + transmission of QoS data frames (IEEE Std 802.11e), half-clocked + operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. 3. Communication Scenarios where IEEE 802.11-OCB Links are Used The IEEE 802.11-OCB Networks are used for vehicular communications, as 'Wireless Access in Vehicular Environments'. The IP communication scenarios for these environments have been described in several documents, among which we refer the reader to one recently updated [I-D.petrescu-its-scenarios-reqs], about scenarios and requirements for IP in Intelligent Transportation Systems. The link model is the following: STA --- 802.11-OCB --- STA. In - vehicular networks, STAs can be RSUs and/or OBUs. While 802.11-OCB + vehicular networks, STAs can be RSRUs and/or OBRUs. While 802.11-OCB is clearly specified, and the use of IPv6 over such link is not radically new, the operating environment (vehicular networks) brings in new perspectives. The 802.11-OCB links form and terminate; nodes connected to these links peer, and discover each other; the nodes are mobile. However, the precise description of how links discover each other, peer and manage mobility is not given in this document. 4. Aspects introduced by the OCB mode to 802.11 @@ -296,22 +310,22 @@ o No IEEE 802.11 Beacon frames are transmitted 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 encryption is provided in order to be able to communicate o Flag dot11OCBActivated is set to true - All the nodes in the radio communication range (OBU and RSU) receive - all the messages transmitted (OBU and RSU) within the radio + All the nodes in the radio communication range (OBRU and RSRU) + receive all the messages transmitted (OBRU and RSRU) within the radio communications range. The eventual conflict(s) are resolved by the MAC CDMA function. The following message exchange diagram illustrates a comparison 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 management and control frames (non IP) may be transmitted, as specified in the 802.11 standard. For information, the names of these messages as currently specified by the 802.11 standard are listed in Appendix D. @@ -327,76 +341,71 @@ |<--- Auth Res. -------| |<------ Data -------->| | | | | |---- Asso Req. ------>| |<------ Data -------->| |<--- Asso Res. -------| | | | | |<------ Data -------->| |<------ Data -------->| | | |<------ Data -------->| |<------ Data -------->| (a) 802.11 Infrastructure mode (b) 802.11-OCB mode - The link 802.11-OCB was specified in IEEE Std 802.11p (TM) -2010 + The interface 802.11-OCB was specified in IEEE Std 802.11p (TM) -2010 [IEEE-802.11p-2010] as an amendment to IEEE Std 802.11 (TM) -2007, titled "Amendment 6: Wireless Access in Vehicular Environments". - Since then, this amendment has been included in IEEE 802.11(TM)-2016 - [IEEE-802.11-2016], titled "IEEE Standard for Information - technology--Telecommunications and information exchange between - systems Local and metropolitan area networks--Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer - (PHY) Specifications"; the modifications are diffused throughout - various sections (e.g. the Time Advertisement message described in - the earlier 802.11 (TM) p amendment is now described in section - 'Frame formats', and the operation outside the context of a BSS - described in section 'MLME'). + Since then, this amendment has been included in IEEE 802.11(TM) -2012 + and -2016 [IEEE-802.11-2016]. In document 802.11-2016, anything qualified specifically as - "OCBActivated", or "outside the context of a basic service set" is - actually referring to OCB aspects introduced to 802.11. Note that in - earlier 802.11p documents the term "OCBEnabled" was used instead of - the current "OCBActivated". + "OCBActivated", or "outside the context of a basic service" set to be + true, then it is actually referring to OCB aspects introduced to + 802.11. In order to delineate the aspects introduced by 802.11-OCB to 802.11, we refer to the earlier [IEEE-802.11p-2010]. The amendment is concerned with vehicular communications, where the wireless link is similar to that of Wireless LAN (using a PHY layer specified by 802.11a/b/g/n), but which needs to cope with the high mobility factor inherent in scenarios of communications between moving vehicles, and between vehicles and fixed infrastructure deployed along roads. While 'p' is a letter just like 'a, b, g' and 'n' are, 'p' is concerned more with MAC modifications, and a little with PHY modifications; the others are mainly about PHY 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 5.4GHz. + operating outside the context of a BSS with OFDM at 5.4GHz and + 5.9GHz. 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 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 - layers do (802.11a/b/g/n and 802.3). A packet sent by an OBU may be - received by one or multiple RSUs. The link-layer resolution is + layers do (802.11a/b/g/n and 802.3). A packet sent by an OBRU may be + received by one or multiple RSRUs. The link-layer resolution is performed by using the IPv6 Neighbor Discovery protocol. 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 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 between 802.11-OCB and 802.11 specifications. During this analysis, 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 are only a few characteristics which may be important for an implementation transmitting IPv6 packets on 802.11-OCB links. The most important 802.11-OCB point which influences the IPv6 functioning is the OCB characteristic; an additional, less direct influence, is the maximum bandwidth afforded by the PHY modulation/ demodulation methods and channel access specified by 802.11-OCB. The - maximum bandwidth possible in 802.11-OCB is 12Mbit/s; this bandwidth + maximum bandwidth theoretically possible in 802.11-OCB is 54 Mbit/s + (when using, for example, the following parameters: 20 MHz channel; + modulation 64-QAM; codint rate R is 3/4); in practice of IP-over- + 802.11-OCB a commonly observed figure is 12Mbit/s; this bandwidth allows the operation of a wide range of protocols relying on IPv6. o Operation Outside the Context of a BSS (OCB): the (earlier 802.11p) 802.11-OCB links are operated without a Basic Service Set (BSS). This means that the frames IEEE 802.11 Beacon, Association Request/Response, Authentication Request/Response, and similar, are not used. The used identifier of BSS (BSSID) has a hexadecimal value always 0xffffffffffff (48 '1' bits, represented as MAC address ff:ff:ff:ff:ff:ff, or otherwise the 'wildcard' BSSID), as opposed to an arbitrary BSSID value set by @@ -419,21 +429,21 @@ is worth considering that the frequency range is regulated by a regional authority (ARCEP, ETSI, FCC, etc.); as part of the regulation process, specific applications are associated with specific frequency ranges. In the case of 802.11-OCB, the regulator associates a set of frequency ranges, or slots within a band, to the use of applications of vehicular communications, in a band known as "5.9GHz". The 5.9GHz band is different from the 2.4GHz and 5GHz bands used by Wireless LAN. However, as with Wireless LAN, the operation of 802.11-OCB in "5.9GHz" bands is exempt from owning a license in EU (in US the 5.9GHz is a licensed - band of spectrum; for the the fixed infrastructure an explicit FCC + band of spectrum; for the fixed infrastructure an explicit FCC autorization is required; for an onboard device a 'licensed-by- rule' concept applies: rule certification conformity is required); however technical conditions are different than those of the bands "2.4GHz" or "5GHz". On one hand, the allowed power levels, and implicitly the maximum allowed distance between vehicles, is of 33dBm for 802.11-OCB (in Europe), compared to 20 dBm for Wireless LAN 802.11a/b/g/n; this leads to a maximum distance of approximately 1km, compared to approximately 50m. On the other hand, specific conditions related to congestion avoidance, jamming avoidance, and radar detection are imposed on the use of DSRC (in @@ -849,21 +859,21 @@ The authours would like to thank participants to the Birds-of- a-Feather "Intelligent Transportation Systems" meetings held at IETF in 2016. 10. References 10.1. Normative References [I-D.ietf-tsvwg-ieee-802-11] Szigeti, T., Henry, J., and F. Baker, "Diffserv to IEEE - 802.11 Mapping", draft-ietf-tsvwg-ieee-802-11-07 (work in + 802.11 Mapping", draft-ietf-tsvwg-ieee-802-11-08 (work in progress), September 2017. [RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, DOI 10.17487/RFC1042, February 1988, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, @@ -1061,20 +1071,37 @@ document freely available at URL http://standards.ieee.org/getieee802/ download/802.11p-2010.pdf retrieved on September 20th, 2013.". Appendix A. ChangeLog The changes are listed in reverse chronological order, most recent changes appearing at the top of the list. + From draft-ietf-ipwave-ipv6-over-80211ocb-06 to draft-ietf-ipwave- + ipv6-over-80211ocb-07 + + o Added new terms: OBRU and RSRU ('R' for Router). Refined the + existing terms RSU and OBU, which are no longer used throughout + the document. + + o Improved definition of term "802.11-OCB". + + o Clarified that OCB does not "strip" security, but that the + operation in OCB mode is "stripped off of all .11 security". + + o Clarified that theoretical OCB bandwidth speed is 54mbits, but + that a commonly observed bandwidth in IP-over-OCB is 12mbit/s. + + o Corrected typographical errors, and improved some phrasing. + From draft-ietf-ipwave-ipv6-over-80211ocb-05 to draft-ietf-ipwave- ipv6-over-80211ocb-06 o Updated references of 802.11-OCB document from -2012 to the IEEE 802.11-2016. o In the LL address section, and in SLAAC section, added references to 7217 opaque IIDs and 8064 stable IIDs. From draft-ietf-ipwave-ipv6-over-80211ocb-04 to draft-ietf-ipwave- @@ -1236,26 +1262,28 @@ Appendix B. Changes Needed on a software driver 802.11a to become a 802.11-OCB driver The 802.11p amendment modifies both the 802.11 stack's physical and MAC layers but all the induced modifications can be quite easily obtained by modifying an existing 802.11a ad-hoc stack. Conditions for a 802.11a hardware to be 802.11-OCB compliant: - o The chip must support the frequency bands on which the regulator - recommends the use of ITS communications, for example using IEEE - 802.11-OCB layer, in France: 5875MHz to 5925MHz. + o The PHY entity shall be an orthogonal frequency division + multiplexing (OFDM) system. It must support the frequency bands + on which the regulator recommends the use of ITS communications, + for example using IEEE 802.11-OCB layer, in France: 5875MHz to + 5925MHz. - o The chip must support the half-rate mode (the internal clock - should be able to be divided by two). + o The OFDM system must provide a "half-clocked" operation using 10 + MHz channel spacings. o The chip transmit spectrum mask must be compliant to the "Transmit spectrum mask" from the IEEE 802.11p amendment (but experimental environments tolerate otherwise). o The chip should be able to transmit up to 44.8 dBm when used by the US government in the United States, and up to 33 dBm in Europe; other regional conditions apply. Changes needed on the network stack in OCB mode: @@ -1263,23 +1291,24 @@ o Physical layer: * The chip must use the Orthogonal Frequency Multiple Access (OFDM) encoding mode. * The chip must be set in half-mode rate mode (the internal clock frequency is divided by two). * The chip must use dedicated channels and should allow the use of higher emission powers. This may require modifications to - the regulatory domains rules, if used by the kernel to enforce - local specific restrictions. Such modifications must respect - the location-specific laws. + the local computer file that describes regulatory domains + rules, if used by the kernel to enforce local specific + restrictions. Such modifications to the local computer file + must respect the location-specific regulatory rules. MAC layer: * All management frames (beacons, join, leave, and others) emission and reception must be disabled except for frames of subtype Action and Timing Advertisement (defined below). * No encryption key or method must be used. * Packet emission and reception must be performed as in ad-hoc @@ -1426,21 +1455,21 @@ STA maintains a TSF Timer, subtype Timing Advertisement; o The STA may send control frames, except those of subtype PS-Poll, CF-End, and CF-End plus CFAck; o The STA may send data frames of subtype Data, Null, QoS Data, and QoS Null. Appendix E. Implementation Status - This section describese 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. By way of example we show that there is no modification in the headers when transmitted over 802.11-OCB networks - they are transmitted like any other 802.11 and Ethernet packets. We describe an experiment of capturing an IPv6 packet on an 802.11-OCB link. In this experiment, the packet is an 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 network