Subject: [Autoconf] Why the link definition?

From: "Seung Yi" <[email-masked]>
Date: Wed, 19 Nov 2008 08:12:56 -0800

During the meeting yesterday, Thomas Clausen mentioned that there were
a group of people who requested for the MANET link definition in a
previous IETF meeting. Maybe it's just me but could someone clarify
why one would need such a definition?

As far as I'm concerned, I had no problem working on a MANET
autoconfiguration design while considering a radio range (say,
something like a 3D sphere for an omni radio like 802.11) as the
replacement of a link. Only that, this new "link" had quite a few
non-traditional characteristics such as, (1) the fact I can reach node
B (therefore consider node B is on the link I'm on) doesn't mean I am
on the link he's on, or some would describe as link asymmetry, and (2)
the membership of other nodes on the link I'm on can change frequently
and drastically. ND works when the network condition allows two nodes
to actually share a view (or they can reach each other) and fails
otherwise, which is completely fine because "neighbors" can be
considered as two nodes that can reach each other at a point in time.
Flat routing works just fine also. Depending on the address
configuration, one can configure such a MANET as a set of nodes with
disjoint prefixes or as a multi-link subnet. BTW, as long as you have
a flat routing support, multi-link subnet works just fine. ND will not
discover all other nodes in the same subnet, but it'll still discover
all other nodes on the "link" I'm on. As mentioned in the meeting
yesterday, I also haven't yet run into any application misbehavior
because of the multi-link subnet configuration.

Is there any reason that two (or more) nodes need to share a common
view of a link to design anything?

Maybe these are basic questions but I just thought I would ask before
jumping into the discussion.

Thanks,

- Seung
_______________________________________________
Autoconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/autoconf

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Nov 2008 18:21:33 -0800

> considered as two nodes that can reach each other at a point in time.

When you say "ND" what exactly do you mean? Two nodes using NS/NA 
exchanges to discover the L2 addresses to use for direct communication?

The reason I'm asking for clarification is that I don't think that makes 
much sense when the link is defined as "within radio range", since that 
changes very frequently.

That is why link-local addresses, as well as NS/NA as used on Ethernet, 
is of very limited use on such networks.

But defining the link as a "within radio range" is AFAIK very useful for 
the routing protocols since they can use link-local communication 
(link-local addresses, and/or ttl=1) to find their neighbors.

    Erik

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 20 Nov 2008 05:59:42 +0100

> (link-local addresses, and/or ttl=1) to find their neighbors.

Just asking: what is the problem with using NS/NA exchanges to discover the
L2 addresses with the link defined as a "within radio range"?

Another question: do we need an "IPv6 Packets over WiFi" RFC? There are
expired I-Ds.

Teco.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Nov 2008 14:46:20 -0800

> L2 addresses with the link defined as a "within radio range"?

I don't what I said that made you think that is a problem.
Once you know that an address is on-link then there is no problem to use 
NS/NA to find out the L2 address.
But in a Manet in practice you might only end up using this for 
link-local address. The reason is that in order to know that a global 
address (any address that isn't link-local) is "reachable using one 
radio hop", you'd look at the Manet forwarding tables, and those tables 
might very well indicate the link-local address which is the IP next-hop 
to send the packet to. Hence you can just do the NS/NA for that 
link-local address (if you don't already have a neighbor cache entry for 
it.)

> Another question: do we need an "IPv6 Packets over WiFi" RFC? There are

WiFi tries to look like an Ethernet, which means that we can use just 
"IPv6 over Ethernet". But that might not be the most efficient way to do 
it. Thus it might be that draft-shelby-6lowpan-nd (as it evolves) will 
be something that will be useful for WiFi or even Ethernet in general.

    Erik

---

From: "Teco Boot" <[email-masked]>
Date: Sat, 22 Nov 2008 18:06:14 +0100

Hi Erik,

> link-local address (if you don't already have a neighbor cache entry

Fully agree! 
The question was more or less a motivation to write down which parts of ND
works well and which do not.
If we define address-resolution for L2-addresses / link-local addresses in
MANETs MUST work and address resolution may work, and we define that MANET
Routing Protocols MUST use link-local addresses, we are done. I raised this
issue in MANET, but little response at that moment.

> be something that will be useful for WiFi or even Ethernet in general.

I think it is important that IEEE and IETF agrees in how IPv6 is transported
over 802.11 links. I have equipment on my desk that is WiFi certified but
does not support IPv6. It has to do with bridging and MAC address mappings.
Cause could be that IPv6 is missing in IEEE 802.11-2007 tables M.2 and M.3
(WLAN - Ethernet translation). Somebody can work out something for himself,
but an RFC would help making sure everything is compatible.
Other issues: 
 - MTU size (what happens when 2000 octet frame arrives at access point?)
 - DAD and duplicate L2 addresses (see I-D.daniel-ipv6-over-wifi).
Note that L2 address cloning is quite common in some communities.

Teco.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Nov 2008 11:00:58 -0800

> but an RFC would help making sure everything is compatible.

I've been assuming that RFC2484 is sufficient even though it limits its 
scope to ISO/IEC 8802-3. The reason I think it is sufficient is that 
802.11 is normally bridged to 802.3 hence it better provide the same 
service model as 802.3.

>  - MTU size (what happens when 2000 octet frame arrives at access point?)

If 802.3 and 8702.11 are bridged together then IEEE 802 better have an 
answer.
If there is a router between them then standard IP routing as defined by 
the IETF applies.

>  - DAD and duplicate L2 addresses (see I-D.daniel-ipv6-over-wifi).

I can see that detecting duplicate L2 addresses is problematic. But one 
can still detect duplicate IP addresses when the L2 addresses are unique.

But I wonder why the IPv6 WG didn't do anything with that draft.

    Erik

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 25 Nov 2008 10:56:35 +0100

Hi Eric,

> 802.11 is normally bridged to 802.3 hence it better provide the same

With 802.11 in infrastructure mode, I think I can agree. Although there are
issues like MTU.

> If 802.3 and 802.11 are bridged together then IEEE 802 better have an
> answer.

OK, but I see two issues (at least):
 1 - 802.1D-2004 6.3.8 Maximum Service Data Unit Size
>>>> No attempt is made by a Bridge to relay a frame to a LAN 
>>>> that does not support the size of Service Data Unit conveyed 
>>>> by that frame.

Maximum Service Data Unit Size on 802.3 and 802.11 are different (1500 vs.
2304).
How can we make sure IPv6 can be used on WiFi networks, without bothering
users with all kind of MTU / MaxSDU size problems?
We could _assume_ RFC2464's 1500 default MTU size SHOULD be used on other
802 networks.
But with Dave Thaler his talk in mind, we could better specify our
assumptions.
We could think of using a MUST here.

RA MTU option would be a method to solve problems.
We could specify a router that has a link connected to a heterogeneous LAN
with 802.3 and 802.11 SHOULD send MTU options with MTU 1500. 

 2 - 802.1D-2004 6.5.4 Support by IEEE Std 802.11 (Wireless LANs):
>>>> A bridge shall not connect to an IEEE 802.11 Independent BSS.

I think this is important for MANETs, a router cannot be attached to an IBSS
WLAN bridge via an Ethernet link.
There are methods to solve problems here, e.g. using 4-address mode (DS To
DS: 1 From DS: 1).
This is to be addressed in IEEE, IETF is not primary responsible.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 25 Nov 2008 11:20:42 -0000

Teco Boot
> Erik Nordmark
>> The reason I think it is sufficient is that
> With 802.11 in infrastructure mode, I think I can agree.

Of course for a MANET, we may (are more likely to?) use 802.11 ad hoc
mode, and we need a model that will handle that.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 30 Nov 2008 18:20:38 -0800

> With 802.11 in infrastructure mode, I think I can agree. Although there are

I haven't tried with the implementation of WiFi I use, but I suspect 
because of the infrastructure mode being bridged to Ethernet, that the 
device driver reports the MTU as 1500 even if I'm in ad-hoc mode.

But this would be a good thing for an IPv4/6-over-802.11 document to 
specify.

> But with Dave Thaler his talk in mind, we could better specify our

Yes, it would be good to have this written down.

> RA MTU option would be a method to solve problems.

Sure, but there isn't a counterpart for IPv4 and in many cases folks 
want to make IPv4 as well as IPv6 work.

> with 802.3 and 802.11 SHOULD send MTU options with MTU 1500. 

But the router might not even know that the Ethernet is bridged to 
802.11. What we could recommend is that the administrator should 
configure such a router to send MTU options with 1500.

   Erik