Subject: (IPng 6998) Re: route distribution via ND

From: Richard Draves <[email-masked]>
Date: Mon, 4 Jan 1999 21:44:43 -0800

Back from vacation and I find I've missed a good discussion! I want to thank
everyone for their input, and my apologies for this long message. Let me
summarize where I think the discussion stands, in two parts - first, why
would one want to distribute routes to hosts, and second, (assuming it's
desirable), should it be done via ND or some other mechanism?

1. Why would one want to distribute routes to hosts? The counter-argument is
redirects will always do the job acceptably. Let me break this down into
three cases (a, b, c).

a. Performance. I agree, in most situations the overhead of redirects will
not be significant and so this is not a compelling argument on its own. My
concern is that there may be some scenarios where it will be important, and
for the poor souls stuck with some "feature" it's no comfort to know that
most everyone else is not similarly afflicted.

I think trying to calculate some metric like the percentage of network
bandwidth consumed by redirects is not very interesting, because it
completely dependent on the application traffic patterns and the
implementations involved (eg destination cache size & management,
rate-limiting of redirects).

Another important performance issue, to my mind, is the increased latency
incurred for the first packet of a flow. Between DNS & ND & who knows what
else, it already takes enough packets to start talking to a new destination.

b. Is there always a default router to send the redirect? Marc's scenario is
a node (happens to be a translator, but that's not important) that knows how
to forward packets sent to a certain range of destination addresses, but
that has no particular ability to handle other packets.

One line of thought seems to be that a router is a router and if you are
going to forward any packets, then you must advertise yourself as a router
and forward all packets appropriately. So the translator should advertise
itself as a router, and if there's also a "real" router on link then it must
be configured to forward/redirect to the real router & vice-versa.

Another line of thought is that if there is no advertising router then hosts
will fall back on treating all destinations as on-link, and the translator
can "proxy-ND" for the range of addresses that it is handling. I don't much
like this solution, not least because the fall-back doesn't work for
multi-homed hosts (on which link should the multi-homed hosts attempt ND?).

Btw, I think multi-homed hosts are a very important case - a host with a
single physical interface can also have virtual interfaces, and this will be
very common with some transition mechanisms/scenarios. Some day I would like
to compare notes with some other implementor on this topic, since I like to
think that we've done a good job in MSR IPv6 with support for multi-homed
hosts.

c. Redirects are not always a solution. For example, a redirect can not tell
a multi-homed host that it should be using a different interface.

For another example, consider a host H on a relatively slow link with two
routers A & B and talking to a destination D. The "best" router for host H
to use to reach destination D is router A. When host H uses router B,
there's no redirect because B forwards the packet on to D using a different
route (either not through A, or through A but via a faster link to A).

2. So on balance I think it's reasonable to have a mechanism for routers to
communicate routes to hosts. It can be an optional mechanism, but it would
be nice to have agreement so those desiring it can interoperate.

Then the question is what should this mechanism be? An option in Router
Advertisements? RIPng (RFC 2080)? Perhaps something new?

At this point, I think I would favor a new option in Router Advertisements,
with a route prefix, lifetime, and metric, instead of trying to use the
existing prefix-information option.

The argument in favor of using Router Advertisements is Router
Advertisements are already the architectural mechanism for communicating
information from routers to hosts. If it's there, why have another
mechanism? Another mechanism is just more code & more packets.

The argument in favor of using RIPng is that it already exists and there's
precedent for using RIP in this fashion. It has the drawback that it doesn't
support lifetimes for routes. It would mean hosts & routers would need to
implement two mechanisms (ND/RAs and RIPng) instead of just one (RAs).

Rich
--------------------------------------------------------------------
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: "Matt Crawford" <[email-masked]>
Date: Tue, 05 Jan 1999 10:30:29 -0600

Suppose you have your canonical dual-homed host H on two links L1 and
L2.  Each link has other, single-homed hosts, or hosts dual-homed to
L3, and one or more routers.  There may be no router in common on L1
and L2.  There may be a myriad of destinations for which one link is
preferred over the other, and not always the same link.

Now, what information do you want the routers to convey to the hosts?
How much routing state should the hosts have to cache in advance of
any traffic to send?

Any solution to the perceived problem (and yes, I do agree that it
MAY be worth doing something about this) should be fully general and
be lightweight to the uninterested hosts.

I suggest a new option on neghbor advertisements which would include
an AS identifier and a metric.  Then a multihomed host which does not
participate in a routing protocol but which wants to choose the best
first-hop interface can do an NS (which might also include a new
option, perhaps containing traffic class information?) on each
interface and, when the NA replies have the metric option with equal
AS identifiers, choose the better metric.

				Matt

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 5 Jan 1999 11:42:14 -0800 (PST)

> be configured to forward/redirect to the real router & vice-versa.

I think that is the only way to build a robust network.
Having "half-routers" that forward some packets but drop other packets
on the floor will, when something goes wrong, cause black holes that are
very hard to find.

For instance, the R bit in the neighbor advertisement is used to indicate
that the sender will forward packets - all packets - not just the packets it
cares to forward. Thus I don't see how NUD can possible work in in world with
"half-routers" since those boxes will effectively have an R bit that is
a function of the destination address.

I guess that is why we have the definitions for router and host.
But it seems like we need to modify the definition of router to
say "attempts to forward all packets not explicitly addressed to itself"
to make this more clear :-)

> single physical interface can also have virtual interfaces,

The multihomed case where you need more information for optimal routing
is when a host has multiple *physical* interfaces (so that the node can
select the outgoing interface). Virtual interfaces doesn't
add any new requirements here as far as I know.

> route (either not through A, or through A but via a faster link to A).

I think this is the fundamental tradeoff with moving information out from
the hosts to the routers. Unless the routers maintain a routing table per
interface they will not be able to generate redirects that provide optimal
routing. But the worst case is just one hop more than the optimal path.

> existing prefix-information option.

If we go this path I fear we will soon be getting requests for being able
to authenticate the content of this routing option (but not using AH for
the whole packet) since RIPng has such support. Thus I fear we will end up
with a discussion of what parts of RIP to move into ND and that we might
end up with most of RIPng functionality in ND. What for?

RIPng is done and works. I don't see a problem for using it where it is really
needed e.g. on hosts with multiple physical interfaces.

   Erik