At Mon, 15 Apr 2002 12:24:36 +0200, Hesham Soliman wrote: > > 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. 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. 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. 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. I am also well aware that it is not just the IPv6 WG that has been chasing this weird idea of things walk like servers and quack like servers but are called something else. I disagree with the people chasing this idea in other WGs in those WGs, but there appear to be people chasing it here too, so I guess I need to disagree with it here too. 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. > So would you support a generic mechanism that does not require a > third party server? I mean if the DNS discovery was not limited to > the DNS, would that be a better approach? I'm just trying to > understand if the argument is: > > a. Just use DHCP, we don't want anything else, or > b. Let's not have a separate mechanism for each > server. > > If a) then I disagree, there has been good steps taken towards > stateless autoconfig in IPv6. I don't think we should mandate a > server-based discovery all the time. If b) then I can understand. I'm suggesting both, but for different reasons, and in neither case am I suggesting that we should get rid of all forms of stateless autoconfig in IPv6. (b) is an architectural argument with a philosphical component. (a) is because the Information Request mechanism in DHCP already provides exactly the necessary service, and I still have not received any good answer as to why the IPv6 WG needs to reinvent this wheel. > 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. > And it just happens that DNS is the one server that needs to be > discovered. As I've stated before, even if one were to assume for purposes of discussion that DNS is the only service that needs to be discovered today, I think that's unlikely to remain true in the future. In particular, I strongly suspect that NTP (well, some kind of time protocol) will be required to verify DNSSEC signatures. I am aware that some people don't think that end nodes will ever need to do that, but I think that those people are confused. For more information on this subject, please see the draft that Derek Atkins and I wrote about DNS threats and the extent to which DNSSEC can be used to combat them. > Maybe that's not a good enough justification for the draft, but I'm > failing to see any concrete side effects that would result from > using this extremely simple draft. Multiple mechanisms that do the same thing with no significant benefit from the choice are not harmless if they both have to be implmented. They cost in code size, program complexity, increased vulnerability to clever attacks, and so forth. In this case, since the mechanism being proposed is (IMNSHO) inferior to a mechanism that already exists, I don't see the point of the exercise. > Which is a usual problem with philosophical arguments. Not that I'm > underestimating the value of philosophical arguments. Glad there's something on which we can agree. :) --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] --------------------------------------------------------------------
