Iljitsch van Beijnum writes: > On 13-aug-2007, at 17:38, James Carlson wrote: > > There's a problem with that idea. There's no guarantee in any > > deployment that the DHCPv6 server is actually the definitive source of > > information about the prefixes that are on the link. Routers are > > supposed to be that source in IPv6 (via RAs), and DHCPv6 servers > > needn't also be routers. > > 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.
Not exactly. 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. You're right that the lists of addresses are administratively related to the prefixes, but they're not the same thing. In fact, it's possible for the two to be in different administrative hands -- one group responsible for routing, and the other for address assignment and configuration parameters. A modified DHCPv6 protocol that hands out prefixes and default routes (in order to subsume RA's role) will need to coordinate that _extra_ information for prefix length and lists of router addresses. This whole line of debate seems pointless to me. You need to support RS/RA if you're going to operate on any normal IPv6 network. Why bother trying to force that data into DHCPv6? It seems to be a desire to support a configuration that nobody would need to use. > I.e., the only way a host is going to be able to use the > address it got from the DHCP server, is if at least one router knows > to send packets for that address to the host in question. Yes. > The > traditional way for routers to know this is to make sure that the > addresses given to a host (through DHCP or other means) fall within > the (well, a) subnet configured on the router's interface that the > host connects to. That's right, but it's not required that any DHCPv6 server "owns" all of the addresses within any given prefix. > 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. > > Unlike > > IPv4, I think the DHCPv6 designers got this choice _right_. For the > > sake of consistency, should only be _one_ source of authoritative > > information, and for prefixes and routes on hosts, RAs are it. > > Well, if you want consistency, you'll have to look elsewhere, because > having DHCPv6 servers tell hosts their addresses breaks exactly this > separation. I can almost agree with that. I think a better deployment is to use stateless address assignment with DHCPv6 Information Request. That way, the DHCPv6 servers need not have any address information, and the hosts can forge up addresses as needed. Having DHCPv6 servers supply addresses makes some sense to me in an environment where you have hosts with assigned, fixed addresses, and you use DHCPv6 to manage central control and renumbering. It makes less sense to me in more ad-hoc networks (where, oddly, DHCPv4 is commonly used). > 1. Because it's desireable for the host to have an address that's > based on information that the host itself doesn't know (for instance, > a hash based address for shim6 proxy operation) Yes. > 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. -- 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 --------------------------------------------------------------------
