steve@BRILLIG.UMD.EDU (Steve D. Miller) (05/03/87)
I noticed yesterday that ucbvax was sending me Net Unreachable messages for hosts on a subnet of ucb-ether, although ucb-ether itself was indeed reachable. Since I don't know that ucb-ether is subnetted (well, OK, I know, but my kernel doesn't), I could make wrong decisions based on that information. This seemed wrong to me, so I added a quick hack to the 4.3 ip_forward() so that, when ip_output() returns ENETUNREACH or ENETDOWN, it checks to see if the destination address of the unforwardable packet is on a known subnetted network, and sends a Host Unreachable message (instead of a Net Unreachable message) if the destination network is indeed subnetted. I then started thinking about the suggestion in RFC 985 that states that, because subnetting information isn't visible outside the subnetted network, Host Unreachable messages should always be sent in the place of Network Unreachable messages. However, it seems to me that the entity sending the unreachability message will fall into one of the following two classes: 1) The entity is a gateway for the destination network, and as such should either know the subnetting scheme for the network or should forward the packet to another gateway with such knowledge. In this case, I think that the Host Unreachable message should be used so that false unreachability information doesn't creep out onto the network. 2) The entity is a gateway that knows (inasmuch as anything ever does) that the entire destination network is down. In this case, the Network Unreachable message should be sent, since this message in this case conveys the maximum amount of correct information. Since it seems to me that there is no ambiguity here, and since there might be software Somewhere Out There that can use the Network Unreachable information to avoid sending extra packets out onto the Internet, it might be better to follow the scheme above. In fact, the reason that I stumbled across this behavior is because I'm testing such an application (the ICMP caching beast I described a few months ago). Does this scheme make sense to everyone, or am I missing something obvious? -dateat