Subject: Keeping the DNS discovery discussion focused and civil

From: Rob Austein <[email-masked]>
Date: Tue, 05 Aug 2003 15:49:10 -0400

<hat wg-co-chair=on personality-simulator-sensitivity-level=new-age>

A few observations and requests regarding the recent discussion.

1) Regardless of what we might wish, we are starting from where we are
   today, not from where we might have been had various decisions been
   made differently at some point in the past. This is not the IPv6
   WG, and we are not here to revise or debate stateless address
   autoconfiguration, neighbor discovery, etc.  The only exception to
   this that I can see is that we might reasonably conclude that the
   "O" bit in the Router Advertisement ICMPv6 message is not relevant
   to DNS discovery, in the sense that we might conclude that DNS
   discovery should be performed in the same way regardless of the
   setting of the "O" bit.

2) Several of our participants are making a serious attempt to
   communicate with each other past nontrivial language and cultural
   barriers.  Misunderstandings are very easy under such
   circumstances, and all of us (particularly those of us whose native
   language happens to be English) need to be careful both not to read
   too much into the phrasing and tone of others' messages and also to
   be sensitive to how tone and phrasing in our own postings might be
   read.  Limiting postings to subjects which are within the proper
   scope of the discussion should help, since it will at least limit
   the range of subjects on which we can have these misunderstandings.

</hat>
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 6 Aug 2003 14:11:01 +0859 ()

Rob Austin;

>    today,

that IPv6 is not deployed in the real world, partly because the
protocol suite is not complete pursuing unclear goals some of
which are impossible.

An attempt to obscure the incompleteness is to delegate some
of the work from IPv6 WG to other WGs, only to export the internal
chaos.

>    not from where we might have been had various decisions been
>    made differently at some point in the past.

Haven't we, IETF, changed a past decision to use OSI?

>    This is not the IPv6
>    autoconfiguration, neighbor discovery, etc.

First, we should analyze the problem to its source, which is
what we are doing now.

Then, perhaps, we must define what "autoconfiguration" means,
even though we are not the IPv6 WG.

And then, we can solve some of the problem by ourselves and
recommend others to solve the rest.

>    barriers.

As we often say "read the draft", it is our culture to regard
draft reading the prerequisite to participate the discussion.

However, it is not even a cultural issue but a very basic
requirement by definition to regard reading mails, at
least recent ones of the thread, the prerequisite to
participate the mailing list discussion.

Still, I'm less demanding than you never expect people
have wide knowledge of archive content of other WGs.

							Masataka Ohta

---

From: Rob Austein <[email-masked]>
Date: Wed, 06 Aug 2003 16:40:58 -0400

> have wide knowledge of archive content of other WGs.

That's a fair criticism.  I've been reluctant to attempt to summarize
the IPv6 WG's discussion of the well-known-address proposal, in part
because I was hardly a neutral party in that debate and thus would
prefer to let others form their own conclusions.  However, since
you're correct that it's unfair to say that one has to understand that
whole debate to participate in this WG's discussion of requirements,
I'll try to summarize what I remember, with the understanding that
this is just my view.  For those who have the interest and patience to
dig through the IPv6 WG archives, the relevant stuff probably starts
in April of 2002 and runs (on and off) through October 2002.

Ignoring irrelevant issues (eg, the IPv6 Site-Local swamp), I still
have concerns with the well-known address approach:

