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
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
