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

From: "Dave Thaler" <[email-masked]>
Date: Sat, 19 Oct 2002 16:22:10 -0700

Just trying to catch up on email... a few comments below.
I've already seen other people answering most questions in the
same way I would, so (as another individual who supports this 
draft going forward) I'll concentrate on responding to other
points.

Margaret writes:
> I think that it should be required (a MUST) that nodes that 
> implement this specification provide a method to override the 
> default values manually.

I support this suggestion.  (Others might suggest removing 
the word "manually".)

Pekka writes:
> Options a) - c) should be sufficient to describe how the routing
system
> will get the information.  Perhaps it should be reworded to be
something
> like:
> d) Developing an "announcement" protocol [...]
>    [...].  However, the three first mechanisms should
>    cover the necessary techniques sufficiently for most cases.

I would support this suggestion as well.

Jonne writes (responding to Pekka):
> I do not really see what harm would three addresses do. You may have
> networks that would have only one DNS server (small business or a home
> user with for a reason or another his own DNS server). However, in
cases
> like ISPs or bigger businesses there may be multiple DNS servers
> configure. I believe this is the case even now.

Correct.  Three was chosen based on common practice in the many places
in the industry.  While it's true that if the first one fails, that
it's unlikely the second one will succeed (due to there really being
no DNS server at all), using multiple addresses is important so that
when ones do exist, the host can fail over to a second server more
quickly than routing converges.  More on this below.

Rob writes:
> 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.

The above objection appears to be against anycast addresses.  This
draft is about *unicast* addresses, not anycast addresses.  Hence, no
such
change can take place.  The use of 3 unicast addresses is specifically
to enable the resolver to keep track of which of the name servers it is
using are performing properly.

-Dave

--------------------------------------------------------------------
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: Rob Austein <[email-masked]>
Date: Sun, 20 Oct 2002 14:43:04 -0400

At Sat, 19 Oct 2002 16:22:10 -0700, Dave Thaler wrote:
> 
> Rob writes:
> > 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.
> 
> The above objection appears to be against anycast addresses.

Sorry, wrong, and I think we had this discussion already.

> This draft is about *unicast* addresses, not anycast addresses.
> Hence, no such change can take place.  The use of 3 unicast
> addresses is specifically to enable the resolver to keep track of
> which of the name servers it is using are performing properly.

And what happens if all three servers fail?  Bringing up a new name
server is not hard, but if I understand you correctly it won't help to
bring up a new server because there's no way to switch over.

Perhaps the IPv6 WG should leave DNS operational issues to the WG
that's chartered to deal with them and instead spend IPv6 WG time on
issues that have something to do with IPv6 (eg, figuring out how and
if address scopes other than global and link-local are going to work)?
--------------------------------------------------------------------
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]
--------------------------------------------------------------------