Subject: ND for link-local addresses on multi-homed hosts.

From: Peter Tattam <[email-masked]>
Date: Thu, 1 Jul 1999 20:59:33 +1000 (EST)

When trying to locate a known link-local address (for test purposes), I have
had trouble with ND over a multi-homed (more than one interface) host.

According to the ND specs, to find an address, one determines which interface
the dest address belongs and then does a ND on either the host or the next hop.

However for link-local addresses, no route will be found so the default
route processing would take place.  If a default gateway were available, the ND
for the link-local address would appear on the wrong interface, and hence I'd
never find the host.  If no default gateway were to be found, either a default
interface would be used or the dest would be unroutable.

I believe to correct my code, I need to process link-local addresses in a
special manner.

For link-local addresses, I would bypass normal routing table lookups and go
direct to the neighbor cache to look for the address to determine it's
interface and link layer address.

If the link-local address is already in the neighbor cache, then I know where
it is and can use the address directly.

If it is not, I would need to neighbor solicit all interfaces for the link
local address and wait for the neighbor advertise before sending the packet.

I would also have to defer filling in the source address until after the
neighbor advertise arrived as I don't know which interface the link-local
address is related to.  This could also be hairy for higher level protocols
that might want to know the source address before sending the packet...

While I thought this was a pathological case, it may not necessarily be so
for routers & tunnel servers.  It gets worse when the only source address
available for an interface is the link-local address.

Is it a requirement that unknown link-local addresses be reachable on
multi-homed hosts?

Is my asessment correct or have I missed an important RFC on the subject.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

--------------------------------------------------------------------
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: [email-masked]
Date: Thu, 01 Jul 1999 20:10:22 +0900

>interface would be used or the dest would be unroutable.

	I believe userland programs MUST specify outgoing interface by using
	advanced api, or sin6_scope_id (the behavior for latter one is rather
	vague on the document), for link-local addresses.  Otherwise kernel
	cannot disambiguate it in multi-interface node case.

	Once the userland program specifies interface to go out, your problem
	(in kernel) is solved.

itojun

---

From: Steve Deering <[email-masked]>
Date: Thu, 1 Jul 1999 07:47:08 -0700

>	cannot disambiguate it in multi-interface node case.

I would refine that a little bit to say: applications must provide a way
for the user to specify the outgoing interface (regardless of scope of
the destination address).  It would be convenient for a system to have a
notion of a "default" interface (e.g., the first non-loopback interface
instantiated at boot time, overridable by a system configuration command),
to be used as the outgoing interface for non-global destinations whenever
the application does not specify one.  This is how it has been handled
for IP(v4) multicast, which also has the interface-selection problem
when using non-global destination (multicast) addresses.

Steve

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 1 Jul 1999 20:56:58 -0700 (PDT)

> it is and can use the address directly. > 

That would work as long as the link-local addresses are unique across all
links, which is true for the IEEE 802 family. But e.g. with PPP you can
have the same (e.g. fe80::1) address appear on multiple interfaces.

Thus you need to have the applications specify the interface id for
this to work in general.

  Erik