RE: draft-gont-6man-managing-privacy-extensions-00.txt

"Dan Wing" <dwing@cisco.com> Thu, 10 March 2011 19:56 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2713A6962 for <ipv6@core3.amsl.com>; Thu, 10 Mar 2011 11:56:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.57
X-Spam-Level:
X-Spam-Status: No, score=-110.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 fkrqNRskFwSx for <ipv6@core3.amsl.com>; Thu, 10 Mar 2011 11:56:07 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D32DE3A67FF for <ipv6@ietf.org>; Thu, 10 Mar 2011 11:56:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2683; q=dns/txt; s=iport; t=1299787046; x=1300996646; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=OPXKaIv+SAAPWEk7leN0ZCOXt7+Cy23GHKBLzxg/1aw=; b=LAj94si0xPwJ77H8A0/sozoj6yIEmkgqewT5SinxWsu9BX/Qv4WpgP7L iev+bNbdq5bKtWQva4FrqAZART+k1xujr4HRVLmFX1HP5tH6KQ1DQzIZv ggXJsUL3wPHZCEfuCeQAPNZUF9PZ6GVNWvR6d7QnzlWxF0/zBgvlzHUtH w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggBAJ67eE2rR7H+/2dsb2JhbACYX4Fki253pTScMYViBIUk
X-IronPort-AV: E=Sophos;i="4.62,297,1297036800"; d="scan'208";a="319288080"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 10 Mar 2011 19:57:26 +0000
Received: from dwingWS ([10.32.240.195]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p2AJvPXc028366; Thu, 10 Mar 2011 19:57:25 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Paul Chilton' <paul.chilton@nxp.com>, 'james woodyatt' <jhw@apple.com>
References: <7111FC5F-BC3F-4242-9C3F-037E79894749@gmail.com> <alpine.DEB.1.10.1103091212570.7942@uplift.swm.pp.se> <4D77CBB9.1080702@gmail.com> <233b01cbdef5$8e214550$aa63cff0$@com> <25B3D469-F3DA-4A1D-A462-FEB71FA69485@gmail.com> <091D1284-99E4-450E-8AFF-7D4C6310D760@apple.com> <78B923726E7D59429936580CF127E943A13E758C27@eu1rdcrdc1wx032.exi.nxp.com>
In-Reply-To: <78B923726E7D59429936580CF127E943A13E758C27@eu1rdcrdc1wx032.exi.nxp.com>
Subject: RE: draft-gont-6man-managing-privacy-extensions-00.txt
Date: Thu, 10 Mar 2011 11:57:25 -0800
Message-ID: <262f01cbdf5d$607c69f0$21753dd0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcvfPImkSrHUQZ1RTwmX5CUIKMyXDQAEhMlgAAOQCYA=
Content-Language: en-us
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 10 Mar 2011 19:56:08 -0000

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> Paul Chilton
> Sent: Thursday, March 10, 2011 10:18 AM
> To: james woodyatt
> Cc: ipv6@ietf.org
> Subject: RE: draft-gont-6man-managing-privacy-extensions-00.txt
> 
> Doesn't a combination of RFC4941 and NPTv6 produce the necessary
> privacy over both parts of the IPv6 address?
> (BTW thats a question from an interested observer new to this topic,
> not a statement - I started following this thread and ended up digging
> around in the RFCs and drafts the thread uncovered)

RFC4941 by itself does the trick.

But draft-gont-6man-managing-privacy-extensions (the subject of
this thread) says "you can't use RFC4941".

I'm saying the reasons people are tempted to disable RFC4941 are
misplaced.  Really, they want the same tracking of 
which-host-is-using-which-address that they have, today, with
DHCPv4 (by examining the DHCP server's logs) and have, today,
with DHCPv6 (by examining the DHCPv6 server's logs).  Thus the
desire to simply throw away RFC4941 (sorry, "disable on this 
network") is misplaced.  We should devote our energies 
elsewhere and provide the means to log use of a SLAAC address.

-d


> 
> Paul Chilton
> Low Power RF Solutions (formerly Jennic)
> NXP Semiconductors
> 
> 
> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> james woodyatt
> Sent: 10 March 2011 16:02
> To: Ran Atkinson
> Cc: ipv6@ietf.org
> Subject: Re: draft-gont-6man-managing-privacy-extensions-00.txt
> 
> On Mar 10, 2011, at 4:10 AM, Ran Atkinson wrote:
> >
> > It seems pretty clear that Fred's NPTv6 is going to be deployed in at
> least some locations, albeit for entirely  different reasons.  I'm not
> sure if that meets your definition of NAPT66 or not.
> 
> It does not.  NPTv6 only translates the network prefix; it therefore
> doesn't prevent global tracking of hosts that use EUI-64 interface
> identifiers.
> 
> 
> --
> james woodyatt <jhw@apple.com>
> member of technical staff, core os networking
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------