[dhcwg] Re: WLAN (was Re: IPv6 Host Configuration of Recursive DNS Server)

Mohacsi Janos <mohacsi@niif.hu> Tue, 08 June 2004 12:51 UTC

Received: from megatron.ietf.org (megatron.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23644; Tue, 8 Jun 2004 08:51:21 -0400 (EDT)
Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXfy5-0004sJ-3u; Tue, 08 Jun 2004 08:44:41 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXepY-00058c-IX for dhcwg@megatron.ietf.org; Tue, 08 Jun 2004 07:31:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19530 for <dhcwg@ietf.org>; Tue, 8 Jun 2004 07:31:47 -0400 (EDT)
Received: from ietf-mx.ietf.org ([] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXepX-0002rQ-TS for dhcwg@ietf.org; Tue, 08 Jun 2004 07:31:48 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXeoF-00024Z-00 for dhcwg@ietf.org; Tue, 08 Jun 2004 07:30:27 -0400
Received: from mignon.ki.iif.hu ([] helo=mail.ki.iif.hu) by ietf-mx with esmtp (Exim 4.12) id 1BXemz-0000bf-00; Tue, 08 Jun 2004 07:29:09 -0400
Received: from localhost (localhost []) by mail.ki.iif.hu (Postfix) with ESMTP id 7938D5686; Tue, 8 Jun 2004 13:28:37 +0200 (CEST)
Received: from mail.ki.iif.hu ([]) by localhost (mignon.ki.iif.hu []) (amavisd-new, port 10024) with LMTP id 73859-01-13; Tue, 8 Jun 2004 13:28:35 +0200 (CEST)
Received: by mail.ki.iif.hu (Postfix, from userid 1003) id B4BB85635; Tue, 8 Jun 2004 13:28:35 +0200 (CEST)
Received: from localhost (localhost []) by mail.ki.iif.hu (Postfix) with ESMTP id B24615518; Tue, 8 Jun 2004 13:28:35 +0200 (CEST)
Date: Tue, 08 Jun 2004 13:28:35 +0200
From: Mohacsi Janos <mohacsi@niif.hu>
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <40C57A46.2030805@necom830.hpcl.titech.ac.jp>
Message-ID: <20040608130454.R73638@mignon.ki.iif.hu>
References: <DAC3FCB50E31C54987CD10797DA511BA096341CF@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <40C57A46.2030805@necom830.hpcl.titech.ac.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Virus-Scanned: by amavisd-new at mail.ki.iif.hu
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
X-Mailman-Approved-At: Tue, 08 Jun 2004 08:44:34 -0400
Cc: dnsop-v6conf@nominum.com, IPv6 WG <ipv6@ietf.org>, DHC WG <dhcwg@ietf.org>, V6OPS WG <v6ops@ops.ietf.org>, dnsop@lists.uoregon.edu, Jaehoon Paul Jeong <paul@etri.re.kr>
Subject: [dhcwg] Re: WLAN (was Re: IPv6 Host Configuration of Recursive DNS Server)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org

Hi Masataka,

On Tue, 8 Jun 2004, Masataka Ohta wrote:

> Dear all;
> The problem is rather generic than DNS configuration. But...
> I know ND is wrong. That is, I know it is wrong to have generic
> link protocols ignoring link specific properties and has been
> pondering on how such protocols suffer.

I think ND is not wrong. There is a clear need for better support to
discover the link parameters, but it is necessary for mostly to the
routing protocols.

> I just recently noticed that WLAN (802.11*) is not very good at
> supporting ND (nor DHCP nor any broadcast/multicast protocol).
> Because WLAN use CSMA/CA, it needs ACK for reliable transmission
> by confirming that each packet reaches its destination without
> collision.
> However, with broadcast/multicast packets, there is no ACK for
> an obvious reason.

The IPv4 ARP is not better either, as you found. I think the WLAN should
be improved some way to support multicast in some form.

> If WLAN is lightly loaded, it is not a serious problem.
> However, if WLAN is heavily loaded, ND (and DHCP and any broadcast/
> multicast protocol) works poorly. Note that MIPv6 works poorly
> too.
> Still, management beacon frames are transmitted frequently
> and expected to carry information in a long run.
> So, it is possible to piggyback broadcast/multicast part
> of address resolution and autoconfiguration (maybe and
> routing) in reserved fields of beacon frames.

I think autoconfiguration can be treated differently, than address
resolution. ND as stand for "Neighbour" Discovery is a very good
improvement to ARP and transport specific things...
Of course ND can get into trouble if no reply for ND requests (with
soliticited node multicast address)...

> Though  it is possible to use some data frame frequently
> transmitted like beacon frams, it make the already congested
> WLAN worse.
> Anyway, the fundamental mistake is to try not to have link
> specific ways to perform address resolution and autoconfiguration.
> DHCP simply needs link specific ways of DHCP discover.
> ND needs, IMHO, a lot more.

What do you think?

> Note that modifying WLAN protocol to use PIFS is not enough
> unless combined with frequent transmission.

I agree.

Janos Mohacsi
Network Engineer, Research Associate
Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98

dhcwg mailing list