draft-ietf-ipwave-ipv6-over-80211ocb-41.txt   draft-ietf-ipwave-ipv6-over-80211ocb-42.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 18, 2019 Moulay Ismail University Expires: October 19, 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 16, 2019 April 17, 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-41 draft-ietf-ipwave-ipv6-over-80211ocb-42
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 18, 2019. This Internet-Draft will expire on October 19, 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 8, line 44 skipping to change at page 8, line 44
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). A that are in close range (not by their in-vehicle interfaces). A
Prefix List conceptual data structure ([RFC4861] section 5.1) is Prefix List conceptual data structure ([RFC4861] section 5.1) is
maintained for each 802.11-OCB interface. maintained for each 802.11-OCB interface.
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
prefix should be configured on an 802.11-OCB interface. In such prefix should be configured on an 802.11-OCB interface. In such
skipping to change at page 11, line 35 skipping to change at page 11, line 35
To meet the randomization requirements for the 46 remaining bits, a To meet the randomization requirements for the 46 remaining bits, a
hash function may be used. For example, the SHA256 hash function may hash function may be used. For example, the SHA256 hash function may
be used with input a 256 bit local secret, the 'nominal' MAC Address be used with input a 256 bit local secret, the 'nominal' MAC Address
of the interface, and a representation of the date and time of the of the interface, and a representation of the date and time of the
renumbering event. renumbering event.
A randomized Interface ID has the same characteristics of a A randomized Interface ID has the same characteristics of a
randomized MAC address, except the length in bits. A MAC address randomized MAC address, except the length in bits. A MAC address
SHOULD be of length 48 decimal. An Interface ID SHOULD be of length SHOULD be of length 48 decimal. An Interface ID SHOULD be of length
64 decimal for all types of IPv6 addresses. In the particular case specified in other documents.
of IPv6 link-local addresses, the length of the Interface ID MAY be
118 decimal.
5.3. Pseudonym Handling 5.3. Pseudonym Handling
The demand for privacy protection of vehicles' and drivers' The demand for privacy protection of vehicles' and drivers'
identities, which could be granted by using a pseudonym or alias identities, which could be granted by using a pseudonym or alias
identity at the same time, may hamper the required confidentiality of identity at the same time, may hamper the required confidentiality of
messages and trust between participants - especially in safety messages and trust between participants - especially in safety
critical vehicular communication. critical vehicular communication.
o Particular challenges arise when the pseudonymization mechanism o Particular challenges arise when the pseudonymization mechanism
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.
-42: removed 118 len IID; points to 'other documents' for the length
of Interface ID; removed 'directly using' phrase for LLs in a subnet.
-41: updated a reference from draft-ietf-ipwave-vehicular-networking- -41: updated a reference from draft-ietf-ipwave-vehicular-networking-
survey to draft-ietf-ipwave-vehicular-networking; clarified the link- survey to draft-ietf-ipwave-vehicular-networking; clarified the link-
local text by eliminating link-local addresses and prefixes local text by eliminating link-local addresses and prefixes
altogether and referring to RFC4861 which requires the prefixes; altogether and referring to RFC4861 which requires the prefixes;
added a statement about the subnet being a not multi-link subnet. 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).
 End of changes. 7 change blocks. 
10 lines changed or deleted 8 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/