- How does this interact with LLMNR?  Eg, how is a node supposed to
  know whether it should be doing LLMNR or not?  (NB: I'm no fan of
  LLMNR, but it's out there and people are using it.)

- There are layering and administrative issues.  This approach puts
  the DNS configuration information into the routing system.  It's not
  immediately obvious that the local routing system and the local
  recursive name servers are necessarily controlled by the same
  administrators, so there are issues with how updates get into the
  routing system, with how (and whether) the routing system reflects
  recursive name servers that die or move, and so forth.

- There are also fate sharing and coupling issues.  Using well-known
  addresses hides the binding between the addresses and the particular
  recursive name servers in question, which may matter if one or more
  of the recursive name servers starts flaking out.  In the "normal"
  (not well-known-address) case, a resolver can keep track of which of
  the recursive name servers it's using is performing, and might
  conceivably inititate some form of recovery action (eg, probing for
  a new set of recursive name servers) if something bad happens.  In
  the well-known-address case, none of that is likely to work well.

There may have been other issues, but those are the ones I remember.

Summarizing: I think this approach is a step towards the smart
network/dumb host model beloved by telcos, and is a step away from the
smart host/dumb network model that's traditional for Internet
applications (this is, of course, an oversimplification, the truth is
and always has been more complicated, but it's close enough for this
summary).  So this approach might well make sense in certain kinds of
networks, but not in others, and thus it's not obvious to me that this
is the right general solution.

Hope this helps.  Folks who disagree are of course welcome to respond,
with the understanding that the goal here is still the quest to
understand the requirements for DNS discovery here in the DNSOP WG,
not recounting the history of a particular draft.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Paul Vixie <[email-masked]>
Date: 06 Aug 2003 23:03:41 +0000

[email-masked] (Rob Austein) writes:

> ...

I agree with Rob's objections to this approach.  Asking for a well known
address for DNS begs questions like, why do we need to use IRDP or DHCP to
tell a host its default router -- we can just designate the all-zeroes
address in any given subnet for "default route service".  And so on.  This
way lies madness, and we need a layer of indirection where policy can be
localized.
-- 
Paul Vixie
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Alain Durand <[email-masked]>
Date: Wed, 06 Aug 2003 17:00:38 -0700

Being the last author of the well known address document
in the v6 wg, I feel I can answer for the sake of clarification.
I do not intend to reopen the discussion, so I will try to limit
myself to this post only.

See inline.

>  LLMNR, but it's out there and people are using it.)
This is an orthogonal issue. Any DNS discovery mechanism will
have to face this. Beside, this is an LLMNR issue.

>  recursive name servers that die or move, and so forth.
This is the same issue with DHCP-lite or RA. The routing folks
have to put some configuration in their routers, and this configuration
is derived from what the DNS folks tells them.

>  the well-known-address case, none of that is likely to work well.
Fate sharing is not specific to the well know address.
With RA or DHCP-lite, there is also fate sharing on the local router
between the routing process and the RA/DHCP-lite one.

The loss of strong binding with the DNS server is anl issue.
With the well known address, you somehow lose track of who
you're talking to, especially if that address is an anycast one.
Note that the latest draft was especially not using the term anycast
and was reserving 3 addresses, so you could somehow mitigate
the issue by placing 3 servers with 3 different addresses. That way
the DNS client/stub resolver could try another server if the current
one started to behave badly.

Generally speaking, sevral people were uncomfortable
with the idea of overloading IP addresses with service semantic.
For example, it is common practice in IPv4 to use x.x.x.1/24 or y.y.y.254/24
for the local router on the link, but there is no protocol that makes
this assumption. People were reluctant to make this step in IPv6.

    - Alain.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 7 Aug 2003 01:42:43 -0000

Paul Vixie writes:
> we can just designate the all-zeroes address in any given subnet for
> "default route service".  And so on.  This way lies madness

Taking away layers of indirection isn't always a good idea, but it's
inherently self-limiting. Madness lies in the opposite direction, where
people keep adding unnecessary layers of indirection. Examples:

   * ``Instead of specifying port 25 for SMTP, let's use SRV to declare
     site-specific SMTP ports!''
   * ``Instead of specifying IP addresses in NS records, let's specify
     host names, which will be resolved recursively!''
   * ``Instead of specifying a universal character set, let's have every
     piece of text tagged with its character set!''

There's no limit to the amount of ``configurability'' bloat that people
can---and do---add to their designs.

If there's a real advantage to indirection in the router address, DNS
cache address, etc., then someone should be able to state exactly what
that advantage is. So far, all I've seen are religious comments about
how this is ``madness,'' ``not the way the Internet works,'' etc.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 7 Aug 2003 14:12:46 +0859 ()

D. J. Bernstein;

This message is of topic, except that ND and Unicode share similar
chaos.

>      piece of text tagged with its character set!''

Right.

However...

> people keep adding unnecessary layers of indirection. Examples:

The fundamental cause of the chaos is to invent terminology, such
as "stateless autoconfiguration" or "universal character set",
without defining its meaning.

>      piece of text tagged with its character set!''

In Unicode case, there is no definition on "a universal character
set".

As a result, extra tagging, such as a language tag, is added,
as an imprecise alternative of script tagging, if you want to
use Unicode in universal, international, environment.

As we gain more experience, it becomes more and more obvious that
ISO 2022, which was denied because it were not universal, is the
mechanism for "universal character set", just as DHCP, which
was denied because it were not stateless, is the mechanism for
"stateless autoconfiguration".

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 7 Aug 2003 14:56:58 +0859 ()

Rob Austin;

> this is just my view.

Thank you.

> Ignoring irrelevant issues (eg, the IPv6 Site-Local swamp),

That is a reason good enough to avoid reading the archives by myself.

> I still have concerns with the well-known address approach:

Most, if not all, of the concerns is seemingly addressed by Alain
that I add my own comments.

>   LLMNR, but it's out there and people are using it.)

LLMNR was another swamp, but is filled up by DNSOP. So, the LLMNR
document has made it clear how the interaction between LLMNR and
configured DNS servers, hasn't it?

However, I sill am not so sure what the precise requirement of
LLMNR is, so that some of it may be overridden by DNS
autoconfiguration, but it is not anycast-specific and is a
problem of LLMNR.

>   administrators,

In anycast proposal, it is not assumed that the local routing
system and the local (or external) recursive name servers are
necessarily controlled by the same administrators.

An example is ISP controlled name servers exemplified in
my draft. But, the point should have been sunken in the
swamp of scope.

Router configuration is required to limit the scope of local
(or external) recursive name servers, which is common to all
the proposals here.

>   of the recursive name servers starts flaking out. 

>   In the "normal"

Then, autoconfigured case, where hosts blindly believe anything
configured even if something bad happens, is not "normal".

Or, if one insists that a host can be autoconfigured with multiple
sets of resolvers, a host can be preconfigured with multiple sets
of anycast addresses.

> There may have been other issues, but those are the ones I remember.

So far, it is a summary of the archives and is not necessarily
your opinion, I presume.

> Summarizing: I think this approach is a step towards the smart

OK, you think, now.

> summary).

