draft-ietf-ipwave-ipv6-over-80211ocb-42.txt   draft-ietf-ipwave-ipv6-over-80211ocb-43.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 19, 2019 Moulay Ismail University Expires: October 20, 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 17, 2019 April 18, 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-42 draft-ietf-ipwave-ipv6-over-80211ocb-43
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 19, 2019. This Internet-Draft will expire on October 20, 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.
The subnet structure on which the Neighbor Discovery protocol (ND) on
OCB works ok is a single-link subnet; the status of ND operation on a
subnet that covers multiple OCB links that repeat the signal at PHY
layer, or the messages at MAC layer, is unknown.
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 33 skipping to change at page 11, line 35
o The 46 remaining bits are set to a random value, using a random o The 46 remaining bits are set to a random value, using a random
number generator that meets the requirements of [RFC4086]. number generator that meets the requirements of [RFC4086].
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. An Interface ID
SHOULD be of length 48 decimal. An Interface ID SHOULD be of length SHOULD be of length specified in other documents.
specified in other documents.
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 12, line 46 skipping to change at page 12, line 48
Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan
Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray
Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan, Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan,
Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne, Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne,
Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark, Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark,
Bob Moskowitz, Andrew Dryden, Georg Mayer, Dorothy Stanley, Sandra Bob Moskowitz, Andrew Dryden, Georg Mayer, Dorothy Stanley, Sandra
Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun, Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun,
Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in
't Velt, Katrin Sjoberg, Roland Bless, Tijink Jasja, Kevin Smith, 't Velt, Katrin Sjoberg, Roland Bless, Tijink Jasja, Kevin Smith,
Brian Carpenter, Julian Reschke, Mikael Abrahamsson, Dirk von Hugo, Brian Carpenter, Julian Reschke, Mikael Abrahamsson, Dirk von Hugo,
Lorenzo Colitti, Pascal Thubert, Ole Troan, Jinmei Tatuya and William Lorenzo Colitti, Pascal Thubert, Ole Troan, Jinmei Tatuya, Joel
Whyte. Their valuable comments clarified particular issues and Halpern, Eric Gray and William Whyte. Their valuable comments
generally helped to improve the document. clarified particular issues and generally helped to improve the
document.
Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB
drivers for linux and described how. drivers for linux and described how.
For the multicast discussion, the authors would like to thank Owen For the multicast discussion, the authors would like to thank Owen
DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and
participants to discussions in network working groups. participants to discussions in network working groups.
The authors would like to thank participants to the Birds-of- The authors would like to thank participants to the Birds-of-
a-Feather "Intelligent Transportation Systems" meetings held at IETF a-Feather "Intelligent Transportation Systems" meetings held at IETF
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.
-43: removed the SHOULD 48bit of a MAC address, just stay silent
about it; corrected 'global' address to 'Globally Reachable address';
added a paragraph scoping IPv6-over-OCB ND to work ok on single-link
subnets.
-42: removed 118 len IID; points to 'other documents' for the length -42: removed 118 len IID; points to 'other documents' for the length
of Interface ID; removed 'directly using' phrase for LLs in a subnet. 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
skipping to change at page 41, line 49 skipping to change at page 41, line 49
require additional support, e.g., for Address Resolution (AR) and require additional support, e.g., for Address Resolution (AR) and
duplicate address detection (DAD), which depend on multicast. An duplicate address detection (DAD), which depend on multicast. An
infrastructureless radio network such as OCB shares properties with infrastructureless radio network such as OCB shares properties with
both Shared Media and NBMA networks, and then adds its own both Shared Media and NBMA networks, and then adds its own
complexity, e.g., from movement and interference that allow only complexity, e.g., from movement and interference that allow only
transient and non-transitive reachability between any set of peers. transient and non-transitive reachability between any set of peers.
The uniqueness of an address within a scoped domain is a key pillar The uniqueness of an address within a scoped domain is a key pillar
of IPv6 and the base for unicast IP communication. RFC 4861 details of IPv6 and the base for unicast IP communication. RFC 4861 details
the DAD method to avoid that an address is duplicated. For a link the DAD method to avoid that an address is duplicated. For a link
local address, the scope is the link, whereas for a global address local address, the scope is the link, whereas for a Globally
the scope is much larger. The underlying assumption for DAD to Reachable address the scope is much larger. The underlying
operate correctly is that the node that owns an IPv6 address can assumption for DAD to operate correctly is that the node that owns an
reach any other node within the scope at the time it claims its IPv6 address can reach any other node within the scope at the time it
address, which is done by sending a NS multicast message, and can claims its address, which is done by sending a NS multicast message,
hear any future claim for that address by another party within the and can hear any future claim for that address by another party
scope for the duration of the address ownership. within the scope for the duration of the address ownership.
In the case of OCB, there is a potentially a need to define a scope In the case of OCB, there is a potentially a need to define a scope
that is compatible with DAD, and that cannot be the set of nodes that that is compatible with DAD, and that cannot be the set of nodes that
a transmitter can reach at a particular time, because that set varies a transmitter can reach at a particular time, because that set varies
all the time and does not meet the DAD requirements for a link local all the time and does not meet the DAD requirements for a link local
address that could possibly be used anytime, anywhere. The generic address that could possibly be used anytime, anywhere. The generic
expectation of a reliable multicast is not ensured, and the operation expectation of a reliable multicast is not ensured, and the operation
of DAD and AR (Address Resolution) as specificed by RFC 4861 cannot of DAD and AR (Address Resolution) as specificed by RFC 4861 cannot
be guaranteed. Moreoever, multicast transmissions that rely on be guaranteed. Moreoever, multicast transmissions that rely on
broadcast are not only unreliable but are also often detrimental to broadcast are not only unreliable but are also often detrimental to
 End of changes. 9 change blocks. 
17 lines changed or deleted 27 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/