Subject: Proposed IPv6 DNS Discovery Requirements

From: Bob Hinden <[email-masked]>
Date: Wed, 17 Apr 2002 16:23:33 -0700

I took a cut at a requirements statement for IPv6 DNS Discovery.  Comments 
are appreciated.

Thanks,
Bob

----------------------

IPv6 DNS Discovery Requirements Statement

IPv6 provides two approaches to basic IPv6 configuration.  One is 
server-less and is defined in IPv6 Neighbor Discover [RFC2461] and the IPv6 
Stateless Address Autoconfiguration [RFC2462].  The other is server 
oriented and is defined in DHCPv6 [dhcpv6 id].  IPv6 Neighbor Discovery 
includes flags to direct an IPv6 host to use either approach.

In order for an IPv6 host to communicate on the Internet it needs an IPv6 
address, IPv6 prefix for the link it is attached, default router address, 
and a DNS server address.  This information allows the host to use basic 
internet services like the web, email, file transfer, etc.

The server-less approach currently provides mechanisms for the IPv6 host to 
learn an address, IPv6 prefix for the link, and default router address, but 
does not provide any mechanism for the IPv6 host to learn any DNS 
information.  Without any DNS information the IPv6 host can not use basic 
internet services with out some other kind of configuration (except by the 
user typing in literal IPv6 addresses).  Requiring users to enter literal 
IPv6 addresses in difficult in IPv6 given the size of the addresses.

The basic requirement for IPv6 DNS Discovery is to provide a server-less 
mechanism to enable a host to learn the address of an DNS server.  This 
will complete the IPv6 server-less configuration mechanisms.

For this requirement, Server-less is defined to mean the DNS information is 
learned with out any dependence on resources other than are needed (i.e., 
links, interfaces, routers, and DNS server) to communicate with the DNS server.

IPv6 DNS Discovery should work inside of a single site where the DNS 
servers are in the site and between sites where the DNS servers and hosts 
are located in different sites (e.g., small home office where DNS servers 
are in the ISP's network).

It is also desirable to learn other related DNS information such as default 
DNS for the IPv6 host, search path, LLMNR enabled flag, etc. in a 
server-less manner.

Desirable aspects of a solution the meets these requirements include:

   - Minimal changes to existing implementations
   - A solution that could be standardized in a short amount of time.
   - Minimal use of bandwidth

References

[DHCPv6]  J. Bound, et. al., Dynamic Host Configuration Protocol for IPv6
           (DHCPv6), Internet Draft, <draft-ietf-dhc-dhcpv6-23.txt>,
           February 2002.

[RFC2461] T. Narten, et. al., Neighbor Discovery for IP Version 6 (IPv6),
           RFC2461, December 1998.

[RFC2462] S. Thomson, et. al., IPv6 Stateless Address Autoconfiguration,
           RFC2462, December 1998.

--------------------------------------------------------------------
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: Randy Bush <[email-masked]>
Date: Thu, 18 Apr 2002 09:54:51 +0900

as rob pointed out, with dnssec, you will need accurate time, i.e. an ntp
server as well.

randy

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Apr 2002 22:36:06 -0400

> DNS for the IPv6 host, search path, 
...

mumble.  frankly I've always thought this was broken.  a host's DNS default 
search path has nothing inherently to do with the points to which it attaches
to the network. we need to make a clear distinction between attributes which
are specific to a particular network attachment point, and attributes which
are related to a host's name or the services it performs.

Keith

---

From: Rob Austein <[email-masked]>
Date: Thu, 18 Apr 2002 00:19:10 -0400

I think the statement would be clearer if rewritten without ever using
the word "server", since the newly coined term "server-less" strongly
suggests that we are still using that word in multiple ways that
conflict with each other.

Accepting the confusing terminology temporarily for purposes of
discussion: since I assume that the phrase

  "without any dependence on resources other than are needed (i.e.,
  links, interfaces, routers, and DNS server) to communicate with the
  DNS server"

is not intended to rule out a solution in which the "DNS server" also
participates in some non-DNS protocol interaction that provides the
discovery service, it would be good to say so explicitly.

Also, there's at least one more item that belongs on the "desirable"
list:

    - Minimal unwarranted duplication of mechanism

That is: before specifying two separate ways to perform the same
function, it'd be nice to know whether the two mechanisms are really
different enough that it's worth making every toaster vendor in the
world implement both of them.
--------------------------------------------------------------------
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: Thomas Narten <[email-masked]>
Date: Thu, 18 Apr 2002 11:55:35 -0400