If a set of global addresses are tied to a global servers, yes,
which is the case of current root servers.

However, anycast allows for local control of root servers and
default recursive servers, even if addresses of them have
a global scope.

So, just say, anycast.

							Masataka Ohta

---

From: Pekka Savola <[email-masked]>
Date: Thu, 7 Aug 2003 09:21:13 +0300 (EEST)

On Wed, 6 Aug 2003, Alain Durand wrote:
[...]
> this assumption. People were reluctant to make this step in IPv6.

There is such an address -- the subnet-router anycast address.  However, 
I'm not so sure it works in all the cases, e.g. RFC2461 Redirects, or that 
it even should..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Ralph Droms <[email-masked]>
Date: Thu, 07 Aug 2003 08:02:08 -0400

I believe there is also a scaling issue.  If the well-known address 
mechanism is truly limited to unicast (and not anycast) addressing, an 
enterprise can only deploy as many recursive name servers as there are 
reserved, well-known addresses.

Another potential issue is that deployment of hosts using the well-known 
addresses will force network operators to support DNS service at those 
well-known addresses, even if some other service architecture would be 
better suited to that network's requirements.

- Ralph

---

From: Pekka Savola <[email-masked]>
Date: Thu, 7 Aug 2003 15:54:18 +0300 (EEST)

