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:t...@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:t...@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= >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