> Stateless Address Autoconfiguration [RFC2462].

Note: I don't know that I understand this distinction. Calling ND
"server-less" doesn't seem entirely accurate. ND requires a router
sending the client prefix information for the addresses it is to
generate. Without that info, the client can only generate link-local
addresses. In this case, the router quacks like a server. I.e., the
client sends out an RS, the router responds with a RA. Is it not being
a server?

I think this point is important because saying we need a "server-less"
solution implies we all agree on what server-oriented vs. server-less
actually means. I'm not sure I do.

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Fri, 19 Apr 2002 09:50:01 -0700

Thomas,

>actually means. I'm not sure I do.

I suspect that most people can tell the difference.  I used these words I 
thought were clearer than stateless/statefull as both approaches have 
state.  The important definition from the text is:

>For this requirement, Server-less is defined to mean the DNS information 
>is learned with out any dependence on resources other than are needed 
>(i.e., links, interfaces, routers, and DNS server) to communicate with the 
>DNS server.

It could be changed to something like "third-party-server-less" and 
"third-party-server-based" but that is pretty awkward.

Bob

---

From: Rob Austein <[email-masked]>
Date: Fri, 19 Apr 2002 13:30:26 -0400

At Fri, 19 Apr 2002 09:50:01 -0700, Bob Hinden wrote:
> 
> I suspect that most people can tell the difference.

No, Bob, that's exactly the point.  You see a difference.  I see a
difference.  But is the difference you see the same as the difference
I see?  Maybe, maybe not.

I understand that you're trying to avoid spelling all this out in
mindnumbingly tedious detail, but in this case I think you really have
to do so.  Lack of clarity is how we got into this swamp.
--------------------------------------------------------------------
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: Ralph Droms <[email-masked]>
Date: Mon, 22 Apr 2002 11:43:28 -0400

Thanks, Bob, for writing a draft doc on DNS Discovery requirements.  We 
need something concrete to center this discussion.

So, here are some discussion points around the draft doc...

Is a server-less solution the best solution for DNS Discovery?
==============================================================
The requirements statement starts off with the same premise as the DNS 
Discovery team: "server-less" (as the term is defined in the doc) operation 
is a design requirement.  The DNS Discovery team report stated "It is a 
further requirement that the above information be obtained without using a 
DHCP server."

The issue with the DNS Design Team analysis and the recommended DNS 
discovery mechanism is not "is this the best server-less solution"; rather, 
the issue is "is this best server-less solution the best solution" or "do 
we need this best server-less solution".  Bob's requirements will give us 
another answer to "is this the best server-less solution" and won't answer 
the question of whether the server-less solution is needed.

So, we should either:

* throw out the requirement for a server-less solution and
   find the best solution; or,
* do an apriori analysis to confirm that a server-less
   solution is fundamentally required; or,
* have and end-game analysis of "best server-less" solution
   vs. server-ful solution and decide if we need both

Do we need a server-less solution for every IPv6
configuration problem?
================================================
I read an unstated assumption in the first sentence, "IPv6 provides two 
approaches to basic IPv6 configuration." that server-less and server-ful 
configuration are two mutually exclusive, stovepipe approaches, where both 
alternatives must be provided for each component of basic configuration.  I 
believe we've shown that server-less configuration for IPv6 addresses is 
useful and a solved problem.  It may be the only required solution - I can 
suppose situations in which address assignment might require constraint and 
control, but we don't have any deployment experience that proves such a 
requirement.

But a solution to server-less configuration of IPv6 addresses does not 
imply that a solution to server-less configuration of routing information, 
DNS resolution and other basic configuration is a good idea or even 
possible.  I think we should be careful to consider each type of 
configuration separately to make sure we're generating useable solutions to 
real problems.

Server-less DNS Discovery or server-less DNS resolution?
========================================================
Just to be careful - the basic requirement in Bob's draft requirements is 
"to provide a server-less mechanism to enable a host to learn the address 
of an DNS server."  This is a more stringent requirement than to provide a 
server-less mechanism to perform DNS resolution.  I would say that the most 
recent "Stateless DNS Discovery" mechanism 
<draft-ietf-ipv6-dns-discovery-04.txt> does *not* meet the requirement laid 
out in Bob's requirements statement.  A host using the Level 1 compliance 
mechanism defined in <draft-ietf-ipv6-dns-discovery-04.txt> does not find 
the address of an arbitrary DNS server.  Rather, the host can do DNS 
resolution in a site that has specifically configured its network routing 
and DNS infrastructure to support DNS resolution through the well-known DNS 
server addresses.

