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 PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
