10010000 00000001 00000000 00000000
Or, in other words everyhting starting with 144.1 as the first two octets is on the same network.
What this proposal appears to be proposing is to permit NON-CONTIGUOUS netmasks such as:
255.128.127.0
It was obvious, through the author did a lot to mascarade this simple idea amongs the heap of words -:). Just as the resume - it's not problem to use broadcast bits, it's not a problem to propose non-contiguous network masks, but (1) hosts do not know masks at all, IP address only, and (2) 99% existing routing protocols and ip forwarding software can't work with non-contiguous masks at all. But I think it is nessesary to establish some aware for the such works - when so plain idea is described by so complex way -:).
In all reality, I think that the IP address problem is solving itself. The majority of the customers I deal with have a SINGLE ip address for all of their internal machines. I have actually allocated LESS space than I have reclaimed over the past year and a half from customers who have moved to Private Address space. To facilitate this I sell them a $250 "iGate
Junior" which is basically a 486 with some software I've put together in house (shameless plug). The iGate Jr. basically takes all of the inside requests and NAT's them into a single outside address. It also takes inbound connections for Mail and other services and routes them to the appropriate inside box. As a result, a typical small-to-medium sized company only needs ONE real ip address in most circumstances. JUst as I'v wrote yesterday - if you allow to assign WWW addresses (or exactly, SERVICE addresses) to the _IP:PORT_ instead of _IP_ (and ask _give the port from your local _service_ table_, you'll be free in usage
No doubt. Using private address space + NAT decrease the address needs and (important) increase your security a lot (except, of course, L4/L7 viruses, trojans, etc... - usial student's mistake is to forgot about this levels). the same IP address even for the incoming services, not for the clients only (as todays).
- Forrest W. Christian (forrestc@imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)