> 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.
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. > > 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. The point is it is a detectable event that can help distinguish the two cases. > > 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. 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 > 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. 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). > > 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. 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 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
