On 13-aug-2007, at 17:38, James Carlson wrote:
For better or for worse, the notion of a subnet mask going along with an interface address is deeply ingrained in the way IP is implemented. Separating the two for no apparent reason is a bad idea.
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. 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. 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.
Now if we can manage for all that to happen correctly, why not finish the job and tell the host about the subnet size?
If you were to add an option to DHCPv6 to transfer routing-related data (including prefixes and default router addresses), you'd have to invent some way to keep the DHCPv6 server information in sync with the actual set of routers on the network. Otherwise, you're relying on manual configuration of the DHCPv6 server that's continuously tweaked to match the routers.
For that reason, I oppose adding this information to DHCPv6.
I can go along with that for the most part.
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.
There are two reasons that I can think of to have a DHCPv6 server assign addresses:
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)
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
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
