Re: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

[William Whyte <[e-mail]>]

Using the VIN to create the link-local address would have to be done carefully or it could create significant privacy concerns. In IEEE/ETSI/ISO work on this topic, which is being adopted by USDOT and the European Commission, we’re being careful to avoid having (a) identifiers that are directly derived from something unique to the vehicle and (b) long-lived identifiers, as these identifiers can be used to track system participants. In general we’ve favored generating any lower layer identifiers at random and changing them periodically (on a timescale of minutes rather than seconds or hours). This creates occasional disruptions to long-lived sessions but the tradeoff was considered worth it.

Cheers,

William



From: its <[e-mail]> On Behalf Of ??? ???R&D???
Sent: Friday, April 17, 2020 3:31 AM
To: Templin (US), Fred L <[e-mail]>; its <[e-mail]>
Subject: [EXT] Re: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt


Hello, Fred



I think you pointed out the good way to ensure uniqueness of link-local address for vehicle.

Using the VIN to create link-local address sounds good and we can get fast connection by skipping DAD process.



I wonder if it's okay when a vehicle need to have multiple addresses for different services.

Isn't it safe to check DAD for double check?



Kim


[cid:[e-mail]6B8F20]






김증일([e-mail]<mailto:[e-mail]>) 글로벌R&D마스터 / 전력제어시험팀

 [cid:[e-mail]6B8F20]


ZEUNG IL (Ben) KIM      Global R&D Master / Electric Power Control Test Team







Automotive Research & Development Division, www.hyundai.com<http://www.hyundai.com>




18280 경기도 화성시 남양읍 현대연구소로 150 Tel: [phone], Mobile: [phone]
150, Hyundaiyeonguso-ro, Namyang-eup, Hwaseong-si, Gyeonggi-do, 18280, Korea





[cid:[e-mail]6B8F20]





________________________________________
보낸 사람: Templin (US), Fred L <[e-mail]<mailto:[e-mail]>>
보낸 날짜: 2020년 4월 15일 수요일 오전 12:33:56
받는 사람: its
제목: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

Hi, I read this draft and have some comments. In the aviation domain, we are designing
an Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS)
with the goal of having a worldwide IPv6 Internetwork interconnecting aircraft, air traffic
controllers and other authorized entities. This work is focused in the International Civil
Aviation Organization (ICAO), but is now being brought into the IETF:

https://datatracker.ietf.org/liaison/1676/
https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/
https://datatracker.ietf.org/doc/draft-templin-intarea-6706bis/

However, the vehicular network model we have for the airplanes differs significantly from
the vehicular model in this ipwave draft when in fact I think there should be no difference.

In particular, in the ATN/IPS aircraft are statically configured with a Mobile Network
Prefix (MNP) (sort of like a VIN) that travels with the aircraft wherever it goes. It uses
this MNP to form a unique link-local address, then assigns the address to the OMNI
interface which is a virtual interface configured over the wireless data link interfaces.
Then, on the wireless links themselves, there are no on-link prefixes and no PIOs
advertised by access routers. The wireless links therefore carry only link-local or
MNP-addressed IPv6 packets, therefore no two vehicles will appear to be on the
same subnet and no multi-link issues for subnet partitions and merges occur. Also,
DAD is not needed at all due to the unique assignment of MNPs.

This same model could be applied to ipwave vehicles, and would alleviate the problems
stated in Section 5. In particular, the link model could adopt the OMNI link model (see
the OMNI draft) where all nodes within the transportation system are "neighbors" on
a shared NBMA virtual link. IPv6 ND works with no modifications, and the link model is
always connected. So, there would be no need for vehicular extensions to IPv6 and ND.
Likewise, mobility management services would work the same as the ATN/IPS design
and would not require any adaptations for fast-moving vehicles.

Final comment for now - the document lists only MIPv6 and PMIPv6 as example
mobility services. We are considering them in the aviation domain, but also have
AERO and LISP as candidate services. Since these would also apply in the ipwave
case, it would be good to list them as candidates here also.

Fred