As per Relevance of the word allocate, we have this rfc below:
Network Working Group V.
Request for Comments: 1519
Obsoletes: 1338 T.
Category: Standards Track
J.
K.
September 1993
Classless Inter-Domain Routing (CIDR):
an Address Assignment and Aggregation
Status of this
This RFC specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" for the standardization state and
of this protocol. Distribution of this memo is unlimited
This memo discusses strategies for address assignment of the
IP address space with a view to conserve the address space and
the explosive growth of routing tables in default-route-free routers
Table of
Acknowledgements ................................................. 2
1. Problem, Goal, and Motivation ................................ 2
2. CIDR address allocation ...................................... 3
2.1 Aggregation and its limitations ............................. 3
2.2 Distributed network number allocation ....................... 5
3. Cost-benefit analysis ........................................ 6
3.1 Present allocation figures .................................. 7
3.2 Historic growth rates ....................................... 8
3.3 Detailed analysis ........................................... 8
3.3.1 Benefits of new addressing plan ........................... 9
3.3.2 Growth rate projections ................................... 9
4. Changes to inter-domain routing protocols and practices ...... 11
4.1 Protocol-independent semantic changes ....................... 11
4.2 Rules for route advertisement ............................... 11
4.3 How the rules work .......................................... 13
4.4 Responsibility for and configuration of aggregation ......... 14
4.5 Intra-domain protocol considerations ........................ 15
5. Example of new allocation and routing ........................ 15
Fuller, Li, Yu & Varadhan [Page 1]
RFC 1519 CIDR Address Strategy September 1993
5.1 Address allocation .......................................... 15
5.2 Routing advertisements ...................................... 17
6. Extending CIDR to class A addresses .......................... 18
7. Domain Naming Service considerations ......................... 20
7.1 Procedural changes for class-C "supernets" ................... 20
7.2 Procedural changes for class-A subnetting .................... 21
8. Transitioning to a long term solution ........................ 22
9. Conclusions .................................................. 22
10. Recommendations ............................................. 22
11. References .................................................. 23
12. Security Considerations ..................................... 23
13. Authors' Addresses .......................................... 24
The authors wish to express their appreciation to the members of
ROAD group with whom many of the ideas contained in this
were inspired and developed
1. Problem, Goal, and
As the Internet has evolved and grown over in recent years, it
become evident that it is soon to face several serious
problems. These include
1. Exhaustion of the class B network address space.
fundamental cause of this problem is the lack of a
class of a size which is appropriate for mid-
organization; class C, with a maximum of 254
addresses, is too small, while class B, which allows up
65534 addresses, is too large for most organizations
2. Growth of routing tables in Internet routers beyond
ability of current software, hardware, and people
effectively manage
3. Eventual exhaustion of the 32-bit IP address space
It has become clear that the first two of these problems are
to become critical within the next one to three years. This
attempts to deal with these problems by proposing a mechanism to
the growth of the routing table and the need for allocating new
network numbers. It does not attempt to solve the third problem
which is of a more long-term nature, but instead endeavors to
enough of the short to mid-term difficulties to allow the Internet
continue to function efficiently while progress is made on a longer
term solution
Fuller, Li, Yu & Varadhan [Page 2]
RFC 1519 CIDR Address Strategy September 1993
The proposed solution is to topologically allocate future IP
assignment, by allocating segments of the IP address space to
transit routing domains
This plan for allocating IP addresses should be undertaken as soon
possible. We believe that this will suffice as a short
strategy, to fill the gap between now and the time when a viable
term plan can be put into place and deployed effectively. This
should be viable for at least three (3) years, after which time
deployment of a suitable long term solution is expected to occur
This plan is primarily directed at the first two problems
above. We believe that the judicious use of variable-
subnetting techniques should help defer the onset of the last
problem, the exhaustion of the 32-bit address space. Note also
improved tools for performing address allocation in a "supernetted
and variably-subnetted world would greatly help the user community
accepting these sometimes confusing techniques. Efforts to
some simple tools for this purpose should be encouraged by
Internet community
Note that this plan neither requires nor assumes that
assigned addresses will be reassigned, though if doing so
possible, it would further reduce routing table sizes. It is
that routing technology will be capable of dealing with the
routing table size and with some reasonably small rate of growth
The emphasis of this plan is on significantly slowing the rate
this growth
Note that this plan does not require domains to renumber if
change their attached transit routing domain. Domains are
to renumber so that their individual address allocations do not
to be advertised
This plan will not affect the deployment of any specific long
plan, and therefore, this document will not discuss any long
plans for routing and address architectures
2. CIDR address
There are two basic components of this addressing and routing plan
one, to distribute the allocation of Internet address space and two
to provide a mechanism for the aggregation of routing information
2.1 Aggregation and its
One major goal of this addressing plan is to allocate
address space in such a manner as to allow aggregation of
Fuller, Li, Yu & Varadhan [Page 3]
RFC 1519 CIDR Address Strategy September 1993
information along topological lines. For simple, single-
clients, the allocation of their address space out of a
routing domain's space will accomplish this automatically -
than advertise a separate route for each such client, the
domain may advertise a single aggregate route which describes all
the destinations connected to it. Unfortunately, not all sites
singly-connected to the network, so some loss of ability to
is realized for the non-trivial cases
There are two situations that cause a loss of aggregation efficiency
o Organizations which are multi-homed. Because multi-
organizations must be advertised into the system by each
their service providers, it is often not feasible
aggregate their routing information into the address
any one of those providers. Note that they still may
their address allocation out of a transit domain's
space (which has other advantages), but their
information must still be explicitly advertised by most
their service providers (the exception being that if
site's allocation comes out of its least-preferable
provider, then that service provider need not advertise
explicit route - longest-match will insure that
aggregated route is used to get to the site on a
basis). For this reason, the routing cost for
organizations will typically be about the same as it
today
o Organizations which change service provider but do
renumber. This has the effect of "punching a hole" in
aggregation of the original service provider's advertisement
This plan will handle the situation by requiring the
service provider to advertise a specific advertisement
the new client, which is preferred by virtue of being
longest match. To maintain efficiency of aggregation, it
recommended that organizations which do change
providers plan to eventually migrate their
assignments from the old provider's space to that of the
provider. To this end, it is recommended that mechanisms
facilitate such migration, including improved protocols
procedures for dynamic host address assignment, be developed
Note that some aggregation efficiency gain can still be had
multi-homed sites (and, in general, for any site composed
multiple, logical IP network numbers) - by allocating a
power-of-two block of network numbers to the client (as opposed
multiple, independent network numbers) the client's
information may be aggregated into a single (net, mask) pair. Also
Fuller, Li, Yu & Varadhan [Page 4]
RFC 1519 CIDR Address Strategy September 1993
since the routing cost associated with assigning a multi-homed
out of a service provider's address space is no greater than
current method of a random allocation by a central authority,
makes sense to allocate all address space out of blocks assigned
service providers
It is also worthwhile to mention that since aggregation may occur
multiple levels in the system, it may still be possible to
these anomalous routes at higher levels of whatever hierarchy may
present. For example, if a site is multi-homed to two NSFNET
networks both of whom obtain their address space from the NSFNET
then aggregation by the NSFNET of routes from the regionals
include all routes to the multi-homed site
Finally, it should also be noted that deployment of the
addressing plan described in this document may (and should)
almost immediately but effective use of the plan to aggregate
information will require changes to some Inter-Domain
protocols. Likewise, deploying classless Inter-Domain
without deployment of the new address plan will not allow
aggregation to occur (in other words, the addressing plan and
protocol changes are both required for supernetting, and
resulting reduction in table growth, to be effective.) Note
however, that during the period of time between deployment of
addressing plan and deployment of the new protocols, the size
routing tables may temporarily grow very rapidly. This must
considered when planning the deployment of the two plans
Note: in the discussion and examples which follow, the network
mask notation is used to represent routing destinations. This is
for illustration only and does not require that routing protocols
this representation in their updates
2.2 Distributed allocation of address
The basic idea of the plan is to allocate one or more blocks of
C network numbers to each network service provider.
using the network service provider for Internet connectivity
allocated bitmask-oriented subsets of the provider's address space
required
It is also worthwhile to mention that once inter-domain
which support classless network destinations are widely deployed,
rules described by this plan generalize to permit
super/subnetting of the remaining class A and class B address
(the assumption being that classless inter-domain protocols
either allow for non-contiguous subnets to exist in the system
that all components of a sub-allocated class A/B will be
Fuller, Li, Yu & Varadhan [Page 5]
RFC 1519 CIDR Address Strategy September 1993
within a single routing domain). This will allow this plan
continue to be used in the event that the class C space is
before implementation of a long-term solution is deployed.
alternative is discussed further below in section 6.
Hierarchical sub-allocation of addresses in this manner implies
clients with addresses allocated out of a given service provider are
for routing purposes, part of that service provider and will
routed via its infrastructure. This implies that routing
about multi-homed organizations, i.e., organizations connected
more than one network service provider, will still need to be
by higher levels in the hierarchy
The advantages of hierarchical assignment in this fashion
a) It is expected to be easier for a relatively small number
service providers to obtain addresses from the
authority, rather than a much larger, and
increasing, number of individual clients. This is not to
considered as a loss of part of the service providers'
space
b) Given the current growth of the Internet, a scalable
delegatable method of future allocation of network numbers
to be achieved
For these reasons, and in the interest of providing a
procedure for obtaining Internet addresses, it is recommended
most, if not all, network numbers be distributed through
providers. These issues are discussed in much greater length in [2].
3. Cost-benefit
This new method of assigning address through service providers can
put into effect immediately and will, from the start, have
benefit of distributing the currently centralized process
assigning new addresses. Unfortunately, before the benefit
reducing the size of globally-known routing destinations can
achieved, it will be necessary to deploy an Inter-Domain
protocol capable of handling arbitrary network and mask pairs.
then will it be possible to aggregate individual class C
into larger blocks represented by single routing table entries
This means that upon introduction, the new addressing allocation
will not in and of itself help solve the routing table size problem
Once the new Inter-Domain routing protocol is deployed, however,
immediate drop in the number of destinations which clients of the
protocol must carry will occur. A detailed analysis of the
Fuller, Li, Yu & Varadhan [Page 6]
RFC 1519 CIDR Address Strategy September 1993
of this expected drop and the permanent reduction in rate of
is given in the next section
In should also be noted that the present method of flat
allocations imposes a large bureaucratic cost on the central
allocation authority. For scaling reasons unrelated to address
exhaustion or routing table overflow, this should be changed.
the mechanism proposed in this paper will have the fortunate
effect of distributing the address allocation procedure,
reducing the load on the central authority
3.1 Present Allocation
An informal analysis of "network-contacts.txt" (available from
DDN NIC) indicates that as of 2/25/92, 46 of 126 class A
numbers have been allocated (leaving 81) and 5467 of 16382 class
numbers have been allocated, leaving 10915. Assuming that
trends continue, the number of allocated class B's will continue
double approximately once a year. At this rate of growth, all
B's will be exhausted within about 15 months. As of 1/13/93, 52
class A network numbers have been allocated and 7133 class B's
been allocated. We suggest that the change in the class B
rate is due to the initial deployment of this address
plan
Fuller, Li, Yu & Varadhan [Page 7]
RFC 1519 CIDR Address Strategy September 1993
3.2 Historic growth
MM/YY ROUTES MM/YY
ADVERTISED
------------------------ -----------------------
Dec-92 8561 Sep-90 1988
Nov-92 7854 Aug-90 1894
Oct-92 7354 Jul-90 1727
Sep-92 6640 Jun-90 1639
Aug-92 6385 May-90 1580
Jul-92 6031 Apr-90 1525
Jun-92 5739 Mar-90 1038
May-92 5515 Feb-90 997
Apr-92 5291 Jan-90 927
Mar-92 4976 Dec-89 897
Feb-92 4740 Nov-89 837
Jan-92 4526 Oct-89 809
Dec-91 4305 Sep-89 745
Nov-91 3751 Aug-89 650
Oct-91 3556 Jul-89 603
Sep-91 3389 Jun-89 564
Aug-91 3258 May-89 516
Jul-91 3086 Apr-89 467
Jun-91 2982 Mar-89 410
May-91 2763 Feb-89 384
Apr-91 2622 Jan-89 346
Mar-91 2501 Dec-88 334
Feb-91 2417 Nov-88 313
Jan-91 2338 Oct-88 291
Dec-90 2190 Sep-88 244
Nov-90 2125 Aug-88 217
Oct-90 2063 Jul-88 173
Table I : Growth in routing table size, total
Source for the routing table size data is
3.3 Detailed
There is a small technical cost and minimal administrative
associated with deployment of the new address assignment plan.
administrative cost is basically that of convincing the NIC,
IANA, and the network service providers to agree to this plan,
is not expected to be too difficult. In addition,
cost for the central numbering authorities (the NIC and the IANA
will be greatly decreased by the deployment of this plan. To
advantage of aggregation of routing information, however, it
necessary that the capability to represent routes as
network and mask fields (as opposed to the current class A/B/
Fuller, Li, Yu & Varadhan [Page 8]
RFC 1519 CIDR Address Strategy September 1993
distinction) be added to the common Internet inter-domain
protocol(s). Thus, the technical cost is in the implementation
classless interdomain routing protocols
3.3.1 Benefits of the new addressing
There are two benefits to be had by deploying this plan
o The current problem with depletion of the available class
address space can be ameliorated by assigning more
appropriately sized blocks of class C's to mid-
organizations (in the 200-4000 host range).
o When the improved inter-domain routing protocol is deployed
an immediate decrease in the number routing table
should occur, followed by a significant reduction in the
growth of routing table size (for default-free routers).
3.3.2 Growth rate
As of Jan '92, a default-free routing table (for example, the
tables maintained by the routers in the NSFNET backbone)
approximately 4700 entries. This number reflects the current size
the NSFNET routing database. Historic data shows that this number,
average, has doubled every 10 months between 1988 and 1991.
that this growth rate is going to persist in the foreseeable
(and there is no reason to assume otherwise), we expect the number
entries in a default-free routing table to grow to
30000 in two years time. In the following analysis, we assume
the growth of the Internet has been, and will continue to be
exponential
It should be stressed that these projections do not consider that
current shortage of class B network numbers may increase the
of instances where many class C's are used rather than a class B
Using an assumption that new organizations which formerly
class B's will now obtain somewhere between 4 and 16 class C's,
rate of routing table growth can conservatively be expected to
least double and probably quadruple. This means the number of
in a default-free routing table may well exceed 10,000 entries
six months and 20,000 entries in less than a year
As of Dec '92, the routing table contains 8500 routes. The
growth curves would predict over 9400 routes. At this time, it
not clear if this would indicate a significant change in the rate
growth
Under the proposed plan, growth of the routing table in a default
Fuller, Li, Yu & Varadhan [Page 9]
RFC 1519 CIDR Address Strategy September 1993
free router is greatly reduced since most new address assignment
come from one of the large blocks allocated to the service providers
For the sake of this analysis, we assume prompt implementation
this proposal and deployment of the revised routing protocols.
make the initial assumption that any initial block given to
provider is sufficient to satisfy its needs for two years
Since under this plan, multi-homed networks must continue to
explicitly advertised throughout the system (according to Rule #1
described in section 4.2), the number multi-homed routes is
to be the dominant factor in future growth of routing table size
once the supernetting plan is applied
Presently, it is estimated that there are fewer than 100 multi-
organizations connected to the Internet. Each such organization'
network is comprised of one or more network numbers. In many
(and in all future cases under this plan), the network numbers
by an organization are consecutive, meaning that aggregation of
networks during route advertisement may be possible. This means
the number of routes advertised within the Internet for multi-
networks may be approximated as the total number of multi-
organizations. Assuming that the number of multi-homed
will double every year (which may be a over-estimation, given
every connection costs money), the number of routes for multi-
networks would be expected to grow to approximately 800 in
years
If we further assume that there are approximately 100
providers, then each service provider will also need to advertise
block of addresses. However, due to aggregation,
advertisements will be reduced to only 100 additional routes.
assume that after the initial two years, new service
combined with additional requests from existing providers
require an additional 50 routes per year. Thus, the total is 4700 +
800 + 150 = 5650. This represents an annual growth rate
approximately 6%. This is in clear contrast to the current
growth of 130%. This analysis also assumes an immediate
of this plan with full compliance. Note that this analysis
only a single level of route aggregation in the current Internet -
intelligent address allocation should significantly improve this
Clearly, this is not a very conservative assumption in the
environment nor can 100% adoption of this proposal be expected
Still, with only a 90% participation in this proposal by
providers, at the end of the target three years, global routing
size will be "only" 4700 + 800 + 145 + 7500 = 13145 routes --
any action, the routing table will grow to approximately 75000
during that time period
Fuller, Li, Yu & Varadhan [Page 10]
RFC 1519 CIDR Address Strategy September 1993
4. Changes to inter-domain routing protocols and
In order to support supernetting efficiently, it is clear that
changes will need to be made to both routing protocols themselves
to the way in which routing information is interpreted. In the
of "new" inter-domain protocols, the actual protocol syntax
should be relatively minor. This mechanism will not work with
inter-domain protocols such as EGP2; the only ways to
with old systems using such protocols are either to use
mechanisms for providing "default" routes or b) require that
routers talking to old routers "explode" supernet information
individual network numbers. Since the first of these is
while the latter is cumbersome (at best -- consider the
requirements it imposes on the receiver of the exploded information),
it is recommended that the first approach be used -- that
systems to continue to the mechanisms they currently employ
default handling
Note that a basic assumption of this plan is that those
which need to import "supernet" information into their
systems must run IGPs (such as OSPF [1]) which support
routes. Systems running older IGPs may still advertise and
"supernet" information, but they will not be able to propagate
information through their routing domains
4.1 Protocol-independent semantic
There are two fundamental changes which must be applied to Inter
Domain routing protocols in order for this plan to work. First,
concept of network "class" needs to be deprecated - this plan
that routing destinations are represented by network and mask
and that routing is done on a longest-match basis (i.e., for a
destination which matches multiple network+mask pairs, the match
the longest mask is used). Second, current inter-domain
generally do not support the concept of route aggregation, so the
semantics need to be implemented in a new set of inter-
protocols. In particular, when doing aggregation, dealing
multi-homed sites or destinations which change service providers
difficult. Fortunately, it is possible to define several
simple rules for dealing with such cases
4.2. Rules for route
1. Routing to all destinations must be done on a longest-
basis only. This implies that destinations which are multi
homed relative to a routing domain must always be
announced into that routing domain - they cannot be
(this makes intuitive sense - if a network is multi-homed,
Fuller, Li, Yu & Varadhan [Page 11]
RFC 1519 CIDR Address Strategy September 1993
of its paths into a routing domain which is "higher" in
hierarchy of networks must be known to the "higher" network).
2. A routing domain which performs summarization of
routes must discard packets which match the summarization
do not match any of the explicit routes which makes up
summarization. This is necessary to prevent routing loops
the presence of less-specific information (such as a
route). Implementation note - one simple way to
this rule would be for the border router to maintain a "sink
route for each of its aggregations. By the rule of
match, this would cause all traffic destined to components
the aggregation which are not explicitly known to
discarded
Note that during failures, partial routing of traffic to a site
takes its address space from one service provider but which
actually reachable only through another (i.e., the case of a
which has change service providers) may occur because such
will be routed along the path advertised by the aggregated route
Rule #2 will prevent any real problem from occurring by forcing
traffic to be discarded by the advertiser of the aggregated route
but the output of "traceroute" and other similar tools will
that a problem exists within the service provider advertising
aggregate, which may be confusing to network operators (see
example in section 5.2 for details). Solutions to this problem
to be challenging and not likely to be implementable by
Inter-Domain protocols within the time-frame suggested by
document. This decision may need to be revisited as Inter-
protocols evolve
An implementation following these rules should also be generalized
so that an arbitrary network number and mask are accepted for
routing destinations. The only outstanding constraint is that
mask must be left contiguous. Note that the degenerate route 0.0.0.0
mask 0.0.0.0 is used as a default route and MUST be accepted by
implementations. Further, to protect against
advertisements of this route via the inter-domain protocol,
route should never be advertised unless there is
configuration information indicating to do so
Systems which process route announcements must also be able to
that information which they receive is correct. Thus,
of this plan which filter route advertisements must also allow
in the filter elements. To simplify administration, it would
useful if filter elements automatically allowed more specific
numbers and masks to pass in filter elements given for a more
mask. Thus, filter elements which looked like
Fuller, Li, Yu & Varadhan [Page 12]
RFC 1519 CIDR Address Strategy September 1993
accept 128.32.0.0
accept 128.120.0.0
accept 134.139.0.0
deny 36.2.0.0
accept 36.0.0.0
would look something like
accept 128.32.0.0 255.255.0.0
accept 128.120.0.0 255.255.0.0
accept 134.139.0.0 255.255.0.0
deny 36.2.0.0 255.255.0.0
accept 36.0.0.0 255.0.0.0
This is merely making explicit the network mask which was implied
the class A/B/C classification of network numbers
4.3. How the rules
Rule #1 guarantees that the routing algorithm used is
across implementations and consistent with other routing protocols
such as OSPF. Multi-homed networks are always explicitly
by every service provider through which they are routed even if
are a specific subset of one service provider's aggregate (if
are not, they clearly must be explicitly advertised). It may seem
if the "primary" service provider could advertise the multi-
site implicitly as part of its aggregate, but the assumption
longest-match routing is always done causes this not to work
Rule #2 guarantees that no routing loops form due to aggregation
Consider a mid-level network which has been allocated the 2048
C networks starting with 192.24.0.0 (see the example in section 5
more on this). The mid-level advertises to a "backbone
192.24.0.0/255.248.0.0. Assume that the "backbone", in turn, has
allocated the block of networks 192.0.0.0/255.0.0.0. The
will then advertise this aggregate route to the mid-level. Now,
the mid-level loses internal connectivity to the
192.24.1.0/255.255.255.0 (which is part of its aggregate),
from the "backbone" to the mid-level to destination 192.24.1.1
follow the mid-level's advertised route. When that traffic gets
the mid-level, however, the mid-level *must not* follow the
192.0.0.0/255.0.0.0 it learned from the backbone, since that
result in a routing loop. Rule #2 says that the mid-level may
follow a less-specific route for a destination which matches one
its own aggregated routes. Note that handling of the "default"
(0.0.0.0/0.0.0.0) is a special case of this rule - a network must
follow the default to destinations which are part of one of it'
aggregated advertisements
Fuller, Li, Yu & Varadhan [Page 13]
RFC 1519 CIDR Address Strategy September 1993
4.4. Responsibility for and configuration of
The domain which has been allocated a range of addresses has the
authority for aggregation of its address space. In the usual case
the AS will install manual configuration commands in its
routers to aggregate some portion of its address space. An
can also delegate aggregation authority to another domain. In
case, aggregation is done in the other domain by one of its
routers
When an inter-domain border router performs route aggregation,
needs to know the range of the block of IP addresses to
aggregated. The basic principle is that it should aggregate as
as possible but not to aggregate those routes which cannot be
as part of a single unit due to multi-homing, policy, or
constraints
One mechanism is to do aggregation solely based on
learned routing information. This has the danger of not specifying
precise enough range since when a route is not present, it is
always possible to distinguish whether it is temporarily
or that it does not belong in the aggregate. Purely dynamic
also does not allow the flexibility of defining what to
within a range. The other mechanism is to do all aggregation based
ranges of blocks of IP addresses preconfigured in the router. It
recommended that preconfiguration be used, since it more flexible
allows precise specification of the range of destinations
aggregate
Preconfiguration does require some manually-maintained
information, but not excessively more so than what
administrators already maintain today. As an addition to the
of information that must be typed in and maintained by a human
preconfiguration is just a line or two defining the range of
block of IP addresses to aggregate. In terms of gathering
information, if the advertising router is doing the aggregation,
administrator knows the information because the aggregation
are assigned to its domain. If the receiving domain has been
the authority to and task of performing aggregation, the
would be known as part of the agreement to delegate aggregation
Given that it is common practice that a network administrator
from its neighbor which routes it should be willing to accept
preconfiguration of aggregation information does not
additional administrative overhead
Implementation note: aggregates which encompass the class D
space (multicast addresses) are currently not well understood.
present, it appears that the optimal strategy is to
Fuller, Li, Yu & Varadhan [Page 14]
RFC 1519 CIDR Address Strategy September 1993
aggregates to never encompass class D space, even if they do
numerically
4.5 Intra-domain protocol
While no changes need be made to internal routing protocols
support the advertisement of aggregated routing information
autonomous systems, it is often the case that external
information is propagated within interior protocols for
reasons or to aid in the propagation of information through a
network. At the point when aggregated routing information starts
appear in the new exterior protocols, this practice of
external information will have to be modified. A transit
which imports external information will have to do one of
a) use an interior protocol which supports aggregated
b) find some other method of propagating external
which does not involve flooding it through the
protocol (i.e., by the use of internal BGP, for example).
c) stop the importation of external information and flood
"default" route through the internal protocol for
of paths to external destinations
For case (a), the modifications necessary to a routing protocol
allow it to support aggregated information may not be simple.
protocols such as OSPF and IS-IS, which represent routing
as either a destination+mask (OSPF) or as a prefix+prefix-
(IS-IS) changes to support aggregated information are
fairly simple; for protocols which are dependent on the class-A/B/
nature of networks or which support only fixed-sized subnets,
changes are of a more fundamental nature. Even in the "
simple" cases of OSPF and IS-IS, an implementation may need to
modified to support supernets in the database or in the
table
5. Example of new allocation and
5.1 Address
Consider the block of 2048 class C network numbers beginning
192.24.0.0 (0xC0180000 and ending with 192.31.255.0 (0xC01FFF00)
allocated to a single network provider, "RA". A "supernetted"
to this block of network numbers would be described as 192.24.0.0
with mask of 255.248.0.0 (0xFFF80000).
Fuller, Li, Yu & Varadhan [Page 15]
RFC 1519 CIDR Address Strategy September 1993
Assume this service provider connects six clients in the
order (significant because it demonstrates how temporary "holes"
form in the service provider's address space):
"C1" requiring fewer than 2048 addresses (8 class C networks
"C2" requiring fewer than 4096 addresses (16 class C networks
"C3" requiring fewer than 1024 addresses (4 class C networks
"C4" requiring fewer than 1024 addresses (4 class C networks
"C5" requiring fewer than 512 addresses (2 class C networks
"C6" requiring fewer than 512 addresses (2 class C networks
In all cases, the number of IP addresses "required" by each client
assumed to allow for significant growth. The service
allocates its address space as follows
C1: allocate 192.24.0 through 192.24.7. This block of networks
described by the "supernet" route 192.24.0.0 and
255.255.248.0
C2: allocate 192.24.16 through 192.24.31. This block is
by the route 192.24.16.0, mask 255.255.240.0
C3: allocate 192.24.8 through 192.24.11. This block is
by the route 192.24.8.0, mask 255.255.252.0
C4: allocate 192.24.12 through 192.24.15. This block is
by the route 192.24.12.0, mask 255.255.252.0
C5: allocate 192.24.32 and 192.24.33. This block is described
the route 192.24.32.0, mask 255.255.254.0
C6: allocate 192.24.34 and 192.24.35. This block is described
the route 192.24.34.0, mask 255.255.254.0
Note that if the network provider uses an IGP which can
classless networks, he can (but doesn't have to)
"supernetting" at the point where he connects to his clients
therefore only maintain six distinct routes for the 36 class
network numbers. If not, explicit routes to all 36 class C
will have to be carried by the IGP
To make this example more realistic, assume that C4 and C5
multi-homed through some other service provider, "RB". Further
Fuller, Li, Yu & Varadhan [Page 16]
RFC 1519 CIDR Address Strategy September 1993
the existence of a client "C7" which was originally connected to "RB
but has moved to "RA". For this reason, it has a block of
numbers which are allocated out "RB"'s block of (the next) 2048
C network numbers
C7: allocate 192.32.0 through 192.32.15. This block is
by the route 192.32.0, mask 255.255.240.0
For the multi-homed clients, we will assume that C4 is advertised
primary via "RA" and secondary via "RB"; C5 is primary via "RB"
secondary via "RA". To connect this mess together, we will
that "RA" and "RB" are connected via some common "backbone"
"BB".
Graphically, this simple topology looks something like this
C
192.24.0.0 -- 192.24.7.0 \ _ 192.32.0.0 - 192.32.15.0
192.24.0.0/255.255.248.0 \ / 192.32.0.0/255.255.240.0
\ / C
C2 +----+ +----+
192.24.16.0 - 192.24.31.0 \| | | |
192.24.16.0/255.255.240.0 | | _ 192.24.12.0 - 192.24.15.0 _ | |
| | / 192.24.12.0/255.255.252.0 \ | |
C3 -| |/ C4 \| |
192.24.8.0 - 192.24.11.0 | RA | | RB |
192.24.8.0/255.255.252.0 | |___ 192.24.32.0 - 192.24.33.0 ___| |
/| | 192.24.32.0/255.255.254.0 | |
C6 | | C5 | |
192.24.34.0 - 192.24.35.0 | | | |
192.24.34.0/255.255.254.0 | | | |
+----+ +----+
\\ \\
192.24.12.0/255.255.252.0 (C4) || 192.24.12.0/255.255.252.0 (C4) ||
192.32.0.0/255.255.240.0 (C7) || 192.24.32.0/255.255.254.0 (C5) ||
192.24.0.0/255.248.0.0 (RA) || 192.32.0.0/255.248.0.0 (RB) ||
|| ||
VV
+--------------- BACKBONE PEER BB ---------------+
5.2 Routing
To follow rule #1, RA will need to advertise the block of
that it was given and C7. Since C4 is multi-homed and
through RA, it must also be advertised. C5 is multi-homed
primary through RB. It need not be advertised since longest match
BB will automatically select RB as primary and the advertisement
Fuller, Li, Yu & Varadhan [Page 17]
RFC 1519 CIDR Address Strategy September 1993
RA's aggregate will be used as a secondary
Advertisements from "RA" to "BB" will be
192.24.12.0/255.255.252.0 primary (advertises C4)
192.32.0.0/255.255.240.0 primary (advertises C7)
192.24.0.0/255.248.0.0 primary (advertises remainder of RA
For RB, the advertisements must also include C4 and C5 as well
it's block of addresses. Further, RB may advertise that C7
unreachable
Advertisements from "RB" to "BB" will be
192.24.12.0/255.255.252.0 secondary (advertises C4)
192.24.32.0/255.255.254.0 primary (advertises C5)
192.32.0.0/255.248.0.0 primary (advertises remainder of RB
To illustrate the problem alluded to by the "note" in section 4.2,
consider what happens if RA loses connectivity to C7 (the
which is allocated out of RB's space). In a stateful protocol,
will announce to BB that 192.32.0.0/255.255.240.0 has
unreachable. Now, when BB flushes this information out of its
table, any future traffic sent through it for this destination
be forwarded to RB (where it will be dropped according to Rule #2)
virtue of RB's less specific match 192.32.0.0/255.248.0.0.
this does not cause an operational problem (C7 is unreachable in
case), it does create some extra traffic across "BB" (and may
prove confusing to a network manager debugging the outage
"traceroute"). A mechanism to cache such unreachability
would help here, but is beyond the scope of this document (such
mechanism is also not implementable in the near-term).
6. Extending CIDR to class A
At some point, it is expected that this plan will eventually
all of the remaining class C address space. As of this writing,
upper half of the class A address space has already been reserved
future expansion. This section describes how the CIDR plan can
used to utilize this portion of the class A space efficiently. It
expected that this contingency would only be used if no long
solution has become apparent by the time that the class C
space is consumed
Fundamentally, there are two differences between using a class
address and a block of class C's. First, the configuration of
becomes somewhat more complicated than it is without the
of class A subnets. The second difference is that the routers
Fuller, Li, Yu & Varadhan [Page 18]
RFC 1519 CIDR Address Strategy September 1993
the class A address would need to support and use a classless IGP
Maintenance of DNS with a subnetted class A is somewhat painful.
part of the mechanism for providing reverse address lookups,
maintains a "IN-ADDR.ARPA" reverse domain. This is configured
reversing the dotted decimal network number, appending "IN-ADDR.ARPA
and using this as a type of pseudo-domain. Individual hosts then
up pointing back to a host name. Thus, for example, 131.108.1.111
has a DNS record "111.1.108.131.IN-ADDR.ARPA." Since the pseudo
domains can only be delegated on a byte boundary, this
painful if a stub domain receives a block of address space that
not fall on a byte boundary. The solution in this case is
enumerate all of the possible byte combinations involved. This
painful, but workable. This is discussed further below
Routing within a class A used for CIDR is also an
challenge. The usual case will be that a domain will be assigned
portion of the class A address space. The domain can either use
IGP which allows variable length subnets or it can pick a
subnet mask to be used throughout the domain. In the latter case
difficulties arise because other domains have been allocated
parts of the class A address space and may be using a
subnet mask. If the domain is itself a transit, it may also need
allocate some portion of its space to a client, which might also
a different subnet mask. The client would then need
information about the remainder of the class A
If the client's IGP does not support variable length subnet masks
this could be done by advertising the remainder of the class A'
address space in appropriately sized subnets. However, unless
client has a very large portion of the class A space, this is
to result in a large number of subnets (for example, a mask
255.255.255.0 would require a total of 65535 subnets, including
allocated to the client). For this reason, it may be preferable
simply use an IGP that supports variable length subnet masks
the client's domain
Similarly, if a transit has been assigned address space from a
A network number, it is likely that it was not assigned the
class A, and that other transit domains will get address space
this class A. In this case, the transit would also have to
routing information about the remainder of the class A into it's IGP
This is analogous to the situation above, with the
complications. For this reason, we recommend that the use of a
A for CIDR only be attempted if IGP's with variable length
mask support be used throughout the class A. Note that the IGP'
need not support supernetting, as discussed above
Fuller, Li, Yu & Varadhan [Page 19]
RFC 1519 CIDR Address Strategy September 1993
Note that the technique here could also apply to class B addresses
However, the limited number of available class B addresses and
usage for multihomed networks suggests that this address space
only be reserved for those large single organizations that
this type of address. [2]
7. Domain Service
One aspect of Internet services which will be notably affected by
move to either "supernetted" class-C network numbers or
class-A's will be the mechanism used for address-to-name translation
the IN-ADDR.ARPA zone of the domain system. Because this zone
delegated on octet boundaries only, any address allocation plan
uses bitmask-oriented addressing will cause some degree of
for those which maintain parts of the IN-ADDR.ARPA zone
7.1 Procedural changes for class-C "supernets
At the present time, parts of the IN-ADDR.ARPA zone are
only on network boundaries which happen to fall on octet boundaries
To aid in the use of blocks of class-C networks, it is
that this policy be relaxed and allow the delegation of arbitrary
octet-oriented pieces of the IN-ADDR.ARPA zone
As an example of this policy change, consider a hypothetical
network provider named "BigNet" which has been allocated the 1024
class-C networks 199.0.0 through 199.3.255. Under current policies
the root domain servers would need to have 1024 entries of the form
0.0.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET
1.0.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET
....
255.3.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET
By revising the policy as described above, this is reduced only
delegation records
0.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET
1.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET
2.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET
3.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET
Fuller, Li, Yu & Varadhan [Page 20]
RFC 1519 CIDR Address Strategy September 1993
The provider would then maintain further delegations of
authority for each individual class-C network which it assigns
rather than having each registered separately. Note that due to
way the DNS is designed, it is still possible for the
nameservers to maintain the delegation information for
networks for which the provider is unwilling or unable to do so.
should greatly reduce the load on the domain servers for the "top
levels of the IN-ADDR.ARPA domain. The example above
only the records for a single nameserver. In the normal case,
are usually several nameservers for each domain, thus the size of
examples will double or triple in the common cases
7.2 Procedural changes for class-A
Should it be the case the class-A network numbers are subdivided
blocks allocated to transit network providers, it will be
necessary to relax the restriction on how IN-ADDR.ARPA naming
for them. As an example, take a provider is allocated the 19-
portion of address space which matches 10.8.0.0 with
255.248.0.0. This represents all addresses which begin with
prefixes 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, an 10.15
requires the following IN-ADDR.ARPA delegations
8.10.IN-ADDR.ARPA. IN NS NS1.MOBY.NET
9.10.IN-ADDR.ARPA. IN NS NS1.MOBY.NET
....
15.10.IN-ADDR.ARPA. IN NS NS1.MOBY.NET
To further illustrate how IN-ADDR.ARPA sub-delegation will work
consider a company named "FOO" connected to this provider which
been allocated the 14-bit piece of address space which
10.10.64.0 with mask 255.255.192.0. This represents all addresses
the range 10.10.64.0 through 10.10.127.255 and will require that
provider implement the following IN-ADDR.ARPA delegations
64.10.10.IN-ADDR.ARPA. IN NS NS1.FOO.COM
65.10.10.IN-ADDR.ARPA. IN NS NS1.FOO.COM
....
127.10.10.IN-ADDR.ARPA. IN NS NS1.FOO.COM
with the servers for "FOO.COM" containing the individual PTR
for all of the addresses on each of these subnets
Fuller, Li, Yu & Varadhan [Page 21]
RFC 1519 CIDR Address Strategy September 1993
8. Transitioning to a long term
This solution does not change the Internet routing and
architectures. Hence, transitioning to a more long term solution
not affected by the deployment of this plan
9.
We are all aware of the growth in routing complexity, and the
increase in allocation of network numbers. Given the rate at
this growth is being observed, we expect to run out in a few
years
If the inter-domain routing protocol supports carrying network
with associated masks, all of the major concerns demonstrated in
paper would be eliminated
One of the influential factors which permits maximal exploitation
the advantages of this plan is the number of people who agree to
it
If service providers start charging networks for advertising
numbers, this would be a very great incentive to share the
space, and hence the associated costs of advertising routes
service providers
10.
The NIC should begin to hand out large blocks of class C addresses
network service providers. Each block must fall on bit
and should be large enough to serve the provider for two years
Further, the NIC should distribute very large blocks to
and national network service organizations to allow additional
of aggregation to take place at the major backbone networks.
addition, the NIC should modify its procedures for the IN-ADDR.
domain to permit delegation along arbitrary octet boundaries
Service providers will further allocate power-of-two blocks of
C addresses from their address space to their subscribers
All organizations, including those which are multi-homed,
obtain address space from their provider (or one of their providers
in the case of the multi-homed). These blocks should also fall
bit boundaries to permit easy route aggregation
To allow effective use of this new addressing plan to
propagated routing information, appropriate IETF WGs will specify
modifications needed to Inter-Domain routing protocols
Fuller, Li, Yu & Varadhan [Page 22]
RFC 1519 CIDR Address Strategy September 1993
Implementation and deployment of these modifications should occur
quickly as possible
11
[1] Moy, J, "The OSPF Specification Version 2", RFC 1247, Proteon
Inc., January 1991.
[2] Rekhter, Y., and T. Li, "An Architecture for IP
Allocation with CIDR", RFC 1518, T.J. Watson Research Center,
Corp., cisco Systems, September 1993.
12. Security
Security issues are not discussed in this memo
Fuller, Li, Yu & Varadhan [Page 23]
RFC 1519 CIDR Address Strategy September 1993
13. Authors'
Vince
Pine Hall 115
Stanford, CA, 94305-4122
EMail: vaf@Stanford.
Tony
cisco Systems, Inc
1525 O'Brien
Menlo Park, CA 94025
EMail: tli@cisco.
Jessica (Jie Yun)
Merit Network, Inc
1071 Beal Ave
Ann Arbor, MI 48109
EMail: jyy@merit.
Kannan
Internet Engineer,
1224, Kinnear Road
Columbus, OH 43212
EMail: kannan@oar.
Fuller, Li, Yu & Varadhan [Page 24]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
