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
