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

[jefsey <jefsey@club-internet.fr>]

Dear Jim,
thank you for that clear explanation. But I still miss two things:
- how would the DNS would see it? I understand that addresses would be:
   0.123.12.12.123
   1.123.12.12.123
   2000.123.12.12.123 ?
- what is needed in the real life to have this happen? I suppose that I 
cannot just name myself with such an adress and expect it to work?
jfc


On 04:10 13/05/02, Jim Fleming said:

>----- 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
>
>
>
>
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.351 / Virus Database: 197 - Release Date: 19/04/02
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.351 / Virus Database: 197 - Release Date: 19/04/02