Scope of required information for DNS Discovery
================================================
Others have pointed out the a device using DNSSEC may need NTP.  The 
requirements should be expanded to read something like "learn the address 
of a DNS server and any other servers required for use of DNS".

At 04:23 PM 4/17/2002 -0700, you wrote:
>server-less and is defined in IPv6 Neighbor Discover [RFC2461] and the 
>IPv6 Stateless Address Autoconfiguration [RFC2462].  The other is server 
>The server-less approach currently provides mechanisms for the IPv6 host 
>to learn an address, IPv6 prefix for the link, and default router address, 
>but does not provide any mechanism for the IPv6 host to learn any DNS 
>It is also desirable to learn other related DNS information such as 
>default DNS for the IPv6 host, search path, LLMNR enabled flag, etc. in a 
>server-less manner.
>

---

From: Bob Hinden <[email-masked]>
Date: Mon, 22 Apr 2002 13:57:02 -0700

Could you comment on the definition I used for server-less?  There was more 
than just the use of the word.

Bob

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 22 Apr 2002 19:22:13 -0400

> as rob pointed out, with dnssec, you will need accurate time, i.e. an ntp

You don't need submillisecond-accurate NTP time, though -- accurate to
the nearest hour will likely be sufficient in many cases.

						- Bill

---

From: Bill Manning <[email-masked]>
Date: Mon, 22 Apr 2002 17:10:35 -0700 (PDT)

% > as rob pointed out, with dnssec, you will need accurate time, i.e. an ntp
% > server as well.
% 
% You don't need submillisecond-accurate NTP time, though -- accurate to
% the nearest hour will likely be sufficient in many cases.

	actually, it seems the failures occur when clocks are more
	than 5min off.  the code seems to back this observed behaviour.

--bill

---

From: Rob Austein <[email-masked]>
Date: Tue, 23 Apr 2002 00:12:01 -0400

At Mon, 22 Apr 2002 13:57:02 -0700, Bob Hinden wrote:
> 
> Could you comment on the definition I used for server-less?  There
> was more than just the use of the word.

I think that Ralph already addressed the main point, I doubt that I
can improve much on his comments, and I implore you to read what he
wrote very carefully.

However, since you did ask a direct question, I'll try to answer it.

> For this requirement, Server-less is defined to mean the DNS
> information is learned with out any dependence on resources other
> than are needed (i.e., links, interfaces, routers, and DNS server)
> to communicate with the DNS server.

Comments:

  The term "DNS server" is not well defined at the level of detail
  that this problem statement requires.  Is an entity that implements
  both the DNS server role and portions of the DHCP server role a "DNS
  server" within the meaning of this definition?

  The term "router" is not well defined at the level of detail that
  this problem statement requires.  Eg, would DHCP relay agents
  co-resident with routers be parts of the routers within the meaning
  of this definition?

In all seriousness: I can't tell you whether I agree with your
statement of the problem until I know what what the words mean.
--------------------------------------------------------------------
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 23 Apr 2002 16:09:23 +0900

>>>>> On Mon, 22 Apr 2002 11:43:28 -0400, 
>>>>> Ralph Droms <[email-masked]> said:

> configuration separately to make sure we're generating useable solutions to 

Aside from the definition of "server-less" (though some people would
say the definition is the point...), this is IMO the most essential
point of this discussion.

Bob said:

>>>>> On Wed, 17 Apr 2002 16:23:33 -0700, 
>>>>> Bob Hinden <[email-masked]> said:

> internet services like the web, email, file transfer, etc.

this means a DNS server address (for name resolution) is one of the
very fundamental parts of the Internet communication where we'd like
to reduce dependencies as much as possible.  Thus the server-less
solution.

So perhaps the question is: is a DNS server address that special?  The
answer from the design team is "yes", but the answer from those making
objections (or doubts) in this discussion would be "not really".

If my view is correct, then I'm afraid we cannot reach a consensus,
which would probably mean we should reconsider the mechanism from the
scratch.  In that case we'll have to start with (more primary)

>    - Minimal use of bandwidth

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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: Ralph Droms <[email-masked]>
Date: Tue, 23 Apr 2002 08:28:43 -0400

Here's my cut at a list of requirements for DNS Configuration.  It's based 
on Bob's "IPv6 DNS Discovery Requirements Statement", previous discussions 
on DNS configuration, and  my own $0.02.  My intention is to list all of 
the requirements I've heard in the various discussions about DNS configuration.

