I have discovered a problem with the implementation of ICMP redirect in the BSD code: Due to interaction between this code and the router discovery protocol, stations may receive and keep a wrong default route, and the routers will not correct this wrong route. This leads to excessive traffic on Ethernet cables. I wish to have opinions on this problem. Which is wrong, automatic configuration of router discovery (and of any method of distributing defult routes which can be sub optimal), or the BSD routing code ? The problem was discovered with Solaris 2 staions, as they use the router discovery by default, but the Solaris system is not the cause of the problem. Description: 1/ Configuration Ethernet R1 +---+ ---------------------------------------| R | --> + connexion to station D | | +---+ using the default route +---+ +---+ + connexion to station C | A | | B | using an explicit net route +---+ +---+ | ------------ Ethernet R2 - A is a Sun station (1 Ethernet card), system Solaris 2.3 or 2.4, automatic configuration (no explicit routing information configured) - B is a Sun server (2 Ethernet cards), system Solaris 2.3 or 2.4, automatic configuration (no explicit routing information configured) - R is a router (not a Sun) running RIP but not running the Router Discovery protocol. R is connected to cable R1, and connect the site to outside. It gives access to machine C (using an explicit net route), and to machine D, using the defaut route. 2/ The problem All the packets from A to D are routed through B. Therefore each packet appears twice on the ethernet cable R1. Using snoop and netstat -r on A one can see: - A has received a default route to B. - Packets sent from A to D are sent by A to B on Ethernet, and then are sent by B to R on Ethernet. - No ICMP redirect is sent by B to A to correct the routing information. On the opposite, packets from A to C behave correctly: - the first packet from A to C is forwarded to B, then to R - On this first packet, B sends a ICMP redirect to A (redirect C through R). - the following packets from A to C are directly forwarded to R. So in this configuration, a station acquires a wrong default route, and routers fail to generate ICMP redirects to correct it. 3/ Discussion The fact that A acquires a wrong default route comes from the default configuration of both A and B (use of in.rdisc): - At boot time, B starts the in.rdisc -r daemon. (and also in.routed -s, so B receives all routes of R, including a default route) - At boot time, A starts the in.rdisc -s daemon. As B's in.rdisc daemon is active, A will use in.rdisc information and will not start in.routed. - But as R is not using the router discovery protocol, A will not discover the router R, and so will install a poor default route. One should note that : - If B sends ICMP redirects, the problem is solved : the ICMP redirect will correct the wrong route. But B does not send ICMP redirects for messages forwarded by the default route. - B knows all the correct routes received from R through RIP. It also receives the correct default routel to Internet. - Even if R is a router using rdisc protocol, there is still a problem: with standard configuration, the rdisc messages sent by R and B will have the same preference, and so there is a chance that A chooses B as default routeur. The decision not to send ICMP redirects for default routes is explicit in all the BSD codes. For example here is the comment and test in the bsd.networking code (file ip_input.c): /* * If forwarding packet using same interface that it came in on, * perhaps should send a redirect to sender to shortcut a hop. * Only send redirect if source is sending directly to us, * and if packet was not source routed (or has any options). * Also, don't send redirect if forwarding using a default route * or a route modfied by a redirect. */ #define satosin(sa) ((struct sockaddr_in *)(sa)) if (ipforward_rt.ro_rt && ipforward_rt.ro_rt->rt_ifp == ifp && (ipforward_rt.ro_rt->rt_flags & (RTF_DYNAMIC|RTF_MODIFIED)) == 0 &&

...

...

...

...

...

satosin(&ipforward_rt.ro_rt->rt_dst)->sin_addr.s_addr != 0 &&

ipsendredirects && ip->ip_hl == (sizeof(struct ip) >> 2)) { struct in_ifaddr *ia;

My opinion is that ``don't send redirect if forwarding using a default route'' is a wrong decision and should be suppressed. This contradicts the RFCs on ``gateway requirements'', which do not suggest that a default route is something special. It also contradicts the philosophy of Router discovery ICMP. In order to use efficiently the net when using default routes on hosts, routers must be able to correct all routes. Default routes for a router are normal, they are a mean to lower the route information exchanged and stored. In a hierarchic routing domain, the default route is simply ``let the upper domain do the correct thing''. The problem can also appear in a site which use static default routes on hosts, when the topology changes. Suppose stations are manually configured with a default route pointing on a router B (the default router of the site). Some time after a new default router R is installed. With the current code for ICMP redirect all stations must be modified in order to correct the default route. Here are some parts of relevant RFCs: RFC1009 (Gateway requirements) A gateway will generate an ICMP Redirect if and only if the destination IP address is reachable from the gateway (as determined by the routing algorithm) and the next-hop gateway is on the same (sub-)network as the source host. Redirects must not be sent in response to an IP network or subnet broadcast address or in response to a Class D or Class E IP address. RFC1716 (Gateway requirements) Routers MUST be able to generate the Redirect for Host message (Code 1) and SHOULD be able to generate the Redirect for Type of Service and Host message (Code 3) specified in [INTERNET:8]. Routers MUST NOT generate a Redirect Message unless all of the following conditions are met: o The packet is being forwarded out the same physical interface that it was received from, o The IP source address in the packet is on the same Logical IP (sub)network as the next-hop IP address, and o The packet does not contain an IP source route option. The source address used in the ICMP Redirect MUST belong to the same logical (sub)net as the destination address. A router using a routing protocol (other than static routes) MUST NOT consider paths learned from ICMP Redirects when forwarding a packet. RFC 1256 (ICMP outer discovery message) The router discovery messages do not constitute a routing protocol: they enable hosts to discover the existence of neighboring routers, but not which router is best to reach a particular destination. If a host chooses a poor first-hop router for a particular destination, it should receive an ICMP Redirect from that router, identifying a better one. It has been suggested that, when the preference level of an address has not been explicitly configured, a router could set it according to the metric of the router's "default route" (if it has one), rather than defaulting it to zero as suggested above. ...... ....... Such a strategy might reduce the amount of ICMP Redirect traffic on some links by making it more likely that a host's first choice router for reaching an arbitrary destination is also the best choice. On the other hand, Redirect traffic is rarely a significant load on a link, and there are some cases where such a strategy would result in more Redirect traffic, not less (for example, on links from -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr richier@imag.fr) LGI, IMAG-CAMPUS, BP 53, F-38041 GRENOBLE Cedex 9 Tel : (33) 76 82 72 32 Fax : (33) 76 44 66 75