--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-21.txt 2018-03-20 09:14:09.536746612 -0700 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-22.txt 2018-03-20 09:14:09.620748586 -0700 @@ -1,26 +1,26 @@ Network Working Group A. Petrescu Internet-Draft CEA, LIST Intended status: Standards Track N. Benamar -Expires: September 4, 2018 Moulay Ismail University +Expires: September 21, 2018 Moulay Ismail University J. Haerri Eurecom J. Lee Sangmyung University T. Ernst YoGoKo - March 3, 2018 + March 20, 2018 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-21.txt + draft-ietf-ipwave-ipv6-over-80211ocb-22.txt Abstract 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 @@ -35,21 +35,21 @@ 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 September 4, 2018. + This Internet-Draft will expire on September 21, 2018. Copyright Notice Copyright (c) 2018 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 @@ -191,30 +191,38 @@ 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 [RFC2464]. This value of the MTU respects the recommendation that every link on the Internet must have a minimum MTU of 1280 octets (stated in [RFC8200], and the recommendations therein, especially with respect to fragmentation). 4.2. Frame Format - IP packets are transmitted over 802.11-OCB as standard Ethernet - packets. As with all 802.11 frames, an Ethernet adaptation layer - MUST be used with 802.11-OCB as well. This Ethernet Adaptation Layer - performing 802.11-to-Ethernet is described in Section 4.2.1. The - Ethernet Type code (EtherType) for IPv6 MUST be 0x86DD (hexadecimal - 86DD, or otherwise #86DD). + IP packets MUST be transmitted over 802.11-OCB media as QoS Data + frames whose format is specified in IEEE Std 802.11. - The Frame format for transmitting IPv6 on 802.11-OCB networks MUST be - the same as transmitting IPv6 on Ethernet networks, and is described - in section 3 of [RFC2464]. + The IPv6 packet transmitted on 802.11-OCB MUST be immediately + preceded by a Logical Link Control (LLC) header and an 802.11 header. + In the LLC header, and in accordance with the EtherType Protocol + Discrimination (EPD), the value of the Type field MUST be set to + 0x86DD (IPv6). In the 802.11 header, the value of the Subtype sub- + field in the Frame Control field MUST be set to 8 (i.e. 'QoS Data'); + the value of the Traffic Identifier (TID) sub-field of the QoS + Control field of the 802.11 header MUST be set to binary 001 (i.e. + User Priority 'Background', QoS Access Category 'AC_BK'). + + To simplify the Application Programming Interface (API) between the + operating system and the 802.11-OCB media, device drivers MAY + implement an Ethernet Adaptation Layer that translates Ethernet II + frames to the 802.11 format and vice versa. An Ethernet Adaptation + Layer is described in Section 4.2.1. 4.2.1. Ethernet Adaptation Layer An 'adaptation' layer is inserted between a MAC layer and the Networking layer. This is used to transform some parameters between their form expected by the IP stack and the form provided by the MAC layer. An Ethernet Adaptation Layer makes an 802.11 MAC look to IP Networking layer as a more traditional Ethernet layer. At reception, @@ -239,46 +247,42 @@ +---------------------+-------------+---------+ | Ethernet II Header | IPv6 Header | Payload | +---------------------+-------------+---------+ Figure 1: Operation of the Ethernet Adaptation Layer The Receiver and Transmitter Address fields in the 802.11 header MUST contain the same values as the Destination and the Source Address fields in the Ethernet II Header, respectively. The value of the Type field in the LLC Header MUST be the same as the value of the - Type field in the Ethernet II Header. + Type field in the Ethernet II Header. That value MUST be set to + 0x86DD (IPv6). The ".11 Trailer" contains solely a 4-byte Frame Check Sequence. - The specification of which type or subtype of 802.11 headers are used - to transmit IP packets is left outside the scope of this document. - The placement of IPv6 networking layer on Ethernet Adaptation Layer is illustrated in Figure 2. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Adaptation Layer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 802.11 MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 802.11 PHY | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Ethernet Adaptation Layer stacked with other layers (in the above figure, a 802.11 profile is represented; this is used - also for 802.11 OCB profile.) - Other alternative views of layering are EtherType Protocol - Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. + also for 802.11-OCB profile.) 4.3. Link-Local Addresses The link-local address of an 802.11-OCB interface is formed in the same manner as on an Ethernet interface. This manner is described in section 5 of [RFC2464]. Additionally, if stable identifiers are needed, it is RECOMMENDED to follow the Recommendation on Stable IPv6 Interface Identifiers [RFC8064]. Additionally, if semantically opaque Interface Identifiers are needed, a potential method for generating semantically opaque Interface Identifiers with IPv6 @@ -343,34 +347,34 @@ that are in close range (not their on-board interfaces). This ephemeral subnet structure is strongly influenced by the mobility of vehicles: the 802.11 hidden node effects appear. On another hand, the structure of the internal subnets in each car is relatively stable. The 802.11 networks in OCB mode may be considered as 'ad-hoc' networks. The addressing model for such networks is described in [RFC5889]. - The operation of the Neighbor Discovery protocol (ND) over 802.11 OCB + The operation of the Neighbor Discovery protocol (ND) over 802.11-OCB links is different than over 802.11 links. In OCB, the link layer does not ensure that all associated members receive all messages, because there is no association operation. The operation of ND over - 802.11 OCB is not specified in this document. + 802.11-OCB is not specified in this document. - 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 (section 11.5.1 of [RFC6275]) can not rely on Neighbor Unreachability 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 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. 5. Security Considerations 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 operating over 802.11-OCB. 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 @@ -441,23 +445,23 @@ The authors would like to thank Witold Klaudel, Ryuji Wakikawa, Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan, Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne, Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark, Bob Moskowitz, Andrew Dryden, Georg Mayer, Dorothy Stanley, Sandra Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun, Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in - 't Velt, Katrin Sjoberg, Roland Bless and William Whyte. Their - valuable comments clarified particular issues and generally helped to - improve the document. + 't Velt, Katrin Sjoberg, Roland Bless, Russ Housley, Tijink Jasja, + Kevin Smith and William Whyte. Their valuable comments clarified + particular issues and generally helped to improve the document. Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB drivers for linux and described how. For the multicast discussion, the authors would like to thank Owen DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and participants to discussions in network working groups. The authors would like to thank participants to the Birds-of- a-Feather "Intelligent Transportation Systems" meetings held at IETF @@ -642,20 +646,28 @@ 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-21 to draft-ietf-ipwave- + ipv6-over-80211ocb-22 + + o Corrected typo, use dash in "802.11-OCB" instead of space. + + o Improved the Frame Format section: MUST use QoSData, specify the + values within; clarified the Ethernet Adaptation Layer text. + From draft-ietf-ipwave-ipv6-over-80211ocb-20 to draft-ietf-ipwave- ipv6-over-80211ocb-21 o Corrected a few nits and added names in Acknowledgments section. o Removed unused reference to old Internet Draft tsvwg about QoS. From draft-ietf-ipwave-ipv6-over-80211ocb-19 to draft-ietf-ipwave- ipv6-over-80211ocb-20 @@ -717,32 +730,32 @@ Adaptation Layer". From draft-ietf-ipwave-ipv6-over-80211ocb-13 to draft-ietf-ipwave- ipv6-over-80211ocb-14 o Created a new Appendix titled "Extra Terminology" that contains terms DSRC, DSRCS, OBU, RSU as defined outside IETF. Some of them are used in the main Terminology section. o Added two paragraphs explaining that ND and Mobile IPv6 have - problems working over 802.11 OCB, yet their adaptations is not + problems working over 802.11-OCB, yet their adaptations is not specified in this document. 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- ipv6-over-80211ocb-12 + o Improved the appendix about "MAC Address Generation" by expressing the technique to be an optional suggestion, not a mandatory mechanism. From draft-ietf-ipwave-ipv6-over-80211ocb-10 to draft-ietf-ipwave- ipv6-over-80211ocb-11 o Shortened the paragraph on forming/terminating 802.11-OCB links. o Moved the draft tsvwg-ieee-802-11 to Informative References. @@ -893,21 +906,21 @@ o Moved the packet capture example into an Appendix Implementation Status. o Suggested moving the reliability requirements appendix out into another document. o Added a IANA Consiserations section, with content, requesting for a new multicast group "all OCB interfaces". o Added new OBU term, improved the RSU term definition, removed the - ETTC term, replaced more occurences of 802.11p, 802.11 OCB with + ETTC term, replaced more occurences of 802.11p, 802.11-OCB with 802.11-OCB. o References: * Added an informational reference to ETSI's IPv6-over- GeoNetworking. * Added more references to IETF and ETSI security protocols. * Updated some references from I-D to RFC, and from old RFC to @@ -1023,21 +1036,21 @@ o Moved references to scientific articles to a separate 'overview' draft, and referred to it. Appendix B. 802.11p 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 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 + 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. 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 directly communicate with each other without involving authentication or association procedures. At link layer, it is necessary to set the same channel number (or frequency) on two stations that need to