>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.
Why would you then assume that an RA on one link could do any more? It too would be restricted to providing policies JUST FOR THAT LINK. I think that's likely all we'd want DHCPv6 to do -- only provide the policies associated with that link? - Bernie > -----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: ipv6@ietf.org > 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. 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. > > 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). > > 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). > > Greg > > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
