Subject: Re: [dnsop] WGLC for "IPv6 Host Configuration of DNS Server Information Approaches"

From: Pekka Savola <[email-masked]>
Date: Wed, 7 Jul 2004 11:35:20 +0300 (EEST)

On Wed, 16 Jun 2004, David Meyer wrote:
> 	ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-configuration-01.txt
> 
> 	Please review the document carefully, and send your
> 	feedback to the list.  Please also indicate whether or
> 	not you believe that this document is ready to go to the
> 	IESG. Note that this is a somewhat unusal case as the
> 	IESG requested this document.

A few comments below.  In general, I think the document was pretty
good, and with some amount of tuning should be "good enough".

....

This approach has an issue that the DNS
   information needs to be configured in the routers doing the
   advertisements.  The configuration of DNS server address can be
   performed manually by operator or automatically DHCPv6 client
   running on the router.

==> as discussed separately, and commented by Ted Lemon on the list on Jun
22, configuring the DNS information may or may not be an issue.

RA approach is
   light-weight especially in wireless environment where RA message is
   used for IPv6 address autoconfiguration, such as cellular networks.

==> I recall Hesham Soliman saying on IPv6 WG list that the /64 is assigned
on a cellular node with the v6 PDP context activation?  That is, he argued
that there's no need for proxy-ND on the cellular node, as the /64 is
assigned independently.  The only way to interpret AFAICS is that ND is not
used for SLAAC on those hosts, or we were talking of different things.

   The RA approach is useful in environments where the addresses of
   the recursive DNS servers is changing because the RA option
   includes a lifetime field.  This can be configured to a value that
   will require the client to time out the entry and switch over to
   another recursive server address [5].

==> This assumes, I think, that the ultimate RA option will include the
lifetime field, of course ;-).  Looking at it from the implementation
point-of-view, lifetime would seem to make matters a bit more complex. 
Instead of just writing resolv.conf (or equivalent) and being done, you'll
have to have a deamon around (or a program that's called at the defined
intervals) that keeps monitoring the lifetime of the servers all the time.  

I'm not saying that lifetime is bad, but it seem like a non-trivial
exercise, and to be more in line with the rest of the ND framework, it would
be better if it wasn't there. (typically, the IP addresses which do have
lifetime are handled quite a bit differently in the systems than DNS
servers..)

3.1.2 Disadvantages
                                                                                                                                        
   ND is mostly implemented in kernel part of operating system.
   Therefore, if ND supports the configuration of some additional
   services, such as DNS, NTP and SIP servers, ND should be extended
   in kernel part and need kernel compilation.  DHCPv6, however, has
   more flexibility for extension of service discovery because it is
   an application layer protocol.

==> The kernel part extension has a (minor) point, but the compilation issue
doesn't seem too convincing to me.  However, this doesn't spell out IMHO the
real thing being in kernel causes.  I.e., writing and rewriting resolv.conf
from the kernel is probably unacceptable, and much easier if done by the
user-land process.  Of course, one approach to solve this is to have a
daemon listening to what the kernel conveys, and have the daemon do these
steps -- but such a daemon is not necessary with the current ND framework!

   3) DHCPv6 allows for the configuration of a host with information
   specific to that host, so that hosts on the same link can be
   configured with different DNS recursive name servers as well as
   other configuration information.  This capability is important in
   some network deployments such as service provider networks or WiFi
   hotspots.

==> how is this important e.g., on WiFi hotspots?  I'm not sure if I know
what kind of host-specific things you're referring to here, maybe elaborate
a bit ?

   5) Hosts in some environments are likely to need DHCPv6 for other
   configuration information.

==> this is a rather vague statement (and a strong one, when true) -- would
it make sense to try to clarify it a bit more? ("some environments" in
particular).

  7) Interoperability among independent implementations demonstrated
   at TAHI and Connectathon.

==> s/demonstrated/has been demonstrated/

   DNS clients have redundancy by having multiple resolvers that there
   should be multiple well-known anycast addresses configured on
   clients.

==> something missing before 'that' ?

4. Interworking among IPv6 DNS Configuration Approaches

==> this takes no stance on interworking/precedence when O bit is set, *and*
RA includes an RDNSS option ?

In
   order to fly anycast approach with the other solutions, there are
   three options.

==> should you try to summarize if any of these approaches is preferable, or
something?  Currently, you make no recommendations or provide any analysis
on which approach would be best?

5.1 ISP Network

