On Thu, 9 Sep 2004, David Meyer wrote:
>
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-configuration-03.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.
[...]
> This Last Call will end on 23 Sep 2004 at 1400 PDT (UTC/GMT-7).
Unfortunately, I think this still needs a spin as my earlier comments
were not (IMHO) adequately addressed.
substantial
-----------
I already commented on the link-layer WLAN "bashing", and the text is
now better, but IMHO not sufficiently so.
Trying to pre-empt another revision cycle, let me try to suggest
something I wouldn't have problems with -- rewriting section 3.1 to
something like below (note new paragraphs -- the existing ones were
ridiculously long!):
RA approach is to define a new ND option called RDNSS option that
contains a recursive DNS server address. Existing ND transport
mechanisms (i.e., advertisements and solicitations) are used. This
works in the same way that nodes learn about routers and prefixes.
An IPv6 host can configure the IPv6 addresses of one or more
RDNSSes via RA message periodically sent by router or solicited by
a Router Solicitation (RS) [8].
This approach needs RDNSS
information to be configured in the routers doing the
advertisements. The configuration of RDNSS address can be
performed manually by operator or other ways, such as automatic
configuration through DHCPv6 client running on the router. When
advertising more than one RDNSS options, an RA message includes as
many RDNSS options as RDNSSes.
Through ND protocol and RDNSS
option along with prefix information option, an IPv6 host can
perform its network configuration of its IPv6 address and RDNSS
simultaneously [3][4]. The RA option for RDNSS can be used on any
network that supports the use of ND.
However, it is worth noting that some link layers (e.g., WLAN)
need to acknowledge multicast packets, which may increase the
amount of link-layer traffic. This is discussed in Appendix A.
The RA approach is useful in some mobile environments
where the addresses of the RDNSSes are changing because the RA
option includes a lifetime field that allows client to use RDNSSes
nearer to the client. This can be configured to a value that will
require the client to time out the entry and switch over to another
RDNSS address [8]. However, from the viewpoint of implementation,
lifetime would seem to make matters a bit more complex. Instead of
just writing DNS configuration file, such as resolv.conf for the
list of RDNSS addresses, we have to have a daemon around (or a
program that is called at the defined intervals) that keeps
monitoring the lifetime of RDNSSes all the time.
The preference value of RDNSS, included in RDNSS option, allows
IPv6 hosts to select primary RDNSS among several RDNSSes; this can
be used for load balancing of RDNSSes [8].
Appendix A - Link-layer Multicast Acknowledgements with RA option
One benefit of RA option has been to be able to multicast the
advertisements, reducing the need for duplicated unicast
communications.
However, some link-layers may not support this as well as others.
Consider, for example, WLAN networks
where multicast is unreliable. The unreliability problem is caused
by lack of ACK for multicast, especially on the path from the
Access Point (AP) to the Station (STA), which is specific to
CSMA/CA of WLAN. Namely, multicast packet is unacknowledged on the
path from the AP to the STA, but acknowledged in the reverse
direction from the STA to the AP. For example, when a router is
placed at wired network connected to an AP, a host may sometimes
not receive RA message advertised through the AP.
The fact that this problem has not been felt to be a problem in
Neighbor Discovery [RFC2461] indicates that the extra link-layer
acknowledgements have not been felt to be a serious problem,
at least until as of this writing.
A possible mitigation technique could be mapping all-nodes
link-local multicast address to the link-layer broadcast address,
and relying on the ND retransmissions for message delivery.
(feel free to gripe about the shortcomings of Neighbor Discovery in
WLAN environments in an appendix if you feel it's warranted, but
please don't do that in the body of the memo!)
editorial
---------
3.3 Well-known Anycast Addresses
[...]
==> I already commented on this, but I think it would be useful to use
'shared-unicast' -terminology instead, or at least refer to that to
disambiguate with "IPv6 anycast". After all, that's a good
terminology (coined in the IESG evaluation), based on
draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt.
I could live with 'anycast' here, but I'd think it would be confusing
especially if you don't mention "shared unicast" at all..
3.1.2 Disadvantages
1) 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 completed by a user-land process.
==> s/completed/complemented/
--
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
