Subject: [Autoconf] Try to eliminate term subnet?

From: "Teco Boot" <[email-masked]>
Date: Fri, 21 Nov 2008 00:15:58 +0100

All,

It seems that the term "subnet" is confusing.
So I can agree with Thomas C his draft, title Figure 5: MANET Subnet
Challenge

I think we make life more easy to get rid of confusing terminology.
Has someone a problem not using the term subnet in our documents? We know
what prefixes are (entities where we can route to) and what addresses are
(endpoint identifiers). Then we can work on the details on IPv6 address
assignments, which have IMHO nothing to do with the discussion on the term
subnet.

Just recap the proposal from Emmanuel, eliminating subnet:
- a prefix defines a contiguous range of IP addresses.
- a link is what lower layers reach without TTL decrement, through a given
interface.

In our charter, the term subnet is mentioned a few times:
===
The address autoconfiguration related protocol specifications such as
RFCs 2462, 2461, as used in traditional IP networks, assume that
subnet-local signals (e.g. link-local multicast signals) are received
by each of the hosts on the particular subnet without being forwarded
by the routers defining the subnet boundary. Hence, ad hoc networks
(as defined and understood by the IETF MANET WG) cannot use these
protocol specifications as-is.
===

I would read this as:
===
The address autoconfiguration related protocol specifications such as
RFCs 2462, 2461, as used in traditional IP networks, assume that
link-local signals (e.g. link-local multicast signals) are received
by each of the hosts on the particular medium without being forwarded
by the routers defining the medium boundary. Hence, ad hoc networks
(as defined and understood by the IETF MANET WG) cannot use these
protocol specifications as-is.
===
1st subnet -> link
2nd subnet -> medium
3th subnet -> medium

RFC4861 says that a link is a medium, which does not apply for RF
communication.
The description for a link in RFC4861 says link equals medium, but luckily,
it does not list RF spectrum as an example.
So if we refine our understanding of a link and / or communications facility
for RF, we are done.
Actually I am writing something down on what service 802.11-2007 provides
for the IP layer.

Regards, Teco

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

---

From: mase <[email-masked]>
Date: Fri, 21 Nov 2008 08:53:03 +0900

I strongly agree with not using the term "subnet". As I wrote, I 
think that subnet only introduces a lot of confusions.

Kenichi

---

From: Ralph Droms <[email-masked]>
Date: Thu, 20 Nov 2008 19:09:44 -0500

+1

"subnet" is overloaded in so many ways.

If it is used in a document, it MUST be clearly and carefully defined.

- Ralph

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 20 Nov 2008 16:23:25 -0800

Hello folks,

I am very nervous about not having a definition for the
term "subnet" for two reasons:

- If we don't define it, we must constantly be on watch to
    make sure it is not used, and to explain why it is not
    used.  This will be a battle of perpetual weariness.

- As difficult as it may be, a subnet would naturally be
    the unit of address allocation.  And, that's what we
    are tasked with doing in [autoconf].  Of course we
    could allocate addresses out of some random grab
    bag of addresses, but I'm willing to bet people would
    not like that.

Besides that, if we're willing to forgo the pleasure of
making a subnet map onto a pretend Ethernet, I think
it is manageable.

We have some candidate definitions that seem to
work.  Why not go forward with one of them?

Regards,
Charlie P.

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Fri, 21 Nov 2008 01:43:43 +0100

I agree with Charlie. I think we have no choice: we (in autoconf) must
unfortunately explain somewhere how we relate to the basic term "subnet", as
well as to the terms "prefix", "link" etc.Emmanuel

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Fri, 21 Nov 2008 01:49:32 +0100

That said, once properly defined in our context, we may not use the concept
as much as elsewhere...Emmanuel

On Fri, Nov 21, 2008 at 1:43 AM, Emmanuel Baccelli <
[email-masked]> wrote:

> well as to the terms "prefix", "link" etc. Emmanuel
>
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 20 Nov 2008 16:56:01 -0800

> That said, once properly defined in our context, we may not use the
concept as much as elsewhere...

Then, why bother saying it? Less is more...

Fred

[email-masked]

________________________________

From: Emmanuel Baccelli [mailto:[email-masked]] 
Sent: Thursday, November 20, 2008 4:50 PM
To: [email-masked]
Subject: Re: [Autoconf] Try to eliminate term subnet?

