DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) (07/10/86)
Date: Thu, 10 Jul 86 13:28:47 EDT From: jnc@brubeck.proteon.com Hosts shouldn't be forwarding packets (or sending redirects) anyway. It is a complete bug that the LISP machine are even presuming to do either. I agree there is a bug with broadcast packets. But... if a non-gateway host receives a non-broadcast packet that is not for it, why shouldn't it BOTH forward it and send a redirect? How is the sender to know that it is sending packets to the wrong place? P.s., it looks like your mail sending program didn't tack on @proteon.com to the bug-cgw CC recipient. -------
JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") (07/19/86)
(For those who are lost, this is about the incident I reported where broadcast RIP packets from a subnet gateway were being reforwarded by all of a certain class of machine which didn't recognize them as broadcast, causing a massive jamup on the net.) I sent a message out to TCP-IP a few months (28 April if you want to look it up in the archives) ago in which I discussed a similar topic at length. (The question there was when to send ICMP Error packets). The general philosophy behind the answer here is the same. Had the algorithm about 'hosts not doing anything with wrong packets that were broadcast' been followed by the hosts here, the problem would not have occurred. If a host receives what looks to it like a misdirected packet, it got it either because a gateway was confused or some host was. In the first case, things are really in trouble anyway; reforwarding it could just cause a loop or other serious problems. In the second, I don't think that you should encourage broken behaviour on the part of hosts; if they didn't send the packet to the right place they should be fixed. The real problem is that in practice usually when a host sees a packet it doesn't recognize it's not because the packet was sent to the wrong place, but because there is some strange address in there the host didn't recognize. In this case it was a subnet broadcast address, and a host that didn't recognize that it was on a subnetted net. In the future it might be multicast addresses, or whatever. In either case, doing anything except ignoring it is the wrong thing. Yes, maybe in .001% of the cases, forwarding the packet on is the right thing, but in the rest it's the wrong (and usually disastrous) thing to do. Clearly, the cost/benefit analysis says that forwarding the packet is the wrong thing. Noel -------
gds@SRI-SPAM.ARPA (The lost Bostonian) (08/05/86)
From: jnc@brubeck.proteon.com Hosts shouldn't be forwarding packets (or sending redirects) anyway. It is a complete bug that the LISP machine are even presuming to do either. I agree there is a bug with broadcast packets. But... if a non-gateway host receives a non-broadcast packet that is not for it, why shouldn't it BOTH forward it and send a redirect? How is the sender to know that it is sending packets to the wrong place? Why not use the icmp parameter problem message? Rather than dropping the packet on the floor, or worsening the problem by forwarding the packet or sending a redirect (question: what does the host redirect to?), it seems a reasonable way to let the sender know about the problem, and it costs the same as sending a redirect. All the ip implementations will have to be taught to do something with the parameter problem type, besides just accept it. --gregbo