Subject: Addressing in ad-hoc scenarios [IPV6LL]

From: Mika Liljeberg <[email-masked]>
Date: 22 Aug 2003 20:54:36 +0300

As there appears to be some opposition to using IPv6LL for application
level connectivity in ad hoc situations, I would like to ask the WG what
is considered the best alternative and why people think that:

1) 	Use whatever routable address it may have configured earlier?

        A node that finds itself in an ad-hoc situation might continue
        using it's PA address for ad-hoc connectivity. This avoids
        having multiple addresses per interface which might confuse
        applications, but there are some problems as well. Unless the
        address is permanent it will eventually expire and leave the
        node without an address. The PA address assignment is also
        accompanied with topology dependent routing information (on-link
        prefix, default routers, any other routes) each of which have
        their own associated expiration times. These might prevent the
        node from communicating with other nodes in the ad-hoc context,
        causing it to send packets towards a non-existent router
        instead.
        
2)	Use non-routable PI?

        A non-routable PI address could be permanently assigned to a
        node. This avoids some of the problems with the associated
        routing information, as an appropriate on-link route could be
        permanently installed as well. Of course this isn't all that
        different from using link-local addresses, but at least the
        address would be unambiguous (with some probability).
        Non-(globally)routable PI's might be a good choise for routed
        ad-hoc networks as well.
        
3)	Use something else?

	What exactly? Pros and cons?

Our customer base is of the type that doesn't appreciate having to jog
the switch in order to make the thing start, so requiring any manual
intervention from the user is out of the question. The devices have to
be able to transition between connected and ad-hoc states quickly,
without undue fuss and with absolutely no guidance from the user. Having
applications sometimes break because the necessary connectivity is lost
is understood and acceptable. This must not happen due to IP layer
problems, however, if the necessary link layer connections exist.

I hope to see some constructive suggestions.

	MikaL

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Aug 2003 14:39:27 -0400

> level connectivity in ad hoc situations, I would like to ask the WG
> what is considered the best alternative and why people think that:

It's important to analyze two cases separately:

1. The case where a network is assembled "ad hoc", i.e. with no prior
arrangement and no management

2. The case where external connectivity is down but we want the apps
to keep working

You may have only one of these in mind, but it's been my experience
that people often have both of them in mind when they argue about ad
hoc networks, or they may want the same mechanism to address both cases.
That might be a perfectly reasonable desire (especially if hosts cannot
tell the difference between these two cases), but the analysis needs to
be done separately to make sure that both cases work.

Also, the question of what kind of address to use begs a number of other
questions - no answer makes sense without some set of supporting
discipline within hosts or apps, or in some cases, without support from
such infrastructure as might exist (e.g. bridges or routers) in the ad
hoc network.  So by attempting to answer the question one exposes
oneself to criticism about the missing pieces, which weren't part of
the question in the first place.  Frankly I haven't seen any set of
answers to this problem that seemed thoroughly worked out, and I'm not
even entirely sure that there's a satisfactory answer.  But I haven't
tried to follow every group working on some piece of this problem.

Now I'll actually assert that - at least for hosts that have wireless
interfaces - the two cases above are distinct, and that it's reasonable
to provide different answers for those two cases - for the simple reason
that you don't necessarily want a host trying to talk to every wireless
network that happens to be within reach.  The reason is that the host
has no basis for trusting those networks to deliver its packets or to
not send forged packets to it.  And for wired interfaces you are
required to perform some manual action - to at least plug in a cable -
to expect it to work at all.  So I conclude that class #1 ad hoc
networks can reasonably be treated differently from class #2 networks.

For the class 1 case, a randomly generated PI address would be
appropriate.  As I imagine it, each link would elect a randomly chosen
PI prefix, and all nodes on that link would use that prefix.  Routers
would learn about PI prefixes and advertise routes for them on the ad
hoc network (but if the network were then connected to the public
network the border routers would filter such routes). If connectivity to
the public Internet subsequently became available on that link, the PI
prefix might be deprecated in favor of a PA prefix, but it might still
make sense to use it with prefix substitution (as in
draft-moore-ipv6-prefix-substitution-aa-00.txt)

