Hello all,
you can find below the draft on CIDR FAQ produced by Giuliana Tamorri.
All comments and suggestions welcome.
Daniele
----------------------------------------------------
GARR-NIS
January 1994
FAQ on CIDR
DRAFT DRAFT DRAFT DRAFT
1) What is CIDR?
Classless Inter-Domain Routing (CIDR) is an architecture for allocating
IP addresses in the Internet [1]. It plays an important role in
steering the Internet towards the Address Assignment and Aggregating
Strategy [3].
2) Why do we need to plan an architecture such as CIDR?
The IP address space is a scarce shared resource that must be managed
for the good of the community.
Due to the growth of the Internet, some scaling problems
arosen [2,3,6,11]:
- Exhaustion of the class-B network address space. More than half
of the total class B address space has been handed out. One
fundamental cause of this problem is the lack of an appropriate
sized network number for a mid-sized organization. Class-C,
with a maximum of 254 host addresses, is too small, while
class-B, which allows up to 65534 addresses, is too large to
be densely populated. The result is inefficient utilization
of class-B network numbers.
- Routing information overload. The size and rate of growth of the
routing tables in Internet routers is beyond the ability of
current software (and people) to be effectively managed. This is
mainly a problem for those routers which don't use
a default route, and have to carry a routing entry
for each network they need connectivity to.
The current growth trend is approximatelly exponential.
- Eventual exhaustion of IP network numbers. With more than half
of the class B networks assigned and a little over 6 percent of
the class C networks assigned, and the current growth in the
address allocation rate, this is a real, though not imminent
danger.
The first two problems will become extrimely critical in a near future.
CIDR defines a mechanism to:
i) slow the growth of routing table providing a mechanism
for aggregation of routing information
ii) reduce the need to allocate new IP network numbers managing
the allocation of Internet address space.
[page 1]
The last point takes great advantages from the assigment policy
reported in RFC 1466 [10] in which a managing schema for IP Address
Space is defined.
The rules of the class C network number allocation defined in
[10], will quickly accelerate the explosion of the routing
information carried by Internet routers.
Anyhow, assignment of consecutive class C network number
will facilitate and favourite the aggregation mechanism developed
by CIDR. The rule foresees to delegate to the network service
providers the address allocation of the class C network numbers.
3) Is CIDR a solution to the serious scaling problem of the Internet?
Yes, it is, but not a permanent one. It is a transition phase,
or a short-term solution, in order to allow the development of
a long-term solution, which will also cover the problem of the
exhaustion of IP network numbers.
CIDR will mainly deal with the solution (since the present problem, a
short-term one) of the routing table explosion problem.
4) Which are the aspects analyzed in realising an Address Allocation
schema?
Some of the technical and administrative aspects of an IP address
allocation faced in deploying a CIDR architecture are reported in [1]:
- Benefits of encoding some topological information in IP
addresses to significantly reduce routing protocol overhead;
- The anticipated need for additional levels of hierarchy in
Internet addressing to support network growth;
- The recommended mapping between Internet topological entities
(i.e., service providers, and service subscribers) and IP
addressing and routing components;
- The recommended division of IP address assignment among service
providers (e.g., backbones, regionals), and service subscribers
(e.g., sites);
- Allocation of the IP addresses by the Internet Registry;
- Choice of the high-order portion of the IP addresses in leaf
routing domains that are connected to more than one service
provider (e.g., backbone or a regional network).
- Identification of specific administrative domains in the
Internet.
[page 2]
5) Which is the Authority to which an organization could ask for a network
number?
The centralised procedures for obtaining IP network numbers from the
Global Internet Registry (known as InterNIC previously the DDN NIC)
is now replaced by a distributed allocation schema [10,12,13].
At the present, there are a number of Distributed Regional Registries
to which Internet Registry (IR) and the Internet Assigned Numbers
Authority (IANA) have delegated the registration function on a
geographic area.
These Regional Registres cover many geographical areas; but until an
organization is identified in those regions, the IR will continue to
serve as the default registry. That is, the IR remains the root
registry and continues to provide the registration function to all
those regions not covered by distributed regional registries.
So, it is possible for network applicants to contact the IR directly,
but it will be referred to the Regional Registry, if any.
Regional Registry in turn delegates blocks of IP network numbers to
local IR's. They are of two types: "service provider" and "registry
of last resort". An IP service provider is an organisation that
supplies Internet connectivity to its customers or users (examples
are academic network providers and commercial network providers).
"Registry of last resort" local IR's are managed by organisations
that are prepared to handle requests from organisations that
have no present or planned connection to the Internet.
The diagram below shows the distributed hierarchy of IR.
Global IR (InterNIC)
|
|
Regional IR (RIPE NCC)
|
________________________|____________________
| | | |
Local IR Local IR Local IR Local IR
/ /
( "REGISTRY" (SERVICE PROVIDERS) (SERVICE PROVIDER)
OF LAST RESORT")
In Europe, the IR has now delegated blocks of IP network numbers
to the RIPE NCC as the registry for the European region, which
following the main criteria, delegates blocks of IP network numbers
to local IR's.
If you are NOT a customer of a service provider, then you should
send your completed application form to the "registry of last resort"
local IR. Currently only one of this type of registry exists in the
european countries.
6) Which are the criteria to submit an appropriate request for a block
of class C network number?
It mainly depends on the organizational network topology, ie number
of internal LANs, and on the needed address numbers, taking in mind
[page 3]
the end system type, ie hosts, routers, printers, terminal server,
etc.
The following schema, which takes in consideration the number of
hosts to be connected per network, could be a starting guide to
evaluate the number of class C networks to be applied for.
1 class C ----> 254 hosts
2 class C ----> 508 hosts
4 class C ----> 1016 hosts
8 class C ----> 2032 hosts
16 class C ----> 4064 hosts
32 class C ----> 8128 hosts
Moreover, if the network is divided into logically distinct LANs
across which it could be difficult to use a smaller number of
class C network numbers, the above criteria may apply on a
per-LAN basis.
It is important to submit the request with an engineering plan
which can motivate it.
If the request will be inappropriate, it will be investigated and
suggested a different solution which could take advantage of the
feasibility of subnetting Class C network numbers which can resolve
the need of a great number of Class C network; in particular, it
can resolve the problem of requesting a network number for
every subnet.
If there is a need for more than 4096 unique IP addresses it
could conceivably receive a Class B network number.
The maximal block of Class C network numbers that should be assigned
to a subscriber consists of 64 contiguous Class C networks. This
would correspond to a single IP prefix of 18 bits.
It is also important that an organization could foresee its growth
in requesting the block of contiguos network numbers. As a
consequence, submitting its forms to its Local Registry, an
organization must indicate which could be its immediate growth
in terms of number of machines to be connected and of subnet
numbers foreseen for its network.
7) When could an organization consider to approach a subnetting criteria?
If an address space needed for an organizatin covers only about
tens addresses, and there are no plans to expand in the future,
it makes little sense to allocate a full class C network number for
this local network [11].
More details on subnetting technique can be found in [14], a
Standard Internet.
However, two issues must be taken into consideration in subnetting
class C networks:
i) subnets and hosts numbered "0" and "-1" are reserved
for special purpose in IP (broadcast and this host/subnet
indication.
[page 4]
ii) which kind of protocol to be used to distribute subnets
information within the network.
Limits imposed by the first point have led to the development of some
technique which can improve the address space utilization.
One of them is "variable-lengh subnet mask" (VLSM).
For the second issue, it is suggested to use a new generation
interior protocol. With old ones, such as RIP, it is quite impossible
to distribute information on subnets. While with the new ones, as
OSPS, integrated IS-IS or RIP-2, announced destinations carry
a corrisponding network mask, favouring the subnetting mechanism.
8) Which would be an appropriate request for a class B network number,
in order to be approved?
An organization applying for a class B network number must present
a subnetting plan which documents more than 32 subnets within its
network and must have more than 4096 hosts.
The submitted document must demonstrate the impossibility of
engineering the network with a block of class C network numbers.
The engineering plan must include both how many hosts and how
many hosts per subnet the network will have within the next
24 months.
9) What does hierarchy mean in Internet addressing? How could hierarchy
help in reducing the growth of routing table?
The situation in which each domain may have non-contiguous network
numbers assigned to it could lead to a dissemination of routing
information in the Internet.
If routing domains are randomly interconnected, it is difficult to
obtain a degree of routing data abstraction. Moreover, at a lower
level, if IP addresses within a routing domain are all drawn from
non-contiguous IP address spaces (allowing no aggregation or
abstraction), then the information exchanged between boundary router
consists of an enumerated list of all the IP addresses.
Anyhow, being service providers and service subscribers (ie sites,
routing domain) arranged hierarchically in the Internet, it is
natural to map this hierarchy also to the IP routing components.
The aim of using a hierarchical routing is to achieve some level
of routing data abstraction: an element lower in the hierarchy
reports summary routing information to its parents. The idea is to
assign to any group of routing domains an address prefix from a
a shorter prefix given to a routing domain which has the function
of interconnecting the group of routing domains.
It is clear that the routing abstraction carries more advantages
at a higher levels of the hierarchy.
10) Does it mean all the routing domains in the Internet need to convert
to CIDR?
No, it is not required all Internet domains to be converted to
use CIDR, neither now nor in the future; anyhow, it is assured
[page 5]
the global connectivity, including for those non-CIDR domains
for which, however, optimality of routes could be impacted.
The only constrain on a non-CIDR-capable domain is the need to
default towards the CIDR-capable parts of the Internet for routes
which have been aggregated to non-network boundaries [2].
Anyhow, it is strongly reccommended that all non-backbone/transit
Internet domains also implement CIDR because it will reduce the
amount of routing information inside them.
Any connected domain that supports IP version 4, could implement
CIDR.
On the contrary, it is imposed ALL Internet domains providing backbone
and/or transit service to fully implement CIDR, ensuring
a slow growth of the routing table, while providing Internet-wide
connectivity.
11) Which are the protocols supporting CIDR architecture?
Two main protocols realising the CIDR architecture are:
i) Border Gateway Protocol 4 (BGP-4)
ii) Inter-Domain Routing Protocol (IDRP for IP)
Each of them are inter-domain routing protocol, but the last one
has been standardized within ISO as multi-protocol.
BGP-4 is an extension of BGP-3 that provides support for routing
information aggregation and reduction based on CIDR architecture.
They are quite interchangeble [6].
12) What is an aggregate? What is an IP-prefix? What an IP-mask?
CIDR removes the concept of class A, B and C networks providing
a new representation of the destination address as a combination
of an address and a mask. The aim is to represent multiple contiguos
class C networks with a single routing table entry [11].
CIDR requires that inter-domain routing protocols be capable
of handling reachability information that is expressed solely in
terms of IP address prefixes [2].
It is possible to support aggregation through the use of an IP
address prefix.
Indipendently of the "class" of IP network number, an aggregate
collects a set of network addresses matching a pattern. In other words,
an aggregate combines announcements for a set of separate networks
into a single net aggregate.
It is now visible how the notion of "class" in routing information
will lose importance.
It is not mandated the use of a particular IP address prefix, and
till now there is no standardized one.
[page 6]
In [1], an IP-prefix is a tuple: <IP-address IP-mask> such that a
bitwise logical AND operation on the IP-address and IP-mask components
of a tuple yields the sequence of leftmost contiguous significant bits
that form the IP address prefix. For example a tuple with the value
<193.1.0.0 255.255.0.0> denotes an IP address prefix with 16 leftmost
contiguous significant bits.
In [7], which describes the NSFNET aggregation schema, an aggregate
is described as: <net-IP prefix-length>.
This refers to the IP prefix "net-IP", with a mask which has
"prefix-length" 1's as counted from the high-order end. For example,
<192.64.128 17> is equivalent to <192.64.128, 255.255.128.0> [7].
They choose to use a prefix-length rather than the mask, considering
it more compact.
13) What is a CIDR Aggregate Registry?
It has become evident the need for sharing of aggregate information;
there is a clear need to have a separate database which will allow
aggregate information from any Autonomous System to be stored and
made available for easy electronic retrieval. This information can be
used for routing coordination and policy configuration in the larger
inter-domain context.
One of the expected uses of such a database is to help determine, as
CIDR matures, the granularity of aggregation of network reachability
information with respect to policy.
In [7], Merit proposes an implementation of an "Aggregate Registry"
to provide sharing of aggregate information for the Internet
inter-domain routing community. It should be a community
registry and MERIT invites all to use and make use of it. It will
consist of a list of aggregate announcement statements.
14) Who does realise aggregation?
Speaking in term of BGP, a border BGP router of an AS will be
responsable for generating the aggregated route for a whole set
of destination IP addresses (NLRI) under its administrative control.
NLRI [6] stays for Network Layer Reachability Information and
represents a set of destination IP addresses over which a border
BGP speaker has an administrative control.
When aggregating NLRI, a border BGP must be cognizant of the implication
on routing policies [6].
[page 7]
References:
[1] Y. Rekhter, T. Li, "An Architecture for IP Address Allocation with
CIDR" RFC 1518, T.J. Watson Research Center, IBM Corp., cisco Systems,
September 1993.
[2] R. Hinden, "Applicability Statement for the Implementation of Classless
Inter-Domain Routing (CIDR)", RFC 1517, Internet Engineering Steering
Group, September 1993.
[3] V. Fuller, T. Li, J. Yu, K. Varadhan, "Classless Inter-Domain Routing
(CIDR): an Address Assignment and Aggregation Strategy", RFC 1519,
BARRNet, cisco, Merit, and OARnet, September 1993.
[4] Y. Rekhter, C. Topolcic, "Exchanging Routing Information Across
Provider Boundaries in the CIDR Environment", RFC 1520, T.J. Watson
Research Center, IBM Corp., CNRI, September 1993.
[5] C. Topolcic, "Status of CIDR Deployment in the Internet", RFC 1467,
CNRI, August 1993.
[6] Y. Rekhter, S. Hares, "Application of the Border Gateway Protocol and
IDRP for IP in the Internet", <draft-ietf-bgp-idrp-usage-00.txt>.
[7] M. Knopper, S. J. Richardson, "Aggregation Support in NSFNET
Policy-Based Routing Database", RFC1482, Merit/NSFNET, June 1993.
[8] C. Huitema, "IAB Recommendation for an Intermediate Strategy to
Address the Issue of Scaling", RFC 1481, Internet Architecture Board,
July 1993.
[9] C. Topolcic, "Schedule for IP Address Space Management Guidelines",
RFC 1367, CNRI, October 1992.
[10] E. Gerich, "Guidelines for Management of IP Address Space", RFC 1466,
Merit, May 1993.
[11] H. Eidnes, "Pratical Consideration for Network Addressing using CIDR
Block Allocation", Network Address Assignment, Proc.INET '93.
[12] "European IP network number application form & supporting notes",
ripe-107.
[13] D. Karrenberg, M. Terpstra, "European Internet Registry: IP Address
Space Assignment Procedures", ripe-104.
[14] J. Mogul, J. Postel, "Internet standard subnetting procedure", RFC 950,
Stanford, ISI, Agust 1985.
[page 8]
--
Daniele Vannozzi Phone: +39 50 593280
GARR - Network Information Service Fax: +39 50 904052
Via Santa Maria 36 Telex: 500371 - CNUCE
56126 Pisa - Italy E-mail: vannozzi(a)nis.garr.it
----- -----
