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

Mohacsi Janos <> Fri, 16 July 2010 11:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F40173A698D for <>; Fri, 16 Jul 2010 04:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.182
X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ndwUYS+CY6pK for <>; Fri, 16 Jul 2010 04:14:10 -0700 (PDT)
Received: from ( [IPv6:2001:738:0:411::241]) by (Postfix) with ESMTP id C28233A6987 for <>; Fri, 16 Jul 2010 04:14:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 28C358518D; Fri, 16 Jul 2010 13:14:20 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id cspXtX81XISh; Fri, 16 Jul 2010 13:14:13 +0200 (CEST)
Received: by (Postfix, from userid 9002) id A9028851A4; Fri, 16 Jul 2010 13:14:13 +0200 (CEST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7195850DD; Fri, 16 Jul 2010 13:14:13 +0200 (CEST)
Date: Fri, 16 Jul 2010 13:14:13 +0200 (CEST)
From: Mohacsi Janos <>
To: Tim Chown <>
In-Reply-To: <EMEW3|4316cf345919db8a053a6805f4783a3em6FBvV03tjc||>
Message-ID: <>
References: <> <> <EMEW3|4316cf345919db8a053a6805f4783a3em6FBvV03tjc||>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-748727248-1279278853=:21959"
Subject: Re: [addr-select-dt] about on/off switch of privacy extension
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPv6 Address Selection Design Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Jul 2010 11:14:11 -0000

On Fri, 16 Jul 2010, Tim Chown wrote:

> 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.

This policy distribution can be done in Windows domain today. You can 
disable privacy enhanced address usage in domain group policy. I don't 
think that you can automatically distinguish between privacy enhanced or 
autoconfigured or dhcpv6 assigned addresses, except if you have other 
administrative rules for interface id generation. RFC 4941, the new 
privacy enhanced address draft, is explicitly stating the privacy address 
not to be used by default. Although RFC 4941 is not widely implemented - I 
did not see any ;-).

By the way, what 3484 policy table stanza you would use to forbid use 6to4 
or some other kind of prefix?

Best Regards,
 		Janos Mohacsi