We're likely to see a lot of those small sites without a DNS server, run by unsophisticated users. Our recent experience with small IPv4 sites - SOHO behind a CPE box (router/NAT) - is that they are very likely to include a light-footprint, full-function, low-configuration DHCP server. Those sites are not very likely to include a DNS server.
In the IPv6 SOHO scenario, I see either using a distributed discovery/configuration mechanism in which each device in the SOHO network has to reach into the ISP network for configuration, or a stateless DHCPv6 server in the CPE box that entirely or mostly autoconfigures itself. In fact, I believe DHCPv6 would be even lighter weight than DHCPv4 in this scenario, exactly because of stateless autoconfig. The stateless DHCPv6 server, in the simplest scenario, could operate in a single-threaded, query-response mode, returning the same response with DNS server, domain name and search list to every client request. Based on our experience with seeing DHCPv4 deployed in <$100 CPE boxes, I would expect stateless DHCPv6 would find its way into SOHO devices, as well. I'm working on an implementation of stateless DHCPv6, so I can't give any running code results, yet. My intuition is that stateless DHCPv6 would be no more difficult to implement or require any more resources from the device in which it runs than ICMP. - Ralph At 05:29 PM 12/1/2001 +0200, you wrote: >On Sat, 1 Dec 2001, Robert Elz wrote: > > | There's one additional point to consider. > > | > > | DNS server is pretty much required; or so the draft > assumes. Personally, > > | for small sites, I disagree. > > > > Yes. That was more or less what I was saying - the hard part of this is > > to design something that works when there is no central database of any > > kind at all. As soon as you start assuming the existence of one, and > hence > > something (or someone) to maintain it, half the complexity goes away (or > > rather is hidden - "the administrator" simply makes it all work...) > >True. But consider -- a small site that doesn't even have a DNS server of >its own is, well, small. In most cases, it's no big deal configuring >stuff by hand in every system. With bigger sites, more centralized >structure is needed, like this. > >A problem here is that there are lots and lots of very small sites. >Practically, if there was no way of "automatically discover" required >information, renumbering would more a few steps more difficult. > > > | If DHCP server existed in the network -- sure, it would be ok to > put the > > | data there. But one of the points here is to avoid adding DHCP > server at > > | all. > > > > Why? There's nothing magic about DHCP servers that make them something > > to be avoided. Installing a DHCP server is mostly just a matter of going > > to your server's "what daemons do I run" facility, and enabling it. It > > isn't running the DHCP server that some people want to avoid, it is doing > > the centralised data administration. That's just as true for a DNS server > > as it is for a DHCP server. If you're going to collect and maintain the > > data anyway, whether it is distributed via DHCP or DNS isn't going to > bother > > anyone much. Or it wouldn't, if they really thought about it. (DHCP > > actually has a whole set of small advantages for things like this). > >DNS is a required part of working infrastructure. DHCP is not. Do we >want to make it that? I'd prefer there would be as few links in the >requirement chain as possible. > >Not that DNS is necessarily the best place to put this data in.. > > > | The real question is: "are all of these configurables so critical > that we > > | should mandate DHCPv6 server in every network which would like to > > | autoconfigure them?". > > | > > | IMO, the answer for at least some parts of the draft is "no, we > shouldn't > > | need DHCP for them". > > > > I agree with that. But the answer cannot be to require the same > > data served by the DNS instead. The replacement has to be to collect > > the data from a distributed system, with no central maintenance, just > > like IPv6 addresses are generated by the routers advertising prefixes, > > and the nodes generating the addresses. Or by a centralised server if > > the net prefers that method. It is the same kind of choice that needs > > to be permitted here, not just a choice of which particular centralised > > database to use. > >I basically agree -- but the "cost" (design, implementation, etc.) of the >system is much larger that way; and it'd most probably be more complex >too. > >Of course, this decision could be pushed off the hosts; for example, make >all of these things options in router advertisements, and define some >mechanisms how routers would get the data (from servers, from >configuration, ...). > >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to [EMAIL PROTECTED] >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
