Subject: RE: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver"

From: [email-masked]
Date: Thu, 17 Oct 2002 17:11:36 +0300

Hi all,

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.

Best Regards,
	         -Juha W.-

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "BELOEIL Luc FTRD/DMI/CAE" <[email-masked]>
Date: Thu, 17 Oct 2002 18:18:49 +0200

Hi all, 

few comments below

> -----Original Messages -----
> From : Rob Austein [mailto:[email-masked]]
> 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:[email-masked]]
> 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:[email-masked]]
> 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-masked] [mailto:[email-masked]]
> 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 ;+)

---

From: "BELOEIL Luc FTRD/DMI/CAE" <[email-masked]>
Date: Mon, 21 Oct 2002 14:33:29 +0200

To my mind, this draft is a simple and efficient way to pre-configure
one's network. Thus I'd prefer to consider it as a way to introduce a
"by-default manual configuration" in my devices but not a hard coded
solution that I could not change easily.

I understand that 3G networks and small sheap devices would have full
benefit of such a mechanism. But in other scenarii, that could introduce
pb:
- the draft impose to fixe 3 addresses in any network (one disagrees see
below)
- the draft impose to introduce those addresses in the routing system
- the draft impose to use site-local address whereas sites and site
borders are not clearly idendified / understood (?).

Luc

> From : Robert Elz [mailto:[email-masked]]
> Date : Mon, 21 oct 2002 12:45
> 
> The truly big problem with this draft is that it is usurping address
> assignments that have already been made elsewhere (I'll reply to a
> different message and make that point - once more).
> 
> kre
>

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 Oct 2002 17:42:52 +0200 (CEST)

> Those are two different things. dns-resolver discovery is to be used
> to locate a DNS resolver/server in last resort when no other information
> for finding this server is available.

Reading the document I don't see a separate step where the
DNS resolver/server is located. Instead I see that as a last
resort DNS queries are sent to a well-known site-local unicast
address.

> LLMNR (at least to my understanding) is to be used
> in last resort when the information had not been found in the DNS maps
> (meaning you already have found a DNS server/resolver).

As I understand the intent one goal is for LLMNR to work 
on a network consisting of just a few hosts, i.e. there might not
be any router or DNS resolver.
In that case a likely LLMNR usage end up being that 
when resolving host names as a last resort when DNS didn't return 
an answer, then use LLMNR.

Thus I can't tell which of these last resorts should be the last one.

> I thought that the IETF was in the business of specifying protocols,
> not how people should implement them nor how people should
> use them.
> The best we can do here is to providing guidelines like
> "use it only under those circumstances if you don't want to get hurt"

I think that specifying protocols and folks implementing them
is a bad idea unless the result is actually operationally useful.

Thus ignoring operational issues as you seem to advocate 
doesn't make for quality IETF standards.

---

From: [email-masked]
Date: Fri, 25 Oct 2002 00:10:07 -0700

Hi Robert,

> -----Original Message-----
> From: ext Robert Elz [mailto:[email-masked]]
> This is the "we need a solution today, it doesn't matter if it is a
> crappy solution, we have to have something so we can pretend we have
> done all of the work" argument.   Some of us are not missing this at
> all...

Sorry to be a bit unclear. I didn't mean that we should pick a crappy solution. 
However, if we have a good _enough_ solution (which I believe we have) we shouldn't look for the "Holy Grail" of perfection. To my understanding, they guys writing the draft have done a good job of (at least trying of) doing all the work. 

Cheers,

Jonne.