[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    (IPng 321) Re:  multi-homed hosts
From:       "Thomas Narten" <narten () VNET ! IBM ! COM>
Date:       1995-06-28 15:10:34
[Download RAW message or body]

>  I don't agree that multi-homed hosts are uncommon.

That may be the case. However, ...

>Most local
>dual-homed systems run (host-side) Router Discovery now and some few
>have manually configured default routers because their OS doesn't yet
>support Router Discovery.  The number of multi-homed hosts is on the
>increase in my neck of the woods, often to increase network
>availability to command and control systems.

The current ND spec sticks with this model, so you haven't lost an
ability you had before.

I agree that there are still scenarios that neither v4 or the ND solve
satisfactorily, namely, selecting which outgoing *interface* to use in
forwarding a packet to an off-link destination.

>  Alan Cox's example is increasingly commonplace in the real world.
>Lots of DoD/Navy hosts are dual-homed onto administratively separate
>networks and yet are not routers.

But in such situations aren't we also getting into policy routing
types of issues/questions (e.g., when do we use the secure network,
when not)? Is a simple "query for a metric" protocol going to solve
this problem in the general case? Would we be better off focusing
effort on solving the general case?

>  My own experience with hosts eavesdropping on routing protocols
>(such as running "routed -q") is all strongly negative,

Could you summarize those negatives?  That is, are they flaws with
implementations or fundamental to eavesdropping?

Would the negatives go away if a new "barebones" routing protocol was
developed that restricited itself to propagating routing information
from routers to neighboring hosts?

>If a dual-homed
>system knows the Routing Prefix associated with each interface, then
>it has a fighting chance of picking a plausible outgoing interface for
>a packet.  If someone has a better approach to picking an outgoing
>interface, I'm all ears.

Not sure I follow your point.  Under ND, hosts do know the routing
prefixes associated with each interface (for on-link neighbors).

If you want hosts to also know prefixes for off-link destinations as
well (so that they can choose the best outgoing interface), a routing
protocol is needed.  Call it what you want; it is in fact a routing
protocol that hosts would need to listen in on.  ND at present does
not support this model.

>  I believe that most customers will not want to be _forced_ to turn
>their multi-homed hosts into routers and will not want to be _forced_
>to eavesdrop on routing protocols (too much administrative pain
>involved with either of those options if you have many multihomed
>hosts).

>  The approach for multi-homed discovery described in Simpson's drafts
>seemed very reasonable to me (and some others).

I think that the "query router for a destination's metric" is
deceptively simple, but I'm not convinced that it is the right
model. For one thing, whenever a connection is opened to a new
destination, there will be a delay (several seconds perhaps) while a
host sends out queries, waits long enough to be sure its gotten all
the responses, and then chooses the best one. Note that it would not
be sufficient to act on the first response; one must wait long enough
before acting to be sure no additional responses (with the best
metric!) come along. (Note also that one shouldn't pick one interface
and then change it when a better response comes along, since the
source address of the outgoing packet must match that of the outgoing
interface.)

Moreover, you'd have to periodically issue new queries, to handle
metrics/reachability changing (e.g., stale cache problem).

As an alternate approach, it might be reasonable to define a new
"routing protocol" whose sole purpose is to propgate routing
information one way from routers to (multihomed) hosts. By making it a
standard that all routers must implement, future changes to other
routing protocols would not break the existing mechanism. The protocol
could also be simple; the routers would do the main work of figuring
metrics, hosts would just choose routers based on simple metric
comparisons.

>"x" = host part of routing prefix; A, B, C, D, F are arbitary numbers.
>
>                                     |================|----|
>         PREFIX = B.D.x              |                | R1 |
>       =========================================     |----|
>                           |                             |
>                        -------                          |     |------|
>                        | SRC |                          |-----| DEST |
>                        -------                          |     |------|
>                           |                             |
>         ========================================        |
>          PREFIX= A.C.x               |                  | PREFIX = B.F.x
>                                      |                  |
>                                    ------             ------
>                                    | R2 |             | R3 |
>                                    ------             ------
>                                      |                  |
>                                      |                  |
>                            TO THE INTERNET          Different connection
>                                                       TO THE INTERNET

>ASSUMPTIONS:
>       R1, R2, and R3 are routers.
>       "SRC" is a multi-homed sending host.
>       "DEST" is the node that "SRC" is sending to.
>       R2 is higher preference in Router Discovery than R1.

>SRC wants to send packets to DEST.


>CASE 1:

>       The default routing path would be to send via R2, The
>Internet, and R3 to DEST.  This is not nearly optimal (and perhaps not
>"reasonable" :-).

>       Is it possible for SRC to be told to send via R1,
>       using the shorter path ??    If so, how ??

The above configuration is a bit curious. If we've got a zillion
multihomed hosts connected to both net A.C and B.D, wouldn't there be
at least one router between those networks? In that case, choosing the
wrong default interface would result in a sub-optimal path (one extra
LAN hop), but the overall picture would not be as bad as the picture
suggests.

>CASE 2:
>       Recall the Alan Cox scenario where network "B" is
>       not attached to The Internet at any location.

This is the really bad case.

>GENERAL NOTE:
>       In talking with Dan about this, Dan observed that routing prefixes
>       have lifetimes and are stored in some logical table in the host
>       [per our understanding of ADDRCONF & the new DISCOVERY].  One
>       possible (BSDish) implementation of the longest prefix match
>       approach goes like this:
>               1) lookup DEST in Routing Table (radix) code.
>               2) if DEFAULT-ROUTE returned && multi-homed, then
>                       compare DEST against the prefix list kept
>                       anyway for Discovery/AddrConf reasons.

I don't understand this suggestion (are we confusing "prefixes" as
defined to identify on-link destination vs. "prefixes" that identify
both on- and off-link destinations)? Are you saying, "check the
prefixes that we know about from Router Advertisements, even though
the "on-link" bit is off, meaning that we are not supposed to
interpret the destination as being on-link?  This would seem a bad
idea on principle. Moreover, I don't see how this relates to finding
paths to off-link destinations.

Thomas
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

[prev in list] [next in list] [prev in thread] [next in thread]