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

[Brian Haberman <[e-mail]>]

Speaking only as a WG member...

On 6/9/10 5:22 AM, Fortune HUANG wrote:
> 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?
> 

I believe this type of functionality belongs in DHCPv6 and not in an RA
option (or extension to the PIO).  The complexity the User Class Option
allows is better managed in a centralized approach like DHCPv6.  It
conflicts greatly with the original intent of simplicity of SLAAC.

Regards,
Brian

> 
> Best regards,
> Fortune
> 
>  
> 
> -----Original Message-----
> From: Tim Chown [mailto:[e-mail]] 
> Sent: Tuesday, June 08, 2010 10:34 PM
> To: Fortune HUANG
> Cc: 'JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)'; [e-mail]
> 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:[e-mail]]
>> Sent: Tuesday, June 08, 2010 4:53 PM
>> To: Fortune HUANG
>> Cc: 'JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)'; [e-mail]
>> 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=
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------