Date: Mon, 5 Jan 1998 11:13:32 +1030 From: Greg Lehey <grog@lemis.com> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: Brian Somers <brian@awfulhak.org>, John-Mark Gurney <gurney_j@efn.org>, freebsd-bugs@hub.freebsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: kern/5404: slXX slip (tun & ppp) interfaces always point to point Message-ID: <19980105111332.39295@lemis.com> In-Reply-To: <19980104193137.01479@uriah.heep.sax.de>; from J Wunsch on Sun, Jan 04, 1998 at 07:31:37PM %2B0100 References: <19980104110521.14399@uriah.heep.sax.de> <199801041629.QAA04727@awfulhak.demon.co.uk> <19980104193137.01479@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 04, 1998 at 07:31:37PM +0100, J Wunsch wrote: > As Brian Somers wrote: > >> Not quite. I was suggesting that instead of the first, we have the >> second, or in fact >> >> route add 1.2.3.4 -netmask 0xffffff00 1.4.5.6 >> >> If you specify a 0xffffffff netmask, you get the same as the existing >> stuff *always* does. > > However, since most people don't bother messing with the netmask on > p2p interfaces at all (why should they), they'll always catch the > default netmask, so the above will violate the principle of least > surprise for them (configurations that used to work would no longer > work). I don't see what would change with this method. What would it break? The correct behaviour for a ppp interface is to address only the IP at the other end of the line. Add a netmask for pseudo-broadcast, and you're addressing this address and a number of other IPs around it. This works because the other end of the link typically performs packet forwarding. It's not real broadcast, but it's hard to tell the difference. What wouldn't work? >> The real purpose, as you've already suggested, is that you get the >> associated broadcast address. With this broadcast address, all sorts >> of other things work (timed, rwhod, nmbd etc.), assuming that you've >> got a proxy arp setup on the other end. > > Proxy arp is a hack. We shouldn't encourage using hacks. If people > are interested in using hacks, they should have more work to be done > than those who are interested in clean setups. Agreed. > (Sure, like all hacks, there are situations why proxy arp can be > useful. vfork() is another example of a useful hack. Recommending > proxy arp as a general method is ugly. Setup correct IP routing > instead.) The problem is, the Microsoft World uses it, and that's a significant number of the machines that might be involved in such a network. IIRC, proxy arp is needed because NETBEUI can't route. >> Of course, this implies that the destination address isn't actually >> required - as with a real network. > > `Real' networks have broadcast addresses, but aren't point-to-point. You're talking about broadcast networks here. 'Real' networks can be built out of p2p links. This is still the way the Internet works: broadcast network hardware is almost always local. > `Real' networks can't share the same local adress for different > interfaces, p2p interfaces can. What do you mean by that? Of course they can, they just need to be on different networks, like p2p interfaces are. > `Real' networks have native broadcasting, p2p interfaces don't. You're talking about Ethernet again. > p2p interfaces always connect to just one remote address, that's why > they are called by this name. ;) Well, it's not the address, it's the interface. It could have multiple IPs :-) <IMO mode on> I don't really understand what the purpose of this discussion is. I am concerned that we're making changes in the name of "purity" which don't bring us any particular advantage, and which could bring disadvantages. For example, take a look in the FreeBSD network book. Which one? Oh yes, we don't have one. OK, take Stevens, or Nemeth and Co., or Craig Hunt, or one of the many excellent books on UNIX networking. They all apply pretty well. Be a moderately informed user, and set up a network with a moderately informed ISP. Get one like mine who insists on a net mask of 0xffffffc0. Ignore him, he's harmless. So far, everything works. Those who understand the matter know that the funny netmask is really just a superstition, but who cares? All that changes when we start changing the behaviour of the system. For example, look at page 411 of Nemeth & Co: "Other local customs, such as the interface subnet mask, should be applied as well". Go looking for a net mask with ifconfig. Where's it gone? Unnecessary confusion. The kernel data structures still maintain a net mask for p2p interfaces. Not showing it isn't the answer. A better way to handle the problem would be to set it to 0xffffffff by default, and allow changing it if absolutely required. In the latter case, I can't see why it shouldn't imply a "broadcast network" of a size corresponding to the netmask, and enter a route it. If you want, you can issue a message saying what you've done, and that this isn't a real broadcast network. It would make interoperabilitiy a whole lot easier. <IMO mode off> Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980105111332.39295>