Re: addrsel: privacy addresses within/out of a site
Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> Mon, 03 January 2011 10:08 UTC
Return-Path: <ipng@69706e6720323030352d30312d31340a.nosense.org>
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 94B4628C10E for <ipv6@core3.amsl.com>; Mon, 3 Jan 2011 02:08:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.515
X-Spam-Level:
X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
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 vmbJoAuvvOWU for <ipv6@core3.amsl.com>; Mon, 3 Jan 2011 02:08:27 -0800 (PST)
Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id BCAC028C0FE for <ipv6@ietf.org>; Mon, 3 Jan 2011 02:08:27 -0800 (PST)
Received: from 182-239-157-145.ip.adam.com.au ([182.239.157.145] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1PZhN2-0005Hp-Ny; Mon, 03 Jan 2011 20:40:32 +1030
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 0AED83B335; Mon, 3 Jan 2011 20:40:32 +1030 (CST)
Date: Mon, 03 Jan 2011 20:40:31 +1030
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: Pekka Savola <pekkas@netcore.fi>
Subject: Re: addrsel: privacy addresses within/out of a site
Message-ID: <20110103204031.0c3589b7@opy.nosense.org>
In-Reply-To: <alpine.LRH.2.02.1101031151250.23654@netcore.fi>
References: <alpine.LRH.2.02.1101031151250.23654@netcore.fi>
X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu)
X-Location: Lower Mitcham, South Australia, 5062
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
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: Mon, 03 Jan 2011 10:08:28 -0000
Hi Pekka, On Mon, 3 Jan 2011 11:51:38 +0200 (EET) Pekka Savola <pekkas@netcore.fi> wrote: > Hi, > > Operational input: when discussing the use of RFC4941 (privacy) addresses with > our LAN/workstation admins, it seemed as if there would be great benefit from > being able to specify an RFC3484 rule which would in essence say: > > "do not use privacy addresses when communicating inside the site [a set of > designated destination prefixes], use it by default otherwise" > I'd be curious what the benefits are. The only reason I could think of as to why to do this is to be able to associate internal application access logs with internal hosts. At face value that sounds useful, however if you really care about auditing application access and use, it isn't the hosts you need to worry about, but the people behind them - and they can usually easily change hosts. So I think those applications should be using proper AAA to identify the user, rather than using IPv6 host identifiers as very poor substitutes for user identities. > I don't think this is possible today because rfc3484 policy table only allows > matching by prefixes, not by address type. > > Has this come up in discussions / has anyone else thought about this? > Regards, Mark.
- addrsel: privacy addresses within/out of a site Pekka Savola
- Re: addrsel: privacy addresses within/out of a si… Mark Smith
- Re: addrsel: privacy addresses within/out of a si… Pekka Savola
- Re: addrsel: privacy addresses within/out of a si… Brian E Carpenter
- Re: addrsel: privacy addresses within/out of a si… Pekka Savola
- Re: addrsel: privacy addresses within/out of a si… Mark Smith
- RE: addrsel: privacy addresses within/out of a si… Suresh Krishnan
- Re: addrsel: privacy addresses within/out of a si… Arifumi Matsumoto
- Re: addrsel: privacy addresses within/out of a si… Bob Hinden
- Re: addrsel: privacy addresses within/out of a si… Fernando Gont