Subject: RE: Addressing in ad-hoc scenarios [IPV6LL]

From: "Bound, Jim" <[email-masked]>
Date: Sat, 23 Aug 2003 01:39:28 -0400

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

---

From: Mika Liljeberg <[email-masked]>
Date: 23 Aug 2003 10:33:04 +0300

> But that can be done out of the IETF.

Ok, and I agree. Thanks for making your position clear on that.

It has been pointed out before that LLMNR falls back on advertising
link-local addresses when nothing else is available and, with a proper
API, it also disambiguates the addresses on multihomed nodes. This is
far from perfect and most probably not suited for anything
mission-critical. It does help in the cases where no connectivity would
otherwise exist at all, however. For non-mission critical things,
consumer devices that are likely to find themselves in various ad-hoc
scenarios, having this fallback is a good thing.

I suppose my question was really aimed at finding out whether it would
be a good policy to configure such devices with an additional fallback
address, such as a non-routable PI, rather than directly falling back on
the link-local address.

	MikaL