That said, once properly defined in our context, we may not use the
concept as much as elsewhere...

Emmanuel

On Fri, Nov 21, 2008 at 1:43 AM, Emmanuel Baccelli
<[email-masked]> wrote:

I agree with Charlie. I think we have no choice: we (in autoconf) must
unfortunately explain somewhere how we relate to the basic term
"subnet", as well as to the terms "prefix", "link" etc.

Emmanuel

On Fri, Nov 21, 2008 at 1:23 AM, Charles E. Perkins
<[email-masked]> wrote:

Hello folks,

Regards,
Charlie P.

Teco Boot wrote:

All,

I think we make life more easy to get rid of confusing terminology.
Has someone a problem not using the term subnet in our documents? We
know
what prefixes are (entities where we can route to) and what addresses
are
(endpoint identifiers). Then we can work on the details on IPv6 address
assignments, which have IMHO nothing to do with the discussion on the
term
subnet.

Just recap the proposal from Emmanuel, eliminating subnet:
- a prefix defines a contiguous range of IP addresses.
- a link is what lower layers reach without TTL decrement, through a
given
interface.

I would read this as:
===

RFC4861 says that a link is a medium, which does not apply for RF
communication.
The description for a link in RFC4861 says link equals medium, but
luckily,
it does not list RF spectrum as an example.
So if we refine our understanding of a link and / or communications
facility
for RF, we are done.
Actually I am writing something down on what service 802.11-2007
provides
for the IP layer.

Regards, Teco

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 20 Nov 2008 17:43:06 -0800

Hello Fred,

Templin, Fred L wrote:
> Then, why bother saying it? Less is more…
>

But, you didn't respond to the two points I had

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 21 Nov 2008 04:47:52 +0100

> > used. This will be a battle of perpetual weariness.

We can describe that subnet is not well defined and therefore we prefer less
confusing terminology.
I think if we try to define it, and fail, that this will be a battle of
perpetual weariness
Moreover, I prefer leaving this task for the 6man wg.

> > bag of addresses, but I'm willing to bet people would

