Subject: RE: WLAN (was Re: IPv6 Host Configuration of Recursive DNS Server)

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 15 Jun 2004 12:50:52 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Masataka Ohta
> Sent: mardi 15 juin 2004 06:06
> To: Ignatios Souvatzis
> Cc: Jari Arkko; Pascal Thubert (pthubert); IPv6 WG; Pekka Savola; Greg
Daley
> Subject: Re: WLAN (was Re: IPv6 Host Configuration of Recursive DNS
Server)
> 
> Ignatios Souvatzis;
> 
> >>>I think we're straying from the original topic...
> >>
> >>I think that infrastructure WLAN is point (not all statsions but
> >>only the base station) to multipoint one.
> 
> > Radio, yes. Network, no. The base station creates the illusion of a
> > broadcast domain.
> 
> And the problem is that the illusion is not the reality.
> 
> Broadcast over the domain is a lot less reliable than unicast.

I'm not sure that the question is whether ND is good or poor, OSPFv3 is
good or poor, etc... All these protocols have proven their qualities in
the context they were designed for.

On the other hand, radios open a new world of problems, some of them
specific to the type of radio, which prevents them from being
efficiently abstracted as classical broadcast media. The link
availability is generally much poorer than classical links (even WAN).
The bandwidth is changing rapidly, the error rate is several orders of
magnitude worse then usual, the connectivity is at best of the
many-to-many type etc... 

For MIPv6 and DNA, we have a set of problems addressed at 802.21 about
the visibility of the various potential peers and the control of the
radio by L3. There's a lot of activity around what's being called the
radio layer 2.5; Should we change all the upper layer protocols, all the
radios, or is there a way to produce an adaptation layer between 2 and
3, which minimizes these changes... and what should the adaptation layer
be able to do?   

Another aspect of this problem is ethernet itself. ND over a broadcast
medium is not at its best in terms of performance for DNA related
functionalities, such as getting an address. Not arguing we should do
PPPoE either since it's still ethernet behind; but saying that the L2
abstraction we take should be as close as possible to the radio
operation, in order to minimize the aberrations caused by the emulation,
mostly when the emulation is not needed.

In many radio cases, the closest abstraction is to be found on serial
links. .11 APs are a hub and spoke model, matching some P2MP Frame relay
networks. Other radios add a notion of polling and require a stronger
flow control, reminding of SDLC. And it would be beneficial for Public
AP to be abstracted as PPP in order to reuse all the existing AAA... and
to get an address faster, with no DAD (so that's not only DHCP, but also
DAD, referring to the discussion between Masataka-san and Greg).

Summary is I'm not sure that this discussion is the right angle for the
right problem. Sorry about that. It's not even IPv6-over-foo. It's more
like what should a new foo-link provide to L3 in order to be more usable
than radios are today, and what should it manage by itself in order to
get there - at L2.5. Hints about that are already coming from .21 and L2
meshing.

Pascal

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Jun 2004 22:26:14 +0900

Pascal;

> the context they were designed for.

Though OSPF has its own problems, let's not discuss them here.

As for ND, what, do you think, is the context for which ND
was designed?

I recognize that ND is fine for 3Mbps Ethernet segment
containing 1000 immobile hosts, which will takes minutes
to boot.

However, with 100Mbps Ethernet segment with 10 hosts which
boot quickly and move frequently, which is a common context
today, ND is already poor.

Our goal is to run IP over various link types as efficiently
as possible.

Our non-goal is to have a single mechanism to run IP over
various link types ignoring link specific properties.

> On the other hand, radios open a new world of problems,

So, you are agreeing with me that radio is not a context for
which ND was designed. Right?

To me, WLAN happens to be a good example to show that ND is
a bad idea.

> some of them

Most of your concerns are not an issue at all for best effort IP.

> radio layer 2.5;

No, thank you. There is no such thing as layer 2.5

> Should we change all the upper layer protocols, all the
> radios,

No. All we need are link specific mechanisms to run IP.

It is called "IP over XXX", not layer 2.5.

> functionalities, such as getting an address.

"stateless autoconfiguration" is, of course, a wrong thing to do.

But, you are rather off topic.
 
> links. .11 APs are a hub and spoke model,

11 APs are 11 APs.

We don't need further abstractions to design IP over 11 APs.

> right problem. Sorry about that. It's not even IPv6-over-foo. It's more

It's your problem of insisting on layer 2.5.

It's simply IP over XXX.

							Masataka Ohta

---

From: Mohacsi Janos <[email-masked]>
Date: Mon, 21 Jun 2004 10:55:47 +0200 (CEST)

> To me, WLAN happens to be a good example to show that ND is

Please be constructive. Do you have better idea than ND or ARP for WLAN
type environment?  Do you have method to get Layer-2 address information
of your communicationg partner in WLAN? E.g Ask Access Point?

Regards,

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

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Jun 2004 20:54:50 +0900

Mohacsi Janos;

> Please be constructive.

First, we should discuss the problem to analyze the problem.

Then, we can be constructive.

Note also that, IMHO, ND is a destructive protocol discouraging
development of link specific protocols to accommodate IP.

That is, it is constructive to suggest to abandon ND.

> Do you have better idea than ND or ARP for WLAN
> type environment?

If you have followed the discussion closely, you should have
noticed that ARP is a lot better than ND in a typical
environment where WLANs are used as leaf of the Internet.

So, as a short term solution, I'd like to suggest to use ARP,
not ND, over WLAN.

As a long term solution, I already suggested

	1. periodic beacons from routers
	2. unicast request from hosts to routers
	3. unicast reply from routers

is the way to go.

However, I think most of ND specific (i.e., not available with ARP)
features, such as DAD, are difficult to be supported.

> Do you have method to get Layer-2 address information

See above.

							Masataka Ohta