rfc1519.txt

RFC 的详细文档！

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.  As
   part of the mechanism for providing reverse address lookups, DNS
   maintains a "IN-ADDR.ARPA" reverse domain.  This is configured by
   reversing the dotted decimal network number, appending "IN-ADDR.ARPA"
   and using this as a type of pseudo-domain.  Individual hosts then end
   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 becomes
   painful if a stub domain receives a block of address space that does
   not fall on a byte boundary.  The solution in this case is to
   enumerate all of the possible byte combinations involved.  This is
   painful, but workable.  This is discussed further below.

   Routing within a class A used for CIDR is also an interesting
   challenge.  The usual case will be that a domain will be assigned a
   portion of the class A address space.  The domain can either use an
   IGP which allows variable length subnets or it can pick a single
   subnet mask to be used throughout the domain.  In the latter case,
   difficulties arise because other domains have been allocated other
   parts of the class A address space and may be using a different
   subnet mask.  If the domain is itself a transit, it may also need to
   allocate some portion of its space to a client, which might also use
   a different subnet mask.  The client would then need routing
   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's
   address space in appropriately sized subnets.  However, unless the
   client has a very large portion of the class A space, this is likely
   to result in a large number of subnets (for example, a mask of
   255.255.255.0 would require a total of 65535 subnets, including those
   allocated to the client).  For this reason, it may be preferable to
   simply use an IGP that supports variable length subnet masks within
   the client's domain.

   Similarly, if a transit has been assigned address space from a class
   A network number, it is likely that it was not assigned the entire
   class A, and that other transit domains will get address space from
   this class A.  In this case, the transit would also have to inject
   routing information about the remainder of the class A into it's IGP.
   This is analogous to the situation above, with the same
   complications.  For this reason, we recommend that the use of a class
   A for CIDR only be attempted if IGP's with variable length subnet
   mask support be used throughout the class A.  Note that the IGP's
   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 their
   usage for multihomed networks suggests that this address space should
   only be reserved for those large single organizations that warrant
   this type of address. [2]

7.   Domain Service considerations

   One aspect of Internet services which will be notably affected by a
   move to either "supernetted" class-C network numbers or subdivided
   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 is
   delegated on octet boundaries only, any address allocation plan which
   uses bitmask-oriented addressing will cause some degree of difficulty
   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 delegated
   only on network boundaries which happen to fall on octet boundaries.
   To aid in the use of blocks of class-C networks, it is recommended
   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 large
   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 four
   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 naming
   authority for each individual class-C network which it assigns,
   rather than having each registered separately. Note that due to the
   way the DNS is designed, it is still possible for the root
   nameservers to maintain the delegation information for individual
   networks for which the provider is unwilling or unable to do so. This
   should greatly reduce the load on the domain servers for the "top"
   levels of the IN-ADDR.ARPA domain.  The example above illustrates
   only the records for a single nameserver.  In the normal case, there
   are usually several nameservers for each domain, thus the size of the
   examples will double or triple in the common cases.

   7.2  Procedural changes for class-A subnetting

   Should it be the case the class-A network numbers are subdivided into
   blocks allocated to transit network providers, it will be similarly
   necessary to relax the restriction on how IN-ADDR.ARPA naming works
   for them. As an example, take a provider is allocated the 19-bit
   portion of address space which matches 10.8.0.0 with mask
   255.248.0.0. This represents all addresses which begin with the
   prefixes 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, an 10.15 and
   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 has
   been allocated the 14-bit piece of address space which matches
   10.10.64.0 with mask 255.255.192.0. This represents all addresses in
   the range 10.10.64.0 through 10.10.127.255 and will require that the
   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 records
   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 solution

   This solution does not change the Internet routing and addressing
   architectures.  Hence, transitioning to a more long term solution is
   not affected by the deployment of this plan.

9.  Conclusions

   We are all aware of the growth in routing complexity, and the rapid
   increase in allocation of network numbers.  Given the rate at which
   this growth is being observed, we expect to run out in a few short
   years.

   If the inter-domain routing protocol supports carrying network routes
   with associated masks, all of the major concerns demonstrated in this
   paper would be eliminated.

   One of the influential factors which permits maximal exploitation of
   the advantages of this plan is the number of people who agree to use
   it.

   If service providers start charging networks for advertising network
   numbers, this would be a very great incentive to share the address
   space, and hence the associated costs of advertising routes to
   service providers.

10.  Recommendations

   The NIC should begin to hand out large blocks of class C addresses to
   network service providers.  Each block must fall on bit boundaries
   and should be large enough to serve the provider for two years.
   Further, the NIC should distribute very large blocks to continental
   and national network service organizations to allow additional levels
   of aggregation to take place at the major backbone networks.  In
   addition, the NIC should modify its procedures for the IN-ADDR.ARPA
   domain to permit delegation along arbitrary octet boundaries.

   Service providers will further allocate power-of-two blocks of class
   C addresses from their address space to their subscribers.

   All organizations, including those which are multi-homed, should
   obtain address space from their provider (or one of their providers,
   in the case of the multi-homed).  These blocks should also fall on
   bit boundaries to permit easy route aggregation.

   To allow effective use of this new addressing plan to reduce
   propagated routing information, appropriate IETF WGs will specify the
   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 as
   quickly as possible.

11  References

   [1] Moy, J, "The OSPF Specification  Version 2", RFC 1247, Proteon,
       Inc., January 1991.

   [2] Rekhter, Y., and T. Li, "An Architecture for IP Address
       Allocation with CIDR", RFC 1518, T.J. Watson Research Center, IBM
       Corp., cisco Systems, September 1993.

12.  Security Considerations

   Security issues are not discussed in this memo.




































Fuller, Li, Yu & Varadhan                                      [Page 23]

RFC 1519                 CIDR Address Strategy            September 1993


13.  Authors' Addresses

   Vince Fuller
   BARRNet
   Pine Hall 115
   Stanford, CA, 94305-4122

   EMail: [e-mail]


   Tony Li
   cisco Systems, Inc.
   1525 O'Brien Drive
   Menlo Park, CA 94025

   EMail: [e-mail]


   Jessica (Jie Yun) Yu
   Merit Network, Inc.
   1071 Beal Ave.
   Ann Arbor, MI 48109

   EMail: [e-mail]


   Kannan Varadhan
   Internet Engineer, OARnet
   1224, Kinnear Road,
   Columbus, OH 43212

   EMail: [e-mail]



















Fuller, Li, Yu & Varadhan                                      [Page 24]