> reserved, well-known addresses.

It depends on what you mean by "anycast" here.

If well-known addresses are shared-unicast addresses (by the terminology 
of draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt), it might go easier.

You could just deploy the same (service) address in a lot of different
nodes, and just propagate host routes to those service addresses in the
internal routing; so, there could be more servers, but based on one node's
temporal view of the topology, it could only see N (e.g. three) at the
time and the place.
 
> better suited to that network's requirements.

Agreed, this may be an issue.  However, just as well you could redirect 
all of those to a box (even a router) which could proxy those requests to 
some otherwise configured DNS servers.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 07 Aug 2003 11:36:26 -0400

I really did mean to talk about unicast as opposed to any kind of anycast,
because the most recent published description of a scheme for using
well-known addresses to access DNS service
<draft-ietf-ipv6-dns-discovery-07.txt> specifies unicast.  If I remember
correctly, the earlier discussion about well-known addresses progressed from
specifying anycast to unicast because of concerns that "just propagate host
routes to those service addresses in the internal routing" might prove to be
complicated in practice.

- Ralph

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 8 Aug 2003 04:55:49 +0859 ()

Ralph;

> <draft-ietf-ipv6-dns-discovery-07.txt> specifies unicast.

See

	draft-ohta-preconfigured-dns-00.txt

> If I remember

Routers just propagate routes with no configuration that there is no
complication.

> better suited to that network's requirements.

As the DNS is the name service, it is an issue of those who want
to provide alternatives. See, for example, LLMNR draft of this WG.
Another approach could be to use DHCP to override the default.

						Masataka Ohta

---

From: Pekka Savola <[email-masked]>
Date: Fri, 8 Aug 2003 14:43:50 +0300 (EEST)

> routes to those service addresses in the internal routing" might prove to be

The argument I've heard a lot is one of architectural purity, as the 
address architecture states (for example):

--8<--
2.6 Anycast Addresses
                                                                                                                         
   An IPv6 anycast address is an address that is assigned to more than
   one interface (typically belonging to different nodes), with the
   property that a packet sent to an anycast address is routed to the
   "nearest" interface having that address, according to the routing
   protocols' measure of distance.
                                                                                                                         
   Anycast addresses are allocated from the unicast address space, using
   any of the defined unicast address formats.  Thus, anycast addresses
   are syntactically indistinguishable from unicast addresses.  When a
   unicast address is assigned to more than one interface, thus turning
   it into an anycast address, the nodes to which the address is
   assigned must be explicitly configured to know that it is an anycast
   address.

[...]
--8<--

I.e. that any address which is allocated in more than one interface turns 
into an anycast address... and there can be _no_ "nearest-unicast" 
addresses at all.

Needless to say I disagree with this model... :-)

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 9 Aug 2003 08:08:48 +0859 ()

Pekka Savola;

> address architecture states (for example):

The proper interpretation of the address architecture RFC
is that IPv6 WG does not know anything about address (not only
anycast one) architecture.

The RFC says:

> An IPv6 unicast address refers to a single interface.

> When a unicast address is assigned to more than one interface,

without defining "assign".

The confusion, seemingly, is a result of an attempot to purposelessly
distinguish a subnet and a link.

Purposeful requirements are that a subnet, which is identical to
a link, may have multiple address prefixes and that a link may
be divided into virtual links such as VLAN, which is purely
an L2 issue.

>    one interface (typically belonging to different nodes),

>    it into an anycast address,

If a host (or a router or a node or whatever) have a unicast address
assigned to an interface, the host must receive a packet to the address,
even if the packet is received on another interface. In addition,
if a host have a unicast address assigned to an interface, the host
may send a packet from the address, even if the packet is sent from
another interface.

That is, all the unicast addresses of a multi-interface host are
assigned to more than one interface and are anycast ones.

> Needless to say I disagree with this model... :-)

Yup.

						Masataka Ohta