Re: [ga] Re: How do you "rebid" a cartel ?

["Jim Fleming" <jfleming@anet.com>]

----- Original Message ----- 
From: "Eric Dierker" <eric@hi-tek.com>
> 
> So let us get down to basics.
> 

The basics are very simple. Start with the 160 bits (1s and 0s) in each header
of each packet you send and receive. Two 32-bit fields are for the IP addresses,
that amounts to 64 bits. Assume you do not touch those, and you have 96 other
bits to consider. Of those 96, some can not easily be changed, because the
routers, servers, and PCs use them to get the packets from one place to another.
You can go thru those 96 as three groups of 32. In the first 32, 16-bits have a
length and can not be touched, that leaves 16, and of those, 4-bits can not be
touched, because they contain the "version". Four other bits have a fixed value
of 5, for this discussion, let's assume you do not touch those. That leaves 8 bits
of that group of 32 that you can touch. Moving to the second group of 32, there
are 16 bits you can *touch carefully*, and 16 that are hard to change, but only 15
of those are critical, which leaves a single bit to play with. Moving to the third
group of 32, you can not change the 8-bit time-to-live field, the 8-bit protocol
field can be touched, but carefully, and the other 16-bits are checksum which
can not be touched. That is all of the bits.

Summarizing, beyond the 32-bit addresses (64 total bits), you have 8 bits,
plus 16 (maybe), plus 1 unused bit, plus maybe some bits from the 8-bit protocol
field. Of the 160 bits, you might be able to come up with 8+16+1+8=33 bits
to modify for routing around the existing 32-bit legacy Internet. You have to
of course divide that 33 by 2 because you want to have symmetry to go to and
from locations. Since 33 is odd, you might drop one bit and make it 32 and
then consider having 16 new bits in each direction. Unfortunately, to get that
much extra addressing, you may have to give up too much in the 8-bit protocol
functionality and you might be pushing your luck with the 16-bit field that we
noted as *touch carefully*. Let's say, that you consider instead of 32 bits, a
more conservative route and only hope to get 22 bits, with 11 bits in each
direction. That allows you to not touch 10 of the bits, as well as that single
spare bit. With 11 bits in each direction, that is an Internet which has 2,047
more Address Spaces the size of the Address Space which has not been
exhausted for the past 20+ years. Experts can show that the existing Address
Space probably has another 20 years before it is exhausted. Without changing
protocols, we can add thousands more equal size Address Spaces, depending
on how one wants to design the software.

Assuming that Address Spaces can somehow be added, one then turns to
the question, "Who would manage those Address Spaces ?". With a couple
thousand new Address Spaces, it seems most fair to have the TLD Managers
each help manage an Address Space, via IN-ADDR.[TLD], in parallel with
IN-ADDR.ARPA. In order to do that, each of the TLD Managers simply
has to have a "unique" number. It should not cost tens of millions of dollars
per year to keep a list of the unique numbers for the TLD Managers. Some
people believe that the TLD Managers may actually be able to keep such a
list themselves, and via software, self-maintain the list. The DNS provides the
natural distributed database technology to do this. Even though more than
2,048 TLDs are possible, the concept is to have the "best-of-breed" TLDs
be allocated the unique numbers. Given their 11-bit unique number, they can
then use that in whatever extended addressing approach they want.

Moving to 128-bit DNS, you now have a different problem, there are more
bits than most people can handle. It is surprising how fast they get used up
when you look at transition plans. As one example, you can start with 16-bits
for the UDP or TCP Port. 32-bits can then be used for legacy addressing.
Another 16 bits can contain that 11-bit unique number plus some bits for
other interesting uses. That covers 64 bits. The other 64 bits could be used
in largely the same manner, if you want to encourage encapsulated architectures,
VPNs, etc. There are many ways to dice up 128 bits. The software developers
are currently producing many ways, and the marketplace will eventually
decide on what people prefer, which will also probably be based on what
actually works and evolves most smoothly from the existing installed base of
systems.

If you feel this is too complex, you could also consider a more basic approach.
Consider a 1-bit extension to the current addressing. You can not get much more
basic than that. If you do that, you could end up with the Even Internet (legacy)
and the Odd Internet. You could use IN-ADDR.ARPA to manage the Even
Address Space and IN-ADDR.NET to manage the Odd Address Space.

http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
0:0 .ARPA
0:1 .NET

With this approach, you only need to find 2 bits in the existing 160-bit header
to use for the extended address bits. Do you think it would be possible to
find 2 ?, if we were able to dig up 22 ? Assuming you answer yes, you may
find it is harder to decide, what 2?, when there are many to choose from.
Because of that, it may be easier to go for a larger expansion. Some people
of course toss all cares to the wind and shoot for 128-bits and do not
consider that not everyone may want to change their software and all other
systems. Small, incremental changes, have been the norm in protocol
evolution. It is happening each day with NAT, TOS Routing, Policy Routing,
NetFilter, RIFRAF Routing, IP Tables, etc. People are making incremental
changes to route around the legacy Internet's limitations, and the artificial
road-blocks set up by the I* society's regulators.

The marketplace will now converge on what solutions work and solve
the problem. This is a classic Beta vs. VHS scenario or a classic Segmented
Intel x86 Architecture vs. Non-Segmented SPARC/68000 Architecture.
Some claimed in the 80's that SPARC would blow Intel x86 away. It did
not happen. Some claimed that Beta would beat VHS. It did not happen.
Some claim that revolution and an entire new protocol (IPv6) will replace
IPv4.....we shall see...

Jim Fleming





--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html