Subject: naming in non-routed ad-hoc networks

From: Erik Nordmark <[email-masked]>
Date: Thu, 28 Aug 2003 23:28:21 +0200 (CEST)

Non-routed ad-hoc networks, and in particular multi-homing to such things,
have been discussed on the list but I don't recall seeing a discussion
of how naming could work in such a case, hence this post.
[Note I say "non-routed" because there is the MANET type world where
there are routers that glue together multiple links and I don't
think they have this issue.]

For a single ad-hoc link I can see LLMNR work as a naming protocol
(and link-locals or any other IP address can be used - doesn't matter
since all IP addresses must either be local to the link or be unreachable).
Thus the user or devvice could pick a name (e.g. "laptop" or 
"philips-coffee-maker") and check if any other node on the link is already
using that name (do an LLMNR lookup); if the name is already being used
pick another name ("eriks-laptop",
"philips-coffee-maker-serial-number-0345174").

Then LLMNR lookups would work just fine - users type "laptop" as the name; 
all assuming there is no multi-homed nodes.
This seems like a useful and harmful application of IPv6 in the small.

But when multihoming enters, in particular there are nodes which have
multiple interfaces enabled at the same time, then things get more
difficult.
Imagine the multihomed node has two interfaces and there are multiple neighbors
on each of those interfaces. On interface A a node might pick the name
"laptop" and another node might pick the same name of interface B without
conflict; the lookup for duplications can't be forwarded since there is no
router between the two links. In this case, independently of what addressing
and scope-ids, a application looking up the name "laptop" will have a
non-unique name.

So either the LLMNR type lookup needs to be relayed by the multihomed node
(seems to have all the usual loop avoidance issues plus the inability
to treat the links as different from a security perspective; somebody on some
less trusted link can prevent me from using a name on my more trusted link),
or there has to be some infrastructure that can make sure that the names
become unique across the two links (e.g. by handing out different name suffixes
for the two links). Alternatively this could be made a routed ad-hoc network
using DNS for naming and avoid the issue.

My point is that even with applications and/or APIs that deal with scope ids,
there is a difficult naming issue when multihoming is applied to non-routed
ad-hoc networks.
This seems to be a more basic issue than whether or not link-local addresses
can be used by the applications in this case.

  Erik

--------------------------------------------------------------------
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: Fri, 29 Aug 2003 01:54:55 +0300

> and scope-ids, a application looking up the name "laptop" will have a

I suppose it comes down to what one considers good enough. In practise
people will have to learn to pick names that have a very good
probability of being unique. Unique not only in the current situation
but also in any ad-hoc situation the user might run into during the
course of the day. Having to change the name of the device every time
the set of neighbors changes is a pretty good way of learning that words
like "laptop" are not particularly good choises.

The conflict resolution protocol is just a way of letting the user know
that a particular name is ambiguous in the domain that is currently
reachable. One of the users will then have to pick another name and
announce it to any other users who knew about the old name and were
using it. Having the conlict resolution protocol remove a name or change
it to something else will not remove the confusion, since the old name
will still be lodged into the minds of the people who need it.

Frankly, I don't see that having multiple intefaces makes all that much
difference.

	MikaL

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 29 Aug 2003 01:25:23 +0200 (CEST)

> Frankly, I don't see that having multiple intefaces makes all that much

The difference is that the names need to be unique not only on one link,
but across all interfaces connected to the multihomed host.

How would you expect conflict resolution to handle that?

   Erik

---

From: Joshua Graessley <[email-masked]>
Date: Thu, 28 Aug 2003 17:50:46 -0700

> but across all interfaces connected to the multihomed host.

Do they really? If so, how do we guarantee this? As you mentioned, some 
sort of conflict resolution protocol would have to allow a node 
straddling two networks notify nodes of conflicts. This is a very 
difficult problem to solve. For example, if there are two machines that 
are connect to the same wired network and wireless network, machine A 
may see responses from machine B on the wireless network as conflicting 
with the responses on the wired network from machine B. Machine A has 
no way to know that the responses are both from the exact same machine 
so this is perfectly valid.

> How would you expect conflict resolution to handle that?

I don't think this is something we can solve. I also don't think it is 
something particularly important to solve. There are a number of simple 
solutions that could work well. For example, if it was possible to 
append a name with the interface the query should be sent on (i.e. 
laptop%en0), this would give someone the ability to specify which 
"laptop" they were referring to in the case that just specifying laptop 
would not be enough. Specifying the name alone will often work in 99% 
of cases. Adding additional functionality to allow this to work for the 
additional 1% of the cases might be worthwhile. If requiring the 
protocol perfectly handle that last 1% (the edge cases) results in an 
impossible task, is it really worth throwing out the protocol that 
works for 99% of the cases just because we can't perfectly solve the 
edge case?

-josh

---

From: Mika Liljeberg <[email-masked]>
Date: Fri, 29 Aug 2003 08:37:16 +0300

> How would you expect conflict resolution to handle that?

The conflict only becomes relevant when a multhomed node tries to
resolve a name that is not unique across all its interfaces. When it
does that it will then receive responses from more than one interface
==> the conflict has been detected. It's then up to humans to fix it.

	MikaL

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 29 Aug 2003 23:43:40 +0200 (CEST)

> ==> the conflict has been detected. It's then up to humans to fix it.

But there are cases when this doesn't work.
For instance if you assume the devices with the conflicting names perform
the conflict detection protocol but have no mechanisms beyond this protocol
for the user to override the chosen name. 

Thus you seem to silently assume that these devices have a rich user interface
that would allow humans to fix this on the devices.
An alternative would be to be able to qualify the names on the multihomed
node e.g. "canon-camera@firewire1" where the part after the @ sign is
the interface on which to perform the name lookup. Thus it would be a local
convention, and the camera itself would know its name as "canon-camera"
only.

  Erik

---

From: Mika Liljeberg <[email-masked]>
Date: Sat, 30 Aug 2003 01:26:25 +0300

> that would allow humans to fix this on the devices.

Not exactly. I'm saying that if a device allows a user to name it, the
user is ultimately responsible for resolving any naming conflicts. If a
device does not provide a UI for this, then it should (preferably) have
a globally unique name in the first place.

> convention, and the camera itself would know its name as "canon-camera"

To my mind this is not really an alternative but one of the ways in
which the user might try to resolve the conflict once it has been
detected. I.e., if "canon-camera" comes back ambiguous, the device might
tell the user "Choose one of: 1) canon-camera@firewire1, 2)
canon-camera@bluetooth1". I think of this as device assisted conflict
resolution. The human user still has to make the decision.

In many cases this approach would be preferable to unconfiguring or
renaming one of the ambiguous names, which would potentially impact
multiple human users.

	MikaL