Subject: RE: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-configuration-03.txt

From: <[email-masked]>
Date: Thu, 23 Sep 2004 17:07:04 +0300

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-masked]
[mailto:[email-masked]]On 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

---

From: "Jaehoon Jeong" <[email-masked]>
Date: Fri, 24 Sep 2004 10:32:21 +0900

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-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, September 23, 2004 11:07 PM
Subject: RE: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-configuration-03.txt

.

---

From: David Meyer <[email-masked]>
Date: Fri, 24 Sep 2004 08:56:37 -0700

>> David, is another WGLC necessary on the basis of the revised (-04) version?

	Yes. I want to make sure that this document is thoroughly
	vetted with the WG.

	Dave
.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 25 Sep 2004 07:57:09 +0900

Jaehoon Jeong;

It's not productive to revise the draft again and again, only
because the same person keep insisting on the point already
taken care of.

> I agree with Juha at the point that our draft should focus on IPv6 DNS configuration rather than ND in WLAN.

The point is that ND based IPv6 DNS configuration does not work,
at least not very well, over WLAN.

Or, if you think talking about specific link layer in the
draft is inappropriate, let's remove all the text about WLAN
and 3GPP.

> Pekka's rewitten pharagraph also looks good.

No, I don't think so.

							Masataka Ohta

.