📄 rfc1519.txt
字号:
Fuller, Li, Yu & Varadhan [Page 6]
RFC 1519 CIDR Address Strategy September 1993
of this expected drop and the permanent reduction in rate of growth
is given in the next section.
In should also be noted that the present method of flat address
allocations imposes a large bureaucratic cost on the central address
allocation authority. For scaling reasons unrelated to address space
exhaustion or routing table overflow, this should be changed. Using
the mechanism proposed in this paper will have the fortunate side
effect of distributing the address allocation procedure, greatly
reducing the load on the central authority.
3.1 Present Allocation Figures
An informal analysis of "network-contacts.txt" (available from the
DDN NIC) indicates that as of 2/25/92, 46 of 126 class A network
numbers have been allocated (leaving 81) and 5467 of 16382 class B
numbers have been allocated, leaving 10915. Assuming that recent
trends continue, the number of allocated class B's will continue to
double approximately once a year. At this rate of growth, all class
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 have
been allocated. We suggest that the change in the class B allocation
rate is due to the initial deployment of this address allocation
plan.
Fuller, Li, Yu & Varadhan [Page 7]
RFC 1519 CIDR Address Strategy September 1993
3.2 Historic growth rates
MM/YY ROUTES MM/YY ROUTES
ADVERTISED 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 numbers
Source for the routing table size data is MERIT
3.3 Detailed Analysis
There is a small technical cost and minimal administrative cost
associated with deployment of the new address assignment plan. The
administrative cost is basically that of convincing the NIC, the
IANA, and the network service providers to agree to this plan, which
is not expected to be too difficult. In addition, administrative
cost for the central numbering authorities (the NIC and the IANA)
will be greatly decreased by the deployment of this plan. To take
advantage of aggregation of routing information, however, it is
necessary that the capability to represent routes as arbitrary
network and mask fields (as opposed to the current class A/B/C
Fuller, Li, Yu & Varadhan [Page 8]
RFC 1519 CIDR Address Strategy September 1993
distinction) be added to the common Internet inter-domain routing
protocol(s). Thus, the technical cost is in the implementation of
classless interdomain routing protocols.
3.3.1 Benefits of the new addressing plan
There are two benefits to be had by deploying this plan:
o The current problem with depletion of the available class B
address space can be ameliorated by assigning more-
appropriately sized blocks of class C's to mid-sized
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 entries
should occur, followed by a significant reduction in the rate
growth of routing table size (for default-free routers).
3.3.2 Growth rate projections
As of Jan '92, a default-free routing table (for example, the routing
tables maintained by the routers in the NSFNET backbone) contained
approximately 4700 entries. This number reflects the current size of
the NSFNET routing database. Historic data shows that this number, on
average, has doubled every 10 months between 1988 and 1991. Assuming
that this growth rate is going to persist in the foreseeable future
(and there is no reason to assume otherwise), we expect the number of
entries in a default-free routing table to grow to approximately
30000 in two years time. In the following analysis, we assume that
the growth of the Internet has been, and will continue to be,
exponential.
It should be stressed that these projections do not consider that the
current shortage of class B network numbers may increase the number
of instances where many class C's are used rather than a class B.
Using an assumption that new organizations which formerly obtained
class B's will now obtain somewhere between 4 and 16 class C's, the
rate of routing table growth can conservatively be expected to at
least double and probably quadruple. This means the number of entries
in a default-free routing table may well exceed 10,000 entries within
six months and 20,000 entries in less than a year.
As of Dec '92, the routing table contains 8500 routes. The original
growth curves would predict over 9400 routes. At this time, it is
not clear if this would indicate a significant change in the rate of
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 will
come from one of the large blocks allocated to the service providers.
For the sake of this analysis, we assume prompt implementation of
this proposal and deployment of the revised routing protocols. We
make the initial assumption that any initial block given to a
provider is sufficient to satisfy its needs for two years.
Since under this plan, multi-homed networks must continue to be
explicitly advertised throughout the system (according to Rule #1
described in section 4.2), the number multi-homed routes is expected
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-homed
organizations connected to the Internet. Each such organization's
network is comprised of one or more network numbers. In many cases
(and in all future cases under this plan), the network numbers used
by an organization are consecutive, meaning that aggregation of those
networks during route advertisement may be possible. This means that
the number of routes advertised within the Internet for multi-homed
networks may be approximated as the total number of multi-homed
organizations. Assuming that the number of multi-homed organization
will double every year (which may be a over-estimation, given that
every connection costs money), the number of routes for multi-homed
networks would be expected to grow to approximately 800 in three
years.
If we further assume that there are approximately 100 service
providers, then each service provider will also need to advertise its
block of addresses. However, due to aggregation, these
advertisements will be reduced to only 100 additional routes. We
assume that after the initial two years, new service providers
combined with additional requests from existing providers will
require an additional 50 routes per year. Thus, the total is 4700 +
800 + 150 = 5650. This represents an annual growth rate of
approximately 6%. This is in clear contrast to the current annual
growth of 130%. This analysis also assumes an immediate deployment
of this plan with full compliance. Note that this analysis assumes
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 Internet
environment nor can 100% adoption of this proposal be expected.
Still, with only a 90% participation in this proposal by service
providers, at the end of the target three years, global routing table
size will be "only" 4700 + 800 + 145 + 7500 = 13145 routes -- without
any action, the routing table will grow to approximately 75000 routes
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 practices
In order to support supernetting efficiently, it is clear that some
changes will need to be made to both routing protocols themselves and
to the way in which routing information is interpreted. In the case
of "new" inter-domain protocols, the actual protocol syntax changes
should be relatively minor. This mechanism will not work with older
inter-domain protocols such as EGP2; the only ways to interoperate
with old systems using such protocols are either to use existing
mechanisms for providing "default" routes or b) require that new
routers talking to old routers "explode" supernet information into
individual network numbers. Since the first of these is trivial
while the latter is cumbersome (at best -- consider the memory
requirements it imposes on the receiver of the exploded information),
it is recommended that the first approach be used -- that older
systems to continue to the mechanisms they currently employ for
default handling.
Note that a basic assumption of this plan is that those organizations
which need to import "supernet" information into their routing
systems must run IGPs (such as OSPF [1]) which support classless
routes. Systems running older IGPs may still advertise and receive
"supernet" information, but they will not be able to propagate such
information through their routing domains.
4.1 Protocol-independent semantic changes
There are two fundamental changes which must be applied to Inter-
Domain routing protocols in order for this plan to work. First, the
concept of network "class" needs to be deprecated - this plan assumes
that routing destinations are represented by network and mask pairs
and that routing is done on a longest-match basis (i.e., for a given
destination which matches multiple network+mask pairs, the match with
the longest mask is used). Second, current inter-domain protocols
generally do not support the concept of route aggregation, so the new
semantics need to be implemented in a new set of inter-domain
protocols. In particular, when doing aggregation, dealing with
multi-homed sites or destinations which change service providers is
difficult. Fortunately, it is possible to define several fairly
simple rules for dealing with such cases.
4.2. Rules for route advertisement
1. Routing to all destinations must be done on a longest-match
basis only. This implies that destinations which are multi-
homed relative to a routing domain must always be explicitly
announced into that routing domain - they cannot be summarized
(this makes intuitive sense - if a network is multi-homed, all
Fuller, Li, Yu & Varadhan [Page 11]
RFC 1519 CIDR Address Strategy September 1993
of its paths into a routing domain which is "higher" in the
hierarchy of networks must be known to the "higher" network).
2. A routing domain which performs summarization of multiple
routes must discard packets which match the summarization but
do not match any of the explicit routes which makes up the
summarization. This is necessary to prevent routing loops in
the presence of less-specific information (such as a default
route). Implementation note - one simple way to implement
this rule would be for the border router to maintain a "sink"
route for each of its aggregations. By the rule of longest
match, this would cause all traffic destined to components of
the aggregation which are not explicitly known to be
discarded.
Note that during failures, partial routing of traffic to a site which
takes its address space from one service provider but which is
actually reachable only through another (i.e., the case of a site
which has change service providers) may occur because such traffic
will be routed along the path advertised by the aggregated route.
Rule #2 will prevent any real problem from occurring by forcing such
traffic to be discarded by the advertiser of the aggregated route,
but the output of "traceroute" and other similar tools will suggest
that a problem exists within the service provider advertising the
aggregate, which may be confusing to network operators (see the
example in section 5.2 for details). Solutions to this problem appear
to be challenging and not likely to be implementable by current
Inter-Domain protocols within the time-frame suggested by this
document. This decision may need to be revisited as Inter-Domain
protocols evolve.
An implementation following these rules should also be generalized,
so that an arbitrary network number and mask are accepted for all
routing destinations. The only outstanding constraint is that the
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 all
implementations. Further, to protect against accidental
advertisements of this route via the inter-domain protocol, this
route should never be advertised unless there is specific
configuration information indicating to do so.
Systems which process route announcements must also be able to verify
that information which they receive is correct. Thus, implementations
of this plan which filter route advertisements must also allow masks
in the filter elements. To simplify administration, it would be
useful if filter elements automatically allowed more specific network
numbers and masks to pass in filter elements given for a more general
mask. Thus, filter elements which looked like:
Fuller, Li, Yu & Varadhan [Page 12]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -