Subject: RE: Proposed IPv6 DNS Discovery Requirements

From: [email-masked]
Date: Wed, 17 Apr 2002 19:06:01 -0700

Hi Bob,

good that you took the ball on writing the first version of the requirements statement.

Though, this is the first cut, at least to my opinion it reflects the needs of the simple hosts that rely on stateless autoconfiguration, e.g. a cellular web client.

I do not know if this is already included in the "Minimal changes to existing implementations", but I think it could be worth while to mention the requirement that the implementation on the host side (which is performing the autoconfiguration) should be simple, and small. Thus, something like "Mechanism is compact and efficient". Maybe someone of the native speakers can help, but what I am looking for is that the code (in memory) does not take much space, and the running of the code does not take much resources from the host.

Cheers,

Jonne.

> -----Original Message-----
> From: Hinden Bob (IPRG) 
> Sent: Wednesday, April 17, 2002 4:24 PM
> To: IPng List
> Subject: Proposed IPv6 DNS Discovery Requirements
> 
> 
> 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]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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: [email-masked]
Date: Fri, 19 Apr 2002 12:41:24 +0300

Hi Thomas,

> > 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.

I think that the difference is that calling ND "server-less" implies that
there is not an additional server required.

John

---

From: [email-masked]
Date: Tue, 23 Apr 2002 16:16:44 +0300

Hi Robert,

>   | 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.

I agree - would a default method be what is meant?  

John

---

From: BELOEIL Luc FTRD/DMI/CAE <[email-masked]>
Date: Tue, 23 Apr 2002 10:45:36 +0200

Hi all, 

Thanks Bob for initiating requirements draft.

IMHO "stateless address autoconfiguration" is actually a huge improvement
propose by IPv6. In the same way, I think that a "server less" DNS server
discovery should be a great service .

Anyway, I wonder if we should introduce to distinct requirements:
1- to provide a server less mechanism to enable a host to resolve any Domain
Name
2- to provide a server less mechanism to enable a host to discover DNS
server IPv6 address (so as "to learn other related DNS information" as
stated Bob).

I think that those two mechanisms are actually distinct, and that each
solution to those requirements will perhaps not be addressed by the same
mechanism.
1- I think my first requirement is compliant with Level 1 of
<draft-ietf-ipv6-dns-discovery-04.txt>. In that case, the host does not
really want to know the IP address of the local DNS servers.
2- no solution has already be accepted, is that requirement really relevant
?
  -> Does anycast enough mature ? unfortunately I've seen no answer to that.
  -> ICMPv6 options could be enough ? But could be if an issue any other
services discovery would like to use such a mechanism in the future, to
modify the RA means an update of all existing devices ;+((
  -> I thought it was a question for SLP but SLP seems needing for User
Agents which is not compliant with other Bob's requirements (User Agent
would be a kind of server... ?).
  -> other solutions DDDT proposed in
<draft-ipnwg-dns-discovery-analysis-00.txt> ?...

My 2%
Luc

-----Message d'origine-----
De : Ralph Droms [mailto:[email-masked]]
Envoye : lundi 22 avril 2002 17:43
A : [email-masked]
Objet : Re: Proposed IPv6 DNS Discovery Requirements

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:
>I took a cut at a requirements statement for IPv6 DNS Discovery.  Comments 
>are appreciated.
>
>Thanks,
>Bob
>
>----------------------
>
>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 
>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 
>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 
>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 
>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.
>
>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 
>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.
>
>[DHCPv6]  J. Bound, et. al., Dynamic Host Configuration Protocol for IPv6
>[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.
>
>
>
>
>

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 29 Apr 2002 00:08:41 -0400

Folks,

I worked on this design team.  Many of these issues came up and they are coming up again.
The draft you see is the design team and IETF meeting discussion.  It is good to get this right.

The driver for this design team and this work was to develop a very quick IETF tracked spec that could also be delivered to the market quickly.  The reason was that clients required the DNS parts we are all discussing.  But I think some very important questions have been raised.But with what I say below does not change the market requirement and that should be somewhere in the requirements doc to so all understand the assumptions the design team was under to develop a fast and quick solution.  

I do think we need to revmove the wording of "serverless" or "server" as Rob and Thomas have pointed out real technology and I believe market issues with such terminology.

I do think Ralph provided some new reqs we did not discuss in the design team that need to be part of the reqs doc per his exchange with Keith.  And configuration is pretty important and how many ways do we get to do it with IPv6 ??????????  

I am also very concerned about the use of anycast for servers?  I believe we can do it but right now our address arch spec says no way for anything but routers using anycast addresses and the issues Itojun has pointed out in his work on anycast.

I think we do need to revisit the entire purpose of the "O" bit and I think now it should be deprecated.  It will also make building a dhcp for IPv6 client much easier.  The dhcp for Ipv6 work is in very good shape.  More on that below.

One proposed solution I supported with Bob which did not make it was using RAs to send the node DNS Server related information so the client could connect to the DNS. 

But now we do have dhcp for IPv6 and implementations underway and the Information Request option can be built very lightweight to support DNS and some other pieces very well colocated with a Router or DNS Server.  There are other options too I won't go into just yet.  Or I could drift into a product discussion and thats not for here I hope.

Also HP and Linux have working dhcp for IPv6 code running and others are in process for real implementation input.

Lastly I am not clear cellular hosts won't want the dhcp for IPv6 process or application (Rob made a good technical and philosophical point about this too and both are part of our process) instead of stateless in many situations.

regards,
/jim

> From: Rob Austein [mailto:[email-masked]]
> Sent: Sunday, April 28, 2002 3:41 AM
> To: [email-masked]
> Subject: Re: Proposed IPv6 DNS Discovery Requirements
> 
> 
> At Fri, 26 Apr 2002 15:38:35 -0700, Bob Hinden wrote:
> > 
> > There are issues raised in solutions like this to insure that the 
> > co-located services are adequately tied together.  For 
> example in case of a 
> > "DHCP server in the DNS server" the processes need to be 
> tied together in a 
> > manner that the DHCP process would not provide the address 
> of the DNS 
> > server if the DNS server process was down.  Or that the 
> DHCP server not 
> > provide the addresses for other DNS serves unless it knows 
> that they are up 
> > and available.
> 
> I suspect that upon close examination all solutions will have issues
> along these lines (anycast certainly does).
> 
> In any case, I agree that such issues are part of the analysis.
> 
> > So I think the examples you raised do fit with the 
> definition.  My intent 
> > was that the requirements should allow for a of number different 
> > solutions.  Picking a specific solution requires evaluating 
> the strengths 
> > and weaknesses of the specific solution.
> 
> Ok, thanks.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 30 Apr 2002 14:24:28 +0200

> >>> 1. The DNS can inject a route.
  > >> please tell us the rfc or i-d which describes this
  > > => I wasn't aware that we need an id to tell
  > > us how to run a routing daemon on a node, do we?
  > 
  > i missed routing daemons in the dns protocols

=> Well it's not in the DNS protocols, so you
didn't miss anything. 
Any node can run a routing daemon and whether 
other routers will accept its routes or not will
depend on the security requirements of the domain,
right?

Hesham