rfc1467.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                        C. Topolcic
Request for Comments: 1467                                          CNRI
Obsoletes: 1367                                              August 1993


               Status of CIDR Deployment in the Internet

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   This document describes the current status of the development and
   deployment of CIDR technology into the Internet. This document
   replaces RFC 1367, which was a schedule for the deployment of IP
   address space management procedures to support route aggregation.
   Since all the milestones proposed in RFC 1367 except for the delivery
   and installation of CIDR software were met, it does not seem
   appropriate to issue an updated schedule. Rather, this document is
   intended to provide information about how this effort is proceeding,
   which may be of interest to the community.

1. Background

   The Internet's exponential growth has led to a number of difficulties
   relating to the management of IP network numbers.  The administrative
   overhead of allocating ever increasing volumes of IP network numbers
   for global users has stressed the organizations that perform this
   function.  The volume of IP network numbers that are reachable
   through the Internet has taxed a number of routers' ability to manage
   their forwarding tables.  The poor utilization of allocated IP
   network numbers has threatened to deplete the Class A and Class B
   address space.

   During the past few years, a consensus has emerged among the Internet
   community in favor of a number of mechanisms to relieve these
   problems for the mid-term.  These mechanisms are expected to be put
   into place in the short term and to provide relief for the mid-term.
   Fundamental changes to the Internet protocols to ensure the
   Internet's continued long term growth and well being are being
   explored and are expected to succeed the mid-term mechanisms.

   The global Internet community have been cooperating closely in such
   forums as the IETF and its working groups, the IEPG, the NSF Regional
   Techs Meetings, INET, INTEROP, FNC, FEPG, and other assemblies in



Topolcic                                                        [Page 1]

RFC 1467       Status of CIDR Deployment in the Internet     August 1993


   order to ensure the continued stable operation of the Internet.
   Recognizing the need for the mid-term mechanisms and receiving
   support from the Internet community, the US Federal Agencies proposed
   procedures to assist the deployment of these mid-term mechanisms.
   These procedures were originally described in RFC 1366 [1], which was
   recently made obsolete by RFC 1466 [2].  In October 1992, a schedule
   was proposed for the implementation of the procedures, described in
   RFC 1367 [3].

2. Milestones that have been met

   Most of the milestones of the proposed schedule were implemented on
   time. These milestones are shown below, essentially as they appear in
   [3], but with further comment where appropriate:

      1) 31 October 92:

         The following address allocation procedures were continued:

         a) Initial set of criteria for selecting regional address
            registries were put into place, and requests from
            prospective regional registries were accepted by the
            IANA.

            The Reseaux IP Europeens Network Coordination Centre
            (RIPE NCC) requested to become a regional registry.
            As per the addressing plan of RFC 1366, the RIPE NCC
            was given the block 194.0.0.0 to 195.255.255.255 to
            administer for the European Internet community. The RIPE
            NCC had previously and independently obtained the block
            193.0.0.0 to 193.255.255.255. Although this block had been
            allocated before RFC 1366, the RIPE NCC was able to manage
            it according to the guidelines in RFC 1366.

         b) Class A network numbers were put on reserve for possible
            future use. The unreserved Class A numbers became very
            difficult to obtain.

         c) Class B network numbers were issued only when
            reasonably justified.  Whenever possible, a block of C's
            was issued rather than a B. The requirements for
            allocating a Class B became progressively more constrained
            until the date in step (3).








Topolcic                                                        [Page 2]

RFC 1467       Status of CIDR Deployment in the Internet     August 1993


         d) Class C network numbers were allocated according to the
            addressing plan of [1], now obsoleted by [2].  Allocation
            continued to be performed by the Internet Registry (IR)
            for regions of the world where an appropriate regional
            registry had not yet been designated by the IANA.

      2) 14 February 93:

         The schedule in [3] was re-evaluated, and there appeared to
         be no reason to readjust it, so it was continued as
         originally set out.

      3) 15 April 93:

         a) The IR began to allocate all networks according to the
            addressing plan of [1], now obsoleted by [2], in
            appropriately sized blocks of Class C numbers.

         b) Class B network numbers became difficult to obtain,
            following the recommendation of the addressing plan and
            were only issued when justified.

   Furthermore, throughout this time period, network service providers
   have requested blocks of network numbers from the Class C address
   space for the purpose of further allocating them to their clients.
   The network service providers were allocated such space by the RIPE
   NCC or the IR, acting for North America and the Pacific Rim. This
   process has started to distribute the function of address
   registration to a more regional level, closer to the end users. The
   process has operated as hoped for, with no major problems.

3. Milestone that has not been met

   The proposed schedule of [3] stated that 6 June 1993 was the date
   when an address aggregation mechanism would be generally available in
   the Internet. Although this target date was based on the plans as
   stated by the router vendors and was reasonable at the time the
   schedule in [3] was formulated, it has slipped.  Nevertheless, the
   continuation of that schedule has so far not added significantly to
   the problems of the Internet. The rest of this document looks at the
   current situation and what can be expected in the near future.

4. Current status of address aggregation mechanisms in commercial
   routers

   Although RFCs 1366, 1466, and 1367 do not depend on any specific
   address aggregation technology, there is consensus in the Internet
   community to use Classless Inter-Domain Routing (CIDR) [4]. CIDR is



Topolcic                                                        [Page 3]

RFC 1467       Status of CIDR Deployment in the Internet     August 1993


   supported by BGP-4 and IDRP. Most router vendors are working on BGP-
   4, first, and there is a consensus to use BGP-4 to support the
   initial deployment of CIDR in the Internet.

   The following paragraphs describe the implementation status and plans
   of software to support CIDR in various router vendors' products,
   listed in alphabetical order.  Some speculation is necessarily
   involved in deriving these projections.  See also the minutes of the
   July 1993 meeting of the BGP Deployment Working Group of the IETF
   [5].

   3Com's BGP-4 code has been tested internally. They have code that
   accepts, forwards and manages aggregated routes properly, and they
   are ready to test it for interoperability with other vendors. They
   have yet to implement the code that forms the route aggregates. They
   expect to have Beta code done by September, and full release code
   shortly thereafter. The initial implementation will not support de-
   aggregation.  Their plans here are not yet formulated. They will
   support de-aggregation if necessary.

   ANS has a BGP-4 implementation that is being tested internally.  It
   is stable enough to begin testing for interoperability with other
   vendors' implementations.  Depending of the results of
   interoperability testing, this code could be deployed into the ANSNET
   by August.  This delay is primarily because some routers are running
   older code, and they all need to be upgraded to GATED before they can
   all support BGP-4 internally. So the ability to support CIDR looks
   like it is about one to two months away. This code will not support
   controlled de-aggregation, but de-aggregation will be supported if
   necessary.

   BBN plans to complete it's development of BGP-4 by early Summer 1994.
   Initial plans are to implement both aggregation and controlled de-
   aggregation with an early release of the software.

   Cisco's BGP-4 implementation is under development at this time.
   There is pre-Beta code available for people to begin testing.  It is
   expected that the code will be stable sometime during the summer of
   1993 and will be made available for limited deployment at that time.
   This BGP-4 code will implement aggregation. It will not be part of
   the normal release cycle at this time.  It will be available in a
   special software release based on the 9.21 release. This initial
   BGP-4 code will not implement controlled de-aggregation, but Cisco
   plans on implementing de-aggregation.

   Proteon's BGP-4 code has been tested internally. They are ready to
   test it for interoperability with other vendors. If this works out
   reasonably well, then it is reasonable to expect that they can start



Topolcic                                                        [Page 4]

RFC 1467       Status of CIDR Deployment in the Internet     August 1993


   to deploy this as Beta code by August, with a target of full release
   in the fall. This initial implementation will not support aggregation
   or de-aggregation. Aggregation will be implemented soon thereafter,
   but their plans for de-aggregation are not yet formulated.  They will
   implement de-aggregation if necessary.

   Wellfleet is aiming at having beta code implementing BGP-4 roughly in
   early 1994. This code will include controlled de-aggregation.

5. Rate of growth

   MERIT periodically publishes the number of networks in the
   NSFNET/ANSNET policy routing database.  Analysis of this data
   suggests that the number of entries in this database is growing at
   approximately 8% per month, or doubling every nine or ten months [6].

   Although there are currently over 13K networks in the NSFNET/ANSNET
   policy routing database, a number of them are not active. That is,
   they are not announced to the NSFNET/ANSNET Backbone. The 10K active
   network point was passed in late June. Assuming that the number of
   active networks continues to grow at the same rate as in the past, it
   can be projected that the 12K active network point will be reached
   sometime in approximately late September 1993 and that the 25K active
   network point will be reached sometime in mid-94 (two high water