Re: FW: Structuring the Root
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: Structuring the Root



First, I'd like to suggest to move this discussion from the RIPE TLD-WG list,
since IP address space allocations/assignments are out of the scope of TLD
registrar business. Please, appologies if anyone from the TLD-WG list has
a different oppinion.

RIPE NCC and ARIN hold separate lists which deal with IP address space
allocation and assignment policies and procedures, as well as with reverse
domain infrastructure (IN-ADDR.ARPA) maintenance. Please, have a look at
http://www.ripe.net/, http://www.arin.net/ and STOP sending CC's of this
discussion to <tld-wg at ripe.net>. Many thanks for your understading (and
reducing traffic volume on the list to the TLD-related matter)! ;-)

Now, here's my reply to the last posting from <Jay at Iperdome.com>:

>> At 11:45 PM 4/20/98 +0100, Berislav Todorovic wrote:
>> >* IP address allocation/assignment process is totally independent of
>> >  domain name delegations. IP address management hierarchy (IANA ->
>> >  Regional IRs -> ISPs/LIRs -> End users) is a logical consequence of the
>> >  hierarchy of the global routing system. 
>> 
>> Only a small fraction of the IP address space is allocated in 
>> this manner.  Based on the limited information that I've seen, 
>> only about 30 /8s have been delegated to the regional IRs.

Correct! But, as you perfectly remarked:

>> A large portion of the IP address space has been allocated 
>> directly to some large, independent organizations, and a large 
>> portion remains available to the IANA for future allocations.

Also true! Explanation: the allocation/assignment process I described
in my previous posting is the way how it is being done nowadays. That
process is based on CIDR and the guidelines denoted in RFC 2050. Long
before that, however, allocation/assignment procedures were totally
different. To be more precise - the rules themselves have constantly
been changing over time! But - the rules were always, in some way,
a consequence of the current principles of the Internet architecture.

While Cerf and Kahn had thought about the Internet, as a collection
of mutually connected huge national-level networks, of which each one
would be assigned a single 8-bit IP network prefix (/8 in today
terms), the evolution of the Internet architecture inevitably changed
that firstly adopted rule. The address space had been initially
partitioned into classes and - as a last resort to save the Net from
address space exhaustion (and to reduce routing information traffic),
CIDR and hierarchical distribution was was introduced in early 90's.

Thus, some huge networks (like MIT) had been allocated an increadibly
large address space (MIT holds 18/8), according to the policy that
had been in use in that time. Some users in the late 80's, claiming
that they have more than 250 hosts obtained a /16 etc. But, since the
"original criteria for those assignments are still met" (as stated in
the RFC 2050 and other similar documents), which means they still
meet the criteria that had been valid in the moment when their IP
addresses had been assigned, they have the right to hold that address
space.

But, the fact I've said in my previous posting still states: IP
address allocations/assigments - no matter how they have been done
and no matter what rules have been applied in the process of their
distribution - still are totally independent from domain name
delegations.

Best regards,
Beri

.-------.
| --+-- |  Berislav Todorovic, B.Sc.E.E.     | E-mail: BERI at etf.bg.ac.yu
|  /|\     Hostmaster of the YU TLD          | 
|-(-+-)-|  School of Electrical Engineering  | Phone:  (+381-11) 3221-419
|  \|/     Bulevar Revolucije 73             |                   3370-106
| --+-- |  11000 Belgrade SERBIA, YUGOSLAVIA | Fax:    (+381-11) 3248-681
`-------' --------------------------------------------------------------------



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.