> 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.
Don't some implementations process Router Advertisements in a user-level
process, radvd? I think putting the information in Router Advertisements
does not preclude user-level processing.
> 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).
Yes, I alluded to this idea (Dave Thaler also suggested it) in the draft.
Here's a possibility: allow the Length field in the option to be 1, 2, or 3.
If the Prefix Length is 0, then the Length field can be 1 and the option is
only 8 bytes. If the Prefix field is <= 64, then the Length field can be 2
and the option is only 16 bytes. If the Prefix field is <= 128, then the
Length field can be 3 and the option is 24 bytes.
> 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).
You have a point, but I think security is a weak argument. I'd hate to rely
on routing for the mechanism that prevents my sensitive corporate
information from leaving my network.
> 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).
This would complicate the conceptual sending algorithm for host C somewhat.
If I understand your intent, then your formulation isn't correct. For
example with routes:
::/0 -> router X (Medium)
3ffe::/16 -> router X (Unreachable)
::/0 -> router Y (Medium)
you'd want destination 3ffe::1 to be sent to router Y (only), not result in
the packets being discarded because it matched the 3ffe::/16 route. If
router Y is not reachable, then you do not want the packets sent to router
X.
Here's an attempt at modifying the conceptual sending algorithm to include
Unreachable routes - is this what you meant?
When host C does next-hop determination and consults its Routing Table for
an off-link destination, it looks for routes in the Routing Table that match
the destination (meaning the leading Prefix Length bits of the destination
address and the Prefix are the same). If there is more than one such
matching route, then the following rules are used to compare matching routes
and select the best one:
a) If one route has an unreachable next-hop router and the other route has a
reachable next-hop router, prefer the route to the reachable next-hop
router.
b) If one route has a Preference value of -2 (Unreachable) and the other
route as a larger Preferenc value (not Unreachable) and the two routes have
different next-hop routers, prefer the route with the larger Preference
value.
c) If the routes have different Prefix Lengths, prefer the route with the
larger Prefix Length.
d) If the routes have different Preferences, prefer the route with the
larger Preference value.
If the best matching route has an unreachable next-hop router or a
Preference value of -2 (Unreachable), then host C SHOULD round-robin among
all routers matching the destination regardless of preference value or
prefix length, except not including routers whose longest prefix route
matching the destination has a Preference value of -2 (Unreachable).
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 PROTECTED]
--------------------------------------------------------------------