For the class 2 case, it would make some sense for the network to
continue using the last prefix(es) assigned to it; this would be the
least dirsuptive thing for apps and allow for smooth recovery when the
connectivity were regained.  If the local router(s) go down then RAs
stop being advertised; so in order to continue using those addresses
hosts would have to be able to make assumptions about the meaning of the
absence of RA without any indication that the old prefix was
deprecated, and to have a way to inform other (new) hosts on the link
about the prefix being used. If the routers stayed up, they could keep
advertising RA for that prefix, even though they lacked external
connectivity. An alternative would be to deprecate the external
addresses in favor of a PI address of some kind, either randomly chosen
or one pre-arranged for use in that network.

In either case what you want to do is to retain the ability to use the
old addresses for a reasonable amount of time (we need to specify what
is "reasonable" for this - taking both ad hoc networking and renumbering
into account).

It's clear that IPv6 wasn't designed with due consideration for ad hoc
networks, and that some changes will be needed to adequately support
such networks.  Again, if anyone has worked out all of the details, I
haven't seen it, and I certainly don't claim to have done so myself.
However I do think it's necessary to work out these details, and to make
the changes necessary, rather than simply assuming that one can "just
use LL" or "just use PI" or whatever.

Keith

---

From: Mika Liljeberg <[email-masked]>
Date: 22 Aug 2003 23:11:35 +0300

> be done separately to make sure that both cases work.

Both cases are indeed relevant. The same device might find itself in
either of these situations and a common solution to both would be
desirable, although not essential.

The transitions are also interesting. Basically any transition between a
case 1 situation, a case 2 situation, and a fully connected situation is
possible. Therefore, I think the solutions for case 1 and case 2 must be
at least complementary to each other. The transitions can be difficult
to detect, which probably means that the addressing solutions for case 1
and case 2 may have to overlap in time.

> tried to follow every group working on some piece of this problem.

I recognize the difficulty in providing a good answer but I feel the
question is justified, since people have expressed a strong sentiment in
the WG to place restrictions on how different types of addresses may be
used. I'm merely trying to clarify what those restrictions are.

> not send forged packets to it.

This is only partially true. While it is true that a node will typically
want to verify whether it is authorized to participate in a particular
wireless network, it requires connectivity to actually do that. Either
that or the user will have to intervene manually (undesirable). In
addition, there are valid use cases where security is not a concern.

>  And for wired interfaces you are

For some types of devices yes, but in general no. Pluggin and unplugging
a cable is something that is generally within the capabilies of the
average consumer. Anything more complex should be automated, though.

> draft-moore-ipv6-prefix-substitution-aa-00.txt)

Electing a PI prefix seems plausible enough in a scenario where the
ad-hoc network consists of a single link although I'm not sure I like
the idea of having to both run DAD and a prefix election protocol in
order to acquire an address usable for ad-hoc. It would seem more
convenient and less error prone to just permanently assign a static
non-routable PI.

In a routed ad-hoc network the situation gets more complex as it is not
necessarily possible to clearly identify what constitutes link. The set
of neighbors for node A is not necessarily the same as the set of
neighbors for node B even if A and B are neighbors. However, in the
interest of providing customers a usable solution during this decade I
would be happy enough to deploy something that at least solves 
the single link case. Routed ad-hoc networks will be a research topic
for a while yet, I fear.

> is "reasonable" for this - taking both ad hoc networking and renumbering

Keeping in mind what I said about transitions, all of the above would
seem to lead to a solution where a node might be required to retain its
routable address as well as possess a PI address in order to operate
reliably in different scenarios.

> use LL" or "just use PI" or whatever.

It would be nice to see some of this happen. While the bulk of the work
is a matter for another WG, the addressing issue clearly isn't.

	MikaL

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 22 Aug 2003 13:40:18 -0700

Mika Liljeberg wrote:
> > However I do think it's necessary to work out these details, and to 
> > make the changes necessary, rather than simply assuming 
> that one can 
> > "just use LL" or "just use PI" or whatever.
> 
> It would be nice to see some of this happen. While the bulk 
> of the work is a matter for another WG, the addressing issue 
> clearly isn't.

To some degree the discussion is restricting the potential solution space by
assuming that one has to choose between LL, PI, ??? . The state that was not
discussed was arriving at 2 because the router crashed, while a new node
comes up thinking the network must be in 1 because there is no RA. This is
not a problem as long as existing nodes keep both the LL & RA derived
prefixes, because the new node can talk to their LL address. The problem is
that if the existing nodes are forced to choose a single address, they
either break the existing app when the router crashes, or they refuse to
talk to new nodes until the router comes back up or the lifetimes expire. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Aug 2003 16:52:09 -0400

