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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 18 April 2019 21:01 UTC

Return-Path: <brian.e.carpenter@gmail.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 A2F9712038D; Thu, 18 Apr 2019 14:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 h0bxzgKGhqm5; Thu, 18 Apr 2019 14:01:19 -0700 (PDT)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959FD120126; Thu, 18 Apr 2019 14:01:19 -0700 (PDT)
Received: by mail-pg1-x52c.google.com with SMTP id e6so1732999pgc.4; Thu, 18 Apr 2019 14:01:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FS+YJr00iamo6jNgf1svWdaQI9/TO3Zn364jLiYy7xY=; b=YoqvwXvctbfOCWghuvetbL8IeG1azu+gBewvAAQzUWcw5+s59Zqeq63m9lfxdfoz61 SE3eUoLYSAdkxr4KSusyYlsZ+g0VDQcmUSZo6fqM3YH6Sz/ZhdteUh2caNAu84SVxLxf pZy+M1Nl5XuB5FX9rIdfKerOE3MkE9EU+yXVOy96/QkX1ACjGV0HEmqeBXYr2MJgSJEj BsWmZw3SirLS1vD0lYuiFwKh+6mPH3lEY0tYTy2uzKs/nvf6hzweMNIBzVDDB4aXT0F2 npafWvGjbR3mzh6VRyu8KClhvawRC/iZyPVvR1Kgom/FQy7K0hstHxkwOPlK9uwzrrf3 6CSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FS+YJr00iamo6jNgf1svWdaQI9/TO3Zn364jLiYy7xY=; b=WhzwXRpLWOV2igo96b77MQh8GsC3aietDSxC9JFq3uMYJYjtorzPPRVq+aQvC6m2Ms 1PVG+HAoISNUJntPBhfSSOfrGka9RnPh2fINCIvUrw2/SpT7oNsKnF72JI+cSO/o7g4T h7HRMEGUNWHb0jNare3ej01aFPoKkaMf+RJRDLYVNJPDcaHd8k8EF8yQaEqmuTykhLPx G4+/LIyXq6LbY6woyFDASX8whds27zNt5R1A8M+58jGsgpX6K7MsuXaJIgNVt6W+DCn3 h3qEJuynxyT6xJAPr6QCV1kD4bk6NxOybBmpnWA5RKGQNEh6cHqxojoXETgjM8z0IfKL 3q9g==
X-Gm-Message-State: APjAAAVgHq3oD4VYdlrEXGv3GgEY6/dX3WWPOYaRuKDtMd0B1F82ba77 h502+e/cwdWGhIgseLIPqsdCe6xU
X-Google-Smtp-Source: APXvYqyzx65aAsarQTE56lckSfhWrCkZHexu1SwIaNTMrgm2zp/LvSPcc3VqOt5Mxnrc9I9k6Vf0AQ==
X-Received: by 2002:a62:3583:: with SMTP id c125mr96750300pfa.169.1555621278710; Thu, 18 Apr 2019 14:01:18 -0700 (PDT)
Received: from [192.168.178.30] ([118.148.72.205]) by smtp.gmail.com with ESMTPSA id 25sm5297766pfo.145.2019.04.18.14.01.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Apr 2019 14:01:17 -0700 (PDT)
To: Alexandre Petrescu <alexandre.petrescu@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> <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> <e62568a8-d178-ac42-f0f8-aa7687ce29de@gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <fcf00129-6ceb-dfd7-6a43-73aaeb31bef7@gmail.com>
Date: Fri, 19 Apr 2019 09:01:13 +1200
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: <e62568a8-d178-ac42-f0f8-aa7687ce29de@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/iofuW3RgdBjCI7kqig6Q6srKeyE>
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb and draft-ietf-ipwave-vehicular-networking
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: Thu, 18 Apr 2019 21:01:22 -0000

On 19-Apr-19 00:23, Alexandre Petrescu wrote:
> 
> 
> 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.

OK. We could argue whether it should be "unknown" or "undefined"
but I think this is a useful clarification, thanks.

> 
> [...]
> 
>> 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.

OK
  Brian

> 
> Alex
> 
>>
>> Regards Brian
>>
>>
>