David W. Hankins writes: > On Tue, Aug 14, 2007 at 08:54:13AM -0400, James Carlson wrote: > > > That may very well be, but if DHCP servers give out addresses, then > > > this particular can of worms is already open and you have to deal > > > with it. > > > > If they provide addresses (they needn't do so), then they need to be > > configured with lists and/or ranges of addresses to provide. They > > don't need to know about the full prefix extent, nor do they need to > > know the IP addresses of the operable IPv6 routers on the network. > > They effectively do, actually, one way or the other. The server has > to give out an address that is appropriate for the link to which the > client is attached,
If the DHCPv6 assigns addresses at all (as opposed to just providing configuration parameters), then it needs to be able to work within the prefixes assigned on the link. That's true. It needn't use *all* of the addresses possible within the prefix, and that's the configuration management part. > and it needs to be able to Confirm the use of > addresses, which it may not have allocated. That doesn't make sense to me. The DHCPv6 Confirm message is for confirming an address lease. If the server hasn't allocated the lease, then it _cannot_ confirm anything about the address and must Nak in response. If it does confirm addresses it hasn't allocated, then it's just broken. > - Have a list of all the 'link-address' fields that all > operating DHCPv6 relays will use to identify a link. I'm confused. Why would relays be confirming anything? > I think that you will find realistically, DHCPv6 servers will know > prefix lengths. None that I've worked with (including the WIDE server) seems to care. What's needed are assignment ranges, not prefixes. > > > Now if we can manage for all that to happen correctly, why not finish > > > the job and tell the host about the subnet size? > > > > Because we already have a perfectly good protocol to do that -- RAs > > already contain that information, so there's no need to duplicate it. > > Surely, there must also be some need to perpetuate two protocols, > other than to simply perpetuate the need not to duplicate their > contents? If you're going to deprecate DHCPv6 for address assignment and fold it into the RA mechanism, then I'd be (somewhat weakly) in favor of that. If you're just going to duplicate things, then I'm very much opposed. > > > 2. For authentication, authorization and control. I.e., as an ISP, I > > > want to know which IPv6 belongs to which customer. The interesting > > > part here is that it's not necessary for the DHCPv6 server to come up > > > with the address. What we need is that some central server learns > > > about all the addresses. The crucial difference here is that handing > > > out addresses has the potential for routing problems, while learning > > > addresses that the host got through other means (probably stateless > > > autoconf) is just as useful but without the potential for trouble > > > > That sounds like IPv4 thinking to me. If I were an ISP, I'd be > > handing out customer prefixes, not addresses. > > Even if you delegate a prefix, you still need to know your customer's > address so that you might route packets to them. I don't understand that. If you delegate a prefix, then you route to the prefix -- best match. Why would you care about individual addresses within the prefix? -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