> > 1. The case where a network is assembled "ad hoc", i.e. with no
> > prior arrangement and no management
> > 
> > hoc networks, or they may want the same mechanism to address both
> > cases. That might be a perfectly reasonable desire (especially if
> > hosts cannot tell the difference between these two cases), but the
> > analysis needs to be done separately to make sure that both cases
> > work.
> 
> The transitions are also interesting. Basically any transition between
> a case 1 situation, a case 2 situation, and a fully connected
> situation is possible. 

Don't forget mobile ip and renumbering!  LOTS of transitions are
possible.

Naturally it's nice if the same mechanisms can work with different kinds
of transitions, and there's a strong motiviation to look for
similarities that can be exploited.

> > Now I'll actually assert that - at least for hosts that have
> > wireless interfaces - the two cases above are distinct, and that
> > it's reasonable to provide different answers for those two cases -
> > for the simple reason that you don't necessarily want a host trying
> > to talk to every wireless network that happens to be within reach. 
> > The reason is that the host has no basis for trusting those networks
> > to deliver its packets or to not send forged packets to it.
> 
> This is only partially true. While it is true that a node will
> typically want to verify whether it is authorized to participate in a
> particular wireless network, it requires connectivity to actually do
> that. 

yes, but it doesn't have to route to and from ordinary apps in order to
do that.

> Either that or the user will have to intervene manually
> (undesirable). In addition, there are valid use cases where security
> is not a concern.

I'm not sure about that.

What I can imagine is that if you already have exchanged keying material
with a particular wireless network and have decided to invest trust in
it, you don't necessarily need to manually initiate each transition to
or from using that network.

> > required to perform some manual action - to at least plug in a cable
> > - to expect it to work at all.  So I conclude that class #1 ad hoc
> For some types of devices yes, but in general no. Pluggin and
> unplugging a cable is something that is generally within the
> capabilies of the average consumer. 

The point is it is a detectable event that can help distinguish the two
cases.

> > appropriate.  As I imagine it, each link would elect a randomly
> > chosen PI prefix, and all nodes on that link would use that prefix. 
> > Routers would learn about PI prefixes and advertise routes for them
> > on the ad hoc network (but if the network were then connected to the
> > public network the border routers would filter such routes). If
> > connectivity to the public Internet subsequently became available on
> > that link, the PI prefix might be deprecated in favor of a PA
> > prefix, but it might still make sense to use it with prefix
> > substitution (as in draft-moore-ipv6-prefix-substitution-aa-00.txt)
> 

well, that's not exactly "ad hoc" is it?  I suspect we'd like to be able
to plug things in and have them "just work".  What I have in mind is
that you'd only have to do prefix election the first time a few hosts
found themselves connected to a link; after that, new hosts would learn
about the prefix used on that link from other hosts on that link.  Maybe
something like each host advertises the prefix on that link at random
intervals based on how many hosts were seen on the network - the more
hosts, the less frequent the advertisements.

> In a routed ad-hoc network the situation gets more complex as it is
> not necessarily possible to clearly identify what constitutes link.

sure it is.  you run the prefix election protocol over LL.  or what am I
missing?

> The set of neighbors for node A is not necessarily the same as the set
> of neighbors for node B even if A and B are neighbors. However, in the

perhaps.  for now I am happy if each link can choose its own prefix.
somehow I don't think it's that difficult for routers to sort out a
small number of ad hoc prefixes.

> > In either case what you want to do is to retain the ability to use
> > the old addresses for a reasonable amount of time (we need to
> > specify what is "reasonable" for this - taking both ad hoc
> > networking and renumbering into account).
> 
> seem to lead to a solution where a node might be required to retain
> its routable address as well as possess a PI address in order to
> operate reliably in different scenarios.

I think that's reasonable.  the trick then becomes how to define a model
that apps can use.  

> > It's clear that IPv6 wasn't designed with due consideration for ad
> > hoc networks, and that some changes will be needed to adequately
> > support such networks.  Again, if anyone has worked out all of the
> > details, I haven't seen it, and I certainly don't claim to have done
> > so myself. However I do think it's necessary to work out these
> > details, and to make the changes necessary, rather than simply
> > assuming that one can "just use LL" or "just use PI" or whatever.
> 
> It would be nice to see some of this happen. While the bulk of the
> work is a matter for another WG, the addressing issue clearly isn't.

