Subject: Re: Proposed IPv6 DNS Discovery Requirements

From: Rob Austein <[email-masked]>
Date: Wed, 01 May 2002 02:44:35 -0400

At Tue, 30 Apr 2002 14:47:20 -0700, Bob Hinden wrote:
> 
> The first set of sections (1-8) does not specify the use anycast or 
> multicast, only unicast using three well know addresses.

Yes, but....

From the client's point of view, the practical difference between a
well-known unicast address and an anycast address is almost
non-existant, other than removal of the can't use as source address
restriction that folks are already talking about elsewhere in this
thread.  Using well-known unicast addresses still moves knowledge of
the server location into the routing system.  Using well-known anycast
addresses still leaves the client unable to take any useful recovery
action if the server location mechanism has returned answers that are
not useful.

Basicly, take all my ranting about service discovery via anycast
address over the last few days, apply s/anycast/well-known unicast/g
and almost all of it will still parse.  That being the case, I assume
that you're no more interested in reading all that again than I am in
sending it all again, so I won't.

I am still fairly skeptical about the existance of a real need for the
service provided by level 1 compliance, given its limitations (some of
which I've commented on, some of which are commented on in the draft).

Finally, I would urge folks to read RFC 1535 then go back and read
section 3.2 of the draft.  Inferring DNS search paths from site names
is dangerous.  It's not too bad if one takes reasonable precautions,
but the draft would have to spell out those precautions (see the RFC).

> Hope you enjoyed your coffee.

The first cup of coffee recapitulates phylogeny.

--------------------------------------------------------------------
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: Steve Deering <[email-masked]>
Date: Wed, 1 May 2002 18:12:03 -0700

At 10:04 AM -0400 4/30/02, Rob Austein wrote:
>Perhaps this week's version of the proposed solution for this is something
>that walks and quacks like an anycast route but is called something else
>so that you can use it as a source address.

Rob,

No, "this week's" version of the proposed solution is to use three well-
known, site-local unicast addresses.  The difference between a unicast
address and an anycast address is that an anycast address is shared by
more than one node (or, more accurately, more than one interface),
while a unicast address is not.  The prohibition against using an
anycast address as a source address is due to the fact that multiple
components of the IP architecture (v4 or v6) assume that a source
address belongs, for a non-negligible length of time, to exactly one
node, and those components may break in circumstances where that
assumption doesn't hold.  This is not a new rule -- it has always
been forbidden to use multicast addresses as source addresses, for
the same reason that they cannot be trusted to belong to only one node.

>I don't really care either way, it's still an anycast route in all
>but name.

No, it's a host route.  Host routes are supported by all IP unicast
routing protocols (I think), and have been used for nigh-on 20 years,
long before the term anycast was coined.  To label all use of host
routes as "anycast" is more likely to obfuscate than clarify what's
what's going on.

At 11:28 PM -0400 4/29/02, Rob Austein wrote:
>[*] Or two, or three, or whatever small fixed number of anycast
                                                         ^^^^^^^
                                                         unicast

>addresses you choose to allocate, and to date I haven't seen an
>explanation of how servers anycast::1, anycast::2, and anycast::3
>are supposed to sort out which one gets which anycast address without
>some kind of coordination mechanism that either involves yet another
>new protocol or something that quacks like manual configuration.

Manual configuration is exactly what is being proposed, at least to
start with.  Instead of manually configuring a database in an
intermediary with the addresses of three DNS servers, you configure
the three DNS servers themselves, thus eliminating an unnecessary
intermediary.

Eventually, it would be nice to fix the DNS service to not insist on
using the destination address of a query as the source address of a
reply, at which point any of the three addresses could also be an
anycast, to lift the arbitrary limit of three DNS servers available
for use by plug-and-play clients within a site.

Steve

---

From: Bob Hinden <[email-masked]>
Date: Thu, 02 May 2002 14:44:52 -0700

Rob,

Two points not made previously.

>action if the server location mechanism has returned answers that are

The reliance on the routing system for a host route IMHO isn't any 
different from having a host on a subnet.  The router had to be configured 
to advertise a route to the subnet.  It didn't happen automatically.  The 
only difference I see from a host route and a subnet route is the length of 
the prefix.  Reachability to all addresses is dependent on the routing 
system.  Note: I am not saying that host routes can be used for everything 
as they have clear scaling problems.  They are a very useful tool if used 
appropriately.

>but the draft would have to spell out those precautions (see the RFC).

I agree this needs be clarified.

>The first cup of coffee recapitulates phylogeny.

I think I need more coffee :-)

