Minutes of the IPWAVE WG meeting at IETF 97 WEDNESDAY, November 16, 2016 1330-1500 Afternoon Session I, Grand Ballroom 3 Chairs: Russ Housley, Carlos J. Bernardos Minute takers: Barry Leiba, Jong-Hyouk Lee Jabber scribe: Robert Sparks 13:30 Administrativia Presenter: Chairs - Note-Well, Blue Sheets, Scribes. - Agenda run-through; no bashes. - Charter presentation. - Status update: new working group, tabula rasa. ** IPWAVE charter related items 13:34 Transmission of IPv6 Packets over IEEE 802.11-OCB Networks Presenter: Alex Petrescu Draft: draft-petrescu-ipv6-over-80211p-05 - Alex Petrescu (AP): this is a merger of four drafts that covered separate aspects, along with some changes to address comments in Berlin. - AP: the title has been changed, but the authors still want some discussion on the title. - AP: here is now some IPv4 text, but there was huge pushback against IPv4 in some discussions. - Suresh Krishnan, AD (SK): justification needed if IPv4 text is going to be in the draft. - Robert Moskowitz (RM): IPv4 text has some interests yet from industries. - RM: this doc should be IPv6 only. For IPv4 use an individual submission about how to coordinate with this. - SK: it should not slow down or interferere with chartered work. - Eric Vyncke (EV): agrees with v6 only. - Russ Housley, chair (RH): hearing no support for IPv4 in the room, authors please take IPv4 out of the document. - RM: QoS data header is really working in OCB mode? I want to know if the QoS data header really work! Are there any studies showing how the QoS fields work? - AP: there are some people who use it. Channel use is an open question. - RM: tt works well in an ESS, but in OCB? - Jaehoon Jeong (JJ): QoS data header is used in link layer... channel access time is different in some cases. We should keep both headers in the draft, but still further investigation is need to know how those headers are used. - AP: let's keep the both headers. - AP: regarding IP handover performance, we need to study more and add details. - Carlos Bernardos, chair (CB): regarding multicast in OCB mode, we consider to ask the author of the multicast draft (draft-perkins-intarea-multicast-ieee802-01) to provide some text regarding multicast in OCB. - SK: regarding MTU size, is it the historical text? - AP: yes, but will be removed. - AP: solved: default MTU 1500, minimum 1280 (256+1024). - AP: solved: multicast address mapping, use 0x3333 for first two octets of MAC address. - AP: solved: use of "LLC Header" - mention 802.11p only once for reference. - AP: solved: interface ID - remove text and refer to RFCs 4862 and 7721. - AP: solved: authn requirements - clarify text; discussion of MAC address change belongs elsewhere. - AP: solved: subnet structure - refer to RFC 5889 and multi-hop-wireless draft. - AP: solved: Appendix D not in scope; remove. 14:06 Survey on IP-based Vehicular Networking for ITS Presenter: J. Jeong Draft: draft-jeong-ipwave-vehicular-networking-survey-00 - EV: instead of modifying protocol semantics, could we use optimistic? - EV: packets should never be fragmented. - SK: referring to particioning of the network, not of the packets. - EV: allocating /64 per node is an example of other solutions to multicast. - Dapeng Liu (DL): most of text are from academic papers... Not sure slide 21 is the right direction. - JJ: we plan to add such other sdo and industrial inputs. - Minpeng Qi (MQ): Vehicle might connect directly, rather than through RSU. RSU not the only way. - CB: as you develop this doc, please include use cases. - AP: there are industry guys in the room who want to contribute use cases. - SK: put all support stuff such as use cases into a single document. 14:24 Problem Statement for Vehicle-to-Infrastructure Networking Presenter: J. Jeong Draft: draft-jeong-its-v2i-problem-statement-02 - RM: communication from inside the vehicle is a big security liability. Only want one component communicating. Things like the dash cam would stream to that common device. But I can't really ensure any security when there's communication open to the vehicle. - -EV: asks about ND, and recommendation not to use. A misunderstanding. Also, gather that multicast is expensive. Energy consumption. - RH: not worried about battery life issues as with cell phone. Multicase & broadcased used all over in this environment. - RM: inside the vehicle, many OEMs won't use IPv6. They will lock down safety networks, no DNS, fixed IP addr. Different for the entertainment networks. Need to make that distinction clear. Safety stuff is totally segmented off. - RH: IP address of the radio is changing in the 1609 spec. - RM is surprised: ah, the radio, misunderstood. Adoption discussion and hums: - AP’s document: mostly leaning toward adopt, but some against... will take to list. - RM thinks it will be OK once today's changes are made. - RH: want to hold off on adopting use cases, problem statement... merge first. ** Other items, time permitting 14:42 Security and Privacy Issues in IPWAVE Presenter: Jong-Hyouk Lee Draft: no draft - MQ: assumptions should be made more general (slide 5). 802.11 should not be the only consideration. - CB: yes, other MAC protocols are also needed to be analyzed. - Jong-Hyouk Lee (JL): slide 2 shows other link layer protocols too. 14:52 Neighbor discovery to support direct communication in ITS Presenter: Zhiwei Yan Draft: draft-yan-its-nd-00 - Chris Shen (CS): MDNS is good, but interval quite long. Did you consider mobility? - Zhiwei Yan (ZY): you are right, and we will consider that. 14:58 Security & Privacy Considerations for IP over 802.11p OCB Presenter: Dapeng Liu Draft: no draft Rushed presentation due to lack of time. - RH: please discuss on the mailing list and we will consider. 15:02 ** Meeting adjourned.