I think we should use prefix delegation instead of "subnet address
allocation".
For now I do not see any reason not using DHCPv6-PD.
And maybe use DHCPv6 for the counterpart of stateless address
autoconfiguration (not using the quite confusing wording of "stateful
configuration", see RFC4862).

Teco.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 20 Nov 2008 20:36:44 -0800

Charlie,

>-----Original Message-----
>From: Charles E. Perkins [mailto:[email-masked]]
>Sent: Thursday, November 20, 2008 5:43 PM
>To: Templin, Fred L
>Cc: [email-masked]

OK, since you insist. Let's consider bringing the more
addressing-neutral term "subnetwork" into the terminology,
where a subnetwork is a connected routing region within a
MANET, and the MANET may contain many such subnetworks.

We then need a way of identifying each subnetwork, and
traditional approaches would call for assigning an
address/prefix on a subnetwork interface, where the
prefix is shorter than /32 (IPv4) or /128 (IPv6). But,
we already know that that is problematic for MANETs,
since the subnetwork can split (half going to partition
A and the other half going to partition B) and then
mayhem ensues in a number of ways.

So, let's instead have all routers in the subnetwork
configure a common "subnet router anycast" address
taken from a common IP prefix, but without assigning
any addresses from the prefix to a MANET interface.
So for example, we could assign the IPv6 prefix:
"2001:DB8:1:2::/64" to a subnetwork, and each MANET
router in the subnetwork assigns the IPv6 subnet router
anycast address "2001:DB8:1:2::" to its loopback
interface.

So, no MANET routers in the subnetwork have a unicast
IPv6 address assignment from the prefix, but all MANET
routers have the subnet router anycast address on their
loopbacks. The routers can retain the anycast address
even if the subnetwork partitions and keep it for as
long as it still makes sense for them to retain
membership to that subnetwork. If they want to join
other subnetworks too, that's OK - they just configure
additional subnet router anycast addresses.

We can now happily ping toward the subnet router anycast
address from anywhere, and the nearest MANET router will
answer us back. I call it the "no-subnet subnetwork model",
but I don't mind if we end up calling it something else.

Fred

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 20 Nov 2008 21:30:11 -0800

Hello Fred,

 From your discussion, I don't see your concern,
or where we should make any modification to
avoid difficulties.  More inline...

Templin, Fred L wrote:
>
>               Let's consider bringing the more

Here, one key operative word is "may"...   Or, the MANET may not
contain subnetworks.

> prefix is shorter than /32 (IPv4) or /128 (IPv6).

Check.  But, again keeping in mind this is specific to the
needs of the network.

>  But,

If this happens, the subnet is broken.  In real life, subnets
can break.  Then people wonder what happened.  It could
be that it would be more frequent in a MANET.  But:
(a) we _could_ have a MANET without any proper
     subnetworks
(b) there are cases where a stable subnet would exist.

> but I don't mind if we end up calling it something else.

Here, I am in the dark about why you would do this.

For one thing, if you have two different routers serving the
same subnet, they basically have to provide reachability to
the same hosts.  I do not see how you are doing this.
Unless of course there are no hosts on the subnetwork.
In which case, perhaps the conditions are all satisfied
vacuously.

In that case, it may be an interesting technical exercise,
but I don't see where it is guiding us, nor where it causes
the definitions to fail.

>>> bag of addresses, but I'm willing to bet people would

I also do not see how it answers the two concerns I raised.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 20 Nov 2008 21:37:01 -0800

Hello Teco,

> We can describe that subnet is not well defined and therefore we prefer less

A subnet is an appropriate range of addresses.  What's not well-defined 
about that?

> Moreover, I prefer leaving this task for the 6man wg.

What if they don't do it the way we need it, or make it more complicated?
Did they even volunteer to do this definition?

> I think we should use prefix delegation instead of "subnet address

Well, that's O.K. with me, but it will still be viewed as an
allocation related to managing the subnet.  And, anyway, what
if we want to allocate addresses from 168.254/16 for some
hoss on a disconnected MANET?  Who is delegating the
prefix?

> For now I do not see any reason not using DHCPv6-PD.

What if there's no DHCP server around?

> configuration", see RFC4862).

What if there's no DHCP server around?

Regards,
Charlie P.

PS. Is there an echo in here?

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Nov 2008 12:19:42 +0100

> making a subnet map onto a pretend Ethernet, I think

I gently beg to differ: I could live with 'subnet' defined in 
relationship with a specific link-layer.

For example, if we say that a wifi essid corresponds to a subnet, and 
vice-versa, then many people would probably understand same thing, there 
wouldn't be much confusion.  We could understand limitations in terms of 
subnet size based on the size of the wifi essid, and more.

If one tries to make a subnet different than the span of a wifi essid 
then one would describe:

-why does one assume only wifi to be MANET - maybe because
  experimentation happened that way?  That's ok, just say it.  One
  wouldn't extend the wifi experience to other untried media.
-why the essid-IPsubnet bijection is not enough, what's special about
  that particular essid.
-why can't one build a MANET with wifi links having one subnet per
  essid, what breaks when one builds a MANET with wifi links and one
  IPsubnet per ESSID?

I could depict a MANET with wifi links and a IPsubnet per essid, if that 
could help in some way.

Alex

>> Actually I am writing something down on what service 802.11-2007 provides

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
Autoconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/autoconf

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Nov 2008 12:30:23 +0100

Charles E. Perkins wrote:
> 
> Hello Teco,
> 
> Teco Boot wrote:
>>>> - If we don't define it, we must constantly be on watch to make
>>>> sure it is not used, and to explain why it is not used. This
>>>> will be a battle of perpetual weariness.
>>>> 
>> 
>> We can describe that subnet is not well defined and therefore we 
>> prefer less confusing terminology.
>> 
> 
> A subnet is an appropriate range of addresses.  What's not
> well-defined about that?
> 
>> I think if we try to define it, and fail, that this will be a
>> battle of perpetual weariness Moreover, I prefer leaving this task
>> for the 6man wg.
>> 
> 
> What if they don't do it the way we need it, or make it more
> complicated? Did they even volunteer to do this definition?
> 
> 
>> 
>> 
>>>> - As difficult as it may be, a subnet would naturally be the
>>>> unit of address allocation. And, that's what we are tasked with
>>>> doing in [autoconf]. Of course we could allocate addresses out
>>>> of some random grab bag of addresses, but I'm willing to bet
>>>> people would not like that.
>>>> 
>> 
> allocation related to managing the subnet.  And, anyway, what if we
> want to allocate addresses from 168.254/16 for some hoss on a
> disconnected MANET?  Who is delegating the prefix?
> 
>> autoconfiguration (not using the quite confusing wording of
>> "stateful configuration", see RFC4862).
>> 
> 

Charlie, I hear this like the question Christopher had previously: what
happens if there is no MAC repeater or long-range antenna extender to
extend a wifi network.

I'm afraid my personal answer to this is another question, if I'm 
permitted:  what if there's no that-something-yet-to-be-designed around?

This leads to much speculation, and one couldn't answer logically on it.
  I mean at least I couldn't.

Maybe better would be to find out what's wrong with having a DHCPServer
around?  Maybe in a MANET-inspired network all nodes are potentially
DHCPServers, so how would one elect _the_ DHCPServer?  I see this as
outlining a potential problem.

Alex

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 21 Nov 2008 07:41:16 -0600

Alexandru Petrescu wrote:
> [...]
> vice-versa, then many people would probably understand same thing,
> there wouldn't be much confusion. We could understand limitations in
> terms of subnet size based on the size of the wifi essid, and more.
I do not think MANET is limited to 802.11. There are many other link
layer technologies that form a perfectly good MANET, such as ethernet
for example.
> -why the essid-IPsubnet bijection is not enough, what's special about
I really don't think considering the ESSID is a good idea. It does not
really say anything about the connectivity of nodes. You could have
several IBBS with the same ESSID without being connected because they
are too far apart. Or they use a different channel. Or some stations use
WEP/WPA, others don't. So they would not necessarily be within the same
subnet. Personally, a subnet for me means that all stations within the
same subnet are on the same link, i.e. they can reach each other without
decrementing TTL. The other way round is not necessarily true, on a same
link there may be different subnets.
> essid, what breaks when one builds a MANET with wifi links and one
I do not think that there is any definition of a MANET that limits this
IP layer technology to 802.11. Nor should there be such a definition.
>
> I could depict a MANET with wifi links and a IPsubnet per essid, if
> that could help in some way.
>
> Alex
Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 21 Nov 2008 07:53:04 -0600

> I mean at least I couldn't.
I think Charlie's question is perfectly adequate. What does it mean to
use DHCP or DHCP-PD when you do not have a DHCP server around? Or if a
node cannot reach it... DHCP(-PD) could be a solution of MANETs in the
subordinate case, but it does not answer our fabulous questions: "What
is a link? What is a subnet?"
> outlining a potential problem.
I do not understand this. What does it mean that every node is a DHCP
server? There is no such thing as _the_ DHCP server. A DHCP server is
just an application that has a certain pool of IP addresses and can
assign on request one or several addresses / prefixes to a client.
We have to be careful not to enter in the solution space, because DHCP
may be part of an autoconf solution, but I do not think it helps us to
understand the architecture of a MANET or the relationship between
link/interface/subnet etc.

Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Nov 2008 15:00:28 +0100

Hi Ulrich,

Ulrich Herberg wrote:
>> [...] I gently beg to differ: I could live with 'subnet' defined in
>> For example, if we say that a wifi essid corresponds to a subnet, 
>> and vice-versa, then many people would probably understand same 
>> thing, there wouldn't be much confusion. We could understand 
>> limitations in terms of subnet size based on the size of the wifi 
>> essid, and more. If one tries to make a subnet different than the 
>> span of a wifi essid then one would describe:
>> 

Yes, one could use Ethernet to build MANETs.  The question is on whether
one has used Ethernet to build a small MANET and what were the issues of
using Ethernet to build such a MANET.  Was there any issue with a subnet
model?  Was that MANET any different than using Ethernet to build a
normal network (non-MANET), with respect to the IP subnet model?

>> -why the essid-IPsubnet bijection is not enough, what's special 
>> about that particular essid.
> 
> I really don't think considering the ESSID is a good idea. It does 
> not really say anything about the connectivity of nodes.

I beg to differ: all stations configuring same ESSID are within reach
with each other, at link-layer.  If they're not in reach is because they
are purposefully moved out of reach.

> You could have several IBBS with the same ESSID without being 
> connected because they are too far apart. Or they use a different 
> channel. Or some stations use WEP/WPA, others don't.

Ok.  Then we could refine the definition to say that all wifi stations
using same ESSID, within a 50m radius (that's a wifi typical
characteristic) and using same MAC address for that ESSID (that's
another typical wifi characteristic, it's the MAC address of the ESSID,
not of any other node) constitute an IP subnet.

What do you think are the characteristics of a well-formed
well-desitinguishable wifi link?

-same essid?
-same channel?
-same auth method?
-same MAC address of the link?

All of the above?  Only some combinations?  This is easy to define.

> So they would not necessarily be within the same subnet. Personally,
>  a subnet for me means that all stations within the same subnet are
> on the same link, i.e. they can reach each other without decrementing
>  TTL.

Link-IPsubnet equating constant TTL is fine with me.  But I'm afraid
this definition will not clarify the AUTOCONF path, simply because
defenders of the MANET characteristics claim this _may_ not be true in
MANETs.

> The other way round is not necessarily true, on a same link there may
>  be different subnets.

Different subnet prefixes on the same link - yes, yet TTL is constant on
each of these subnets.

> I do not think that there is any definition of a MANET that limits 
> this IP layer technology to 802.11. Nor should there be such a 
> definition.

I half disagree with you.

MANET experience should clarify which link-layer technology was
experimented.  It's nonsense to ignore completely the name of the
link-layer technology used in experimentation.

At the same time I agree that MANET-inspired networks were built with
other link-layer technologies than 802.11.  But these experiments, their
results, as well as the issues there may have been - have never been
reported here.  I don't think we can work with issues that are being
speculated upon.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 21 Nov 2008 06:00:34 -0800

>Sent: Thursday, November 20, 2008 9:30 PM
>To: Templin, Fred L
>Cc: [email-masked]

Even if there are no multiple subnetworks, the MANET will
still contain at least one subnetwork which is the MANET
itself.

>but I don't see where it is guiding us, nor where it causes

All right, then let's take the ISATAP approach. In ISATAP,
we can have multiple subnetwork border routers; each
advertising different on-link IPv6 prefixes on their 
ISATAP interface. MANET routers and hosts that receive
the prefix assign it to their ISATAP interface and use
SLAAC to configure an address from the prefix as-normal.
So, the MANET router/host can configure one or more on-link
prefixes on its ISATAP interfaces - one or more for each
subnetwork border router it receives an RA from.

Now, if the ISATAP link stays together we have normal use
of the on-link prefixes. If the ISATAP link partitions,
then the MANET routers and hosts in partition A that have
a subnetwork border router advertising 2001:DB8:1:2::/48
will retain that prefix and let all others time out, while
the nodes in partition B that have a subnetwork border router
advertising 2001:DB8:3:4::/48 will retain *that* prefix and
let others time out.

MANET routers can happily source packets either using the
address assigned to their ISATAP interface or an address
assigned to another non-MANET interface. Or, they can
forward packets on behalf of nodes attached to their
non-MANET interfaces. Simple hosts can source packets
using the address assigned to their ISATAP interfaces
only and would be exposed to address selection agility
in case of partitions, which is why simple hosts may in
some cases be better server by getting themselves attached
to a network reached by MANET router's non-MANET interface.

Does it work for you?

Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Nov 2008 15:10:56 +0100

Ulrich Herberg wrote:
>> Charlie, I hear this like the question Christopher had previously:
>>  what happens if there is no MAC repeater or long-range antenna 
>> extender to extend a wifi network.
>> 
>> This leads to much speculation, and one couldn't answer logically 
>> on it. I mean at least I couldn't.
> 
> I think Charlie's question is perfectly adequate. What does it mean 
> to use DHCP or DHCP-PD when you do not have a DHCP server around? Or
>  if a node cannot reach it...

Then what could one answer?  If there's no DHCP Server around then I
can't auto-configure an address using DHCP.  Or maybe I could use SLAAC 
(stateless autoconf), or maybe I could use link-local addresses - why not?

Are you going then to question 'what if there's no link-local addresses, 
and no slaac'?  What could one then answer?  Questioning the presence of 
such widely-available software is a paradox in itself.

The only reason I could understand when someone asks 'what if there's no 
DHCP Server' is to understand as 'what if there's no fixed 
infrastructure housing a DHCP Server, around that MANET?'  I can 
perfectly understand this, there are many cases of autonomous networks. 
  But within each autonomous network it's very easy to have a DHCP Server.

> DHCP(-PD) could be a solution of MANETs in the subordinate case, but 
> it does not answer our fabulous questions: "What is a link? What is a
> subnet?"
>> Maybe better would be to find out what's wrong with having a 
>> DHCPServer around? Maybe in a MANET-inspired network all nodes are
>>  potentially DHCPServers, so how would one elect _the_ DHCPServer?
>> I see this as outlining a potential problem.
> 
>  server?

Well I mean in a MANET built out of off-the-shelf linux machines, where 
each one can easily run DHCP Server software.

> There is no such thing as _the_ DHCP server. A DHCP server is just an
>  application that has a certain pool of IP addresses and can assign
> on request one or several addresses / prefixes to a client.

In a MANET with two servers each running a DHCP Server, and one DHCP
Client, which Server will the Client choose to send its DHCP Request to
(after having received two DHCP Advertise from two different Servers)?

> We have to be careful not to enter in the solution space, because
> DHCP may be part of an autoconf solution, but I do not think it helps
> us to understand the architecture of a MANET or the relationship
> between link/interface/subnet etc.

Careful yes,

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 21 Nov 2008 14:18:45 -0000

> link-layer technology used in experimentation.

If we were working with a single link layer technology, we'd
create the network at L2.

The point of working at L3 is to build an approach that is, as far
as possible, independent of the L2 technology. We do not wish to
be tied to one, or even a defined list, of L2 technologies, or
even one L2 technology at a time.

Consider the MANET protocols that exist in the IETF: AODV, DSR,
OLSR, TBRPF and now DYMO, OLSRv2 and SMF. Where in any of those
is there a specification of what L2 they are designed to run over?
At most they indicate what behaviour they want from L2 (such as
local broadcast, possibly link quality information, and so on).

One reason no one's getting into a discussion of what L2 technologies
they have used, or plan to use (apart from possible commercial and
other considerations) is that it would be a diversion down a blind
alley. The relevance of specific L2 technologies is for reasons such
as to illustrate specific points (such as the "B can communicate,
on a single interface, with A and C, but A and C can't communicate
directly and must relay through B - which can be illustrated by
802.11 on a single channel, single ESSID etc., but A and C physically
too far apart).

********************************************************************
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: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Nov 2008 16:08:26 +0100

Dearlove, Christopher (UK) wrote:
> If we were working with a single link layer technology, we'd create 
> the network at L2.
> 
> The point of working at L3 is to build an approach that is, as far as
>  possible, independent of the L2 technology. We do not wish to be
> tied to one, or even a defined list, of L2 technologies, or even one
> L2 technology at a time.

I can understand IP being able to run over multiple types of link-layer
technologies.  Stress that for each of those link-layers the behaviour
of IP over them is very well defined and understood (IP-over-foo RFCs).

This is completely different than assuming IP runs over _everything_ and
because everything isn't spelled out we don't know what's inside and
because of that ND/DHCP may not run over it.

> Consider the MANET protocols that exist in the IETF: AODV, DSR, OLSR,
>  TBRPF and now DYMO, OLSRv2 and SMF. Where in any of those is there a
>  specification of what L2 they are designed to run over?

I don't know, could you please say?

Do we know which link-layer tech was used to experiment AODV, DSR, OLSR,
TBRPF, DYMO, OLSRv2 and SMF?

> At most they indicate what behaviour they want from L2 (such as local
>  broadcast, possibly link quality information, and so on).

In expressing the expected behaviour it would be easier if they used
Ethernet terms, or other SDO terms.

> other considerations)

