Re: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt
"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Sat, 18 April 2020 16:10 UTC
Return-Path: <Fred.L.Templin@boeing.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 8FEC13A0CA7 for <its@ietfa.amsl.com>; Sat, 18 Apr 2020 09:10:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com
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 tUcDtm6LbRqs for <its@ietfa.amsl.com>; Sat, 18 Apr 2020 09:10:25 -0700 (PDT)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 83C613A0CA3 for <its@ietf.org>; Sat, 18 Apr 2020 09:10:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 03IGAL0J025521; Sat, 18 Apr 2020 12:10:21 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1587226221; bh=rOmtTa3jqadN7Mrg6RsHVRZoBLNkuxU2n+7bxsdW7Gw=; h=From:To:Subject:Date:References:In-Reply-To:From; b=bN0Jc6HWH/bSmygg+0YSjjSvrdhfRp1kcSVxMGYertzuAW06aUD38rIO9znapCqOt MY8OQcZVsTy/yIIlZpfrTr/l75LVf+mJOk4eliKi6jyO5ZSP5xvFYUEr+JbVtTogcd Lc9luHmcVHoGmSNpEA6k0tuojyrP6nG+kLPjKBQ/2L5XaiYH0gEQu+saqxi11WOxUc lyUkWYUVtJrlOJJCkGEl9XlQmUyGtC+Jpsys6FYOoSu7m46EB8m9lWtABB4lT2KDkH OvGSHQt3qeoq1Ww7mJrod4NrgtNRHp2yymm+NxhkHbffYA6dAmxwEAIFsI+HfM23UY 1UP0eF2Wfshsg==
Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 03IGA2dh024357 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sat, 18 Apr 2020 12:10:02 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Sat, 18 Apr 2020 09:10:01 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1979.003; Sat, 18 Apr 2020 09:10:01 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: "dickroy@alum.mit.edu" <dickroy@alum.mit.edu>, 'William Whyte' <wwhyte@qti.qualcomm.com>, '김증일 글로벌R&D마스터' <ben.kim@hyundai.com>, 'its' <its@ietf.org>
Thread-Topic: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt
Thread-Index: AdYSbIOrgJztO30DSbKHqMRer/dH0wCWEb4AAAJoLSAADzvFAAAOVSZwAANmInAAEfRIEA==
Date: Sat, 18 Apr 2020 16:10:01 +0000
Message-ID: <c6d51bed35b84fa382e649df4555f1fd@boeing.com>
References: <c407ff6c9ffe45c98e74609dae0b1419@boeing.com> <4a1d87b88a3640bcb4729954b0a6e864@hyundai.com> <931e9c145ec84c6fb4aa3bbdf9c5c91c@boeing.com> <BL0PR02MB5427455DF321D3FB45F65D7BF2D90@BL0PR02MB5427.namprd02.prod.outlook.com> <57db6eb73bcd41c39f51edb62c29748d@boeing.com> <718FB5193EAD4D8792F8FCE610258874@SRA6>
In-Reply-To: <718FB5193EAD4D8792F8FCE610258874@SRA6>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 9AFBC87517A4E9C3B9F3871064AFA9BCBC1D7CEBF4747A70E97AE5D029B967EC2000:8
Content-Type: multipart/related; boundary="_006_c6d51bed35b84fa382e649df4555f1fdboeingcom_"; type="multipart/alternative"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/XfD7qAw_fObr6SKaxmD66jgcfYI>
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: Sat, 18 Apr 2020 16:10:29 -0000
Time varying prefixes with short leases can be managed with DHCPv6-PD, so there is no need for the mobile to carry around lots of statically allocated prefixes. The mobile may need to renumber its internal networks frequently, but that’s OK. From: Dick Roy [mailto:dickroy@alum.mit.edu] Sent: Friday, April 17, 2020 9:16 PM To: Templin (US), Fred L <Fred.L.Templin@boeing.com>; 'William Whyte' <wwhyte@qti.qualcomm.com>; '김증일 글로벌R&D마스터' <ben.kim@hyundai.com>; 'its' <its@ietf.org> Subject: RE: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt For the addresses to be unique, each unit (vehicle, smart phone, etc.) would have to be issued a set of unique addresses, which begs the question what’s the cardinality of that set, and how much privacy/anonymity will that provide. In a 64-bit space, there would be plenty of addresses; however address management could be an issue. Another option is of course random address selection; if the RNGs were good enough, it should work w.p.near1. RR ________________________________ From: its [mailto:its-bounces@ietf.org] On Behalf Of Templin (US), Fred L Sent: Friday, April 17, 2020 9:14 AM To: William Whyte; 김증일 글로벌R&D마스터; its Subject: Re: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt Hi William, You indicated a timescale of minutes (not secs or msecs) and I think that might be feasible yes. But, it does require more thought. Fred From: William Whyte [mailto:wwhyte@qti.qualcomm.com] Sent: Friday, April 17, 2020 8:56 AM To: Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>>; 김증일 글로벌R&D마스터 <ben.kim@hyundai.com<mailto:ben.kim@hyundai.com>>; its <its@ietf.org<mailto:its@ietf.org>> Subject: RE: [ipwave] Comments for draft-ietf-ipwave-vehicular-networking-14.txt Hi Fred – would it be possible for this unique prefix to be re-selected from time to time? William From: its <its-bounces@ietf.org<mailto:its-bounces@ietf.org>> On Behalf Of Templin (US), Fred L Sent: Friday, April 17, 2020 11:47 AM To: 김증일 글로벌R&D마스터 <ben.kim@hyundai.com<mailto:ben.kim@hyundai.com>>; its <its@ietf.org<mailto:its@ietf.org>> Subject: [EXT] 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<mailto:Fred.L.Templin@boeing.com>>; its <its@ietf.org<mailto: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@01D61497.DC438CC0] 김증일(ben.kim@hyundai.com<mailto:ben.kim@hyundai.com>) 글로벌R&D마스터 / 전력제어시험팀 [cid:image002.gif@01D61497.DC438CC0] 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@01D61497.DC438CC0] ________________________________________ 보낸 사람: 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
- [ipwave] Comments for draft-ietf-ipwave-vehicular… Templin (US), Fred L
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… Michael Richardson
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… Russ Housley
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… Templin (US), Fred L
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… 김증일 글로벌R&D마스터
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… William Whyte
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… Templin (US), Fred L
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… William Whyte
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… Templin (US), Fred L
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… Templin (US), Fred L
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… 김증일 글로벌R&D마스터
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… Templin (US), Fred L
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… Templin (US), Fred L
- Re: [ipwave] Comments for draft-ietf-ipwave-vehic… Mr. Jaehoon Paul Jeong