Re: [6lo] Advocating a generalisation of RFC8505 to non-6lo LANs

Carsten Bormann <cabo@tzi.org> Thu, 04 July 2019 11:22 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69400120058; Thu, 4 Jul 2019 04:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 SarDTIETltEB; Thu, 4 Jul 2019 04:22:10 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915EA12004E; Thu, 4 Jul 2019 04:22:10 -0700 (PDT)
Received: from [192.168.217.110] (p548DC676.dip0.t-ipconnect.de [84.141.198.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45fbD060CFz10D8; Thu, 4 Jul 2019 13:22:08 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <MN2PR11MB35656135A0513A6DC0AD87E3D8FA0@MN2PR11MB3565.namprd11.prod.outlook.com>
Date: Thu, 4 Jul 2019 13:22:22 +0200
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "6lo@ietf.org" <6lo@ietf.org>, V6 Ops List <v6ops@ietf.org>, 6man <6man@ietf.org>
X-Mao-Original-Outgoing-Id: 583932140.852785-cbb23dc7fc22da945977223bbf5eb36e
Content-Transfer-Encoding: quoted-printable
Message-Id: <B9CDB083-696A-4413-BD59-FE37A8E94CC7@tzi.org>
References: <MN2PR11MB35656135A0513A6DC0AD87E3D8FA0@MN2PR11MB3565.namprd11.prod.outlook.com>
To: Pascal Thubert <pthubert@cisco.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/RuAKmMWx-aqnwQyS1UJHFmIdr34>
Subject: Re: [6lo] Advocating a generalisation of RFC8505 to non-6lo LANs
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2019 11:22:14 -0000

RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty much a no-brainer, if that foo has points where the 6LBR functionality is naturally centralized.

Not so easy for brownfield, i.e., in networks where classic ND is already used in some hosts and some routers.  “Efficient ND” (which was essentially RFC 6775 for Ethernet and thus also traditional WiFi) mostly didn’t take off at the time because we didn’t articulate a cohabitation (“transition”) strategy.  I’m sure we can do that if we put a little more focus on it, leading to another specification that describes how to run in mixed classic/efficient ND networks.

Grüße, Carsten


> On Jul 4, 2019, at 12:28, Pascal Thubert (pthubert) <pthubert@cisco.com>; wrote:
> 
> Hello Brian:
> 
> Yes, I'm willing to make the case. 
> 
> There are a number of reasons to enable a registration method on beyond 6lo networks:
> - It is useful in wireless in general because it addresses non-transit multipoint links (see https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/) and NBMA ML-subnets
> - it is useful in particular in Wi-Fi because it reduces the need for broadcast quite dramatically.
> - It is useful in a switched fabric to maintain an accurate state in the overlay mapping server (see https://datatracker.ietf.org/doc/draft-thubert-6lo-unicast-lookup/)
> - It is useful in a situation of host mobility in general, (see the discussion in https://tools.ietf.org/html/draft-ietf-rift-rift-06#section-5.3.3 ) 
> - It is useful for routers with hardware assist forwarding to avoid the punting dance and dropping of packets
> - It provides SAVI properties with a workable Secure ND (see https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/)
> - It provides an abstract interface to the router to get routing services (already used with RIFT, RPL, see https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/, and ND proxy, see https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/)
> - It solves a number of problems including Jen's, but also sleeping devices on non-6lo networks, remote DOS against router and ND cache, and more.
> 
> All in all I see it as a much needed modernization of ND to cope with the evolutions of the network (IOT, Wi-Fi and overlays) and with the new needs and behaviors (instant connectivity, fast roaming).
> 
> All the best,
> 
> Pascal
> 
>> -----Original Message-----
>> From: 6lo <6lo-bounces@ietf.org>; On Behalf Of Michael Richardson
>> Sent: jeudi 4 juillet 2019 02:58
>> To: 6lo@ietf.org; V6 Ops List <v6ops@ietf.org>;; 6man <6man@ietf.org>;
>> Subject: Re: [6lo] ND cache entries creation on first-hop routers
>> 
>> 
>> Brian E Carpenter <brian.e.carpenter@gmail.com>; wrote:
>>>> I’m interested to have a parallel discussion on where RFC 8505 can not
>>>> apply. In the products and use cases I’m aware of, it could, since we
>>>> are actually faking it by snooping ND and DHCP to achieve similar but
>>>> less accurate results.
>> 
>>> So if you are advocating a generalisation of RFC8505 to non-6lo LANs,
>>> that's certainly a discussion we could have, IMHO.
>> 
>> I think that it could be applied in situations of servers, such as data centers
>> where there are multiple tenants. (Many VM infrastructures have shared
>> front-end networks)
>> 
>> I think that temporary addressess are not a feature in some of those
>> deployments that everyone wants, and thus having a registration system is a
>> feature.
>> 
>> This does not solve the smartphone on new WIFI issue, which is a different
>> situation completely.
>> 
>> --
>> ]               Never tell me the odds!                 | ipv6 mesh networks [
>> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
>> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
> 
>