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

Arifumi Matsumoto <> Mon, 12 July 2010 08:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A838D3A69A8 for <>; Mon, 12 Jul 2010 01:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.663
X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aQuBVoLdTqyP for <>; Mon, 12 Jul 2010 01:57:10 -0700 (PDT)
Received: from ( [IPv6:2001:fa8::25]) by (Postfix) with ESMTP id 4D10E3A6813 for <>; Mon, 12 Jul 2010 01:57:10 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.3) with ESMTP id o6C8vF4J024356; Mon, 12 Jul 2010 17:57:15 +0900 (JST) (envelope-from
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Arifumi Matsumoto <>
In-Reply-To: <>
Date: Mon, 12 Jul 2010 17:57:14 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <0f4301cb1ec0$297b4650$7c71d2f0$@com> <> <> <EMEW3|f7226135d6b882ba63bf54b974a62f41m6B8Eo03tjc||> <> <>
To: Aleksi Suhonen <>
X-Mailer: Apple Mail (2.1081)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 ( []); Mon, 12 Jul 2010 17:57:15 +0900 (JST)
Subject: Re: [addr-select-dt] Proposed default policy table
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPv6 Address Selection Design Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Jul 2010 08:57:11 -0000

Hi Alex,
thank you for comments.

If I understand it correctly, your comments are about implementation.
It's okay if we decide this merging issue is up to implementation.
But, we are still trying to fix a spec for merging.

Moreover, this time, we've almost decided to separate non-merging-capable
mechanism from merging-capable one. So, why not fix it first ?

On 2010/07/12, at 17:34, Aleksi Suhonen wrote:

> 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
> _______________________________________________
> addr-select-dt mailing list

Arifumi Matsumoto
  Secure Communication Project
  NTT Information Sharing Platform Laboratories