Subject: Re: ND on multi-homed nodes

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 02 Nov 1999 22:17:33 +0900

>>>>> On Sat, 30 Oct 1999 12:25:31 -0700 (PDT), 
>>>>> [email-masked] (Sam Manthorpe) said:

> I'm not following the list 100%, so my apologies in advance if this
> is a stupid/already answered question.  Address resolution of link-local
> addresses on multi-homed nodes appears to require neighbour discovery
> on all interfaces of that node.  I was wondering how others have
> decided to implement this as I would like to follow the norm (if
> there is one) for IRIX.

Our (KAME's) kernel basically requires a link identifier when the
kernel tries to resolve a link-layer address of an IPv6 link-local
address. If no identifier is given but there is a default route, the
kernel will just send packets to the default router without address
resolution (I don't think this is a good behavior, though). Otherwise,
the kernel will return an error.

> I see on a Solaris box we have (which is still running 2.5, so this
> may have changed) that there are multiple network routes allowed
> and there is a route for fe80::/10 for each interface.  I assume
> that stack performs ND for each route.  Is this how others have
> tackled this?

I don't think this (i.e. performing ND for each interface) is a good
approach, since uniqueness of link-local addresses is not guaranteed
at all when we consider more than one link; you could get NAs on
different links in response to an NS targeting a link-local
address. Which NA should we believe in such a case?

By the way, ND on different links itself is not fully specified in the
spec (i.e. RFC 2461) regardless of the scope of addresses in question,
IMHO. For example, APPENDIX A of the RFC says as follows:

   There are a number of complicating issues that arise when Neighbor
   Discovery is used by hosts that have multiple interfaces.  This
   section does not attempt to define the proper operation of multihomed
   hosts with regard to Neighbor Discovery.  Rather, it identifies
   issues that require further study.

I remember that someone (itojun?) pointed it out in the interim
meeting in Tokyo, but I'm not sure the result (if any).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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: Steve Deering <[email-masked]>
Date: Tue, 2 Nov 1999 06:02:20 -0800

At 10:17 PM +0900 11/2/99, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
>resolution (I don't think this is a good behavior, though).

Ah, here's another example of where a router might have to forward a
link-local-destined packet.  :-)

I think you ought to have a notion of a "primary" or "default" interface
that is used when the upper layer tried to send to a non-global address
but does not specify the outgoing interface or scope zone.  The same
concept is already needed for multicasts, for similar reasons.

Steve

---

From: Peter Tattam <[email-masked]>
Date: Wed, 3 Nov 1999 12:05:44 +1100 (EST)

> concept is already needed for multicasts, for similar reasons.

A thought on this...  I know this is probably a pathelogical case, but if the
transport layer can't work out which interface to send it, could it not start
an ND on all interfaces and then only use the one where the ND arrives.  If the
link local address is generated using auto config, the probably of a clash
would be low.  Also the information is likely to be in the ND cache already if
a node has already received a packet on one of the interfaces.  You might need
another ND state to identify ND probes which are speculative.

Peter

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 05 Nov 1999 01:40:39 +0900

>>>>> On Wed, 3 Nov 1999 12:05:44 +1100 (EST), 
>>>>> Peter Tattam <[email-masked]> said:

(I think you cited a different part of my mail from the one you
intended, so I removed it.)

> would be low. 

That's true, but the probability is not zero. I'd rather prefer the
idea of the default (or primary) interface, since it is easy to
implement, covers the most typical cases (as Francis said in another
thread), and is less confusing. However, IMO, it is implementation
dependent. If you prefer the "ND for each link" approach, I won't
oppose you.

> Also the information is likely to be in the ND cache already if
> a node has already received a packet on one of the interfaces.

Yes, but the essential point does not change; can we believe that the
cache entry designates the node that we intend? There maybe another
node on another link that has the same link-local address. This
example just means a variation of adopting the first received NA.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 05 Nov 1999 01:21:39 +0900

>>>>> On Tue, 2 Nov 1999 06:02:20 -0800, 
>>>>> Steve Deering <[email-masked]> said:

> concept is already needed for multicasts, for similar reasons.

I agree, and "the primary interface (or link)" is not so difficult to
implement; we only have to install an interface route for the prefix
"fe80::/10" towards the primary interface. We are about to implement
the notion of the primary interface in this way.

Thanks for your suggestion.

					JINMEI, Tatuya