Mika, > 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: Most opposition is not documenting or making clear the problems that can occur from IPvLL use and right now I only see one. Duplicate IPv6LLs on two links for a multihomed node. We document security potential issues and we should do so for other functions too. That is all I am stating. But that can be done out of the IETF. > > 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. I believe that is what Neighbor Unreachable Detection (NUD) is for to help prevent that problem but that will work with IPv6LLs too and transparent to address scope. > > 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. Unambiguous address alleviates my issue for ad hoc networks. If a node has a greater than IPv6LL it should use that address. If it does not and the application can support a command line input of IPv6LLs then that is what must be done. IPv6LLs are not in the DNS. See default address selection by the stack below. > > 3) Use something else? If there is no router or dhcpv6 server there are few choices. > > 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. Applications can default to let the stack select the address and if link-local is all that is there then that is what will be used. But, if that address is IPv6LL on a multilink node how does the stack choose the link, how does it know which link? That is the problem. It can select the most recent IPv6LL communications, and then round robin if Destination Unreachable happens, but worst case scenario is the packet is delivered to the wrong node on the wrong link, because the stack guessed wrong. This problem persists even if all the Neighbor Advertisements received from each link were recorded with the sin6_scope_ID. It doesn't help the default link to select as destination in the stack or if it is input on a command line. In mission critical networks where that error can happen the solution is to use a link-unicast-global address that will not be ambiguous on the ad hoc network pre-configured to be used by each node when there is no router on the link. The moment a router advertisement is heard all nodes in this ad hoc network stop using the link-unicast-global address, begin picking up the prefix advertised. That is what the Hinden draft provides from my view. If it is not mission critical then not worrying about it has pretty good odds that if the worst case happens then the pain is not great enough for the user to preconfigure the link-local-global addresses. But regardless documenting it is important. /jim -------------------------------------------------------------------- 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] --------------------------------------------------------------------
