Iljitsch van Beijnum writes: > On 11-aug-2007, at 1:39, Bernie Volz ((volz)) wrote: > > The configuration of addresses for an interface MUST NOT be tied to > > the > > configuration of prefix information for routing. > > I disagree. 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. 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. 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. > > Just because an interface > > has an address, does not mean that the system has any prefix > > information > > for a prefix that "contains" that address. > > Disagree here. How does it make sense to have an address on an > interface and no knowledge about what other systems are directly > connected to that interface? Note that "no knowledge" isn't the same > thing as "assuming /128". I don't agree with the latter all that much > either, but you still know SOMETHING in that case. All that you know from DHCPv6 is the address. > > And, a node should support both SLACC and DHCPv6 as "The two > > methods are > > complementary but not mutually exclusive." > > I'm sure there are cases where DHCPv6 is very useful, but _I_ don't > want it on my network. IPv6 specifications and implementations > without DHCPv6 have been around for the better part of a decade, so > requiring DHCPv6 now seems curious at best. In other words: DHCPv6 > should be optional. I think implementation of DHCPv6 can certainly be required by consumers, including the DoD. All they have to say is, "I don't care what's optional in the RFC; I just won't buy any gear that doesn't support this list of features, including DHCPv6." Deployment and use of it, of course, is up to individual network administrators, and is by no means required. Leino, Tammy writes: > Iljitsch, thank you for your comprehensive remarks. I think my mistake > was in believing an IPv6 router does not have to be configured to send > RAs, but the DHCPv6 server could serve the same purpose as the RAs. It > appears DHCPv6 was meant to supplement RAs. Exactly. > As an embedded developer, there is a lot of overhead in terms of code > space and memory requirements in the DHCPv6 protocol, particularly for > customers wishing to just distribute DNS servers. It would be nice if > all the configuration options of DHCPv6 had been added to RAs. This > way, we would save on memory. I think that's a mistake. First of all, listening to RAs is no more expensive than listening to DHCPv6 messages. If you really feel compelled to do so, then have your DHCPv6 implementation send RSes when setting up a new address, and listen to the RAs and store the prefixes where they're handy. Secondly, designing protocols to fit the limitations of today's hardware (or, worse, the _perceived_ limitations) is an error. Protocols last a long time, but hardware does not. Consider, for example, that IPv4 discussions were held over 30 years ago, when common small computers had just a few KB of memory. The skill in embedded implementation is in saving on memory where you can without compromising integrity of the external interfaces. Protocols last long enough that today's problems, unless they're intrinsic, ought to be taken with a grain of salt. And, yes, despite my current employer address, my background (for the past 20 years or so) has been in embedded systems as well. -- 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 --------------------------------------------------------------------
