2. History and Problem Description

2. History and Problem Description

What is now known as the Internet started as a research project in

the 1970s to design and develop a set of protocols that could be used

with many different network technologies to provide a seamless, end-

to-end facility for interconnecting a diverse set of end systems.

When it was determined how the 32-bit address space would be used,

certain assumptions were made about the number of organizations to be

connected, the number of end systems per organization, and total

number of end systems on the network. The end result was the

establishment (see [RFC791]) of three classes of networks: Class A

(most significant address bits '00'), with 128 possible networks each

and 16777216 end systems (minus special bit values reserved for

network/broadcast addresses); Class B (MSB '10'), with 16384 possible

networks each with 65536 end systems (less reserved values); and

Class C (MSB '110'), and 2097152 possible networks each and 254 end

systems (256 bit combinations minus the reserved all-zeros and all-

ones patterns). The set of addresses with MSB '111' was reserved for

future use; parts of this were eventually defined (MSB '1110') for

use with IPv4 multicast and parts are still reserved as of the

writing of this document.

In the late 1980s, the expansion and commercialization of the former

research network resulted in the connection of many new organizations

to the rapidly growing Internet, and each new organization required

an address assignment according to the Class A/B/C addressing plan.

As demand for new network numbers (particularly in the Class B space)

took what appeared to be an exponential growth rate, some members of

the operations and engineering community started to have concerns

over the long-term scaling properties of the class A/B/C system and

began thinking about how to modify network number assignment policy

and routing protocols to accommodate the growth. In November, 1991,

the Internet Engineering Task Force (IETF) created the ROAD (Routing

and Addressing) group to examine the situation. This group met in

January 1992 and identified three major problems:



1. Exhaustion of the Class B network address space. One fundamental

   cause of this problem is the lack of a network class of a size

   that is appropriate for mid-sized organization. Class C, with a

   maximum of 254 host addresses, is too small, whereas Class B,

   which allows up to 65534 host addresses, is too large for most

   organizations but was the best fit available for use with

   subnetting.

2. Growth of routing tables in Internet routers beyond the ability

   of current software, hardware, and people to effectively manage.

3. Eventual exhaustion of the 32-bit IPv4 address space.

   It was clear that then-current rates of Internet growth would

   cause the first two problems to become critical sometime between

   1993 and 1995. Work already in progress on topological

   assignment of addressing for Connectionless Network Service

   (CLNS), which was presented to the community at the Boulder IETF

   in December of 1990, led to thoughts on how to re-structure the

   32-bit IPv4 address space to increase its lifespan. Work in the

   ROAD group followed and eventually resulted in the publication of

   [RFC1338], and later, [RFC1519].

   The design and deployment of CIDR was intended to solve these

   problems by providing a mechanism to slow the growth of global

   routing tables and to reduce the rate of consumption of IPv4

   address space. It did not and does not attempt to solve the

   third problem, which is of a more long-term nature; instead, it

   endeavors to ease enough of the short- to mid-term difficulties

   to allow the Internet to continue to function efficiently while

   progress is made on a longer-term solution.

   More historical background on this effort and on the ROAD group

   may be found in [RFC1380] and at [LWRD].

---