nash@vi.ri.cmu.edu (Richard Nash) (09/25/90)
Distribution: usa Organization: Carnegie-Mellon University, CS/RI My company has just recieved our connection to the internet. We are very concerned about securing our business information and source code from outside reading and it is felt that the best way to do this is to seperate ourselves into two nets. Secure and open... So I have two questions... 1> Is it possible to further subclass a Class-C address. Can I have my netmask be 255.255.255.192 so that I have 2 bits of network info and 6 bits to specify the hosts? If so, I do I configure the ka9q net.exe program to route between my internal networks? 2> Can I have the route between the secure and open networks simply disallow any traffic except relatively inoccuous things like mail? Does the ka9q package allow me to do this? I have set up the ka9q package and got it to accept both cards through the attach command. I can ftp from the router PC to either side of the network, but I can't seem to get through the router. From one side to the other. Can anyone help? Rich Nash nash@vi.ri.cmu.edu -- Richard V. Nash nash@vi.ri.cmu.edu
dd@ariel.unm.edu (Don Doerner) (09/29/90)
In article <10560@pt.cs.cmu.edu> nash@vi.ri.cmu.edu (Richard Nash) writes: > [...] > > So I have two questions... > > 1> Is it possible to further subclass a Class-C address. Can I have my > netmask be 255.255.255.192 so that I have 2 bits of network info and > 6 bits to specify the hosts? If so, I do I configure the ka9q net.exe > program to route between my internal networks? This could work but for a single problem: to get two subnets, you must allow two bits of subnet in your last octet. You cannot use x.y.z.0 thru x.y.z.63, you can use x.y.z.64 thru x.y.z.127, you can use x.y.z.128 thru x.y.z.191, but you cannot use x.y.z.192 thru x.y.z.255. This throws away half of your address space, but the bottom line is that you cannot use subnet 0, nor subnet 2**n-1, where n is the number of bits you allocate for your subnetting scheme. Me? I personally think this portion of the RFCs is nonsense, but that's probably because I haven't yet been able to figure out a reason that it shouldn't work. But the RFC says so, and it is the protocol specification for the protocol you have chosen... Now the next problem is that the host portion of the network address is subject to similar constraints: can neither be 0, nor can it be 2**m-1, where m is the number of bits you allocate for your host. This means that x.y.z.64 is not usable, nor is x.y.z.127, nor x.y.z.128, nor x.y.z.191. These are easier to understand: 2**m-1 is reserved as an IP brooadcast address, and 0 has historically been a broadcast in some early implementations of the protocol suite. All in all, I think you will want to apply for a second class C address. But in theory, you've got it right... > 2> Can I have the route between the secure and open networks simply disallow > any traffic except relatively inoccuous things like mail? Does the ka9q > package allow me to do this? Don't know about the KA9Q package. CISCO routers let you do this (we use a lot of them), so I suspect that there are similar access control mechanisms available in most router implementations. > I have set up the ka9q package and got it to accept both cards through > the attach command. I can ftp from the router PC to either side of the > network, but I can't seem to get through the router. From one side to > the other. Can anyone help? I can't help with this, sorry! Don Doerner, Communication Manager University of New Mexico CIRT
jbvb@FTP.COM ("James B. Van Bokkelen") (10/02/90)
The issue with reserving subnet bit values of all-zeroes and all-ones has its roots in the concept of the "all subnets broadcast". In other words, if I have net 128.127.0.0 and 8 bits of subnet, the destination address 128.127.255.255 means "broadcast this packet on all subnets of 128.127". A destination of 128.127.50.255 means "broadcast this only on subnet 128.127.50". So why is zero magic, too? At the time that the HRRFC was in the works, there were still a *lot* of 4.2-based systems out there, and the group was more than a little afraid of their propensity for broadcast storms (4bsd is also the reason that the whole class A address space of 127.0.0.0 is reserved). In the future, if IP multicast becomes wildely supported, the concept of an "all subnets" broadcast will probably become obsolete (I don't know of anything other than perhaps a few locally-written applications that actually uses it in any case). In the mean time, if you don't have 4.2-derived systems around (even some SysVs and other non-Unix OSes like 0.0.0.0 as the broadcast address), you can probably safely use the zero subnet. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901