[Roll] privacy enhanced l2 addresses and parent selection in ROLL

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 19 July 2016 14:03 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C6312E06E; Tue, 19 Jul 2016 07:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level:
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-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 KzsQPcEvx_N7; Tue, 19 Jul 2016 07:03:30 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A463912E196; Tue, 19 Jul 2016 06:29:32 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4F897203BC; Tue, 19 Jul 2016 09:38:59 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7B9BC638D1; Tue, 19 Jul 2016 09:29:31 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Tue, 19 Jul 2016 09:29:31 -0400
Message-ID: <4193.1468934971@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/9NIOejjSAB9QgKlJh94c88tqZMo>
Cc: 6lo@ietf.org
Subject: [Roll] privacy enhanced l2 addresses and parent selection in ROLL
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jul 2016 14:03:36 -0000

Pascal spoke today in 6man concerning the process of providing privacy
enhanced addresses in 6man, and how LLNs typically use their 2-byte short
addresses for layer-2, and also for forming L3 addresses.
Pascal mentioned that 2-byte addresses can be dhcpv6 assigned and therefore
unrelated to the EUI-64.  (Of course, many just use the bottom two bytes of
the EUI-64, and don't do DAD or ND at all.. Let's agree they are not to spec)

I was thinking about the dhcpv6 process.  In order to do it in a route-over
mesh, the route-over mesh needs to be up in order to get traffic to the
DHCPv6 server.  That means that the DAG has been formed using EUI-64 derived
link local addresses.

Afterward, the 6LNs will allocate a 2-byte v6 address from the dhcpv6 server,
and will then set their L2 address based upon that.    I think that this is
not specified anywhere...?

But, the thing that got to write this email (while doing my IETF96 laundry),
is the parent selection process.  Do we need to have a way for an RPL parent
to say in it's DIO, "I know you see me as fe80::1234, but you knew me before
as fe80::1234:56fe:ff78:abcd", such that there could be a seamless and
efficient transition to the new 2-byte addresses?

Perhaps it's good enough that the node, having been allocated a 2-byte L2
address, does a gratitous NA where it announces it's EUI64 LL address with
it's 2-byte L2 address?  How does that sit security-wise?  Have we just
encouraged the network to accept gratuitous L2 address spoofing?

How does this interact with Back-Bone Router EARO processing?

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-