IETF Logo Mail Archive

RE: 3484bis and privacy addresses

Karl Auer <kauer@biplane.com.au> Tue, 27 March 2012 23:26 UTC

Return-Path: <kauer@biplane.com.au>
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 1775D21E80AD for <ipv6@ietfa.amsl.com>; Tue, 27 Mar 2012 16:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7Dmswu-6Cmu for <ipv6@ietfa.amsl.com>; Tue, 27 Mar 2012 16:26:38 -0700 (PDT)
Received: from ipmail06.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 428BD21E800C for <ipv6@ietf.org>; Tue, 27 Mar 2012 16:26:37 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMBAFpLck+WZX+7/2dsb2JhbAANOIVAtjYBAQEDASNbCwsYKgICVxmIBagmkXmNa4IMgRgEoRWHdIFAFw
Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.207]) ([150.101.127.187]) by ipmail06.adl6.internode.on.net with ESMTP; 28 Mar 2012 09:56:36 +1030
Subject: RE: 3484bis and privacy addresses
From: Karl Auer <kauer@biplane.com.au>
To: ipv6@ietf.org
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611078EFB@GAALPA1MSGUSR9N.ITServices.sbc.com>
References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> <4F71FC03.90403@si6networks.com> <4F720F7F.2090108@globis.net> <1332884609.2633.22.camel@karl> <2D09D61DDFA73D4C884805CC7865E611078EFB@GAALPA1MSGUSR9N.ITServices.sbc.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-cuyu1Z7ItruxShYdmCoW"
Date: Wed, 28 Mar 2012 10:26:32 +1100
Message-ID: <1332890792.2633.84.camel@karl>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 27 Mar 2012 23:26:39 -0000

On Tue, 2012-03-27 at 23:12 +0000, STARK, BARBARA H wrote:
> I think the rules for which (temporary vs not temporary) to use should
> be application-specific. And the people who are best-positioned to
> determine what's right for the app are the app developers or
> designers. Not IETF.

The application always has that control anyway. The very first source
address selection rule is "use the source address the application
specifies". The other source address selection rules apply only if the
application does not specify a source address.

> I vote for 3484bis to remain silent as to a preference,

Leaving the source address preference unspecified won't change anything
for applications, but will lead to some implementations preferring
privacy addresses and some implementations preferring non-privacy
addresses. In general, standards should be deterministic - given the
same circumstances, all implementations should behave the same way.
Hence the need for a default position.

Regards, K.
 
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

v2.46.0 | Report a Bug | By Email | System Status