Dear Greg, On Thu, Aug 11, 2005 at 01:27:56PM +1000, Greg Daley wrote: > Dear Stig, > > Stig Venaas wrote: > >So far two principal solutions have been suggested, RAs and DHCP. If > >people want to work on solutions we could possibly look into both of > >these. > > > >Some issues have already been mentioned on this list. Another issue > >which was brought up in dhc wg, is that the policy is a host global > >config, not per interface. This might be an issue when you have > >multiple interfaces. This needs to be considered for both RAs and > >DHCP. > > It's unclear at the moment how a DHCP server on one link is able > to describe how to use addresses available on another interface > or link. > > Particularly, it's not clear how the DHCP server can have authority > to modify the previously advertised address state from another link, > where it isn't responsible for configuration. > > Given that the policy is based on per interface available addresses, > and the host will need to make a combination of these policies anyway, > there's little to be gained by assuming the DHCP server is all-knowing > about foreign addressing policies. > > So I don't see the "per-host" argument as convincing at all.
It seems we are discussing very different things here. You are talking of prioritizing the prefixes announced on the link(s) so that the host can use these to influence source address selection, right? In that case I agree that it makes sense to pass the priority along with the prefixes of course. The 3484 policy table however allows much more than that. It allows destination address selection in which case you want to have some preference among prefixes that are not prefixes for the link where the client is. 3484 also allows preference of IPv4 vs IPv6. That policy would be more awkward to pass in RAs, and isn't necessarily for one particular link. > >I have two problems with RAs. One is that all hosts on the link will > >get the same policy. The other is that I'm worried the policies may > >get large, and I'm not sure if it's a good idea to send relatively > >large RAs regularly to all the nodes on a link. > > The Cost in RA is actually completely subsumed by the existing > advertisement of Prefix Information Options, which may be > augmented (without size modification) by identifying the > preference of the particular prefix, for source address > selection policies. For preference amongst the prefixes on the link, yes. > It is worth noting, that in the DHC proposal, 24 bits of data: > (label, precedence, zone-index) are added which aren't present > in PIOs. But as I said, this does much more. E.g. the label is for destination address selection. You're comparing apples and oranges here. > There's an unused 32 octet field available (and another 5 unused > bits for flags) in each PIO, which are currently unused. > > So there's no on-the-medium additional cost. > > > > So the only issue is: Does it make sense to use RAs for distributing > the default source address preferences to hosts? > > While it may seem to be a good idea to have different preferences > proposed for each host, it's not actually very useful. > Hosts can ignore or override the preferences, which is why > the policy is described as a default policy in the DHC draft. I'm sure there are different views on that. I would like a site administrator to specify behaviour of the hosts in the site without having to manage each host separately. So I want hosts generally to use exactly the specified policy. This is also why I want to allow for different hosts on a link to be told to have different policies. Certainly there might still be ways for a host to override the policy though. > Considering that the advertised Valid and Preferred Lifetime values > for prefixes are per prefix and not per-host, if we're providing > routability and stability information to hosts, then the information > should likewise be per prefix (not per host). For prefix preference which you're talking about I agree. > In that case, I guess that PIOs (in RAs) are a good place for them, > just like the Valid and Preferred Lifetimes. > > If the mechanism is being used for some stealthy control of which hosts > should use which addresses on the link, I'm against it (since it's > unenforceable anyway). I'm also against it if the policy is aimed > at being used as a load sharing mechanism (since there are better ways > of achieving this). Neither of these are what I have in mind. For some possible uses of 3484, see http://www.nttv6.net/dass/ Might be good idea to discuss how to prioritize prefixes (and I assume source address selection) and uses for that, independently of what 3484 can solve and how that can be used. There is of course overlap. I would be interested to see how you want your solution to work wrt source and destination address selection. Do you imagine doing destination and interface selection first, and then use this to pick source address? Or do you want this in some way to influence destination address selection as well. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
