* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ipwave Status Pages

IP Wireless Access in Vehicular Environments (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2016-Oct-18 —  

IETF-99 ipwave minutes

Session 2017-07-20 1550-1750: Athens/Barcelona - Audio stream - ipwave chatroom


minutes-99-ipwave-00 minute

          Minutes of the IPWAVE WG meeting at IETF 99
          THURSDAY, July 20, 2017
          1550-1750  Afternoon Session II, Athens/Barcelona
          Chairs: Russ Housley, Carlos J. Bernardos
          Minute takers: Danny Moses, Alex Petrescu, Jaehoon Paul Jeong
          Jabber scribe: Suresh Krishnan (SK), Behcet Sarikaya (BC)
          15:50 Administrativia .............................................
          10 min
                Presenter: Chairs
          Russ Housley (RH):  We need more reviews for the WG documents. OCB-Mode
          document will be under WGLC by the end of this September. Both Survey and
          Problem Statement documents should be reviewed by volunteers by the
          end of this September. Without reviews the document cannot advance.
          ** IPWAVE WG documents
          16:00 Transmission of IPv6 Packets over IEEE 802.11 Networks in mode
               Outside the Context of a Basic Service Set (IPv6-over-80211ocb)
               20 min
               Presenter: Alex Petrescu (AP)
               Draft: draft-ietf-ipwave-ipv6-over-80211ocb-03
          AP presents, explaining minor textual issues in the revision. The goal is
          to be in WGLC by the end of September. This draft is about transmission of
          IPv6 packets over 802.11 OCB (Outside the Context of a Basic service set)
          networks. Issues from Chicago:
            - Minor text issues.
            - RSU - Road Side Unit. The draft has a definition of RSU since there
              were many discussions about RSUs, mainly regarding handoff between
              and RSU advertisement. Currently the draft does not include handoff
              therefore there is no text regarding RSUs (other than the definition).
              As a result of previous comments, an RSU is defined to “may have
              additional wired or wireless links and may be an Internet
              router”. In
              other context they are not routers and must be disconnected from the
              Internet for security reasons.
            - There were some comments about the prohibition of using IPv6 on some
              IEEE 802.11OCB channels which are reserved for safety. New text about
              this prohibition.
            - Some misunderstanding about the term ‘interface’. The text
              the ‘interface’ is a networking interface card. Text added
              to clarify
              the use of several interfaces in a car and that one of them could be
              dedicated for non-IPv6 communication.
            - Text added to clarify more description regarding IEEE 802.11OCB
            - Added a section of Address Mapping 0 Unicast - followed RFC4861.
            - One issue still on the table: Need to update references to all other
              related IEEE standards and to update the reference to most updated
              version of these specs.
            - Michel Wetterwald (MW): Need to revise additional references and make
              sure they are all up to date (ETSI, IEEE...)
            - AP: This draft is very important and is basis for trials and other
              work being done. The authors are requesting additional reviews of the
                * Sri Gundavelli (SG), Sandra Cespedes (SC) and Rahul Jahdav (RJ)
                  volunteered to review.
                * RH: We plan to do WGLC by the end of this September.
          16:20 Survey on IP-based Vehicular Networking for Intelligent
                Transportation Systems ........................................ 20
                Presenter: Jaehoon Paul Jeong (JJ)
                Draft: draft-ietf-ipwave-vehicular-networking-survey-00
          JJ present the latest revision of the draft:
            - This is a report of a survey on IP-based vehicular networking for ITS.
              It is now a WG draft. It includes use cases for V2V and V2I.
            - The purpose is to monitor activities in academia and other SDOs
              ITS. The assumptions for vehicular NWs: IEEE 802.11 serious OCB and
              Cellular links (#G, 4G and 5G). IPv6 is considered to be the network
              protocols, the RSUs are connected to the Internet and serve as AP to
              vehicles and the TCC (Traffic Control Center) is the central node for
            - Several topics are looked at: IP Address auto configuration,
            Vehicular NW
              architecture and routing, mobility management and security.
            - Some use cases: V2I - Navigation systems, Intersection management,
              Emergency NW system and Pedestrian protection. V2V – Driving safety
              systems, automated driving systems and vehicle-to-vehicle warning
            - Summary and analysis (the appendix of the draft): Suitability of
            IPv6 over
              WAVE, need fast ND. The link is different for traditional IPv6
              link. Plan
              to use ND over VANET.
            - With autonomous vehicles, navigation information can be shared.
            - Next steps: Include more papers and use cases. Include more SDOs
            related to
              automotive. Include taxonomy tables for each technology.
            - Authors will try WGLC in IETF 100.
          Carlos J. Bernardos (CB): Do we need the IPv6 link section? Can you
          sync with
            - AP: I will read it and then discuss and perhaps move it to the
            main document.
          Person from huawei (NONAME1): ND proxy section? included in 6lo. The
          authors can
          refer to 6lo work for the ND adaptation part for ND proxy.
          16:40 Problem Statement for IP Wireless Access in Vehicular
                Environments ................................................ 20 min
                Presenter: Jaehoon Paul Jeong
                Draft: draft-ietf-ipwave-problem-statement-00
          JJ presents the latest revision of the draft:
            - This is about merging drafts:
              and draft-petrescu-its-problem-03 into one draft. It is also a
              WG draft.
            - The objective of the draft is to specify the problem statement for
              IPv6-based V2I and V2V networking. The assumptions are similar to the
              previously presented survey.
            - The focus of this draft is on the one IP hop communication between
              and RSU or vehicle to vehicle.
            - The plan is now to expose the vehicle internal NW (CAN) to Internet (a
            - Vehicles may exchange navigation information among themselves to help
              avoid accidents.
            - Issues for IPv6 vehicular networking:
              * IPv6 addressing problem - local vs global addresses. Local addresses
                can be used for road networking and global addresses for general
                Internet services.
              * In vehicle addresses may be preconfigured or configured dynamically
                a network that is deployed along the road.
              * Establishing a communication path between computers in different
                is a problem that needs resolving.
              * IP Prefix exchange should be performed. Need to consider SLAAC
              or DHCPv6.
                It looks like most people prefer the RA approach.
              * Another issue is host DNS configuration.
              * Another issue is IP mobility. Alternatives are MIP, PMIP or DMM.
                Parameter adjustment is required for high speed vehicles.
              * Another issue is: service discovery. Possible solutions: DNS-based
                service discovery, IPv6 ND extension for Prefix and Service
                There is additional info in the appendix.
              * Security and Privacy: We need fast and reliable authentication. We
                use periodic changing of the IP and MAC address to prevent tracking.
                + SG:: How is the MAC exposed? In what scenario? Is the MAC address
                  exposed to the outside NW? Not clear..
                + JJ: Probably pseudo MAC address, no MAC address
                + AP: To answer the question - many packets expose MAC address
                (NS, RS,
                  NA, RA). They are over the air between 2 cars, a car and RSU.
                  Basically any one along the road with a laptop can listen and hear
                  all these packets and MAC addresses. So they are exposed.
                + Seil Jeon (SJ): Are you talking about the traffic of vehicles
                or the
                  users inside the vehicle as well.
                + JJ: Very good question. If the user is using a smartphone
                  to internal WiFi, than users as well.
                + JJ: If users are also included, this has to be specified
                because MIP
                  already has its own NW mobility solution, and PMIP also has prefix
                  delegation for user inside.
                + SG: For the service point of view the identity of the car is truly
                  about the egress device. There is no security relation to
                  the inside
                  devices only to the head unit which has a service relation.
                + Nancy Cam-Winget (NC): Rotation mac address do not resolve
                  We should thinking about cars communicated with another car (or
                  infrastructure), not head unit and not user.
                + NC: I’m trying to follow all this. I provided feedback in
                the 1609
                  that rotating MAC addresses does not really solve privacy. So why
                  we believe rotating IP MAC address may provide privacy but to the
                  question of the messaging here we have to be very careful
                  in saying
                  head-unit because of connotation. We should discuss a car
                  communicating with another car and not speak about a head-unit. To
                  the comment about users, I am not sure how humans come in
                  the play,
                  we are referring here to vehicle conversing with another
                  vehicle or
                  with an infrastructure - these are not humans, these are cars.
                + RH: If we didn’t change the IP address when we change the
                MAC address
                  then any incremental privacy we are getting by changing the
                  MAC address
                  is lost.
                + SK: Adding to Russ, there is a human associated with the car
                who can
                  be tracked by the car. So that’s why it is important not
                  the tracking
                  of the car. So this will break than link.
                + NC: So is an IP address tied to a human? A Different people
                might drive
                  the same car, so no direct relationship between a car and a
                  human. I
                  have 5 cars and 4 drivers...With a public transport car (rental
                + SK.: So, Nancy please send text to the authors.
            - NONAME2: On slide 15 you said that you can use the VIN as an
              mechanism. You can get it by spoofing the CAN so it is not worth
              Authentication is very important.
            - JJ: the ECU controller is somethign like a black box.  And, the
              entertainment and navigation are somehow separated.
            - NONAME2: it takes more to than change the MAC address to get the
            - AP: The VIN can be taken from the CAN and from taking photos of
            the shield.
            - Dino Farinacci (DF): I don’t think we should be worried about
            MAC address
              tracking. We should worry about DoS attacks.
            - Brian Weis (BW): There is an IEEE 802 privacy document that is
            being worked
              on, I’ll send a reference. It takes a lot more than changing MAC
              address to
              get privacy.
              The reference is IEEE 802.1 Working Group, "DRAFT Recommended
              Practice for
              Privacy Considerations for IEEE 802 Technologies", Information at
              , 18 Mar 2017.
            - RH: IPsec and IKEv2 should consider the change of IP address and
            MAC address
              because this change may break the IPsec sessions.
          CB: Some problem statements (e.g., in ND section and IP mobility section)
          close to survey. Please make the text close to the problem statement. The
          level of
          detail in some sections is not enough. For example privacy has only a
          half a page.
          RH to BW: if the MAC and IP addresses are rotating, will ESP work?
          BW: This is a complication, but this could work. Need to add details.
          CB: We need reviewers for this draft.
            - MW, SG and RJ voluntereed to review.

Generated from PyHt script /wg/ipwave/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -