Subject: Mixed Host/Router behaviour

From: Pekka Savola <[email-masked]>
Date: Fri, 4 May 2001 09:00:39 +0300 (EEST)

Hi,

I don't think the more complex scenario of Router/Host has been discussed.
If so, please provide a pointer.

Consider a system where SERVER wants to have a shortcut into LAN1 (but not
forward traffic from it):

LAN0  ---  eth0 SERVER tun1 - - - ROUTER ----> Internet
                 eth1               |
                  |                 |
                 LAN1 --------------^

(this is a scenario where server acts as a router for LAN0, and uses
LAN1 to e.g. mount NFS shares off a server there ("nfs interface"))

Now, this would appear to be rather problematic.  Some items for a router
include among others setting IsRouter flag in NA's and responding to RS's.
These seem to be usually implemented as global toggles; either the system
is a router or it is not.

This creates problems in the above scenario because:
 - SERVER should act as a router toward eth0 and tun1
 - SERVER MUST NOT be used to forward traffic from LAN1.
    * IsRouter flag off
    * Not answering to RS's
    * Etc.
    * Whether this should be able to accept RA's (to autoconfigure the
prefix, but not otherwise modify the routing table) is open to discussion;
on a "primarily" router, it would probably be acceptable to having to
configure it manually.

Has these kind of "mixed" scenarios been thought of?  I'm sure this is not
the only one...

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
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: Erik Nordmark <[email-masked]>
Date: Fri, 4 May 2001 12:02:09 +0200 (MET DST)

> is a router or it is not.

This seems to be an implementation bug since RFC 2461 says that all the
configuration knobs are per interface.

  Erik

---

From: [email-masked]
Date: Fri, 04 May 2001 19:21:36 +0900

I may need to reread the whole thread to understand the context, but...

>configuration knobs are per interface.

	could you point me to the text where it is specified as a
	"per-interface knob"?

	in KAME stack (I guess Pekka is referring to KAME), per-host
	"forwarding" flag decides whether it is a router or not (there's no
	"interface A and B are host, interface C and D are router" kind of
	configuration), and it affects outgoing IsRouter bit on NS/NA.

itojun

---

From: [email-masked]
Date: Fri, 04 May 2001 19:27:03 +0900

>	I may need to reread the whole thread to understand the context, but...

	aha, I found the original message.

>	configuration), and it affects outgoing IsRouter bit on NS/NA.

	we do not implement "partly host, partly router" behavior.
	also, since RFC2462 basically assumes single-interface host,
	we do not really care about the following cases:
	- autoconfigured host with multiple interfaces
	- chimera (part-host, part-router) node
	- autoconfigured router

	we care about the following cases:
	- autoconfigured host with single interface
	- manually configrured host
	- manually configured router

	for more details, kame IMPLEMENTATION document section 1.4.2.

itojun

---

From: Robert Elz <[email-masked]>
Date: Fri, 04 May 2001 18:04:52 +0700

Date:        Fri, 04 May 2001 19:27:03 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	we do not implement "partly host, partly router" behavior.

That I can understand, it seems like a pretty weird thing to want to
me (though conceptually possible, and perhaps even an interesting case
to consider in protocol design, not a beast that many people are likely
to actually want to use).

  | 	also, since RFC2462 basically assumes single-interface host,

Huh?

I just re-read the thing, and I can't find any assumption like that at
all.

In fact, the first sentence (after boilerplate, abstract, etc, is...)

   This document specifies the steps a host takes in deciding how to
   autoconfigure its interfaces in IP version 6.

"interfaces", in the plural.   Sure, there are a few places where the wording
is perhaps a little loose when view with that possible assumption in mind
(which I had never done before I'll admit), eg:

   If a node determines that its tentative link-local address is not
   unique,

(3rd para, section 4) - which probably really should say

   If a node determines that the tentative link-local address for one
   of its interfaces is not unique,

and

   To speed the autoconfiguration process, a host may generate its
   link-local address (and verify its uniqueness) in parallel with
   waiting for a Router Advertisement.

(last para of section 4, just before section 4.1), which would probably
be better written:

   To speed the autoconfiguration process, a host may generate the
   link- local addresses for its interfaces (and verify their uniqueness)
   in parallel with waiting for a Router Advertisment.

but everywhere substantive in the spec I could find it always talks of
interfaces, and specifies things to be done per interface.

eg:

5.  PROTOCOL SPECIFICATION

   Autoconfiguration is performed on a per-interface basis on
   multicast-capable interfaces.  For multihomed hosts,
   autoconfiguration is performed independently on each interface.

which is about as clear as it can be I think that multi-interface
hosts are expected to be supported.

What leads you to the "assumes a single interface" conclusion?
Whatever that is, certainly needs to be fixed.

  | 	we do not really care about the following cases:
  | 	- autoconfigured host with multiple interfaces

You might not care about them, but they seem to work for me?   That is,
I run KAME, I have nodes set to "autohost" with more than one interface...

  | 	- chimera (part-host, part-router) node

Understandable.

  | 	- autoconfigured router

that would be broken (aside from link local autoconfig, and I suspect
that works in KAME too).

kre

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 4 May 2001 13:58:57 +0200 (MET DST)

> 	could you point me to the text where it is specified as a

There is only section 6.2.1 on router configuration variables say
   For each multicast interface:

but that list doesn't contain the "isRouter" property (I thought it did).

Thus the thing that isn't explicitly stated in the document is that the
property of being a Router vs. Host is really a per interface property.
(There was some email discussion on this a long time ago and as I recall
the conclusion it was viewed too much trouble to make the specfication
explicitly call this out as a per-interface property everywhere.)

I sure wish it was more clear on this than my re-read of the document
indicates.

  Erik

---

From: [email-masked]
Date: Fri, 04 May 2001 20:59:34 +0900

>I just re-read the thing, and I can't find any assumption like that at

	suppose you have heard RAs from multiple interfaces.  there's no
	guidelines for us to pick which interface from them, for the
	installation of default route.  and things like that.
	RFC2461 appendix A talks about a host with multiple interfaces,
	however, the description is not really complete.  so i personally
	feel multi-interface autoconfigured host needs more work in
	specification side.  of course, we can have some configuration
	variable in implementation and prefer one of the outgoing interface,
	but... i'm not sure.

itojun

---

From: Robert Elz <[email-masked]>
Date: Fri, 04 May 2001 19:45:57 +0700

Date:        Fri, 04 May 2001 20:59:34 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	suppose you have heard RAs from multiple interfaces.  there's no
  | 	guidelines for us to pick which interface from them, for the
  | 	installation of default route.

Any time that can rationally be automated, it should make no real
difference (I'd tend to be kind of pragmatic and choose the interface
with the RA of best preference, on the assumption than in this environment
the RA preferences will be configured alike over all nets - even though it
is normally something that is local to a link).

But things should work whatever interface is chosen, pick a router, any
router (which is able to be picked as a default anyway), and packets should
be delivered.   Perhaps not optimally, but delivered.

In the environments where that isn't true, it shouldn't matter what the
kernel thinks is a good default route, as someone is going to have to
tell the kernel what it should be using via a "route add".  That is, if
you have multiple routers each advertising itself as being capable of
routing to default (or being a candidate as the default router), and they
can't find each other, then something is really stuffed...

  |  so i personally feel multi-interface autoconfigured host needs more
  |  work in specification side.

That is very probably true - multi-homing (in all its aspects) has tended
to be one of those "we'll figure that out later" problems...

  |     of course, we can have some configuration
  | 	variable in implementation and prefer one of the outgoing interface,

Perhaps - though if something is to be configurable, it may as well
just be the default router itself I think.   After all, if the best
default router is not available for some reason, why would one assume
that the second best router to use is going to be out the same interface?

kre

---

From: Mattias Pettersson <[email-masked]>
Date: Fri, 04 May 2001 14:47:33 +0200

>         variable in implementation and prefer one of the outgoing interface,

Isn't BSD's single routing table (common for all interfaces) conflicting
with the conceptual model of ND with more or less independent interfaces
with no routing table for a host implementation but more simple things
such as neighbor cache, destination cache, default router list etc. for
each interface?

Should a host allow internal forwarding of packets between interfaces? A
strict routing model maybe doesn't have this problem?

/Mattias

---

From: Markku Savela <[email-masked]>
Date: Fri, 4 May 2001 16:13:51 +0300

> From: Robert Elz <[email-masked]>
>
> with the RA of best preference,

This is basicly what our stack does. It is perfectly happy with
multiple autoconfigured interfaces. It currently (probably a bit
dubiously) uses the interface "speed metrich" as weight when picking
from multiple reachable default routers.

And, wouldn't implementing ideas from

  draft-draves-ipngwg-router-selection-01.txt        

bring some light into the issue?

---

From: [email-masked]
Date: Sat, 05 May 2001 02:48:56 +0900

>such as neighbor cache, destination cache, default router list etc. for

	even if we conceptually separate routing table per interface,
	we'd need to look them up together (as one routing table) when
	we make outgoing connection.  I don't think it very useful to
	have per-interface routing table (I don't think there's big win).

>strict routing model maybe doesn't have this problem?

	BSDs use weak host model, and they do not consider accepting packet
	from interface A for interface address on interface B "forwarding".

itojun

---

From: [email-masked]
Date: Sat, 05 May 2001 03:07:45 +0900

>I run KAME, I have nodes set to "autohost" with more than one interface...

	it may work but is not really tested.  default router selection
	is likely to be suboptimal (or can go flapped?).

itojun

---

From: Ignatios Souvatzis <[email-masked]>
Date: Sun, 6 May 2001 13:04:39 +0200

> 	have per-interface routing table (I don't think there's big win).

Well, consider this scenario:

I have an 486/66 machine being the experimental 6BONE router (tunnel to 
JOIN) here.

I also want it to be a 2002::/16 <-> ournetwork router.
I do NOT want it to be a 2002::/16 <-> alloftheworld router.

Per-interface-routing tables would be a cheap way to do this.
(But well, a generic filter mechanism would work fine, too.)
	-is