On Fri, 2003-08-22 at 23:52, Keith Moore wrote:
> > > 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.
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.
> > 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.
See above. Proximity applications are a good example.
> > > 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.
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).
> > > 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?
Ad-hoc doesn't mean having a dynamic address. It means having a dynamic
environment.
> 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?
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.
> > > 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.
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
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
