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

Tim Chown <tjc@ecs.soton.ac.uk> Tue, 08 June 2010 14:33 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
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 626C328C19C for <ipv6@core3.amsl.com>; Tue, 8 Jun 2010 07:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.485
X-Spam-Level:
X-Spam-Status: No, score=-1.485 tagged_above=-999 required=5 tests=[AWL=1.115, 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 rzy0wXxpXRQX for <ipv6@core3.amsl.com>; Tue, 8 Jun 2010 07:33:54 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id 6F86528C110 for <ipv6@ietf.org>; Tue, 8 Jun 2010 07:33:53 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o58EXc3D021451; Tue, 8 Jun 2010 15:33:38 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o58EXc3D021451
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1276007618; bh=FVXY8E4qw0hoV7IeZ5wLHF0QFzE=; h=References:In-Reply-To:Mime-Version:Cc:From:Subject:Date:To; b=qJRLk9y12VPpa4yEasXkj4S+2O5KS5gK3Or83rwGOYVtUMdsghHQhatwo2uc79i/p Pty9BwbZ5+9Sdq8SjpLa2si+kA6PpUcwbfMe7H8fjeRwSaUFusz8XvJHmX3hNe6M6R /+KzaN+JeBt5Uef6HB26Jy2RdRv4/KlgloCoxS6s=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP id m57FXc0540033964l5 ret-id none; Tue, 08 Jun 2010 15:33:38 +0100
Received: from cerf.ecs.soton.ac.uk (cerf.ecs.soton.ac.uk [152.78.69.39]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o58EXY4D003302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Jun 2010 15:33:34 +0100
References: <3296EED8CD39462B95E5E55E7146E5C8@china.huawei.com> <D0447273-CEE7-4645-935B-F633537D5C19@ecs.soton.ac.uk>
In-Reply-To: <3296EED8CD39462B95E5E55E7146E5C8@china.huawei.com>
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
Message-ID: <EMEW3|5da402bfe576fb1f400ffa376f8768e2m57FXc03tjc|ecs.soton.ac.uk|D0447273-CEE7-4645-935B-F633537D5C19@ecs.soton.ac.uk>
Content-Transfer-Encoding: quoted-printable
From: Tim Chown <tjc@ecs.soton.ac.uk>
Subject: Re: Question about SLAAC: how the host determines the prefixes allocated from different prefix pools
Date: Tue, 08 Jun 2010 15:33:33 +0100
To: Fortune HUANG <fqhuang@huawei.com>
X-Mailer: Apple Mail (2.1078)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=m57FXc054003396400; tid=m57FXc0540033964l5; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: o58EXc3D021451
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
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: Tue, 08 Jun 2010 14:33:56 -0000

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=
>