Re: [addr-select-dt] Proposed default policy table

Aleksi Suhonen <Aleksi.Suhonen@tut.fi> Mon, 12 July 2010 08:34 UTC

Return-Path: <Aleksi.Suhonen@tut.fi>
X-Original-To: addr-select-dt@core3.amsl.com
Delivered-To: addr-select-dt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7828C3A6902 for <addr-select-dt@core3.amsl.com>; Mon, 12 Jul 2010 01:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 DgXq4iu9hJ1e for <addr-select-dt@core3.amsl.com>; Mon, 12 Jul 2010 01:34:47 -0700 (PDT)
Received: from mail-gw2.cc.tut.fi (mail-gw2.cc.tut.fi [130.230.160.16]) by core3.amsl.com (Postfix) with ESMTP id 294993A690A for <addr-select-dt@ietf.org>; Mon, 12 Jul 2010 01:34:46 -0700 (PDT)
X-AuditID: 82e6a010-b7c01ae0000009dc-25-4c3ad3ac11d2
Received: from mail2.tut.fi (mail2.tut.fi [130.230.162.20]) by mail-gw2.cc.tut.fi (Symantec Brightmail Gateway) with SMTP id 76.37.02524.CA3DA3C4; Mon, 12 Jul 2010 11:34:52 +0300 (EEST)
Received: from [130.230.52.51] (halli.atm.tut.fi [130.230.52.51]) by mail2.tut.fi (Postfix) with ESMTP id 256BEA7EF9 for <addr-select-dt@ietf.org>; Mon, 12 Jul 2010 11:34:52 +0300 (EEST)
Message-ID: <4C3AD3AC.5050405@tut.fi>
Date: Mon, 12 Jul 2010 08:34:52 +0000
From: Aleksi Suhonen <Aleksi.Suhonen@tut.fi>
Organization: Tampere University of Technology / Department of Communications Engineering
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4
MIME-Version: 1.0
To: addr-select-dt@ietf.org
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com> <4C3A5931.40709@tut.fi> <6750C85E-1FE7-4C80-A4DE-C1195115FA0B@ecs.soton.ac.uk> <EMEW3|f7226135d6b882ba63bf54b974a62f41m6B8Eo03tjc|ecs.soton.ac.uk|6750C85E-1FE7-4C80-A4DE-C1195115FA0B@ecs.soton.ac.uk> <910AF3E6-1632-480B-9482-FB9572355576@nttv6.net>
In-Reply-To: <910AF3E6-1632-480B-9482-FB9572355576@nttv6.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQxEjes=
Subject: Re: [addr-select-dt] Proposed default policy table
X-BeenThere: addr-select-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Aleksi Suhonen <Aleksi.Suhonen@tut.fi>
List-Id: IPv6 Address Selection Design Team <addr-select-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/addr-select-dt>
List-Post: <mailto:addr-select-dt@ietf.org>
List-Help: <mailto:addr-select-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jul 2010 08:34:48 -0000

On 07/12/10 07:38, Arifumi Matsumoto wrote:
>> I have one other topic to add which I can't remember whether I posted about recently or not, so apologies if I'm repeating myself.
>>
>> In undertaking some work recently on router-based hints for address selection, we found that we could improve address selection behaviour for hosts by using a new ICMP-based message to query a router or route server for an ordered list of address pairs to use for given candidate addresses.  The issue that came up was that if the host were to cache the result, and we chose to cache it within the RFC3484 policy tables, can we change/augment the current syntax/format to accommodate that?
>
> That approach also should have an issue of policy merge/conflict.
>
> When we think about merging process, we may have to think about this
> kind of approach, if we think it looks like some advantages in merging.

The Linux Way of recent days seems to be to replace /etc/<software>.conf 
with /etc/<software>.d/*.conf so in Linux specifically you could 
implement it like this:

/etc/gai.conf:
1. default rules that can be overriden
2. include instruction for /etc/gai.d/*.conf
3. system wide rules that can't be overriden

And then your address selection policy update daemon(s) would update 
their own file(s) in /etc/gai.d/ safely.

I don't have a good understanding on how other operating systems have 
implemented RFC3484 so I can't comment how universal this would be.

-- 
	Aleksi Suhonen
	Department of Communications Engineering
	Tampere University of Technology