Re: Re: 3484bis and privacy addresses

Ray Hunter <> Wed, 28 March 2012 09:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBEAB21E8028 for <>; Wed, 28 Mar 2012 02:14:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uM-7cAMWXeDj for <>; Wed, 28 Mar 2012 02:14:41 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f14:62e::2]) by (Postfix) with ESMTP id DA3F521E801A for <>; Wed, 28 Mar 2012 02:14:40 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4FC18700BB; Wed, 28 Mar 2012 11:14:39 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mAVRcW0vmiJZ; Wed, 28 Mar 2012 11:14:31 +0200 (CEST)
Received: from Rays-iMac.local (unknown []) (Authenticated sender: by (Postfix) with ESMTPA id 03E6D8700B8; Wed, 28 Mar 2012 11:14:30 +0200 (CEST)
Message-ID: <>
Date: Wed, 28 Mar 2012 11:14:30 +0200
From: Ray Hunter <>
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Karl Auer <>
Subject: Re: Re: 3484bis and privacy addresses
References: <> <> <> <> <1332884609.2633.22.camel@karl>
In-Reply-To: <1332884609.2633.22.camel@karl>
Content-Type: multipart/alternative; boundary="------------060901050305070303070006"
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Mar 2012 09:14:42 -0000

Draft RFC3484bis-01 currently references RFC4941 as a normative 
reference in Section 11.1:
> Privacy considerations have introduced the concepts of "public
>     addresses" and "temporary addresses" [RFC4941  <>].
So I think we have to assume that a node will have such addresses 
present by default when considering RFC3484bis.

I could completely agree with your logic if RFC3484bis did not have 
RFC4941 as a normative reference, or if 3484bis was coupled with 
draft-gont-6man-managing-slaac-policy-00, or 
draft-ietf-6man-addr-select-opt-03 was already deployed in the field,  
or the M&O bits of RA were defined to force use of DHCPv6, or there was 
a common proprietary cross-OS mechanism available or indeed anything 
else that would allow a network manager to reliably control use of 
temporary addresses. But there isn't AFAIK. Unless you also 
intentionally break SLAAC.

So IMHO, in the absence of any other reliable OFF switch, RFC3484-bis 
itself currently really is the only place where a reliable default "OFF" 
can be specified at this time. I don't mind how this is achieved: either 
in the preference rules themselves, or in other clarification text that 
describes safe default backwards-compatible end-node behavior that will 
not break other systems that currently rely on IPv4-like behavior.


Karl Auer wrote:
> On Tue, 2012-03-27 at 21:05 +0200, Ray Hunter wrote:
>> IMHO the proper *default* behavior is still "off" = option A. In other
>> words, default = IPv4-like behavior, at least until we really figure
>> out how to operate all of these fancy new features of IPv6.
> The question is not whether the use of privacy addresses (temporary
> addresses) should be enabled by default. Though some OSes do that, I
> believe.
> The question is, where a host *does* have both a temporary and a
> non-temporary addresses, which one it should prefer by default. "Prefer
> by default" in this case means "select as the source address for new
> outbound connections in the absence of specific instructions to do
> otherwise".
> Regards, K.