==> you need to be clearer where whether you're talking about distributing
DNS information from the PE (or some other router) to the CPE, from CPE to
the customer, or what.  Also remember that there isn't necessarily a CPE
router in the network at all.. (dial-ups, bridge-mode xDSL, etc.).

5.1.1 RA Option Approach
                                                                                                                                        
   RA extension for recursive DNS server can be used to allow a host
   to get its recursive DNS server as well as IPv6 prefix at the same
   time through a new DNS option [5] within RA message when the host
   is attached to a new subnet.

==> are you making some assumption about prefix delegation (if prefix = /48)
or advertisement (if prefix = /64) here?  As it is, there is no adopted
mechanism to have RA provide the prefix at the same time (unless you meant a
/64 advertisement).

5.4.1 Case A: Gateway does not provide IPv6 at all

==> shouldn't this be mostly a non-op in this discussion?  I mean, if the
gateway doesn't provide v6, then some node inside the network must be
dual-stack to do tunneling.  If a node needs to be dual-stack, it can use
IPv4 DNS servers without problems.  Or are you concerned that in such a
network where v6 support is not provided there would be v6-only hosts in the
network?  In that case I guess you're down to the case where the customer
has a node which is set up as a dual-stack router.

5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP
                                                                                                                                        
   This is similar to a typical IPv4 home user scenario, where DNS
   configuration parameters are obtained using DHCP.  Except that
   Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the
   DHCP server is stateful (maintains the state for clients).

==> again, are you talking of PE-CPE config or CPE-customer config?  Again,
do you assume /64 prefixes or how do you envision prefix delegation being
done?

5.4.3 Case C: A dual-stack gateway connected to an IPv4-only ISP
                                                                                                                                        
   This is similar to Case B.  The tunnel for IPv6 connectivity
   originates from the dual-stack gateway instead of the host.

==> did you mean similar to case A?

5.4.4 Case D: A gateway connected to an IPv6-only ISP
                                                                                                                                        
   This is similar to Case B.

==> not quite?  the gateway either has no v4 at all, and can't act as a "DNS
proxy", or it has a tunnel some other ISP else where it can send v4 packets.

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

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Suresh Satapati <[email-masked]>
Date: Wed, 7 Jul 2004 11:20:10 -0700 (PDT)

Pekka,

> IPv4 DNS servers without problems.  Or are you concerned that in such a

In this document, we are interested in "IPv6" (but not IPv4) DNS Server
config approaches. I do agree with your statement that hosts can use
IPv4 DNS servers, but that isn't what we are concerened about here.

> has a node which is set up as a dual-stack router.

Agreed. Which is why we'd need the config mechanism has to be some form
of a tunnel.

> do you assume /64 prefixes or how do you envision prefix delegation being

Is there a value in dissecting further ? I thought Stateless DHCPv6
spec does describe how to do this.

> ==> did you mean similar to case A?

I originally wrote 'case A'. I think Jeong changed it based on Christian's
comments. I have to go back and read what his comments were..

> proxy", or it has a tunnel some other ISP else where it can send v4 packets.

Again, are we interested in IPv4 at all here ? If not, I dont think the
current text should change.

.

---

From: Tim Chown <[email-masked]>
Date: Thu, 8 Jul 2004 14:46:58 +0100

> IPv4 DNS servers, but that isn't what we are concerened about here.

Except that this whole IPv6 DNS discovery issue has slipped because people
have been relying on the crutch of IPv4 DNS transport.

Tim
.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 14 Jul 2004 14:55:26 +0300 (EEST)

> IPv4 DNS servers, but that isn't what we are concerened about here.

OK, but..

> Agreed. Which is why we'd need the config mechanism has to be some form

.. this probably has an impact if you consider the mechanisms for 
configuring the CPE or the node acting as v6 CPE.

For those nodes inside the network .. there's probably little 
difference.

> spec does describe how to do this.

The text above needs to be clearer whether you thought to apply 
stateless DHCPv6 to configure the parameters on the CPE, or to apply 
it to configure the parameters at the nodes in the network.

This also has a connection with prefix delegation (with DHCP), as it
requires full DHCP, not stateless.

> comments. I have to go back and read what his comments were..

OK

> current text should change.

There is a difference if you consider how you would configure DNS
servers on the CPE.  If the CPE has v4 capability, you don't need to
(but you still can), as the CPE could act as a resolver.  If it
doesn't have v4 capability, it needs to be configured with an address
of a recursive resolver.

.