Re: 3484bis and privacy addresses

"t.petch" <ietfc@btconnect.com> Thu, 29 March 2012 11:37 UTC

Return-Path: <ietfc@btconnect.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 37E5221F89A3 for <ipv6@ietfa.amsl.com>; Thu, 29 Mar 2012 04:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.354
X-Spam-Level:
X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_20=-0.74]
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 bqliLZYt4zIS for <ipv6@ietfa.amsl.com>; Thu, 29 Mar 2012 04:37:03 -0700 (PDT)
Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id 64EC121F8992 for <ipv6@ietf.org>; Thu, 29 Mar 2012 04:37:02 -0700 (PDT)
Received: from host86-162-135-195.range86-162.btcentralplus.com (HELO pc6) ([86.162.135.195]) by c2beaomr10.btconnect.com with SMTP id GUV31907; Thu, 29 Mar 2012 12:36:57 +0100 (BST)
Message-ID: <03d301cd0d97$b3361060$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: Ray Hunter <Ray.Hunter@globis.net>, Brian Haberman <brian@innovationslab.net>
References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net>
Subject: Re: 3484bis and privacy addresses
Date: Thu, 29 Mar 2012 12:03:21 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4F744959.0013, actions=tag
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.3.29.105416:17:7.944, ip=86.162.135.195, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, __STOCK_PHRASE_7, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4F744959.01A4, ss=1, re=0.000, fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine
X-Junkmail-IWF: false
Cc: ipv6@ietf.org
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: Thu, 29 Mar 2012 11:37:05 -0000

A categorically.

I think that Ray summarises the arguments well below.  I only disagree with him
in that I see the arguments applying outside the corporate world as well.

I think too that Ray is spot on with a later post about
"how to operate all of these fancy new features of IPv6."

Yup, we really need to start rolling out IPv6 and find out what works.

Tom Petch

----- Original Message -----
From: "Ray Hunter" <Ray.Hunter@globis.net>
To: "Brian Haberman" <brian@innovationslab.net>
Cc: <ipv6@ietf.org>
Sent: Tuesday, March 27, 2012 7:00 PM
Subject: Re: 3484bis and privacy addresses


> From the corporate World: option A as default, with local user
> controlled option to override.
>
> RFC3484 (which references RFC3041) "Temporary addresses" are a menace to
> fault finding, audit, logging, firewall rules, filtering, QoS matching,
> conformance: anywhere where an ACL or stable address is used today. Sure
> we shouldn't use fixed/stable IP literals, but we do. And in many cases
> there aren't any practical alternatives in today's products, so the IP
> address is the lowest common denominator used to identify a machine (and
> dare I say even "a user" in some circumstances).
>
> Also not sure if any DHCPv6 server implementations actually provide
> DHCPv6 assigned temporary addresses in practice.
>
> My take on this is that a set of a few hundred individual persons who
> are worried about privacy are more likely to be able to control their
> own particular machines to correctly override the "default off" setting
> than a single corporate network manager is to be able to guarantee
> overriding a "default on" setting on 100% of 10000 machines attached to
> their network.
>
> regards,
> RayH
>
> Brian Haberman wrote:
> > <div class="moz-text-flowed">All,
> >      The chairs would like to get a sense of the working group on
> > changing the current (defined 3484) model of preferring public
> > addresses over privacy addresses during the address selection
> > process.  RFC 3484 prefers public addresses with the ability (MAY) of
> > an implementation to reverse the preference.  The suggestion has been
> > made to reverse that preference in 3484bis (prefer privacy addresses
> > over public ones). Regardless, the document will allow
> > implementers/users to reverse the default preference.
> >
> >      Please state your preference for one of the following default
> > options :
> >
> > A. Prefer public addresses over privacy addresses
> >
> > B. Prefer privacy addresses over public addresses
> >
> > Regards,
> > Brian, Bob, & Ole
> >
> > </div>
>
> --
> Ray Hunter
> Ray.Hunter@globis.net
> Globis Consulting BV, Fazantlaan 23, 5613CB Eindhoven NL,
> Registered at the KvK, Eindhoven, under number BV 17098279
> mobile: +31 620 363864
>
>


--------------------------------------------------------------------------------


> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>