Bob

---

From: Rob Austein <[email-masked]>
Date: Thu, 02 May 2002 21:57:37 -0400

> as they have clear scaling problems.  They are a very useful tool if used 

I'm not claiming that there's a difference between a host route and a
subnet route (a route is a route, the prefix length doesn't matter).

I do claim that there's a difference between letting the client make
the choice of which servers to talk to and having the routing system
decide for the client.
--------------------------------------------------------------------
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: Steve Deering <[email-masked]>
Date: Fri, 3 May 2002 09:49:45 -0700

Rob,

It's not the routing system "deciding" the choice of servers, it's the
human who causes the host routes to be injected into the routing system.
Instead of a human putting three DNS server addresses into a DHCP
database, a human configures the three DNS servers themselves to
advertise the (three different) host routes.  The client still gets to
choose among them, using whatever criteria it wishes.

If, instead of using three unicast addresses, we were to use a single
anycast address, that would indeed take away the decision process from
the clients.  The human who causes the host routes to be injected could,
if it were really important, statically prioritize the choice of server
by suitable assignment of route metrics (if using an IGP with a big
enough metric space).

A couple questions, from one who is expert in neither DNS nor DHCP:
Do the bulk of DHCP servers today provide more than one DNS server
address to each client?  If so, do "consumer-level" IP devices (PCs,
laptops, PDAs, cell phones, etc.) really make sophisticated choices
among those multiple DNS servers, or do they just pick one and then,
only if that one fails to respond, try another?

Steve

---

From: Ralph Droms <[email-masked]>
Date: Fri, 03 May 2002 13:07:25 -0400

At 09:49 AM 5/3/2002 -0700, Steve Deering wrote:
>address to each client?

Yup.

>If so, do "consumer-level" IP devices (PCs,

I can't give an authoritative answer - my understanding is that
ost devices just pick one and only try another if the
currently selected server fails to respond...

- Ralph

---

From: "Anil Kumar Reddy" <[email-masked]>
Date: Mon, 6 May 2002 09:14:44 +0530

Hi,

   I have a question about RFC-2472 (IPv6 over PPP), related to
    interface identifier option. Could somebody please answer.

    RFC-2472 gives 3 options in selecting an interface identifier for
    the negotiation. My doubt is related to option #1 - creating it from
    EUI-64 or EUI-48 identifiers. It says the 'u' (universal/local) bit
    should be set to 1, while deriving the interface identifier from
    EUI-48 identifier.

    In this scenario, suppose we create a ppp interface (which is a logical
    interface) with an interface address derived from the above EUI-48
    ('u' bit set to 1), extracted from any locally available interfaces.
    Then there is a chance of address clashing, when we want to configure
    the interface (physical), from which we have taken EUI-48 identifier &
    used for ppp interface. And it will not be possible to have two
interfaces
    with the same address (& globally unique - u bit).

    What is the meaning of these statements in RFC-2472 ??

    Thanks in advance for your help.

Regards,
Anil

 (Actually, I should post this to ppp mailing list, but as it is related
        to IPv6, I thought I can get some help from IPng group.)

---

From: Rob Austein <[email-masked]>
Date: Mon, 06 May 2002 10:52:49 -0400

> choose among them, using whatever criteria it wishes.

Only if the binding between the well-known unicast address and the
particular name server at that address is stable.  If the binding is a
dynamic thing, then choices that the client tries to make based on
previous history of the server at that address become invalid when the
binding changes, and the client has no way of knowing when the binding
has changed.

> only if that one fails to respond, try another?

Depends on the implementation, but all DNS clients are required to be
capable of being configured to know about more than one server at a
time.  Some implementations just round-robin among the servers they
know about, some perform timing measurements and try the server that
had the best response time in the past for the next query, and so
forth.
--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Mon, 13 May 2002 19:15:46 +0700

Date:        Wed, 1 May 2002 18:12:03 -0700
    From:        Steve Deering <[email-masked]>
    Message-ID:  <v04220800b8f635701fe6@[171.71.119.70]>

Sorry, I haven't been reading this list for the past few weeks,
so this is a bit late.

  | No, "this week's" version of the proposed solution is to use three well-
  | known, site-local unicast addresses.

How can this work if the server isn't in the same site as the client?
Is the intent to require that servers (DNS currently, but others as
well) must live in the same site as the clients?

Whether this is reasonable or not largely depends upon how site boundaries
will be set - maybe I missed it, but I don't recall anything actually
specifying that, it seems to have been left very vague, and perhaps just
"obvious".   Which is always dangerous.

To take the kind of example that is relevant here, I would always have
assumed that my house will be a site - that way I keep on using my stable
site local addresses when I change providers (and at least possibly,
global addresses).   That's why I thought the notion of sites existed.

But I'm most likely not going to want to run a DNS server (back end resolver
we're talking about here) in my house (or I personally might, but many others
probably won't).

So, if the site boundary is the link between my house and my ISP, how do
I get to find the DNS back end, which is something that my ISP is providing
for me?   (For local address resolution I can use something like mDNS if
that ever gets off the ground, of even /etc/hosts, as I would be using site
local addressing for all internal comms, and I can make those addresses
very stable).

I'm also not likely to be running a DHCP server, so "you have to use
managed addresses in that case" isn't a suitable answer.

kre

---

From: Robert Elz <[email-masked]>
Date: Thu, 16 May 2002 11:23:46 +0700

Date:        Mon, 13 May 2002 19:15:46 +0700
    From:        Robert Elz <[email-masked]>
    Message-ID:  <[email-masked]>

  | How can this work if the server isn't in the same site as the client?

In reply to this query of mine, a private message (thanks for that)
reminded me of a message that Itojun sent to the list back in early April...

  | Message-id: <[email-masked]>
  | To: Ralph Droms <[email-masked]>
  | Cc: [email-masked]
  | From: [email-masked]
  | Subject: Re: Stateless DNS discovery draft
  | Date: Fri, 05 Apr 2002 11:25:54 +0900

  | 	if CPE can become dual-sited (participate into ISP's site and
  | 	customer's site) it can relay DNS query requests/responses between
  | 	clients in customer's site to DNS server in the ISP.

which is true, messages could be relayed - however I believe that
breaks the "serverless" requirement that is being suggested.

That is, to relay a site local message effectively, the reply
also needs to be relayed (the message into the ISP needs to be
sent from the relay's address inside the ISP's address space, as
the customer's site local address is useless there).  So the
reply will return to the CPE, and then needs to be relayed back
to the end node (with the appropriate address substitutions made)

To accomplish that, either the relay needs to retain state
(it would be close enough to a specialised NAT server) or the
protocol needs to include enough information so the relay can
tell from the reply where the reply needs to be sent (which
makes the whole protocol close enough to isomorphic to DHCP,
and certainly could not just be DNS packets to a well known
address).

Either way, I don't think this meets the objective.

Aside from the "we aren't sure deployment will be good enough"
is there some reason why multicast isn't being used for this
search?   Or more bluntly perhaps, why svrloc isn't just being
used?

Multicast deployment will follow closely upon a requirement for
multicast deployment - as long as no-one wants to use it
because it isn't deployed, it never will be.   Require it
for a worthwhile application, and deployment will simply happen.

kre

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 16 May 2002 17:28:41 +0900

>and certainly could not just be DNS packets to a well known

	this is totally normal DNS relay server behavior.  they look at
	ID field of DNS packet, and relays response to the original querier.
	it just needs to handle scoped address properly.
	what is your question?

itojun

---

From: Robert Elz <[email-masked]>
Date: Fri, 17 May 2002 13:44:22 +0700

Date:        Thu, 16 May 2002 17:28:41 +0900
    From:        Jun-ichiro itojun Hagino <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	this is totally normal DNS relay server behavior.  they look at
  | 	ID field of DNS packet, and relays response to the original querier.
  | 	it just needs to handle scoped address properly.
  | 	what is your question?

Of course, but that presumes a DNS server inside the site, which is
what I wanted to avoid presuming.   That is, you no longer have anything
close to a serverless setup in any way that it has been defined, you're
requiring a new server to be installed to act as this relay.

Or if you like, instead of being a DNS server that we're searching for,
make it be an NTP server instead.   NTP queries don't get relayed.   It
really ought to be achieved by the same general mechanisms, unless we can
find something so special about one of them that makes it different (eg:
finding routers is different, as we know the router must be on the local
link to be useful at all, hence RA packets are enough).

kre