The requirements are numbered for reference and listed in order of 
importance.  There are notes about some of the requirements following the list.

Questions for the WG:

Are there other requirements not covered by this list?
Do any of the requirements need clarification?
Should any of the requirements be discarded?
What is the order of importance of the requirements?

- Ralph

IPv6 DNS Configuration Requirements
------------------------------------

  1. Host receives IPv6 address(es) of DNS server(s) available to the
     host for DNS resolution
     1.a. The list of servers includes only currently available
          servers
     1.b. The host can obtain the addresses of new servers as needed
  2. Hosts obtain DNS configuration with no manual configuration
  3. The addresses of a particular server are provided to hosts with no
     manual configuration of that server
  4. Hosts obtain DNS configuration using only those resources required
     for DNS resolution
  5. Hosts obtain DNS configuration without the manual configuration of
     any external service
  6. Hosts can (if desired) authenticate the reliability of servers
  7. Definition of DNS configuration requires no additional
     protocol definition
  8. Implementation of DNS configuration requires no additional protocol
     implementation
  9. Time to initial deployment is minimal
10. Hosts have one way to perform DNS configuration
11. DNS configuration operates when host and DNS servers are in same
     site or in different sites
12. A network administrator can control what servers a host uses
13. Host is configured with domain and domain search list

Notes:
------
  2. (and 3.) Hosts and DNS servers operate as "plug-and-play" or
     "zeroconf"
  7. "additional protocol definition" means protocols not currently a
     standard or defined in a standards-track Internet Draft
  8. "no additional protocol implementation" means hosts and servers
     are not required to include code for protocols that they wouldn't
     otherwise implement
10. Hosts shouldn't need to try several different DNS Configuration
     protocols to find which one is available on a link
11. Hosts and DNS servers can exchange datagrams using site-local
     addresses

---

From: Robert Elz <[email-masked]>
Date: Tue, 23 Apr 2002 22:53:45 +1000

Date:        Tue, 23 Apr 2002 08:28:43 -0400
    From:        Ralph Droms <[email-masked]>
    Message-ID:  <[email-masked]>

  | Here's my cut at a list of requirements for DNS Configuration.

I quite like this list, except perhaps ...

  | 10. Hosts have one way to perform DNS configuration

Unless that means only what the notes say ...

  | 10. Hosts shouldn't need to try several different DNS Configuration
  |      protocols to find which one is available on a link

That's fine - a host should only need to try one way, but there should
me multiple possible ways to obtain the config, just as we have for
every other config option for IPv6.

Obviously, the admin of a host must be able to manually config the DNS
servers that are to be used (switch off any autoconfig that the host would
normally do).

And if autoconfig is enabled, we need both the "managed" variety, where
someone actually does configure and run a server that supplies exactly the
info that that administrator says should be supplied (this basically means
discovery via DHCP I think) - but we must not require that, we also need
the option where the host simply figures out what exists, for the cases
where there is no network admin, or the admin simply doesn't care.

  | 11. Hosts and DNS servers can exchange datagrams using site-local
  |      addresses

I'm not sure how that relates to point 11...

  | 11. DNS configuration operates when host and DNS servers are in same
  |      site or in different sites

I wouldn't be including anything about address scoping in a requirements
list, not even in notes, that's a potential part of the solution, not of
the requirements.

kre

ps: while a solution that requires no additional implementation or 
specification would be nice, I certainly wouldn't rule out anything just
on that basis - we have (or should have) the manual option now, and
should have dhcp as an option sometime soon, if not now, the idea for
the third form (configureless autodiscovery) should be that it work well,
and be rationally defined, not just the best we can grab out of the
protocols that exist today.

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Apr 2002 09:23:44 -0400

I strongly disagree with a number of the 'requirements' you've proposed.

1. it is not possible in general for a host to determine it's proper 
DNS configuration from information provided by the network, because 
the DNS search path that the host wants to use may not be the one 
that the local network specifies.  even trusting the local network's
DNS servers to serve as the interface to other DNS zones is a stretch.  
it's fine if hosts want to do this, not fine to insist that they do this.

hosts MUST therefore be able to specify their own DNS configuration which 
overrides that specified by the local network environment, and this 
seems to contradict your 'requirements' #10 and #12.

2. re 'requirement' #12: it's absolutely unacceptable for IETF to dictate 
that a network administrator can 'control' what DNS servers a host can 
use - this is fundamentally a host issue and not a network issue; 
it's outside of the scope of what a network should be able to dictate
to a host.  again, the fact that a host is currently connected to a
certain location in the network should not be taken as evidence that the
context in which that host operates (dns servers, search path, default
domain) should have anything to do with that network location. 