I was wondering about the commercial and possibly military
considerations which are not spelled out potentially due to obvious
confidentiality reasons.  Could one base public work on secret requirements?

One has seen a lot of silence in the WG recently, is that the
confidentiality aspect?

Alex

> is that it would be a diversion down a blind alley. The relevance of 
> specific L2 technologies is for reasons such as to illustrate 
> specific points (such as the "B can communicate, on a single 
> interface, with A and C, but A and C can't communicate directly and 
> must relay through B - which can be illustrated by 802.11 on a single
>  channel, single ESSID etc., but A and C physically too far apart).
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 21 Nov 2008 15:33:54 -0000

> This is completely different than assuming IP runs over _everything_

No, we're defining a general model for what a MANET runs over.
Not everything, just things that fit that general model.

Go back to RFC 2501. That approach is what we've been doing for the
last more years than I've been involved. This is really just attempting
to codify things.

> I don't know, could you please say?

That was a rhetorical question. There isn't any such statement in them.
At least not in terms of specific systems. That's intent, not accident.

> Ethernet terms, or other SDO terms.

Trying to use agreed terms is exactly what people are trying to do!
But trying to discuss what specific L2s is a blind alley you've headed
down.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Nov 2008 16:48:58 +0100

Christopher, thanks for message,

> At least not in terms of specific systems. That's intent, not accident.

