Re: [addr-select-dt] about on/off switch of privacy extension

Tim Chown <tjc@ecs.soton.ac.uk> Fri, 16 July 2010 10:57 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
X-Original-To: addr-select-dt@core3.amsl.com
Delivered-To: addr-select-dt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C413A6832 for <addr-select-dt@core3.amsl.com>; Fri, 16 Jul 2010 03:57:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.274
X-Spam-Level:
X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58OEpnvuMGwS for <addr-select-dt@core3.amsl.com>; Fri, 16 Jul 2010 03:57:25 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id 4B5D43A6875 for <addr-select-dt@ietf.org>; Fri, 16 Jul 2010 03:57:24 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6GAvVWE023327 for <addr-select-dt@ietf.org>; Fri, 16 Jul 2010 11:57:31 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o6GAvVWE023327
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1279277852; bh=nlS5xwKg4G0sTiKt2XrziCu6MQc=; h=Subject:References:From:In-Reply-To:Date:To:Mime-Version; b=WclGNM0EzZzP1Hgx0gcdEUq7Zt3cl2JL9inb2OlxM3j5+7YLnKNwFVsGCX4sw49dP YwpxQ6Twfy0aB1pWyHPYPQKLJXzfk+LqUQH1+JKy+/NcSWWmxp3uOecRqo6BbxFLT4 SA28x4uwe4fzCbrk0NBiT5DUogOsBU/vQShyoorM=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP id m6FBvV0540051689gR ret-id none; Fri, 16 Jul 2010 11:57:32 +0100
Received: from cerf.ecs.soton.ac.uk (cerf.ecs.soton.ac.uk [152.78.69.39]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6GAvR0t012510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <addr-select-dt@ietf.org>; Fri, 16 Jul 2010 11:57:27 +0100
References: <EAE0398F-B61A-49C6-9DDE-A2B9E4ADB955@nttv6.net> <A5868203-E739-41FB-9081-6C59988D115D@ecs.soton.ac.uk>
From: Tim Chown <tjc@ecs.soton.ac.uk>
Content-Type: multipart/alternative; boundary=Apple-Mail-9-322936336
In-Reply-To: <EAE0398F-B61A-49C6-9DDE-A2B9E4ADB955@nttv6.net>
Message-ID: <EMEW3|4316cf345919db8a053a6805f4783a3em6FBvV03tjc|ecs.soton.ac.uk|A5868203-E739-41FB-9081-6C59988D115D@ecs.soton.ac.uk>
Date: Fri, 16 Jul 2010 11:57:26 +0100
To: addr-select-dt@ietf.org
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=m6FBvV054005168900; tid=m6FBvV0540051689gR; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: o6GAvVWE023327
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Subject: Re: [addr-select-dt] about on/off switch of privacy extension
X-BeenThere: addr-select-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPv6 Address Selection Design Team <addr-select-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/addr-select-dt>
List-Post: <mailto:addr-select-dt@ietf.org>
List-Help: <mailto:addr-select-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jul 2010 10:57:26 -0000

On 16 Jul 2010, at 11:27, Arifumi Matsumoto wrote:
> 
> this may be a trivial issue, but let me post it before I forget. :)
> 
> What do you think about putting a on/off bit in the distributing policy
> for controlling client's behavior of privacy address extension.
> 
> I know the privacy extension does harm a lot in a lot of circumstances.
> And, if it is possible, why not provide a way to solve this problem
> at the same time ?

Interesting.

So my personal view with a campus enterprise hat on is I'd like to avoid use of privacy addresses.   The main reason is the same as the reason to use DHCPv6, for accountability.    Of course if use of 802.1x and/or SAVI provides that for autoconf or privacy addresses, we can reconsider.   At the moment 802.1x is common on wireless network but not wired ones.

For managed desktops (or laptops), we can configure privacy addresses off by default in the system build.    Likewise, we *can* configure RFC3484 default policy in our managed desktop builds.    But that is only useful if the same policy applies at all points of attachment on the network and at all times of day.   For RFC3484 policy is may well not do.   For privacy address policy, it probably does.  

If the RFC3484 policy table could distinguish privacy addresses, then their use or prioritisation can be set.   At our site we'd probably like to say in the policy table NEVER use privacy addresses or 6to4 addresses as source addresses.

Tim