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

김증일 글로벌R&D마스터 <ben.kim@hyundai.com> Tue, 21 April 2020 00:25 UTC

Return-Path: <ben.kim@hyundai.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8083A13DC for <its@ietfa.amsl.com>; Mon, 20 Apr 2020 17:25:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E22SfhlUm3Uq for <its@ietfa.amsl.com>; Mon, 20 Apr 2020 17:25:49 -0700 (PDT)
Received: from GW2EDGE00.hyundai.com (hkatwyedgep03.hyundai.com [211.252.134.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8953A13D8 for <its@ietf.org>; Mon, 20 Apr 2020 17:25:48 -0700 (PDT)
Received: from hkatwymailp05.autos.hmgc.net (10.7.20.15) by hkatwyedgep03.autos.hmgc.net (211.252.134.187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 21 Apr 2020 09:25:11 +0900
Received: from hkatwymailp05.autos.hmgc.net (10.7.20.15) by hkatwymailp05.autos.hmgc.net (10.7.20.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Tue, 21 Apr 2020 09:25:11 +0900
Received: from hkatwymailp05.autos.hmgc.net ([fe80::840f:5c90:e651:a0d5]) by hkatwymailp05.autos.hmgc.net ([fe80::840f:5c90:e651:a0d5%19]) with mapi id 15.01.1847.003; Tue, 21 Apr 2020 09:25:11 +0900
From: 김증일 글로벌R&D마스터 <ben.kim@hyundai.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, its <its@ietf.org>
Thread-Topic: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt
Thread-Index: AQHWFISwzMaUiGZ6a0OKWs/l2eNmcqh84FuA///+ogCABdseHQ==
Date: Tue, 21 Apr 2020 00:25:11 +0000
Message-ID: <bb381768c49a4d799c3d60dd5902506c@hyundai.com>
References: <c407ff6c9ffe45c98e74609dae0b1419@boeing.com> <4a1d87b88a3640bcb4729954b0a6e864@hyundai.com>, <931e9c145ec84c6fb4aa3bbdf9c5c91c@boeing.com>
In-Reply-To: <931e9c145ec84c6fb4aa3bbdf9c5c91c@boeing.com>
Accept-Language: ko-KR, en-US
Content-Language: ko-KR
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.7.20.8]
Content-Type: multipart/related; boundary="_009_bb381768c49a4d799c3d60dd5902506chyundaicom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/vLZz9xGSh15hknqmFiNrqXmlwK0>
Subject: Re: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Apr 2020 00:25:56 -0000

Hi Fred



There must be something I misunderstand.



I thought that the IPv6 Link local address prefix is fixed by FE80::/10 and only lower 64bit can be assigned by any method to ensure uniqueness.



If the prefix is defined uniquely by each vehicle, how can they communicate each other through local link?



Best wishes



Kim







[cid:c8dae744ac184dd6b4c33e3e613d87cc]




김증일(ben.kim@hyundai.com<mailto:ben.kim@hyundai.com>) 글로벌R&D마스터 / 전력제어시험팀         [cid:9f64ae36026f4ed7a114156c685f1fdf]

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: +82-31-5172-3134, Mobile: +82-10 -8805-3810
150, Hyundaiyeonguso-ro, Namyang-eup, Hwaseong-si, Gyeonggi-do, 18280, Korea




[cid:5bccf03917f8432fa0f48d1a288acab1]



________________________________
보낸 사람: Templin (US), Fred L <Fred.L.Templin@boeing.com>
보낸 날짜: 2020년 4월 18일 토요일 오전 12:47:08
받는 사람: 김증일 글로벌R&D마스터; its
제목: RE: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt

Hi Kim, the expectation is that the vehicle would be assigned a unique IPv6 prefix
called the Mobile Network Prefix (MNP) for its own exclusive use, e.g. a /64 or
some other prefix length. That gives the vehicle lots of available addresses which
would not need to undergo DAD.

Thanks - Fred

From: its [mailto:its-bounces@ietf.org] On Behalf Of ??? ???R&D???
Sent: Friday, April 17, 2020 12:31 AM
To: Templin (US), Fred L <Fred.L.Templin@boeing.com>; its <its@ietf.org>
Subject: 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:image001.gif@01D61494.583B3980]






김증일(ben.kim@hyundai.com<mailto:ben.kim@hyundai.com>) 글로벌R&D마스터 / 전력제어시험팀

 [cid:image002.gif@01D61494.583B3980]


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: +82-31-5172-3134, Mobile: +82-10 -8805-3810
150, Hyundaiyeonguso-ro, Namyang-eup, Hwaseong-si, Gyeonggi-do, 18280, Korea





[cid:image003.png@01D61494.583B3980]





________________________________________
보낸 사람: Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>>
보낸 날짜: 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