3. 'requirements' #7,8 are premature at best and probably a fantasy.
it's highly unlikely that DNS discovery can be implemented without some 
new protocol definition and implementation, even if you use similar 
packet formats and port # to those that exist now you are certainly 
going to need to change client and server code - and that is a protocol
change.  so I think at the very least these are poorly worded.

more importantly, this decision is best made after alternatives 
have been considered - not as an a priori 'requirement' that
presumes the solution.

4.  I'm not at all sure what it means to 'authenticate the reliability'
of a server, so I think this needs to be reworded.

5. note #7: there's no such thing as a 'standards-track Internet Draft'

6. requirement #11 and your note about #11 seem to be mutually
exclusive - you can't use site-local addresses when the host 
and server are at different sites.  of course, it's fine to use 
site-local addresses between hosts and servers at the same site.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 23 Apr 2002 10:02:37 -0400

Keith - I think we might actually be more in agreement than 
disagreement.  You have pointed out several places where I wasn't clear; 
let me see if I can clarify...

One global clarification - I used the term "requirements" in the sense I 
often see the term (mis)used.  What I've written is more a "wish list", and 
I have every expectation that some of the requirements can't be met and 
other requirements are mutually exclusive.  The list should be used a 
yardstick for measuring proposed solutions.

1. I agree - the DNS configuration discussion should be qualified
by a global "if the host wants to find out about local DNS
services".  Suggestions about how to word that qualification
will be gratefully accepted.

I did try to be clear that "addresses for DNS servers" is a separate
problem from "domain and domain search list"...

2. My wording for requirement 12 was unclear.  What I meant was "if
the host requests information about DNS servers, the list of servers
can be customized for that host".  I don't intend that a network
admin can force a host to use a specific set of DNS servers; rather,
different hosts can get configured with different lists of DNS
servers

3. If interpreted as absolute, binary requirements, 7 and 8 are
quite likely fantasies.  I intend 7 and 8 to be goals that proposed
solutions can be measured against.

4. In requirement 6, I was trying to express the requirement that
the host can trust the servers it learns about through DNS
configuration.  If that wording is clearer, I'll use it in the
requirements list.

5. In the note about requirement 7, I guess simply "defined in
an Internet Draft" might be sufficient.  I was hoping to be able
to restrict consideration to protocols that are already under
development and have achieved some level of maturity.

6. The note about requirement 11 was intended as a definition for
a phrase in requirement 11; it should read:
   "A host and a server are in the same site if they can exchange
   datagrams using site-local addresses."

---

From: Bob Hinden <[email-masked]>
Date: Tue, 23 Apr 2002 07:36:00 -0700

Ralph,

>the requirements I've heard in the various discussions about DNS configuration.

Thanks for your help, but I think it would best to continue discussing the 
requirements I sent earlier, as opposed to having several dueling sets of 
requirements.

Later this week I am planning to send out an update and then take a poll to 
see if there is a "rough consensus" in the working group so we can move 
forward.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Tue, 23 Apr 2002 07:44:41 -0700

Rob,

Thanks.  I will give it some thought and respond tomorrow.  I will not have 
email for most of today.

Bob

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Apr 2002 16:35:20 -0400

> let me see if I can clarify...

thanks for the clarification - it's a bit of a relief...

> different hosts can get configured with different lists of DNS

wow...I didn't get that at all from the first reading - I think
the above text is much better.

> solutions can be measured against.

I guess I don't see this as a very useful yardstick because 
'no additional protocol definition' is too vague.

> configuration.  If that wording is clearer, I'll use it in the

I'm not sure I understand this - what does it mean for a host to be 
able to 'trust' those servers?    seems like the best you can hope
for is some sort of site signature that says "yep, these really
are the addresses of the servers we think you should use". 

Keith

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Apr 2002 09:10:37 -0400

Keith,

>'no additional protocol definition' is too vague.

Yeah ... after rereading my original draft list of
requirements, it seems to me that the goals of requirements
7 and 8 are, in fact, the same as requirement 9 (see
below).  We don't care about new protocol design and
implementation, per se, what we're really interested
in is minimal time to deployment.  If that seems
correct, I'll delete 7 and 8 from my draft list...

(from original list of requirements)

- Ralph

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Apr 2002 13:50:32 -0400

> We don't care about new protocol design and
> in is minimal time to deployment. 

yes, I think it's much clearer if you say just that.

Keith