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

"Pascal Thubert (pthubert)" <> Mon, 08 July 2019 12:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76F0A120168; Mon, 8 Jul 2019 05:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.5
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: (amavisd-new); dkim=pass (1024-bit key) header.b=R98F2Wl+; dkim=pass (1024-bit key) header.b=rnzp/tzG
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pcElIzPoiq-C; Mon, 8 Jul 2019 05:41:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B0B212010D; Mon, 8 Jul 2019 05:41:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6360; q=dns/txt; s=iport; t=1562589684; x=1563799284; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sgKn3x8UN4Rwd+B/o7bYeOu975NZp3se9y3U7mDyZDQ=; b=R98F2Wl+bX8bbZf7XFljZmEqj3Xt8d6/J6cM/lFMxeVVTmuywo2ceT74 EBRT0d7J2g4vm0W9BcIDu/Dz/XIx2sWzl7ivJx7x9tDdKLZPhVxapbXOl cew1whOS4UBcY1aDxEsqLnjpM1mBSowMZRTKxBXYG7R6TuO1e7CcSiqiS g=;
IronPort-PHdr: =?us-ascii?q?9a23=3AYWmwUBw/CjwDt73XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudFU3mJvPwcwQxHd9JUxlu+HToeUU=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.63,466,1557187200"; d="scan'208";a="504308830"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jul 2019 12:41:22 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id x68CfNaC032023 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Jul 2019 12:41:23 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 07:41:22 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 08:41:21 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 8 Jul 2019 08:41:21 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sgKn3x8UN4Rwd+B/o7bYeOu975NZp3se9y3U7mDyZDQ=; b=rnzp/tzGsymyI0Y3tEn4u9zRX8YXglwVSTcj6h4QO/OnRxRTaGAUpSpe+YI8dAoSp2H8whUSyrA50rsPOkfb1sXypZDKfZwq+2mfaL+nUjDL6BYyHBqTDg0RSG41PUzFlj7Gcocq4e3Sg0FFGTl2cL1+7bBVbj+0ckl1S3p7GKw=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Mon, 8 Jul 2019 12:41:20 +0000
Received: from ([fe80::1ce9:1582:146c:c50a]) by ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2052.020; Mon, 8 Jul 2019 12:41:20 +0000
From: "Pascal Thubert (pthubert)" <>
To: Mark Smith <>
CC: Carsten Bormann <>, Michael Richardson <>, V6 Ops List <>, 6man <>, "" <>
Thread-Topic: [6lo] Advocating a generalization of RFC8505 to non-6lo LANs
Date: Mon, 8 Jul 2019 12:41:04 +0000
Deferred-Delivery: Mon, 8 Jul 2019 12:40:07 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 69fe8431-8dfe-4214-9f99-08d703a193f4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4141;
x-ms-traffictypediagnostic: MN2PR11MB4141:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 00922518D8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(366004)(346002)(376002)(199004)(189003)(51444003)(229853002)(52536014)(14444005)(256004)(5024004)(53936002)(74316002)(99286004)(66066001)(6436002)(8676002)(3846002)(6116002)(9686003)(6306002)(55016002)(305945005)(8936002)(66446008)(7736002)(73956011)(66556008)(64756008)(81156014)(81166006)(102836004)(76176011)(5660300002)(66476007)(76116006)(66946007)(6506007)(7696005)(6916009)(2906002)(486006)(54906003)(68736007)(478600001)(476003)(26005)(4326008)(446003)(86362001)(186003)(11346002)(316002)(6246003)(25786009)(33656002)(966005)(66574012)(71190400001)(71200400001)(14454004)(1411001)(6666004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4141;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: lYoid3a3uHmBWTVnRQm9Qf632/AlB+UrATXJCxZ+zozw07ccaL9sRnCykHaXNFq+5QXTKGASwCfFWXKhbu22mwXwVKq6InOKfaNAJFp4H1RxVGIDhTxB1Q9RuLEHL27g6gTfu4I2Ugd+GtFBH42Ld2uzJJSQLedILXsIEinxVrp6AWqSVIwK7ct6wOeM2cmBXgDceCh7dglUVVwtGRVIwN6jecanvLXiKgD7rkI1s3TVmDStQVucErlS6HdOkoIwBKtggdmnbDROZE+xLR5O+kM83ehJCXGsKBSBRSkdvBecVT8rDVCjIAFrBUhqltPPxs/JbEh/x7gbb8u38HLNpv0f3n8hHPSjq0HTcmEsq+R4WSvxsICfwOXoHPLcXf0eNImATVnTI4TnkMQu8yNN5NDL5qILtnz609H7UR6te4w=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 69fe8431-8dfe-4214-9f99-08d703a193f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 12:41:20.1565 (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-Transport-CrossTenantHeadersStamped: MN2PR11MB4141
Archived-At: <>
Subject: Re: [6lo] Advocating a generalization of RFC8505 to non-6lo LANs
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Jul 2019 12:41:28 -0000

Hello Mark:

> > A sense of lifetime; how long should the router/L3AP expect that the
> address will be used; at time out, the router can clean up the state.
> Already being performed by NUD right now.
> NUD avoids the possibility of the router's view of when an address expires
> getting out of sync with when the address does or has expired on a host.

NUD is still important in RFC 6775/8505. The lifetime of a registration has additional value. It is a negotiated contract that the router will maintain and possibly defend / re-advertise the state during that period. It can be very short for short-lived address (e.g., one wake time of your tablet) and very long for an exit sign. NUD defaults show limits there.

> > A sense of order; if a wireless node moves rapidly from a L3AP to the
> > next, or a VM moves rapidly from a server to the next, which is the
> > most recent point of attachment
> What sort of device is a "L3AP"? In RFC 8200 we don't have that sort of device
> defined, we just have links, hosts, routers and nodes (IPv6 host or router).

Like a L3-switch but wireless. An AP is a bridge that is proactively programmed on the wireless side with the association process, as opposed to a learning (transparent) bridge that requires the broadcast. RFC 6775 / 8505 is the same thing at L3. If you add L3 features like an SVI to the AP, and L3 functions in there like RFC8505, routing, and/or ND proxy, then you have an L3-AP.

> I'm guessing it is a combined layer 2/layer 3 device with tight integration
> between layer 2 and layer 3 processing? If it is, we wouldn't want to create a
> requirement that all layer 2 devices are also layer 3 routers for all IPv6
> networks.

There should be one such thing on the path, we usually place it at the edge, device facing, aka Border Nodes. There are roles to be played at ingress, like the registration, ND snooping, and overlay encapsulation. Others at egress like multicast suppression.

> > A sense of ownership; if the router maintains a state about the
> > address for a requested lifetime, then a proof of ownership can be
> > attached, so only the owner of the address can modify the state (SAVI)
> I think that can be achieved using using the state that NUD maintains and is
> already occurring. For example, an unsolicited NA can be sent to update
> remote devices' neighbor cache entry for the address with a new link-layer
> address, however the update only occurs if the remove device already has an
> existing neighbor cache entry for the address.

True, and we do that already. But a solid and local proof that it is the same guy is better, e.g. in fast mobility to avoid slowing down the roaming, or if the target is unreachable for a second, sleeping, rebooting, whatever, in which case the address is easy to steal. 
The companion draft for RFC 8505 is 

> > A sense of service; what should the router do with that address? Examples
> that come to mind are inject in a routing protocol, play sleeping proxy or ND
> proxy.
> >
> These requirements seem to be more specific to 6lo environments, rather
> than a more general and common cases. For example, hosts'
> addresses aren't injected into a routing protocol in most networks.

Another example is the data center underlay, see 

Also 802.11OCB, see

As soon as your link is multiaccess yet non-transitive, or your subnet is multilink, you should consider L3 routing. Alt you let the L2 do it for you like in Switched Ethernet and Wi-Fi infrastructure mode, but then it comes at a cost that you may be willing to avoid, e.g.,  L3 broadcasts. 

The /64 per host is a valid approach to get there, but it throws ND with the water of the bath and seems wasteful at scale, e.g. , for IOT devices and VMs. 

I'm advocating for a modernization of ND that is not antagonistic to that but complementary with the /64 per host towards a same goal of more L3 / proactive, less broadcasts / reactive.

> However, once a router has knowledge of the existence of an address, then I
> think what the router uses that address knowledge for, in addition to
> forwarding, is out of scope for an address discovery or registration protocol.

Agreed, the registration is abstract to the router operation. The point is that the router operation can be vastly improved by simple things like a sequence number or a lifetime.

All the best,