default-iids: Clarifying the use of stable addresses
Fernando Gont <fgont@si6networks.com> Fri, 20 May 2016 22:42 UTC
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FC012D633 for <ipv6@ietfa.amsl.com>; Fri, 20 May 2016 15:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.309
X-Spam-Level:
X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_PASS=-0.001] autolearn=no 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 VFcWQlx-54gg for <ipv6@ietfa.amsl.com>; Fri, 20 May 2016 15:42:10 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F9012D140 for <6man@ietf.org>; Fri, 20 May 2016 15:42:10 -0700 (PDT)
Received: from [100.92.233.6] (unknown [152.206.74.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8312E8011B; Sat, 21 May 2016 00:41:45 +0200 (CEST)
To: "6man@ietf.org" <6man@ietf.org>, Lorenzo Colitti <lorenzo@google.com>, JINMEI Tatuya / 神明達哉 <jinmei@isc.org>
From: Fernando Gont <fgont@si6networks.com>
Subject: default-iids: Clarifying the use of stable addresses
X-Enigmail-Draft-Status: N1110
Message-ID: <573F3F49.9090107@si6networks.com>
Date: Fri, 20 May 2016 12:46:01 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/cBeTctG_CHt6G1NhjdhMgoW6M-A>
Cc: "draft-ietf-6man-default-iids@tools.ietf.org" <draft-ietf-6man-default-iids@tools.ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 May 2016 22:42:12 -0000
Folks, In the hopes of making this document more clear regarding whether this document is requiring the use of stable addresses, how about adding the following text: "SLAAC has traditionally resulted in stable addresses, since the IID has been generated by embedding a stable layer-2 numeric identifier (e.g., a MAC address). [RFC4941] implies, throughout the specification, that temporary addresses are generated and employed along with temporary addresses. We note that depending on the specific device type and/or operating environment, a host may or may not want to configure and/or use a stable address, but may e.g., exclusively use temporary addresses. This document does not require that stable addresses be actively employed or even generated, but simply provides a recommendation regarding how stable addresses should be generated when a node decides to do so. Similarly, this document is orthogonal to other privacy improvements such as MAC address randomization. This document aims to mitigate known security and privacy implications of stable IPv6 addresses in a hardware/protocol-independent manner, without any assumptions on the security/privacy properties of the underlying layers. " If you have suggestions for improvement, please do let me know, and send proposed tweaks. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
- default-iids: Clarifying the use of stable addres… Fernando Gont
- RE: default-iids: Clarifying the use of stable ad… Manfredi, Albert E
- Re: default-iids: Clarifying the use of stable ad… Lorenzo Colitti
- RE: default-iids: Clarifying the use of stable ad… Manfredi, Albert E
- Re: default-iids: Clarifying the use of stable ad… Lorenzo Colitti
- Re: default-iids: Clarifying the use of stable ad… Mark Smith
- Re: default-iids: Clarifying the use of temporary… Brian E Carpenter
- Re: default-iids: Clarifying the use of stable ad… Alexandre Petrescu
- Re: default-iids: Clarifying the use of stable ad… Alexandre Petrescu
- Re: default-iids: Clarifying the use of stable ad… Mark Smith
- RE: default-iids: Clarifying the use of stable ad… Manfredi, Albert E
- Re: default-iids: Clarifying the use of stable ad… Fernando Gont
- Re: default-iids: Clarifying the use of temporary… Fernando Gont
- RE: default-iids: Clarifying the use of stable ad… Mark Smith
- Re: default-iids: Clarifying the use of stable ad… Lorenzo Colitti
- RE: default-iids: Clarifying the use of stable ad… Manfredi, Albert E
- Re: default-iids: Clarifying the use of stable ad… Lorenzo Colitti
- Re: default-iids: Clarifying the use of stable ad… Fernando Gont
- Re: default-iids: Clarifying the use of stable ad… Lorenzo Colitti
- Re: default-iids: Clarifying the use of stable ad… Fernando Gont
- Re: default-iids: Clarifying the use of stable ad… Lorenzo Colitti
- Re: default-iids: Clarifying the use of stable ad… Fernando Gont