Subject: RE: default router selection based on network topology

From: Richard Draves <[email-masked]>
Date: Thu, 16 Nov 2000 21:50:18 -0800

OK, I just submitted the promised draft on this topic...
If you'd like to check it out early, you can find it here:

ftp://ftp.research.microsoft.com/users/richdr/draft-draves-ipngwg-router-sel
ection-00.txt

Comments welcome!

Thanks,
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: Robert Elz <[email-masked]>
Date: Fri, 17 Nov 2000 15:56:22 +0700

Date:        Thu, 16 Nov 2000 21:50:18 -0800
    From:        Richard Draves <[email-masked]>
    Message-ID:  <[email-masked]>

  | OK, I just submitted the promised draft on this topic...
  | If you'd like to check it out early, you can find it here:

It is pretty much as expected - essentially a routing protocol, simplified.
That is, the distinction between a host implementing this fully (your host C)
and a host running "routed -q" is entirely illusory (the protocols have
differences but they're not important ones here).

Unfortunately, as much as we have always preferred for hosts to not engage
in routing protocols, the number that do run routed -q and the obvious
need to do something to handle multi-homed hosts (for which, as the
draft points out, redirects are singularly useless), I suspect that
we really need something like this.

To the details ...

The choice of a two bit signed number as the preference is quaint,
though understandable...

I'm not sure though that this belongs in RA - it is the kind of thing
which I suspect I'd prefer to have a user level application dealing
with, and so having it as a UDP protocol would have a lot of advantages,
even if it currently does gain some advantages by sharing quite a bit with
what RAs already offer at the more primitive level - and that most
likely a host would want to use only one method - this new protocol, or
RAs as its method for finding routers.   This is kind of a big
uncertainty in my mind.

I'd probably make the routing info messages variable length though,
padded to whatever alignment needs to be enforced, but not necessarily
to the maximum address length (ie: sending a 128 bit address to say 0::0/0
seems a bit overboard).   I wouldn't want to restrict the prefixes that
can be advertised to max 64 bits though, that would be an overly
restrictive optimisation for future flexibility - hosts should treat add
addresses as simply 128 bits masked (other than for autoconf purposes,
when that is enabled).

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 17 Nov 2000 17:28:21 +0700

I have been thinking about this a little more, and I suspect that
if this is to fly, the currently unassigned "10" preference value
is going to be needed (but is is OK, it fits the "signed 2 bit
integer model well enough as "-2" .. more negative than "11").

That is, I think there needs to be a "blackhole" (or unreachable)
preference as well as "bad" "average" "good" (or low medium high).

Without that, there's no way to subtract out a piece from a large
block, and you're left having to instead to form the address space
you want to reference from the union of a lot of smaller blocks,
which is error prone (though I guess it could be done in software
with a configuration language that includes a blackhole) and
generates much larger RAs (or whatever they turn out to be).

For example, in your section 5.2, if router Y simply identifies itself
as a default router, then it is claiming that it can reach the
isolated corporate net that is really only reachable via X (which
it is assumed isn't connected to Y, or known to it).   That's not
good.   While X is alive, things work, as its more specific route
will be used instead of the default from Y.   But when X is down,
there's nothing to stop traffic heading at Y.

This may sound like not much of a problem, as if the corporate net
can't be reached at all (its only gateway being down) then not reaching
it via Y might not seem like much of a problem - but it does mean that
what might be potentially sensitive corporate information, that wasn't
ever intended to go anywhere near Y (and who knows how much further
before the default routes end and the lack of a specific route is
detected) which is being dumped that direction (this could be as simple
as SNMP traps from C - so there is no need to postulate the establishment
of a TCP connection before any real data is sent).

So, I would suggest allocating that final code as "unreachable",
with the interpretation by the host that after running the algorithm
the route selected is unreachable, then packets should simply be
discarded (with an appropriate error to the application).

kre

---

From: Steve Deering <[email-masked]>
Date: Fri, 17 Nov 2000 06:52:59 -0800

>with, and so having it as a UDP protocol would have a lot of advantages,

There are also advantages, and architectural arguments, for keeping
it as part of ICMP.  An intermediate approach would be to keep it in
ICMP, but in a separate (new) message type, to facilitate separate
processing.  (Note that ICMP Echo Requests are typically handled by
user-space ping clients, so the fact that something is part of
ICMP certainly does not rule out its implementation in user space.)
However, my first choice would be the same as Richard's, i.e.,
included in RAs.

Steve

---

From: Tim Chown <[email-masked]>
Date: Wed, 22 Nov 2000 12:11:43 +0000 (GMT)

> ftp://ftp.research.microsoft.com/users/richdr/draft-draves-ipngwg-router-sel

It seems that the subject of routers giving hints to hosts as to best
routes off a network is tied in very closely with the issue of source
address selection in a multihomed environment.

Do you intend expanding the scope of the document to suggest what happens
(for example) if the RA preference and src/dst selection algorithm happen
to give conflicting suggestions for source address?  

I'm also interested in just how the routers will be configured to make
the advertisements, as it would seem this would impact the router
renumbering process?

tim