Hi Greg/Stig, > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Greg Daley > Sent: Wednesday, August 10, 2005 11:28 PM > To: Stig Venaas > Cc: [email protected] > Subject: Re: Solutions for distributing RFC 3484 address selection > policies > > 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. > > > I have two problems with RAs. One is that all hosts on the link will > > get the same policy.
One thing is that in using DHCPv6, all DHCPv6 clients on the link will get the same policy. Also, IMO it wouldn't always be bad for all hosts on a link (DHCPv6 or otherwise) to 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. > > 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. > > There's an unused 32 octet field available (and another 5 unused > bits for flags) in each PIO, which are currently unused. Actually it's six unused bits in the Reserved1 field of the PIO, but who's counting? :) In the case of flags, it would seem in most cases one bit per rule would do (0=don't implement rule, 1=do implement rule... or something like this). In the cases where there is an option to implement the reverse of a rule (such as is required for rule #7 for source address selection (if it is implemented)), it seems two bits would be needed (00=don't implement this rule, 11=do implement this rule, 01=implement the reverse of this rule... for example). > > 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. > > 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). Agreed. > In that case, I guess that PIOs (in RAs) are a good place for them, > just like the Valid and Preferred Lifetimes. At least for setting prefix preference, yes RA PIOs are a good place for them. > 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). > > Greg > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
