> 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:
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 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
