At Tue, 16 Apr 2002 17:48:10 +0200, Hesham Soliman wrote: > > Ok, I should say that the functionality I'd like to see is the > ability to discover a DNS without relying on functional entities > other than the DNS. (not necessarily the entire node, but the server > itself, I think the term server is very clear and does not imply an > entire node).
Sorry, but it really is not clear enough to sift fact from confusion in some of the comments that people (not necessarily you) have made. Ok, a "server" isn't a whole node, good. But is it a process, or the entity listening to a particular well-known port, or a collection of subroutines that perform a particular set of conceptual functions? If, say, a single process is listening to both port 53 and to port 67, is that one server or two? > The point of the work is to limit the effects of third party node > failures on discovering the DNS. I.e. When I'm running a network > with a million user devices in it, I can either spend money to make > sure that my DHCP server is super reliable or, make sure that, at > least the very basic functions of the server, are done e2e. That is, > between the end host and the DNS. So if the DHCP server role and the DNS server role were being performed by the same "server", this would not be a problem. Right? > Believe it or not, I think we're in agreement. > I was not referring to an entire node. Ok. > Exactly, but propagating information across routers is _the_ issue > here. People were not comfortable with relying on multicast routing. > Also having an additional function in every router (relay agent) to > simply repackage this single packet didn't seem like a good > investment. Hence the chosen 'transport' mechanism in the > draft. The content could well look identical to a DHCP message, but > the issue is how to send this packet across the network. Right, and if I believed that DNS were the only non-addr-config data we'd ever need to worry about, I might buy the argument, but I don't. > The other issue is, if we assume that the node containing the DNS > will also act like a DHCP server (for the sake of receiving this > single message (DHCP INFORM)), how does that work in the presence of > other DHCP servers used for address configuration as well as > configuring other parameters? I've already claimed lack of deep > knowledge on DHCP, so there might be a pretty simple answer for > this, but I haven't heard it. Well, entities performing the server role of DHCP only answer Inform requests when (they think) they have something useful to say. The specific mechanism by which multiple entities could act in the DHCP server role on a single node is an implementation issue, but if you want an example, it appears (from the man page, I haven't tried it) that setsockopt(SO_REUSEPORT) would suffice on FreeBSD. Thanks, --Rob -------------------------------------------------------------------- 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] --------------------------------------------------------------------
