[6lo] Alissa Cooper's Discuss on draft-ietf-6lo-6lobac-06: (with DISCUSS and COMMENT)
"Alissa Cooper" <alissa@cooperw.in> Wed, 30 November 2016 16:33 UTC
Return-Path: <alissa@cooperw.in>
X-Original-To: 6lo@ietf.org
Delivered-To: 6lo@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A5C12957F; Wed, 30 Nov 2016 08:33:03 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper <alissa@cooperw.in>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148052358314.2961.7757929872750287025.idtracker@ietfa.amsl.com>
Date: Wed, 30 Nov 2016 08:33:03 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/0NTK_sAwqQ5kY94kfiXuWTzB0lY>
Cc: 6lo-chairs@ietf.org, samitac.ietf@gmail.com, draft-ietf-6lo-6lobac@ietf.org, 6lo@ietf.org
Subject: [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-6lobac-06: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 30 Nov 2016 16:33:03 -0000
Alissa Cooper has entered the following ballot position for draft-ietf-6lo-6lobac-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 12 says: "For this reason, it is RECOMMENDED that a different (but stable) IID be generated for each globally scoped address in use according to, for example, [RFC3315], [RFC3972], [RFC4941], [RFC5535], or [RFC7217]." I have a couple of questions about this recommendation that should be easy to clear up. First, do you really mean "different" IID? EUI-64 identifiers are different from each other, but embedding one in an IID still leaves you susceptible to address scanning attacks. Maybe what is meant here is "semantically opaque" or "with maximum supportable entropy" or something along those lines? Second, what is meant by the word "stable" here? The mechanisms cited offer a variety of different "stability" spans -- DHCP lease lifetime, temporary address lifetime, lifetime of connection to a link, etc. So it's not clear what is actually being recommended or if the cited mechanisms all provide the desired property. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I mostly understand why Sections 6 and 12 are specified as they are but there are a couple of points of departure from draft-ietf-6lo-privacy-considerations and draft-ietf-6man-default-iids that I'd like to discuss. (1) draft-ietf-6man-default-iids says that the choice of address generation mechanism should be configurable when a mechanism is specified to embed a link layer address in an IID. Is there a reason that doesn't apply here? The document doesn't say anything about it for the link-local case. (2) draft-ietf-6lo-privacy-considerations says: "Specifications should make sure that an IPv6 address can change over long periods of time. For example, the interface identifier might change each time a device connects to the network (if connections are short), or might change each day (if connections can be long). This is necessary to mitigate correlation over time." This document doesn't seem to provide any guidance about supporting the ability to change an IPv6 address within the life span of a long-lived attachment to the same physical network. Some of the mechanisms cited in Section 12 provide this and some do not. I appreciate that correlation of activities over time isn't perceived to be a huge threat here, but aren't there cases where being able to change an address despite remaining attached to the same physical network would be desirable? That seems worth some guidance for nodes that want to support it.
- [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-6… Alissa Cooper
- Re: [6lo] Alissa Cooper's Discuss on draft-ietf-6… Kerry Lynn