draft-ietf-ipwave-ipv6-over-80211ocb-40.txt   draft-ietf-ipwave-ipv6-over-80211ocb-41.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: October 17, 2019 Moulay Ismail University Expires: October 18, 2019 Moulay Ismail University
J. Haerri J. Haerri
Eurecom Eurecom
J. Lee J. Lee
Sangmyung University Sangmyung University
T. Ernst T. Ernst
YoGoKo YoGoKo
April 15, 2019 April 16, 2019
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-40 draft-ietf-ipwave-ipv6-over-80211ocb-41
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 October 17, 2019. This Internet-Draft will expire on October 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 3, line 43 skipping to change at page 3, line 43
o Exceptions due to the OCB nature of 802.11-OCB compared to 802.11. o Exceptions due to the OCB nature of 802.11-OCB compared to 802.11.
This has impacts on security, privacy, subnet structure and This has impacts on security, privacy, subnet structure and
movement detection. For security and privacy recommendations see movement detection. For security and privacy recommendations see
Section 5 and Section 4.4. The subnet structure is described in Section 5 and Section 4.4. The subnet structure is described in
Section 4.6. The movement detection on OCB links is not described Section 4.6. The movement detection on OCB links is not described
in this document. in this document.
In the published literature, many documents describe aspects and In the published literature, many documents describe aspects and
problems related to running IPv6 over 802.11-OCB: problems related to running IPv6 over 802.11-OCB:
[I-D.ietf-ipwave-vehicular-networking-survey]. [I-D.ietf-ipwave-vehicular-networking].
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
IP-OBU (Internet Protocol On-Board Unit): an IP-OBU is a computer IP-OBU (Internet Protocol On-Board Unit): an IP-OBU is a computer
skipping to change at page 4, line 36 skipping to change at page 4, line 36
attribute dot11OCBActivited is true. Note: compliance with standards attribute dot11OCBActivited is true. Note: compliance with standards
and regulations set in different countries when using the 5.9GHz and regulations set in different countries when using the 5.9GHz
frequency band is required. frequency band is required.
3. Communication Scenarios where IEEE 802.11-OCB Links are Used 3. Communication Scenarios where IEEE 802.11-OCB Links are Used
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], that lists some scenarios and
scenarios and requirements for IP in Intelligent Transportation 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 IP-RSUs and/or IP-OBUs. While vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. While
802.11-OCB is clearly specified, and the use of IPv6 over such link 802.11-OCB is clearly specified, and the use of IPv6 over such link
is not radically new, the operating environment (vehicular networks) is not radically new, the operating environment (vehicular networks)
brings in new perspectives. brings in new perspectives.
4. IPv6 over 802.11-OCB 4. IPv6 over 802.11-OCB
4.1. Maximum Transmission Unit (MTU) 4.1. Maximum Transmission Unit (MTU)
skipping to change at page 8, line 40 skipping to change at page 8, line 40
Transmitting IPv6 packets to multicast destinations over 802.11 links Transmitting IPv6 packets to multicast destinations over 802.11 links
proved to have some performance issues proved to have some performance issues
[I-D.ietf-mboned-ieee802-mcast-problems]. These issues may be [I-D.ietf-mboned-ieee802-mcast-problems]. These issues may be
exacerbated in OCB mode. Solutions for these problems SHOULD exacerbated in OCB mode. Solutions for these problems SHOULD
consider the OCB mode of operation. consider the OCB mode of operation.
4.6. Subnet Structure 4.6. Subnet Structure
A subnet is formed by the external 802.11-OCB interfaces of vehicles A subnet is formed by the external 802.11-OCB interfaces of vehicles
that are in close range (not by their in-vehicle interfaces). This that are in close range (not by their in-vehicle interfaces). A
subnet MUST use at least the link-local prefix and the interfaces Prefix List conceptual data structure ([RFC4861] section 5.1) is
MUST be assigned IPv6 address(es) of type link-local. All nodes in maintained for each 802.11-OCB interface.
the subnet MUST be able to communicate directly using their link-
local unicast addresses. All nodes in the subnet MUST be able to communicate directly using
their link-local unicast addresses.
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 hidden terminal effects influenced by the mobility of vehicles: the hidden terminal effects
appear; the 802.11 networks in OCB mode may be considered as 'ad-hoc' appear; the 802.11 networks in OCB mode may be considered as 'ad-hoc'
networks with an addressing model as described in [RFC5889]. On networks with an addressing model as described in [RFC5889]. On
another hand, the structure of the internal subnets in each car is 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 12, line 10 skipping to change at page 12, line 10
used relies on (randomized) re-addressing. used relies on (randomized) re-addressing.
o A proper pseudonymization tool operated by a trusted third party o A proper pseudonymization tool operated by a trusted third party
may be needed to ensure both aspects simultaneously (privacy may be needed to ensure both aspects simultaneously (privacy
protection on one hand and trust between participants on another protection on one hand and trust between participants on another
hand). hand).
o This is discussed in Section 4.4 and Section 5 of this document. o This is discussed in Section 4.4 and Section 5 of this document.
o Pseudonymity is also discussed in o Pseudonymity is also discussed in
[I-D.ietf-ipwave-vehicular-networking-survey] in its sections [I-D.ietf-ipwave-vehicular-networking] in its sections 4.2.4 and
4.2.4 and 5.1.2. 5.1.2.
6. IANA Considerations 6. IANA Considerations
No request to IANA. No request to IANA.
7. Contributors 7. Contributors
Christian Huitema, Tony Li. Christian Huitema, Tony Li.
Romain Kuntz contributed extensively about IPv6 handovers between Romain Kuntz contributed extensively about IPv6 handovers between
skipping to change at page 16, line 15 skipping to change at page 16, line 15
[ETSI-sec-archi] [ETSI-sec-archi]
"ETSI TS 102 940 V1.2.1 (2016-11), ETSI Technical "ETSI TS 102 940 V1.2.1 (2016-11), ETSI Technical
Specification, Intelligent Transport Systems (ITS); Specification, Intelligent Transport Systems (ITS);
Security; ITS communications security architecture and Security; ITS communications security architecture and
security management, November 2016. Downloaded on security management, November 2016. Downloaded on
September 9th, 2017, freely available from ETSI website at September 9th, 2017, freely available from ETSI website at
URL http://www.etsi.org/deliver/ URL http://www.etsi.org/deliver/
etsi_ts/102900_102999/102940/01.02.01_60/ etsi_ts/102900_102999/102940/01.02.01_60/
ts_102940v010201p.pdf". ts_102940v010201p.pdf".
[I-D.ietf-ipwave-vehicular-networking-survey] [I-D.ietf-ipwave-vehicular-networking]
Jeong, J., Cespedes, S., Benamar, N., Haerri, J., and M. Jeong, J., "IP Wireless Access in Vehicular Environments
Wetterwald, "Survey on IP-based Vehicular Networking for (IPWAVE): Problem Statement and Use Cases", draft-ietf-
Intelligent Transportation Systems", draft-ietf-ipwave- ipwave-vehicular-networking-08 (work in progress), March
vehicular-networking-survey-00 (work in progress), July 2019.
2017.
[I-D.ietf-mboned-ieee802-mcast-problems] [I-D.ietf-mboned-ieee802-mcast-problems]
Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
Zuniga, "Multicast Considerations over IEEE 802 Wireless Zuniga, "Multicast Considerations over IEEE 802 Wireless
Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work
in progress), November 2018. in progress), November 2018.
[IEEE-1609.2] [IEEE-1609.2]
"IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access "IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access
in Vehicular Environments (WAVE) -- Security Services for in Vehicular Environments (WAVE) -- Security Services for
skipping to change at page 17, line 36 skipping to change at page 17, line 36
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.
-41: updated a reference from draft-ietf-ipwave-vehicular-networking-
survey to draft-ietf-ipwave-vehicular-networking; clarified the link-
local text by eliminating link-local addresses and prefixes
altogether and referring to RFC4861 which requires the prefixes;
added a statement about the subnet being a not multi-link subnet.
-40: added a phrase in appendix to further described a condition -40: added a phrase in appendix to further described a condition
where ND on OCB may not work; that phrase contains a placeholder; the where ND on OCB may not work; that phrase contains a placeholder; the
placeholder is 'TBD' (To Be Defined). placeholder is 'TBD' (To Be Defined).
-39: removed a reference to an expired draft trying to update the -39: removed a reference to an expired draft trying to update the
IPv6-over-Ethernet spec 'RFC2464bis'; added text in the subnet IPv6-over-Ethernet spec 'RFC2464bis'; added text in the subnet
structure section saying nodes MUST be able to communicate directly structure section saying nodes MUST be able to communicate directly
using their link-local addresses. using their link-local addresses.
-38: removed the word "fe80::/10". -38: removed the word "fe80::/10".
 End of changes. 10 change blocks. 
21 lines changed or deleted 26 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/