If so, then I assume they work with existing auto-configuration 
mechanisms, because they make the same unspoken assumptions on the IP 
subnets as OSPF and RIP make, and these do work with existing 
auto-configuration mechanisms.

> Trying to use agreed terms is exactly what people are trying to do!

There doesn't seem to be agreement on a common term for 'subnet', 
subject of this topic being a reflection.  At the same time many people 
seem to agree on constant-TTL over an Ethernet.

> But trying to discuss what specific L2s is a blind alley you've headed

Let me try to express why this is not a blind alley.

There are real competitors for the IP-over-generalizedlink concept.  The 
competitors are the several SDOs designing links from ground up to the 
application - without using IP.  These links are for networks truly 
ressembling MANETs.  IP ignores them, SDOs ignore IP.  What gets 
deployed out there are these proprietary links without IP.

This is why I believe AUTOCONF stating the link-layer assumptions is not 
a blind alley, but rather a potential opening.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 21 Nov 2008 16:01:37 -0000

> mechanisms

That would be a bad assumption. If it were true, why would we need the
Autoconf WG?

Some work with static address configuration. Others do various
things. But if any autoconfigured addresses out of the box, with
unmodified existing protocols, with no issues, why would we be here?

> because they make the same unspoken assumptions on the IP 

False premise, false conclusion.

