IPWAVE WG meeting at IETF 104 FRIDAY, 29 March 2019 at 10:50-12:50, Athens/Barcelona Chairs: Russ Housley, Carlos J. Bernardos Minute takers: Jaehoon Paul Jeong Jabber scribe: Russ Housley ------------------------------------------------------------------------ 10:50 Administrativia .......................................... 10 min Presenter: IPWAVE WG Chairs ------------------------------------------------------------------------ Carlos introduces the meeting, and the etherpad will be used for notes. WG progress is behind the milestone, so we need to speed up. The IPv6 over 802.11-OCB document got comments from IntDir and IoTDir. After the IPv6 over 802.11-OCB and Problem Statement documents are done, other work can be considered for a recharter. IPWAVE Problem Statement document is revised to address the reviews by Charlie and Sri. During this meeting, the focus will be on the two WG documents. ------------------------------------------------------------------------ ** HACKATHON report 11:00 Implementing IPWAVE Basic Protocols ...................... 20 min Presenter: Jaehoon Paul Jeong ------------------------------------------------------------------------ Paul Jeong (PJ) presents: We participated Hackathon to show the concept of our WG drafts. We want to make sure the IPv6 over OCB mode works well. We also implemented multihop DAD. Several people joined this Hackathon project. The figure in the slides shows the basic Vehicular Network Architecture. Vehicles can talk with other vehicles, and also communicate with RSUs. A vehicle can configure its IPv6 address by the prefix from an RSU. Safety case: V2V communication should be used. We consider a multiple-link subnet model; it is a possible solution. MA is in charge of mobility information for multiple vehicles. We try to reduce the standard DAD overhead. We use two simulators, SUMO and Veins. SUMO provides mobility information. Vehicle structure enables IPv6 access. Support both a WAVE stack and a TCP/IP stack, using 802.11 in OCB mode. Open source code was posted in GitHub. Sri Gundavelli (SG): Your implementation is in simulator? PJ: We implemented it in the simulator, not the linux kernel. SK: In the simulator, you implement this process? PJ: Simulations are the proof-of-concept work. Hope in the future, we can continue work on the topic. Carlos Bernardos (CB): I understand that you implemented one of your proposed drafts. This is useful, but at this stage, we need feedback from experimentation with the IPv6 over OCB document. Did you experience any issue with that? Chris Shen (CS): We implemented IPv6 over OCB, and no issues were found. PJ: This hackathon implemented IPv6 over OCB for Ethernet Adaptation Layer and Vehicular Neighbor Discovery. ------------------------------------------------------------------------ ** IPWAVE WG documents 11:20 Transmission of IPv6 Packets over IEEE 802.11 Networks ... 20 min in mode Outside the Context of a Basic Service Set Presenter: Alex Petrescu Draft: draft-ietf-ipwave-ipv6-over-80211ocb-34 ------------------------------------------------------------------------ Alex Petrescu (AP): We implemented IPv6 over OCB in real cars, and we demonstrated it for POC with the V2V of three cars. ETSI (TC ITS) will take advantage of IPWAVE for IP-based V2X communications. This draft was revised from -31 to -34: - Handover behavior is clarified; - Clarification of MAC address privacy example; - The section about ND is simplified; - Improvement of handover with MIPv6 and DNAv6; - Improvement of ND retransmissions in respect to packet loss; and - Appendix of channel use is added. SG: DNAv6, is it dead? Suresh Krishnan (SK): It is an RFC; it is not dead. There are some implementations with some variations of it. IoTDir and IntDir Reviews questioning the Ethernet Adaptation Layer as AP bridging Ethernet to WiFi? - IPv6 over OCB does not bridge between these interfaces; and - It bridges between layers (Ethernet/WiFi layer and IP layer). Pascal Thubert (PT): IPv6 over OCB can refer to 6lo for optimizations. SK: Optimization like 6lo's work can be left as future work. SG: OCB draft should refer to the classical ND document. CS: IPWAVE hackathon project used packet framing of 6lo for OCB packet. Dorothy Stanley (DS): OCB document should be done with the classical ND, and it will be improved later by IPWAVE hackathon projects. CB: The way forward is for the OCB document proposes basic ND but document the shortcomings, leaving "enhanced" ND for a separate work. The OCB document will reflect Pascal's comments and it will move forward. AP: Comments from the 6man WG were circulated without improvement. SK: The authors need to clarify the text with questions from reviewers even though the implementation shows the correct mechanism of IPv6 over OCB. AP: Let's make progress through IESG for RFC publication. AP: I will try to improve security considerations; however, the security is not easy to solve. SK: The authors need to specify possible problems and say how to mitigate them. AP: It is very hard to address all security problems in this document. DS: Security part can refer to IEEE 1609.2 security. SG: What security aspects are discussed such as link layer and application layer? SK: We need to document security issues. William Whyte (WW): There are many ETSI documents about security issues and threat models. We can just point to them. Tony Li (TL): Link layer security is out of our scope. We don't have a decent security method in network layer yet. ------------------------------------------------------------------------ 11:40 IP Wireless Access in Vehicular Environments (IPWAVE): ... 20 min Problem Statement and Use Cases Presenter: Jaehoon Paul Jeong Draft: draft-ietf-ipwave-vehicular-networking-08 ------------------------------------------------------------------------ PJ: I am one of the editors of this Problem Statement (PS) document. I clarified key work items in this PS document, such as ND, mobility management, security and privacy. I summarized the solutions, and talk about the link model. This is vehicular network architecture. A vehicle can configure its IP address through this multi-link model. We need to provide Internet access using a global IP address. We also suggest the multihop ND. Mobility Management has two cases for seamless communicaiton and the timely data exchange between. First case is PMIPv6 based mobility management. Trajectory information allows mobility management to be done proactively. DMM based can also be used. Next step, wrap up this PS document. CB: Have been all of the received comments been addressed? You need to tell the reviewers how their comments were handled. Please post to the mail list so that the reviewers can check if they think their comments have been addressed. SG: Stick to the problem statement, not solution. CB: The review from Sri was posted beginning of February, and then an updated draft was posted after the cutoff date for this meeting. If the authors want to progress this document, responding to review cannot take that long, and for sure cannot be submitted after the cutoff. Next revision has to be done well before Montreal meeting. PJ: I will address further comments from the WG quickly. ------------------------------------------------------------------------ ** Additional topics (time permitting) 12:00 IPv6 Vehicular Neighbor Discovery ......................... 15 min Presenter: Yiwen Chris Shen Draft: draft-jeong-ipwave-vehicular-neighbor-discovery-06 ------------------------------------------------------------------------ CS mentioned that there is IPR related to this draft. CS explained vehicular network architecture with vehicular link model. Based on the network, vehicular neighbor discovery (VND) uses address registration for efficient address configuration and management. SG: How does it handle MAC pseudonym? CS: We will address the pesudonym later. WW: Coupling between network layer and transport layer should be considered for efficient pseudonym. CS: Aquisition of prefix can be done to a vehicle far away from RSU via VANET. Prefix and service discovery can be efficiently by VND with ND options. Updates from -05 are specified such as shared prefix model. CB: There cannot be any WG adoption on this (or any other document) without rechartering. And there will be no rechartering process until the two documents on the current charter are done. Erik Nordmark (EN): 6lowpan document is used. What is different from 6lowpan? What are missing from it? SG: Need analysis before WG adoption. AP: In procedure of address registration, does this VND override the classical ND? Can a vehicle have multiple IP addresses? SG: Does this draft consider internal IP addresses along with egress (or external) IP address? TL: Is Private IP address space considered? CS: This is related to mobility management. ------------------------------------------------------------------------ 12:15 Urban Air Mobility Implications for IPWAVE ............ 10 min Presenter: Fred Templin Draft: draft-templin-ipwave-uam-its-00 ------------------------------------------------------------------------ Fred Templin (FT) explains the motivation and requirements of Urban Air Mobility (UAM) in IPWAVE. UAM can use DSRC and C-V2X for communications. PJ: This UAM can be considered as work item after rechartering. SG: Is UAM proposed as IPWAVE work item or a requied work for your company? ------------------------------------------------------------------------ 12:25 IEEE 1609.2/ETSI TS 103 097 certificates in TLS 1.3 ..... 10 min ------------------------------------------------------------------------ WW introduces TLS authentication using certificates in the format defined in ETSI ITS and IEEE WAVE. The objective is to enable client/server authentication these certificates. TLS WG has no interest, so WW proposes the work in IPWAVE WG. ------------------------------------------------------------------------ 12:35 Mobility Management for IP-Based Vehicular Networks ..... 10 min Presenter: Jaehoon Paul Jeong Draft: draft-jeong-ipwave-vehicular-mobility-management-00 ------------------------------------------------------------------------ PJ: This draft offers a vehicular mobility management scheme for IPv6 vehicular networks that takes advantage of a vehicular multi-link subnet model. With a vehicle's position, speed, direction, and trajectory, it can provide a moving vehicle with proactive and seamless handoff along its trajectory. CB: There cannot be any WG adoption on this (or any other document) without rechartering. And there will be no rechartering process until the two documents on the current charter are done. Someone suggested the review of RFC 4903, where Dave Thaler describes issues with multi-link subnets.