On Fri, 2003-08-22 at 21:39, Keith Moore wrote:
> 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.
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.
> 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.
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.
> 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. 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
> 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 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.
> 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)
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.
> 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).
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.
> 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.
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 PROTECTED]
--------------------------------------------------------------------
