Hi everyone, I agree with Juha at the point that our draft should focus on IPv6 DNS configuration rather than ND in WLAN. As Pekka suggested, an appendix seems to be really a good position for ND in WLAN. Pekka's rewitten pharagraph also looks good. I'll reflect them on our revised draft.
David, is another WGLC necessary on the basis of the revised (-04) version? Thanks. Paul ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, September 23, 2004 11:07 PM Subject: RE: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-configuration-03.txt > Hi, > > I think Pekka's suggestion drives this document to correct direction. In my opinion, > shortcomings of Neighbor Discovery in WLAN do not belong to the body of this > document. I think that the existing text in section 3.1 is overstating the problem > (if there is a practical problem at all...). > > BR, > -Juha W.- > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of ext Pekka Savola > Sent: 23 September, 2004 10:19 > > 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). > > 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!) > > . > dnsop resources:_____________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html > mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html > > . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
