On Sat, 1 Dec 2001, Robert Elz wrote: > | Why wouldn't this be done as with ip6.int or ip6.arpa? > > That's a better question, but the draft does say that "local.arpa" is > just a place holder until the actual domain is picked.
What I meant was, why use a mechanism that has no hierarchy? ip6.int does, ip6.arpa might be a bit trickier. I wouldn't care if the way to encode prefixes used there would be copied under local.arpa. This is after, local configuration knowledge, and it would be easier to restrict the visibility that way. > More importantly, the CFG RR design is not well done, DNS RR's that hold > lots of different data types, distinguished by something in the data itself > are almost always a very very very poor idea. There is no shortage of > DNS RR types - just assign a new RR type to each particular record that needs > to be stored, and then if you really need to be able to fetch them all at > once, define a meta-query that does that (but that's to be avoided if > possible). > > And yes, I note that the draft also says that the CFG RR design is also just > a placeholder... I think there was an argument by Rob Austein at IETF51 that TXT records not be used; I don't recall if he suggested to use SRV or invent your own. > A more significant comment might be that there doesn't seem to be much > advantage in using the DNS to store this kind of config info over using > DHCP (DHCPv6). If some central admin is going to have to set it all up > anyway, it is not really harder (in fact, it is generally much easier) > to set it up in a dhcp server, than a DNS server. Easier, because DHCP > servers group config info by topology, DNS servers group systems by admin > boundary. Config info much more often is related to topology. > > That is, I find it a little hard to believe in a scenario when a local > admin is going to be willing to configure lots of junk in the DNS, but > wouldn't be willing to configure it in DHCP instead. It isn't as though > either DNS or DHCP servers are hard to acquire - just about every reputable > server comes with one of each. There's one additional point to consider. DNS server is pretty much required; or so the draft assumes. Personally, for small sites, I disagree. With IPv6, one does not *need* to set up DHCP server (as much as with IPv4). It's apparent that the work is concentrating on making it possible to do certain basic DHCP-like things without DHCP server. 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. 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". -- 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] --------------------------------------------------------------------
