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

Ran Atkinson <ran.atkinson@gmail.com> Thu, 10 March 2011 12:08 UTC

Return-Path: <ran.atkinson@gmail.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 9034C3A695B for <ipv6@core3.amsl.com>; Thu, 10 Mar 2011 04:08:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level:
X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599]
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 wP-SanWt4wrS for <ipv6@core3.amsl.com>; Thu, 10 Mar 2011 04:08:50 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id A9ECD3A6A45 for <ipv6@ietf.org>; Thu, 10 Mar 2011 04:08:50 -0800 (PST)
Received: by vxg33 with SMTP id 33so1730505vxg.31 for <ipv6@ietf.org>; Thu, 10 Mar 2011 04:10:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=UdSIdhuHAXJqh0TNszKWMxncyL0uOiwH9eF0cEF1j2s=; b=Z/+lZgTsSV/F3vyEblXuuh3pKv0mVBByu3TiCUEWNX7POrEB7furmftzAQGLWt+8iO uD/f4BhFzwcaLH6+Vb9i7w48Vsqv1ahZJ+XooDxdSijwIu+z1PnGw7Bzs/9BITpcRRnw TKZ8Gye1d32PoUayh8ajAIf81rgajpacNvn+E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=PsEeDfCHE1Fv8ZeTZ0Scx+jeZtOJJo7BnZkdtK8Sx3AM0cGrlT95Hq5T6utq7DIeli m8y/ZPPau/lw+M8f4hweuXS0z7FmmZjXJufqhnQgzBMkSqgTOrtDn4PHkTVQn7JIH/1I JWCXfsETYYnK+ztBSHN7wvVGSagTSVYdgrPfA=
Received: by 10.52.90.109 with SMTP id bv13mr5920732vdb.237.1299759007837; Thu, 10 Mar 2011 04:10:07 -0800 (PST)
Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id bl17sm570489vdb.0.2011.03.10.04.10.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Mar 2011 04:10:06 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1082)
Subject: Re: draft-gont-6man-managing-privacy-extensions-00.txt
From: Ran Atkinson <ran.atkinson@gmail.com>
In-Reply-To: <233b01cbdef5$8e214550$aa63cff0$@com>
Date: Thu, 10 Mar 2011 07:10:05 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <25B3D469-F3DA-4A1D-A462-FEB71FA69485@gmail.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>
To: ipv6@ietf.org
X-Mailer: Apple Mail (2.1082)
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 12:08:51 -0000

On 10  Mar 2011, at 02:34 , Dan Wing wrote:
> Nobody wants it removed in corporate deployments, either.  

That statement is far too strong; it simply is not true.

> Consider for a moment an IPv6-enabled telephone,
> on the desk of a Very Important Person at a company, ...

(Laugh.  I don't believe in that untrue example for a second,
but thanks for the humorous start to my morning.  :-)

Oh, and consider that Caller-ID, usually including a full name,
is already widely deployed in many countries.  It is so
much simpler just to read the Caller-ID string off of the
telephone handset.  

If one wants to intercept traffic, it is MUCH simpler to intercept 
the SIP traffic -- which is never encrypted in real-world corporate 
deployments because that would make VoIP too hard to debug.

> If we don't have IPv6 privacy addresses, we will also soon
> see NAPT66 (with UDP and TCP port rewriting) in order to 
> achieve the same result as privacy addresses:  trying to 
> obfuscate which host is communicating.

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.

Cheers,

Ran