Date: Sat, 1 Dec 2001 15:42:11 +0200 (EET)
From: Pekka Savola <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| What I meant was, why use a mechanism that has no hierarchy?
There are two issues there, one is the suffix - and yes, once that gets
to be picked, it would probably be better if something more was added
(even using local.arpa). But right now there are more important issues
to consider than this.
The other one is internal hierarchy in the address label part (below)
| ip6.int does, ip6.arpa might be a bit trickier.
Those two, and local.arpa, are completely different beasts. local.arpa
is just a magic suffix that means "this data doesn't really live in the
global DNS at all, but we want to leverage off the existing DNS servers
to supply the data when we ask for it, so we need a domain name to tack
on the end of the key to make it obvious what we're doing".
| I wouldn't care if the way to
| encode prefixes used there would be copied under local.arpa.
I am guessing that no hierarchy was added there because of the wildcards.
That's not really a justification, wildcards will work (as well as they
ever do) when there is hierarchy in the names. That might even make
config fractionally easier here, but it doesn't really make a huge difference.
| This is
| after, local configuration knowledge, and it would be easier to restrict
| the visibility that way.
local.arpa is restricted by definition (it is never delegated anywhere from
the root (or .arpa) servers).
| 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.
Certainly using TXT would be even worse than the CFG as proposed. SRV
would be something a bit different I think (though it would be intersting
to contemplate whether it could be bent into serving this purpose).
What's been done though is just re-invent TXT and give it another name.
That separates out these uses from other uses of TXT (not that it probably
matters for these particlar domain names), but otherwise is no different.
| 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...)
| With IPv6, one does not *need* to set up DHCP server (as much as with
| IPv4).
That's certainly true.
| It's apparent that the work is concentrating on making it possible
| to do certain basic DHCP-like things without DHCP server.
Yes, but that's a bogus goal.
| 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).
| 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.
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
