If someone reads this, understands it, and wants to summarize, I'm sure
many of us would appreciate it. I attempted the first two pages and gave
up when my eyes started bleeding. It badly needs a technical writer to
re-do it. 
-Jon
It needs more than that. After 5 minutes I realized that if this guy was an accountant we'd all be rich...and later thrown in jail after an audit was done.
-craig
You all are happy... for me the _good scientific language_ was the
problem too...
But all this looks like a joke... Except one idea _we don't use all
information keeping by the network masks_. Through it can improve the
routing hierarchy, but not the address range (which is from 0.0.0.0 to
223.255.254.254 wit a little exceptions). To increase address range
Internet shgould use extra bits for the address, foir example by using
two-level hierarchy schema (and it do this - by NAT translation, for
example, bits from the PORT field are used as the address space).
THe more interesting issue for me is _is it possible to use
Source-Routing_ for the hierarchical routing as well?
Through if someone translate this joke to the normal labguage, I'll
appreciate too -:). Good paper - for the evening hours...
Alex.
Through if someone translate this joke to the normal labguage, I'll
appreciate too -:). Good paper - for the evening hours...
I DID look at it pretty deeply.
As far as I can tell the concept is basically this:
Today, we determine the network part of the address via ANDing the netmask
with the address. Thus, if we have (for simplicity sake) a classful B
address we have something like:
144.1.8.3 Address OR
10010000 00000001 00001000 00000011 in binary
255.255.0.0 netmask OR
11111111 11111111 00000000 00000000 in binary
You derive the network number by anding the two above, such as:
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
Or, in binary:
1111111111 10000000 01111111 00000000
Thus, the network number would actually consist of all 8 bits of octet
one, the first bit of octet two, the last 7 bits of octet 3 and none of
octed four.
Initially this seems like a good idea in that by allocating in this
fashion you can reuse bits over and over - that is, my host bits can be
your network bits and vice versa.
Assuming that netmask info was available end to end for both source and
destination addresses this would be a really cool idea.
However, the problem is that since the netmask is not available for
"destination" addresses at the source end, There is no way to determine
which bits mean what for proper routing. In addition, even if you did
provide that information at the source end, it would have to be passed on
with each packet through all the routers so they could uniquely identify
which of the multiple potential endpoints for a given destination address
that the packet is going to.
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.
- Forrest W. Christian (forrestc@imach.com) KD7EHZ
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
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).
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
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)
Are you referring to RFC 2052?
S
Stephen Sprunk, K5SSS, CCIE#3723
Network Consulting Engineer
Cisco NSA Dallas, Texas, USA
e-mail:ssprunk@cisco.com
Pager: +1 800 365-4578
Empowering the Internet Generation
Yes, but (unfortunately) the success of the failure of this approach
depends more from the client's software (and can be successfull if this
can be hidden by the TCP/IP stack and prevent re-writing the client's
software) and less from the RFC itself. Through I meant something like
virtual host defined as _IP address, port shift_ pair.
Anyway, no one approach is used widely now.
Alex.