> > OK, but we still have two options in IPv6 for address > > autoconfiguration: Stateless and Stateful. I don't understand > > why we shouldn't allow the option for _real_ stateless > > autoconfig in IPv6. By 'real' I mean, we can't claim true > > stateless autoconfig when a crucial service like the > > DNS still requires a server. > > Ok, so let's take this a piece at a time, with the > understanding that > I'm not trying to pick on Hesham here. I recognize that Hesham is > representing a point of view to which other members of the WG also > subscribe. To paraphrase Tom Paxton, I'll try to be kind > -- I expect > to fail miserably, but I'll try.
=> You've done well :) > > 1) What, precisely, does the term "stateless" mean in this context? > It suggests a belief that all the existing mechanisms > for telling a > host where to find DNS servers are keeping state recording which > server addresses they've reported to which hosts. That > sure isn't > the way that even "stateful" configuration (DHCPv4 with address > leasing) works with the ISC DHCP server that's running on my > network right now. => I understand. Perhaps stateful is used to refer to the fact that they keep a record of the DNS address. But I agree that it is not really accurate. > The distinction between "stateless" and "stateful" > configuration is > meaningful for address configuration, and the IPv6 stateless > address configuration mechanism is a good and useful thing. I do > not, however, see how the distinction applies to DNS server > discovery, and find attempts to use the term in this > context to be > more confusing than useful. => 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). 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. > > 2) What, precisely, does "server" mean in this context? DNS server? > DHCP server? What's a server, anyway? A node? A > program running > on a node? A well-known port to which one can send > certain queries > and from which one sometimes gets back useful answers? > > I submit that discussion on this topic to date has confused at > least two of these definitions. I also submit that, since the > discovery proposal we're discussing both uses a client/server > protocol (DNS) to discover something and is in fact intended to > discover a (DNS) server, the choice of terminology here > is poor at > best and (presumably accidently) obfuscatory at worst. => Believe it or not, I think we're in agreement. I was not referring to an entire node. > > To be clear (well, clearer): when I suggested using DHCP in order to > locate DNS servers, I meant that entities that wish to locate an > entity that functions in the server role of the DNS protocol when > contacted at UDP port 53 might well do so by issuing DHCPv6 > Information-Request messages and listening for relevant responses. > For the cases where the proposal you're talking about works at all, > the two are semantically equivilent except for details of well-known > port number, packet encoding, and the set of tricks used to > propagate > the queries and responses across routers. => 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. 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. > > FWIW, we have deployment cases where this draft makes > > a lot of sense and there is no alternative to it. > > Given that the Information Request mechanism already exists > in DHCPv6, > and is substantially identical to the DHCPINFORM mechanism which has > been part of the Draft Standard for DHCPv4 since 1997, I have a hard > time believing your statement if I take it literally, so I suspect > that you meant something else. => I've tried to explain above. Thanks, Hesham -------------------------------------------------------------------- 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] --------------------------------------------------------------------
