On Wed, Jul 27, 2005 at 09:00:00PM +0900, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote: > >>>>> On Sat, 23 Jul 2005 14:01:10 +0900 (JST), > >>>>> [EMAIL PROTECTED] said: > > > | Here is the first cut at an agenda for the IPv6 working group session at > > | the Paris IETF. Please review and send us comments, deletions, and > > additions. > > > Could you please give me a few minutes for following draft? > > > Title: Distributing Default Address Selection Policy using DHCPv6 > > Filename: draft-fujisaki-dhc-addr-select-opt-00.txt > > > As a result of a discussion at last IETF dhc wg, I need ipv6 wg > > support to move forward this draft. > > I've read the latest draft, but I'm afraid the document itself doesn't > help assess whether the ipv6 wg can support that or not, since it > mainly concentrates on the DHCPv6 specific issues. > > I believe what should be discussed in this group is the intended > scenarios (the "Practical Usage" section) described in this URL:
Yes, I believe the most important know is whether such an option is useful or not. So one question is how common it will be to have non- default policies. Another is how it might be autoconfigured. If a site has a large number of clients that needs a non-default policy, then some way of distributing that policy to the clients is needed. There are also some technical issues, but those can perhaps be discussed later. Mainly how to represent the different values like precedence, label, scopeid etc. 3484 doesn't really describe the datatypes in detail. E.g. zone-index in draft-fujisaki-dhc-addr-select-opt-00.txt is suggested to be one byte, which I'm not sure is sufficient. Also the label is a single byte which might be fine. Some implementations of 3484 seem to have long text strings as labels, but hopefully they could also cope with short numerical strings like "1" and "100". > > As I posted before, this draft describes the RFC3484 policy table > > distribution (please refer http://www.nttv6.net/dass). > > I've read this page, too. My current impression is that "I see some > point, but I'm not sure if it's enough for introducing a new DHCPv6 > option". > > Specifically, > > > Case1: IPv4 or IPv6 Prioritization > > I see this is a case where the automatic policy distribution may > help. But since the address selection by RFC3484 is much more > powerful than just selection between IPv4 and IPv6, I don't think this > can be a convincing usage if this is the only meaningful case. > > > Case2: ULA or Global Prioritization When using ULAs and globals together, I think you may want different rules depending on whether you have peerings with other sites using different ULA IDs or not. Stig > > Case3: Multicast Source Address Selection > > For these cases, using a non default policy table could resolve the > issue (and automatic policy distribution would help), but I personally > think this should be rather dealt with through a clarification for the > "default" selection rule, with the fact that site-local unicast > addresses were deprecated and ULAs are introduced. > > > Case4: Global and Closed Mixed Connectivity > > This may look a valid use case superficially, but people will actually > wonder why ISP2 needs (or can have) global (non ULA) addresses, or > even any IPv6 addresses, to begin with, if it's not connected to the > global Internet. And, for example, if the closed network uses ULAs > and we clarify the "default" address selection policy, we'll be just > happy with the clarified default policy (we may also need the new > '/54' allocation policy as well, though). Or, if ISP2 just uses > private IPv4 addresses, we'll just be happy even with the current > default rules. Unless the usage example answers to this natural > question, I'm afraid this will look artificial (and thus cannot be > convincing). > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > [EMAIL PROTECTED] > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