> There doesn't seem to be agreement on a common term for 'subnet'

The first word above is "trying", and in fact I accidentally said it
twice. Not yet succeeding.

> a blind alley, but rather a potential opening.

Again, you've made a jump from what I said, to what I didn't say.

I said discussing specific L2s was a blind alley. I didn't say
discussing
the characteristics of L2s was a blind alley. What do you think the
MANET
link type document was trying to do?

But again, this has diverged so far from being useful, that I will
stop here. Note that all questions above are rhetorical, if that
isn't obvious.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Nov 2008 17:13:13 +0100

Dearlove, Christopher (UK) wrote:
> That would be a bad assumption. If it were true, why would we need 
> the Autoconf WG?
> 
> Some work with static address configuration.

Do you mean manually adding an address to an interface?  Or link-local
IPv6 address forming over Ethernet (fe80-prepended addresses, rfc2464)?

> Others do various things. But if any autoconfigured addresses out of 
> the box, with unmodified existing protocols, with no issues, why 
> would we be here?

If we knew why people did these various other things (instead of
link-local addresses, or of slaac, or of dhcp) then we could understand
why we are here.  There sure were reasons, but which?

Could one quickly list a simple one?

Alex

---

From: Paul Lambert <[email-masked]>
Date: Fri, 21 Nov 2008 11:09:17 -0800

