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

[Fortune HUANG <[e-mail]>]

 
Hi Brian,

Sorry for the late reply because I was on a bussiness trip yesterday.

It seems that we have two options here:
1) Assuming DHCPv6 is always available in the scenario where there are
multiple prefix pools for different services, just use DHCPv6 as you and
Shree said.
2) Assuming DHCPv6 may not be available in some scenario where there are
multiple prefix pools for different services, extend the RA in some way. 

{Brian: "The management of that registry would be chaotic.  There is good
reason why the User Class value is opaque.  Each network has its own set of
requirements and the aggregated requirements would overwhelm the registry."}

Your comment quoted above make sense to me. But I am not confident with the
assumption that DHCPv6 is always available in the scenario where there are
multiple prefix pools for different services, so I will still try to take
some more time to figure out how to extend the RA without such problems. I
would also appreciate it if someone could propose a feasible approach about
this and feed back to mailing list or to me.

Best regards,
Fortune


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Brian Haberman
Sent: Wednesday, June 09, 2010 11:13 PM
To: [e-mail]
Subject: Re: Question about SLAAC: how the host determines
theprefixesallocated from different prefix pools

On 6/9/10 9:01 AM, Fortune HUANG wrote:
> Hi Brian,
> 
> Thank you very much for your comments. 
> 
> With your comments, I realize that the User Class Option defined in 
> RFC 3004 allows much flexibility because the User Class value is an 
> opaque field and implementation specific. Without a centralized 
> control point, the value of the User Class can not be well maintained. 
> So I agree with you that the User Class Option is better managed in 
> the centralized approach like DHCPv6 and the User Class can not be 
> introduced to RA in the same way as defined in RFC 3004.
> 
> So I think if we would like to extend the RA or PIO option, we would 
> need unified or global values for the service types (not using the 
> User Class in this case). That is to say, the service types associated 
> with the prefix should be allocated by IANA. What do you think? Would 
> this approach be better?

The management of that registry would be chaotic.  There is good reason why
the User Class value is opaque.  Each network has its own set of
requirements and the aggregated requirements would overwhelm the registry.

In this type of scenario, I would prefer to have networks needing this type
of functionality to stick with the proven technology.

Regards,
Brian

> 
> Thanks again!
> 
> Best regards,
> Fortune
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Brian Haberman
> Sent: Wednesday, June 09, 2010 7:45 PM
> To: [e-mail]
> Subject: Re: Question about SLAAC: how the host determines the 
> prefixesallocated from different prefix pools
> 
> 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
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------