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

Thomas Narten <narten@us.ibm.com> Fri, 11 March 2011 12:50 UTC

Return-Path: <narten@us.ibm.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 479CD3A6BA8 for <ipv6@core3.amsl.com>; Fri, 11 Mar 2011 04:50:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 StCrHnRNF35V for <ipv6@core3.amsl.com>; Fri, 11 Mar 2011 04:50:27 -0800 (PST)
Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id ED5FC3A6A17 for <ipv6@ietf.org>; Fri, 11 Mar 2011 04:50:26 -0800 (PST)
Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e31.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p2BCaUoi005414 for <ipv6@ietf.org>; Fri, 11 Mar 2011 05:36:30 -0700
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p2BCpbI5100522 for <ipv6@ietf.org>; Fri, 11 Mar 2011 05:51:37 -0700
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p2BCpaYF011889 for <ipv6@ietf.org>; Fri, 11 Mar 2011 05:51:37 -0700
Received: from cichlid.raleigh.ibm.com (sig-9-49-154-135.mts.ibm.com [9.49.154.135]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p2BCpZOY011841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2011 05:51:36 -0700
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p2BCpTO6024851; Fri, 11 Mar 2011 07:51:34 -0500
Message-Id: <201103111251.p2BCpTO6024851@cichlid.raleigh.ibm.com>
To: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
Subject: Re: draft-gont-6man-managing-privacy-extensions-00.txt
In-reply-to: <20110310064328.3388ce88@opy.nosense.org>
References: <7111FC5F-BC3F-4242-9C3F-037E79894749@gmail.com> <alpine.DEB.1.10.1103091212570.7942@uplift.swm.pp.se> <4D77CBB9.1080702@gmail.com> <A8E3ED1C-D74F-4B16-8CBE-049CA30B7D29@gmail.com> <4D77D5DD.40100@joelhalpern.com> <20110310064328.3388ce88@opy.nosense.org>
Comments: In-reply-to Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> message dated "Thu, 10 Mar 2011 06:43:28 +1030."
Date: Fri, 11 Mar 2011 07:51:29 -0500
From: Thomas Narten <narten@us.ibm.com>
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: Fri, 11 Mar 2011 12:50:31 -0000

Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> writes:

> I also think there is a fundamentally incorrect assumption is being
> made - that IPv6 addresses and humans are tightly coupled.

Actually, if you look at trends, they are increasingly tightly
coupled.

Internet access by humans is increasingly through single-owner devices
(recently laptops, but increasingly smart phones and the like, which
are typically single-owner). Indeed, I've seen projections that assert
that sometime this year more people will access the Internet though
Mobile Wireless devices than through traditional computers. The
primary method of Internet access is changing...

> An IPv6 address identifies an end-node, and the traffic to or from
> it, but does not always identify the human that caused that traffic
> to occur.

True, but if it correctly identifies the human in 70, 80, or 90% of
the cases, that's likely good enough for "innovation" to move in and
exploit such characteristics.

Up levelling, this draft simply reopens a discussion that was had back
when stateless addrconf was first defined. Today, there is no easy way
for the network adminstrator to "configure" clients. When stateless
addrconf is used, there are pretty much no mechanisms for
communicating network preferences or policy.

Allowing/disallowing temporary addresses is one instance of a broader
problem. Another example of policy that would be useful to commnicate
is address selection preferences. Hence, if we are going to define
something like an "H bit", we should really look at the more general
problem.

And, even if there was a mechanism for the network to communicate its
preferences/policies, we'd still have the problem that end hosts could
simply ignore or override those preferences. 

There is no good/easy/simple answer here folks.

Thomas