RE: Question about SLAAC: how the host determines the prefixes allocated from different prefix pools

Fortune HUANG <fqhuang@huawei.com> Wed, 09 June 2010 09:25 UTC

Return-Path: <fqhuang@huawei.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 4B6B228C0F1 for <ipv6@core3.amsl.com>; Wed, 9 Jun 2010 02:25:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.694
X-Spam-Level:
X-Spam-Status: No, score=0.694 tagged_above=-999 required=5 tests=[AWL=-1.411, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 YaetuAOnjvb5 for <ipv6@core3.amsl.com>; Wed, 9 Jun 2010 02:25:07 -0700 (PDT)
Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B103428C0EC for <ipv6@ietf.org>; Wed, 9 Jun 2010 02:25:06 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3Q00IN0Q1W7G@szxga05-in.huawei.com> for ipv6@ietf.org; Wed, 09 Jun 2010 17:22:44 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3Q0064FQ1VQB@szxga05-in.huawei.com> for ipv6@ietf.org; Wed, 09 Jun 2010 17:22:43 +0800 (CST)
Received: from h36145c ([10.70.39.65]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3Q00GNTQ1V9R@szxml06-in.huawei.com> for ipv6@ietf.org; Wed, 09 Jun 2010 17:22:43 +0800 (CST)
Date: Wed, 09 Jun 2010 17:22:43 +0800
From: Fortune HUANG <fqhuang@huawei.com>
Subject: RE: Question about SLAAC: how the host determines the prefixes allocated from different prefix pools
In-reply-to: <EMEW3|5da402bfe576fb1f400ffa376f8768e2m57FXc03tjc|ecs.soton.ac.uk|D0447273-CEE7-4645-935B-F633537D5C19@ecs.soton.ac.uk>
To: 'Tim Chown' <tjc@ecs.soton.ac.uk>, "'JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)'" <shrinivas_ashok.joshi@alcatel-lucent.com>
Message-id: <E161C74C754340CCA64D594BAC5E18D3@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: AcsHF6L428E5jl5jSkm2NpiUUBEpjQAlnhDA
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: Wed, 09 Jun 2010 09:25:08 -0000

Hi Tim and Shree,

I am not sure if the policy table is applicable for selection of the
prefixes allocated from different prefix pools for different service types,
because the service type is a kind of property of each prefix, while "the
Policy Table is a longest-matching-prefix lookup table, much like a routing
table"(see in RFC 3484). 

In DHCPv6, the problem seems to be solved by the User Class Option. The User
Class option "is used by a DHCP client to optionally identify the type
   or category of user or applications it represents. " (see in RFC3004).

So, a potential solution for RA is to carry the User Class in the RA
message. Maybe we can consider to extend the Prefix Information Option to
include the corresponding user class(e.g. service type) or define a new
option for the binding of the prefix and its user class. What do you think?


Best regards,
Fortune

 

-----Original Message-----
From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] 
Sent: Tuesday, June 08, 2010 10:34 PM
To: Fortune HUANG
Cc: 'JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)'; ipv6@ietf.org
Subject: Re: Question about SLAAC: how the host determines the prefixes
allocated from different prefix pools

So if you look at section 10 of RFC3484 you'll see some examples of how the
policy table can be used.   Where the table is stored will be implementation
specific, but the behaviour should be consistent.   You may (or may not)
find the default rules achieve what you need.

At the moment there's no way to distribute the policy table within a site,
which is why there's been some analysis of this (see
draft-ietf-6man-addr-select-considerations-00) and a DHCPv6-based solution
proposed (see draft-fujisaki-dhc-addr-select-opt-09).    Until such a
mechanism is available, you need to manually edit the table or include the
correct/desired table in whatever system/method you use to distribute
configurations to managed devices in a site.

Tim
 
On 8 Jun 2010, at 10:30, Fortune HUANG wrote:

> Hi Tim,
> 
> I don't know much about RFC3484, but do you mean that the STB in my 
> example can choose the expected prefix/address via the Policy Table?
> What is in the Policy Table and how to configure it? Manually (maybe 
> not acceptable for SLAAC case) or automatically?
> 
> Thanks!
> 
> Best regards,
> Fortune
> 
> 
> -----Original Message-----
> From: Tim Chown [mailto:tjc@ecs.soton.ac.uk]
> Sent: Tuesday, June 08, 2010 4:53 PM
> To: Fortune HUANG
> Cc: 'JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)'; ipv6@ietf.org
> Subject: Re: Question about SLAAC: how the host determines the 
> prefixes allocated from different prefix pools
> 
> 
> On 8 Jun 2010, at 09:44, Fortune HUANG wrote:
> 
>> 
>> I don't have any preference to use RA over DHCPv6, but I would be 
>> grateful if you could tell me the guidance to decide whether to 
>> deploy SLAAC or DHCPv6.
>> Obviously, SLAAC can not work as expected in the scenario in my 
>> example. So this seems be to a restriction to the deployment of SLAAC 
>> at least for the time being (any possibility for the SLAAC/RA to 
>> support multiple prefix pools for different services in the future?).
>> 
> 
> 
> In principle if each prefix is used with a service that is served from 
> that prefix, then if the device implements RFC3484 address selection your
> multi-addressed hosts should use the correct source addresses.    The
device
> would prefer the longest matching prefix.    It's also possible to use
> policy tables with address selection to influence address selection 
> decisions.
> 
> Note though that RFC3484 has some open issues that are hopefully to be 
> resolved with an update soon (many implementors have already reflected 
> these updates in their products) but also that at least one major
operating system
> (Mac OSX) as yet has no support for the feature.   A method to distribute
> policy tables (by DHCPv6) is also on the table.
> 
> Tim=
>