Subject: router-selection comments

From: Pekka Savola <[email-masked]>
Date: Sun, 29 Feb 2004 08:01:39 +0200 (EET)

Thanks for the update.  I think this is in pretty good shape, protocol-wise,
and should be shipped ASAP.  Especially, please work on getting those ICMP
types reserved, the ones currently used by implementations have been taken
already for other applications!

substantial
-----------

   If there are no routes matching the destination (i.e., no default
   routes and no more-specific routes), then if a type C host has a
   single interface then it SHOULD assume the destination is on-link to
   that interface. If the type C host has multiple interfaces then it
   SHOULD discard the packet and report a Destination Unreachable / No
   Route To Destination error to the upper layer.

==> this "onlink-by-default" rule has big problems, and it has been removed
in rfc2461bis -- I think it should be removed from here as well, or at least
reworded.  Additionally, there doesn't appear to be anything
router-selection specific here.

3.5. Router Reachability Probing

==> as a preface, one should IMHO discuss how this relates to the router
reachability probing of RFC2461.  As far as I see, the only difference here
is that that unreachable, preferable routers are explicitly being probed to
notice when they become reachable again -- while with vanilla RFC2461 this
doesn't matter as all the routers are equally preferable.

5.1. Best Router for ::/0 vs Router Least Likely to Redirect 

==> I think these examples show, that if you don't know which type of nodes
(A, B vs C) there exist in the network, the optimal network configuration
can be a very delicate process.

This should be explicitly called out somewhere.  Another approach might be
"disallowing" type B hosts, requiring full router-selection implementation,
which would simplify the types and the configuration quite a bit.

6. Security Considerations

   A malicious node could send Router Advertisement messages,
   specifying High Default Router Preference or carrying specific
   routes, with the effect of pulling traffic away from legitimate
   routers. However, a malicious node could easily achieve this same
   effect in other ways. For example, it could fabricate Router
   Advertisement messages with zero Router Lifetime from the other
   routers, causing hosts to stop using the other routes. Hence, this
   document has no new appreciable impact on Internet infrastructure
   security.

==> this is inaccurate.  There is a significant difference between a 
blackhole attack, and a redirection attack.  Redirection can e.g., be a
trivial way to mount MITM attacks.  This draft actually makes it even
easier. This needs to be explained better in this memo, with appropriate
pointers to SEND stuff.

editorial
---------

A router on one link cannot redirect a host to a
   router on another link. Hence, Redirect messages do not help multi-
   homed hosts select an appropriate router. 

==> a host can be multi-homed (at the site level) while still having only
one interface, so proposing to reword: s/multi-homed/multi-homed (through
multiple interfaces)/

   scenarios can add additional tunnels. For example, hosts may have
   6-over-4 [RFC3056] or configured tunnel [RFC1933] network

==> s/6-over-4/6to4/
==> rFC1933 has been obsoleted, soon twice :-)

   values.  If the host has no information about the routerÆs

==> strange character, should be "'" ? (many other places as well)

   As one exception to this general rule, the administrator of a router
   that does not have a connection to the internet, or is connected
 
==> s/internet/Internet/

5.2. Multi-Homed Host and Isolated Network

   Here's another scenario: a multi-homed host is connected to the
   6bone/internet via router X on one link and to an isolated network

==> s/Here's another scenario:/In another scenario,/
==> remove "6bone".

Author's Addresses

==> s/Author's/Authors'/

   Full Copyright Statement

==> one must add an IPR boilerplate before this section.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------