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

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Tue, 08 June 2004 12:37 UTC

Received: from megatron.ietf.org (megatron.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22886; Tue, 8 Jun 2004 08:37:34 -0400 (EDT)
Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXfne-0002cp-H0; Tue, 08 Jun 2004 08:33:54 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXfgQ-0000IG-IF for dhcwg@megatron.ietf.org; Tue, 08 Jun 2004 08:26:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22499 for <dhcwg@ietf.org>; Tue, 8 Jun 2004 08:26:25 -0400 (EDT)
Received: from ietf-mx.ietf.org ([] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXfgQ-0003hh-0T for dhcwg@ietf.org; Tue, 08 Jun 2004 08:26:26 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXffS-00030Y-00 for dhcwg@ietf.org; Tue, 08 Jun 2004 08:25:27 -0400
Received: from necom830.hpcl.titech.ac.jp ([]) by ietf-mx with smtp (Exim 4.12) id 1BXfeh-0002He-00 for dhcwg@ietf.org; Tue, 08 Jun 2004 08:24:39 -0400
Received: (qmail 11203 invoked from network); 8 Jun 2004 12:18:54 -0000
Received: from yahoobb219001188015.bbtec.net (HELO necom830.hpcl.titech.ac.jp) ( by necom830.hpcl.titech.ac.jp with SMTP; 8 Jun 2004 12:18:54 -0000
Message-ID: <40C5B11F.2000301@necom830.hpcl.titech.ac.jp>
Date: Tue, 08 Jun 2004 21:29:19 +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: Mohacsi Janos <mohacsi@niif.hu>
References: <DAC3FCB50E31C54987CD10797DA511BA096341CF@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <40C57A46.2030805@necom830.hpcl.titech.ac.jp> <20040608130454.R73638@mignon.ki.iif.hu>
In-Reply-To: <20040608130454.R73638@mignon.ki.iif.hu>
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=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit

Mohacsi Janos wrote:

>>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.

ND is wrong, because it was designed to be applicable to all the
link types.

ND deployed multicast only because some ATM guy said NBMA was
capable of not broadcast but multicast, which is totaly denied
by the current ND RFC stating that ND may not be applicable to

> There is a clear need for better support to
> discover the link parameters, but it is necessary for mostly to the
> routing protocols.

If you are talking about QoS, it is a totally different topic.
>>However, with broadcast/multicast packets, there is no ACK for
>>an obvious reason.

> The IPv4 ARP is not better either, as you found.

No, ARP is no better, of course.

Given the point to multipoint nature of infrastructure WLAN,
and given the probability of hidden terminals, ARP is overkill.
Just send all the packets to the base station, IP address of which
should be piggy-backed in beacon.

As for ad-hoc WLAN, it does not work well with multiple link
hops that it is a bad idea at L2. 

> I think the WLAN should
> be improved some way to support multicast in some form.

It is inherent to CSMA/CA link that broadcast/multicast is

Our (IETF) approach has been to make IP work over as much link
technology as possible.

The solution has been never bother to have standard way of
address resolution.

> 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...

However, there are people who think ND should take care of
everything including DNS configuration.

>>ND needs, IMHO, a lot more.

> What do you think?

Because of its bloated set of features, I think ND hopeless.

							Masataka Ohta

dhcwg mailing list