of course, there are hazards associated with the separation.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Aug 2003 16:58:22 -0400

> > > However I do think it's necessary to work out these details, and
> > > to make the changes necessary, rather than simply assuming 
> > that one can 
> To some degree the discussion is restricting the potential solution
> space by assuming that one has to choose between LL, PI, ??? . The
> state that was not discussed was arriving at 2 because the router
> crashed, while a new node comes up thinking the network must be in 1
> because there is no RA. 

I did have exactly that transition in mind; what I thought I said was in
the absence of RA that hosts still on the network would have to inform
new hosts as to what prefix was assigned to that link.

> The problem is that if the existing nodes
> are forced to choose a single address, they either break the existing
> app when the router crashes, or they refuse to talk to new nodes until
> the router comes back up or the lifetimes expire. 

apps need to have stable identifiers for use in referrals.  that
doesn't necessarily mean that those addresses actually have to be used
on the wire.  my prefix substitution draft is one proposal for allowing
a different address to be substituted without impacting the app.  that
draft is intended to address a specific situation.  meanwhile I'm trying
to understand if there's a more general prefix mapping mechanism that
would allow fast and reliable mapping of stable identifiers to addresses
that are currently usable on the network, and what it would look like.

of course, as long as TCP and UDP use addresses as endpoint identifiers
there is a limit to how much functionality you can gain by substituting
addresses on an initial connection.

Keith

---

From: Mika Liljeberg <[email-masked]>
Date: 23 Aug 2003 00:10:34 +0300

On Fri, 2003-08-22 at 23:40, Tony Hain wrote:
> assuming that one has to choose between LL, PI, ??? .

I didn't mean to imply that this would be the only address assigned to
the node. What I wanted to ask was, what type of address should be used
in ad-hoc situations, regardless of what other addresses a node might
have.

>  The state that was not

I agree. Forcing a node to choose a single address is unworkable, as it
would require groups of communicating nodes to execute synchronized
transitions between addressing states. In ad-hoc scenarios the only
stable perspective is that of a single node. The environment consists of
other nodes and is constantly changing.

	MikaL

---

From: Mika Liljeberg <[email-masked]>
Date: 23 Aug 2003 00:42:49 +0300

> yes, but it doesn't have to route to and from ordinary apps in order to

That rather depends on what layer the authorization occurs. In ad-hoc
use cases involving proximity applications the decision to talk might
typically occur on the application layer between a group of nodes
participating in a particular application. For another application, a
different group of nodes might participate. IP layer connectivity in
this case is a free-for-all.

> > (undesirable). In addition, there are valid use cases where security

See above. Proximity applications are a good example.

> The point is it is a detectable event that can help distinguish the two

In the wired case, yes, but not necessarily in the wireless case (depend
on the link layer). Detecting changes in connectivity can be difficult
with technologies like 802.11 (ad-hoc mode).

> well, that's not exactly "ad hoc" is it?

Ad-hoc doesn't mean having a dynamic address. It means having a dynamic
environment.

>   I suspect we'd like to be able

You're missing the idea that with wireless devices there may not be a
clearly defined group of nodes that constitute a "link". The single-link
case could be defined as "all nodes in the area can directly communicate
with all the other nodes without requiring an intermediate node to
forward the packets".

The routed ad-hoc case, on the other hand is when not all nodes can talk
directly to each other, e.g. due to limited range or obstacles in the
line-of-sight path. Ie., A can talk to B, B can talk to C, but A can't
talk to C. Some paths might even be uni-directional, i.e. A can talk to
B but B can't talk to A (maybe A uses more power). In practise, ad-hoc
routing protocols discover the neighbor relationships between each node
and advertise host routes towards individual nodes. While you could
elect a prefix for every point-to-point link {X,Y} that's not really a
good solution. It's better to have a static unambiguous address that can
be advertised around as a host route. The non-routable PI would seem to
fit the bill, though.

> of course, there are hazards associated with the separation.

True. But it is not really appropriate to tell people to "go solve it in
another group" and only tell them that they have used an inappropriate
addressing scheme when they come back with a specification in two or
three years. :)

	MikaL