Minutes IETF97: ipwave
minutes-97-ipwave-02

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.