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