Re: [Int-dir] draft-ietf-ipwave-ipv6-over-80211ocb and draft-ietf-ipwave-vehicular-networking

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 18 April 2019 12:23 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: int-dir@ietfa.amsl.com
Delivered-To: int-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A263120301; Thu, 18 Apr 2019 05:23:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 76CJdnCEub-R; Thu, 18 Apr 2019 05:23:16 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 91C5D1202FF; Thu, 18 Apr 2019 05:23:15 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x3ICN7x2101623; Thu, 18 Apr 2019 14:23:09 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 80D36206500; Thu, 18 Apr 2019 14:23:09 +0200 (CEST)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 62570205BAA; Thu, 18 Apr 2019 14:23:09 +0200 (CEST)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x3ICN960016387; Thu, 18 Apr 2019 14:23:09 +0200
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, NABIL BENAMAR <n.benamar@est.umi.ac.ma>, "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
Cc: nabil benamar <benamar73@gmail.com>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "ietf@ietf.org" <ietf@ietf.org>, "its@ietf.org" <its@ietf.org>, "int-dir@ietf.org" <int-dir@ietf.org>, "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org" <draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>
References: <155169869045.5118.3508360720339540639@ietfa.amsl.com> <a8aad636-069c-4451-dbf1-72c1db2204ef@gmail.com> <CAD8vqFfx_FVi5NobrR1p6xEKjkSNa1_ZejgrEs3JPDHJQoxD7A@mail.gmail.com> <MN2PR11MB356570FDBC5798F155DDEE25D82C0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMugd_Xce5cWLtVB4DbR1ZEaFbdfiRpXre9oq61ukRC+n+3cZw@mail.gmail.com> <D8D5F0B7.2F2BB8%sgundave@cisco.com> <D8D5F510.2F2BC8%sgundave@cisco.com> <3e716b4b-8236-0488-309c-7cd3a54db7b5@gmail.com> <D8D7B1E7.2F2CA2%sgundave@cisco.com> <CAD8vqFfSGKhw_ou3VB98C8r1gq=4WD8+f8C5P53C46k-0V+XuA@mail.gmail.com> <66e7c810-45a5-5244-59dc-4b764b6fb346@gmail.com> <1a6599ee-88f9-42d9-a208-918ba6711612@gmail.com> <11645738-6f95-82e5-48f1-ebc3ce54423e@gmail.com> <0ae10089-4b1a-f85c-1a3d-15e712cb7547@gmail.com> <084449fd-2693-0cfb-6589-0cf67cf9ffe6@gmail.com> <8feab68d-a16b-1582-ac25-8b9933ac1044@gmail.com> <5bb483d2-d658-25f6-1081-c0bdc26233ee@gmail.com> <1c3dfefb-6986-5976-c6ac-f0937548fb1c@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <e62568a8-d178-ac42-f0f8-aa7687ce29de@gmail.com>
Date: Thu, 18 Apr 2019 14:23:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <1c3dfefb-6986-5976-c6ac-f0937548fb1c@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/rMNFtvmgjKXHqNL4axL1UUTtwJQ>
Subject: Re: [Int-dir] draft-ietf-ipwave-ipv6-over-80211ocb and draft-ietf-ipwave-vehicular-networking
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2019 12:23:17 -0000


Le 17/04/2019 à 23:55, Brian E Carpenter a écrit :
> Hi Alexandre, On 17-Apr-19 21:41, Alexandre Petrescu wrote:
>> Brian,
>> 
>> Le 16/04/2019 à 04:18, Brian E Carpenter a écrit : [...]
>>> I think I will drop this discussion until ipwave gets its two 
>>> main drafts properly synchronized.
>> 
>> I would like to ask you whether you disagree that we move the 
>> appendix titled "ND issues in wireless links" away from the 
>> IP-over-OCB draft into the IPWAVE Problem Statement draft?
> 
> My understanding now is that the IP-over-OCB draft is scoped only for
> single-link subnets (i.e. does not even try to cover the case of 
> hidden nodes). I think that needs to be stated very clearly,

I propose this text in the Subnet Structure section of IP-over-OCB draft:
NEW:
> The subnet structure on which the Neighbor Discovery protocol (ND)
> on OCB works ok is a single-link subnet; the status of ND operation
> on a subnet that covers multiple OCB links that repeat the signal at
> PHY layer, or the messages at MAC layer, is unknown.

[...]

> and I don't quite understand whether there is a non-link-local prefix
> at all.

In my network of 3 cars no, there is no non-LL prefix at all between cars.

In my deployment of 2 cars and an IP-RSU IPv6 4G NAT66 NEMOv6 there was
a ULA prefix between the RSU and the car, on OCB.  In year 2015.

> In a very fluid network situation, it isn't at all obvious that a
> useful non-link-local prefix can be established.

I agree.

The problem is probably less in the fluidity, than in determining authority.

When there is an RSU one may associate authority to RSU that got it from
Cellular Operator who got it from the Default FRee Zone; but absent RSU
who should be trusted as authority?

It is the same problem when we try to make security between several cars
in a convoy.  We try to use quickly the OpenVPN software to achieve
security, but who's the client who's the server?  Cars are created
equal.  They are equally safe, even though some are more expensive than 
others.  We may end up with two openvpn tunnels between two cars, when 
one is normally sufficient.

> The draft seems a bit ambiguous on that point, so perhaps that can
> also be clarified.

YEs, could be, in the Problem Statement draft.

> Given those changes, I agree that moving the appendix as you suggest 
> would be reasonable.
> 
> By the way, where you use the word "global" to describe IPv6 
> addresses or prefixes, I suggest using either "Globally Reachable" 
> (as defined in RFC8190) or "global unicast" as defined in RFC8200. 
> ULA != globally reachable. ULA == global unicast

Noted.

Alex

> 
> Regards Brian
> 
>