> From: Alexandru Petrescu
> Sent: Friday, November 21, 2008 6:11 AM
> To: Ulrich Herberg
> Cc: [email-masked]
> Subject: Re: [Autoconf] what if there's no DHCP Server around?
>
> Ulrich Herberg wrote:

There are several issues with using DHCP in mobile devices:
1) in an ad hoc network ... there may not be a consistently available single device - yes, it's hard to know which one to elect
2) ad hoc connectivity makes it impossible to pick a viable routable subnet
3) multicast may not have the full connectivity expected and is not always reliable for discovery
4) It's hard for users to configure (imagine setting the DHCP server settings on your Wi-Fi enabled camera)

Note - I'm currently working with consumer device manufacturers to field ad hoc wireless products.  IP address assignment is an issue ... and we may end up fielding proprietary protocols.

Link local might work ... but also has an issue with multicast ... and needs some enhancements.

Are there other proposals or protocols available for IP address assignment in ad hoc wireless networks?

Paul

---

From: "Emmanuel Baccelli" <[email-masked]>
Date: Fri, 21 Nov 2008 21:08:50 +0100

On Fri, Nov 21, 2008 at 8:09 PM, Paul Lambert <[email-masked]> wrote:

> 1) in an ad hoc network ... there may not be a consistently available
> single device - yes, it's hard to know which one to elect
> Note - I'm currently working with consumer device manufacturers to field ad
> hoc wireless products.  IP address assignment is an issue ... and we may end
> up fielding proprietary protocols.
>

