[dhcwg] WLAN (was Re: IPv6 Host Configuration of Recursive DNS Server)
Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Tue, 08 June 2004 08:43 UTC
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11063; Tue, 8 Jun 2004 04:43:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXc8n-0000Wg-E0; Tue, 08 Jun 2004 04:39:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXc1x-0007d6-MS for dhcwg@megatron.ietf.org; Tue, 08 Jun 2004 04:32:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10288 for <dhcwg@ietf.org>; Tue, 8 Jun 2004 04:32:23 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXc1u-0004Mm-Pq for dhcwg@ietf.org; Tue, 08 Jun 2004 04:32:22 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXc0w-0003gp-00 for dhcwg@ietf.org; Tue, 08 Jun 2004 04:31:23 -0400
Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1BXc0B-00030q-00 for dhcwg@ietf.org; Tue, 08 Jun 2004 04:30:35 -0400
Received: (qmail 10129 invoked from network); 8 Jun 2004 08:24:50 -0000
Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 8 Jun 2004 08:24:50 -0000
Message-ID: <40C57A46.2030805@necom830.hpcl.titech.ac.jp>
Date: Tue, 08 Jun 2004 17:35:18 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja, en-us, en
MIME-Version: 1.0
To: dnsop-v6conf@nominum.com
References: <DAC3FCB50E31C54987CD10797DA511BA096341CF@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA096341CF@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Cc: V6OPS WG <v6ops@ops.ietf.org>, dnsop@lists.uoregon.edu, Jaehoon Paul Jeong <paul@etri.re.kr>, IPv6 WG <ipv6@ietf.org>, DHC WG <dhcwg@ietf.org>
Subject: [dhcwg] 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
Content-Transfer-Encoding: 7bit
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 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. 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. 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. Note that modifying WLAN protocol to use PIFS is not enough unless combined with frequent transmission. Masataka Ohta _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Re: IPv6 Host Configuration of Recursive … Jaehoon Paul Jeong
- [dhcwg] Re: IPv6 Host Configuration of Recursive … Jaehoon Paul Jeong
- [dhcwg] Re: IPv6 Host Configuration of Recursive … bmanning
- [dhcwg] RE: IPv6 Host Configuration of Recursive … Christian Huitema
- Re: [dhcwg] RE: IPv6 Host Configuration of Recurs… Ted Lemon
- [dhcwg] WLAN (was Re: IPv6 Host Configuration of … Masataka Ohta
- [dhcwg] Re: WLAN (was Re: IPv6 Host Configuration… Masataka Ohta
- [dhcwg] Re: WLAN (was Re: IPv6 Host Configuration… Mohacsi Janos