Hi all, few comments below
> -----Original Messages ----- > From : Rob Austein [mailto:sra+ipng@;hactrn.net] > My main objection was and remains that this mechanism, if used, moves > state away from the endpoints and into the network in a way that > cripples the resolver's ability to keep track of which of the name > servers it is using are performing properly, since the binding between > any particular well-known-address and the name server behind it might > change at any time and since there is no mechanism by which the > resolver can find out that such a change has taken place. > [Luc] I agree with that point that's why I'd prefer that hosts know not-shared unicast adresses of the recursive server (thanks to Rob for definition reminders) those hosts use. > From : Pekka Savola [mailto:pekkas@;netcore.fi] > I must chime in to say I dislike this approach a bit, but it could be > salvageable. (Though, I must admit I like an option in RA's more..) > > Most of all, I dislike using *3* well known site local addresses. One > should suffice just fine. Remember that this mechanism, at > least in my > eyes, is intended for *bootstrapping* only. After there is > something that > works, one could use some other mechanism (e.g. a DNS lookup :-) to > discover *real* DNS server addresses and ignore the site > local. It seems > to me that _3_ addresses just triples delays (5-10 seconds > each, per DNS > lookup?) if none of those have been configured in the site. > [Luc] That kind of solution seems interesting. Well-known site-local addresses could help to discover other adresses of recursive servers. But I do think that a lot of work is still needed in that case : - which address to advertise if recursive servers defend several adresses? - how to discover and then choose Domain Names of recursive servers? > In addition, I greatly dislike section 5.2, that is DNS > forwarding between > sites. If we have to implement site-border router behaviour, > let's *NOT* > require it in every cheapo 50$ DSL router. [Luc] That is one of the most awkward point. That draft suppose that any equipement used as a router at site borders must have a DNS relay function (for example: DSL routers, Mobile Phones if Internet Access is shared.) Finally I had found no answer if such a DNS relay breaks DNSSec solutions, I may be another issue. > -----Message d'origine----- > De : Margaret Wasserman [mailto:mrw@;windriver.com] > The document states: > > "Thus, it is recommended to implement also other mechanisms for > overriding this default, for example: manual configuration, L2 > mechanisms and/or DHCPv6." > > I think that it should be required (a MUST) that nodes that > implement this specification provide a method to override the > default values manually. [Luc] If other mechanisms are not required that will impose to deploy such solutions (= to integrated those 3 site-local addresses in a lot of DNS and routing system even if other solutions are available) inside our networks to allow the use of devices that only support the use of those 3 well-known site-local addresses. I definitively prefer to mention: "Thus, other mechanisms MUST be implemented for overriding this default, for example: manual configuration, L2 mechanisms and/or DHCPv6..." > > The document should also specify whether the default DNS addresses > will or won't be considered part of the DNS server list when DNS > server addresses are configured via other means. For example, if > a host receives a single DNS server address via DHCP, will it > fall-back to using these well-known addresses if the DNS server > at the DCHP-configured address fails to respond? [Luc] I agree, this must be clarified. > From : [EMAIL PROTECTED] [mailto:juha.wiljakka@;nokia.com] > as an individual I want to give my full support for this draft. > > The main point is that to make IPv6 deployed *now*, we really > need a mechanism for DNS discovery. I am very much afraid > that if we now wait for the perfect solution, it will come > all too late. > > However, it is fine for me that better / more robust > mechanisms are being developed, but let's make this (and > IPv6) happen now. > [Luc] I do beleive that we must be sure that any solution would not impose strong impact on future solutions. To my mind, some issues are still not resolved. But I do share your point that we do need a mechanism ;+) -------------------------------------------------------------------- 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] --------------------------------------------------------------------