There is SLAAC (RFC 2462). But you run into other problems with it on ad hoc
networks, due to link properties in this context.
Emmanuel
_______________________________________________
Autoconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 21 Nov 2008 18:08:33 -0800

Hello Paul,

> Are there other proposals or protocols available for IP address assignment in ad hoc wireless networks?

Yes!  We've been arguing about subnets and links for so long,
maybe people forgot why the working group was formed!

There are some very interesting and some very straightforward
approaches.  These systems have been built and tested and found
to be worthwhile.  That was why we started the group, in the
belief that a standard approach would create new markets for
ad hoc networks, as well as providing new insights.  Ryuji and I
published what I thought was a very valuable approach lo these
many years ago.

I do not want to sound bitter, but the people complaining the
most about lack of architecture do not seem to have contributed
any of their solutions or experience with implementations.

So I want to get past this definitional phase in a very
definitive way, by actually identifying definitions that will
satisfy even the most demanding aficionado of architectural
correctness.  This does _not_ mean sweeping anything
under the rug. It means being correct, relevant, persuasive,
coherent, and unyielding to the temptations of basing the
definitions upon how many angels can dance on the head
of an ad hoc pin.

Regards,
Charlie P.

PS. I guess your note just reminded me of how long
       it has been.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Nov 2008 15:02:57 -0800

>    used.  This will be a battle of perpetual weariness.

The best way to handle that is to get community consensus around the 
fact that we have cases when there is an address prefix which isn't 
on-link for any link, hence we don't have "subnet prefixes".

If it is helpful I can draft a short I-D for the 6man WG on this.

>    bag of addresses, but I'm willing to bet people would

A think a prefix (or set of prefixes) is the natural unit of address 
allocation.

RFC950 defines a "subnet" as both being a unit of address allocation and 
part of the mechanism to determine what is on-link. (It doesn't use the 
term on-link, but the actual description is what RFC4862 calls on-link; 
can deliver packet at L2.)

Given that is how "subnet" is used it doesn't make sense to reuse that 
term to be the prefix for address allocation across a collection of 
links, since that would conflict with the on-link property.

Thus from a terminology perspective we can't reuse "subnet" to be the 
prefix from which autoconf allocates addresses.

    Erik

---

From: Paul Lambert <[email-masked]>
Date: Mon, 24 Nov 2008 17:01:07 -0800

Hi Charlie,

Glad to hear from you that there are some viable worked solutions.  As a recent lurker to the group, it's hard to tell where to start to build a real product so your guidance is really appreciated

I'm looking largely at single hop mesh and single direct connect ad hoc.  Routing is not so important as basic services between devices for the use case I'm pursuing:

So given this use case ... I see that forwarded multicast might be useful:
draft-ietf-manet-smf-08.txt

This requires you to discover your neighbors:
draft-ietf-manet-nhdp-07.txt

Now you still need an IP address.  Is forwarded mulicast to support existing mechanisms enough or is something else needed?  I've seen a few proposals (expired RFCs) ... is there consensous in the group  on a particular approach

> From: Charles E. Perkins [mailto:[email-masked]]
 ... clip

> any of their solutions or experience with implementations.

I do agree that the pace appears to be slow ...  I suspect it's not this forum, but the industry as a whole that has been slow to adopt useable "ad hoc" solutions.  Ad hoc has been overshadowed by more simple star topologies.  I'm hoping that there is still a window to get out a ad hoc products :-)

Regards,

Paul