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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 04 July 2019 11:38 UTC

Return-Path: <pthubert@cisco.com>
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 70CE7120094; Thu, 4 Jul 2019 04:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=PSL3qG3X; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xCv+bzl+
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 FfkqJwjX7iQl; Thu, 4 Jul 2019 04:38:15 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD42120183; Thu, 4 Jul 2019 04:38:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8346; q=dns/txt; s=iport; t=1562240294; x=1563449894; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=6HOwrpsukxvbx/kAP/3VCHmrjdO3pvYEdiQDa8fMGFY=; b=PSL3qG3XzDON8fS04GvIJu+bH5/8xBTCWpBg/TlpzNSpGNOtGoWtYby0 MgUHV2ZQg0TV6BHFjVoim1AxiJy50HsB5YjMISChEFKCMItwPXYeSWNzm 1n4TH3a6ZN0GMQ0MlipAnUti6b/GIoDsMoBK8lfHv2xY8XnCAvOUiTU6v w=;
IronPort-PHdr: =?us-ascii?q?9a23=3AgqOvIhYttLKVZ6R4fF1Cs7D/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavycywnFslYSHdu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAABN5B1d/5NdJa1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBVAYBAQsBgUNQA2pVIAQLKIQcg0cDjkqCW4lNjXmBLoEkA1QJAQEBDAE?= =?us-ascii?q?BGAsKAgEBgUuCdQIXghMjNQgOAQMBAQQBAQIBBW2KNwyFSgEBAQECAQEBEBE?= =?us-ascii?q?RDAEBLAsBBAcGAQYCDgMEAQEBAgImAgQfBgsVCAkBBA4FCBqDAYFqAw4PAQI?= =?us-ascii?q?Min+QYAKBOIhgcYEygnkBAQWBMgETQYMPDQuCEgmBDCgBhHGGbReBQD+BEUa?= =?us-ascii?q?CHi4+gQSBFkcBAQIBAYE3EBiDCDKCJot1RIIxmx9ACQKCF4ZWiTqEDpd4lG+?= =?us-ascii?q?Bc44JAgQCBAUCDgEBBYFRATaBWHAVO4JsCYI4gx1UhRSFP3IBAYEnixkBJQS?= =?us-ascii?q?CKAEB?=
X-IronPort-AV: E=Sophos;i="5.63,450,1557187200"; d="scan'208";a="583652989"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jul 2019 11:38:12 +0000
Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x64BcCS4004050 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Jul 2019 11:38:12 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 4 Jul 2019 06:38:12 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 4 Jul 2019 06:38:11 -0500
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 4 Jul 2019 06:38:11 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6HOwrpsukxvbx/kAP/3VCHmrjdO3pvYEdiQDa8fMGFY=; b=xCv+bzl+iRvt7Y3tMmgAqxHqG34WXyAHTwLWWf6enC1bw+sl82itlkNfQqC1PeaqbRQZXaWBFB/YG37s0P8W1a7ppuFH0O/kowKBwzBjl7Zhn0WrPpT0se6Ucc82wbTED+GVYf6P3v8YBs9h9eNuK5lsssWJXUUAYHxB1Vb6boM=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3790.namprd11.prod.outlook.com (20.178.253.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Thu, 4 Jul 2019 11:38:09 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2032.019; Thu, 4 Jul 2019 11:38:09 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Carsten Bormann <cabo@tzi.org>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, "6lo@ietf.org" <6lo@ietf.org>, V6 Ops List <v6ops@ietf.org>, 6man <6man@ietf.org>
Thread-Topic: [6lo] Advocating a generalization of RFC8505 to non-6lo LANs
Thread-Index: AdUyXLsjbUS9G1zfTQuzwoWpAiUtYQ==
Date: Thu, 4 Jul 2019 11:37:38 +0000
Deferred-Delivery: Thu, 4 Jul 2019 11:37:35 +0000
Message-ID: <MN2PR11MB3565AC3DE6B4480D296D500FD8FA0@MN2PR11MB3565.namprd11.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:c0c0:1008::1d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9da4fbd7-7d9d-46b4-9ad7-08d7007416b6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3790;
x-ms-traffictypediagnostic: MN2PR11MB3790:
x-ms-exchange-purlcount: 10
x-microsoft-antispam-prvs: <MN2PR11MB3790040CE978381E800A9B3BD8FA0@MN2PR11MB3790.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0088C92887
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(376002)(39860400002)(346002)(396003)(13464003)(199004)(189003)(51444003)(7696005)(7736002)(2906002)(305945005)(68736007)(74316002)(6506007)(53546011)(81156014)(81166006)(8676002)(476003)(99286004)(6116002)(46003)(316002)(102836004)(486006)(86362001)(54906003)(186003)(14444005)(256004)(478600001)(8936002)(9686003)(25786009)(6306002)(66574012)(55016002)(4326008)(6916009)(76116006)(53936002)(52536014)(5660300002)(6246003)(71200400001)(14454004)(71190400001)(33656002)(6666004)(229853002)(66946007)(966005)(73956011)(66556008)(64756008)(66446008)(66476007)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3790; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: jaSYomRLMZ0kvpYOJn7DXkDn3N6ioXhc4yQHC9vT1s2FqhrjOn5jKHEACWGzhWCexOEZAni6dqE2bjg3yPArQqFbSIZf+J7J8EjfzC4R6ny/CV7EBBn3ZvWt66NkqM4FWz9Tp74DCDRqzBEULIpjecqZk8zxLr5TbiGVhjqk55fBeJdttAnJGWpNVjBEEunZ3BpMj1WKg7QRU1ISUwLynP1cfoIHq1U0RZRYnuv7YLBlA5gq2DzERnXJUctFuVA/yEwGWWwWE8tcUezXPzaQ17Phvf2lT8yzERgbryg2N/LUf9/U2bTwHIlwjOr6FL971AxobC9MpPBKhtPacTD4NxhFZ0jjtkXfL1+sr21YSF++Bs3lzx31uG6yyA+Ozk9KfmbB4+FGEINU0oi6WvD2APEJ65zfcT4M3ER8tdup28o=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9da4fbd7-7d9d-46b4-9ad7-08d7007416b6
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2019 11:38:09.1787 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3790
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/heb0ReUUZ63wlwXB_GrthVbSu7A>
Subject: Re: [6lo] Advocating a generalization 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:38:19 -0000

This is all very right, Carsten.


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

No brainer it is, but for Lorenzo's issues on state preservation or reconstruction upon router reboot.

> 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 Wi-Fi) 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.

For I started that at 6lo and there is text in https://datatracker.ietf.org/doc/html/draft-ietf-6lo-backbone-router , e.g., in section 3.2. The coexistence is also discussed in https://tools.ietf.org/html/draft-thubert-6lo-unicast-lookup but at some point it is not a 6lo problem anymore and that work should really move somewhere else. 

Being non-maintenance, it seems too early for 6MAN. If so maybe we should form a short-lived WG to sort out the issues raised by Lorenzo,  yours (coexistence) and mine (limit use of broadcast / interface with a fabric mapping server and do unicast lookup when possible).

All the best,

Pascal

> -----Original Message-----
> From: Carsten Bormann <cabo@tzi.org>;
> Sent: jeudi 4 juillet 2019 13:22
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>;
> Cc: Michael Richardson <mcr+ietf@sandelman.ca>;; 6lo@ietf.org; V6 Ops List
> <v6ops@ietf.org>;; 6man <6man@ietf.org>;
> Subject: Re: [6lo] Advocating a generalisation of RFC8505 to non-6lo LANs
> 
> 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
> >
> >