Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function
RFC 3020

Network Working Group                                         Y. Rekhter
Request for Comments: 1918                                 Cisco Systems
Obsoletes: 1627, 1597                                       B. Moskowitz
BCP: 5                                                    Chrysler Corp.
Category: Best Current Practice                            D. Karrenberg
                                                                RIPE NCC
                                                          G. J. de Groot
                                                                RIPE NCC
                                                                 E. Lear
                                                  Silicon Graphics, Inc.
                                                           February 1996

                Address Allocation for Private Internets

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

1. Introduction

   For the purposes of this document, an enterprise is an entity
   autonomously operating a network using TCP/IP and in particular
   determining the addressing plan and address assignments within that
   network.

   This document describes address allocation for private internets. The
   allocation permits full network layer connectivity among all hosts
   inside an enterprise as well as among all public hosts of different
   enterprises. The cost of using private internet address space is the
   potentially costly effort to renumber hosts and networks between
   public and private.

2. Motivation

   With the proliferation of TCP/IP technology worldwide, including
   outside the Internet itself, an increasing number of non-connected
   enterprises use this technology and its addressing capabilities for
   sole intra-enterprise communications, without any intention to ever
   directly connect to other enterprises or the Internet itself.

   The Internet has grown beyond anyone's expectations. Sustained
   exponential growth continues to introduce new challenges.  One
   challenge is a concern within the community that globally unique
   address space will be exhausted. A separate and far more pressing
   concern is that the amount of routing overhead will grow beyond the

Rekhter, et al           Best Current Practice                  [Page 1]
RFC 1918        Address Allocation for Private Internets   February 1996

   capabilities of Internet Service Providers. Efforts are in progress
   within the community to find long term solutions to both of these
   problems. Meanwhile it is necessary to revisit address allocation
   procedures, and their impact on the Internet routing system.

   To contain growth of routing overhead, an Internet Provider obtains a
   block of address space from an address registry, and then assigns to
   its customers addresses from within that block based on each customer
   requirement. The result of this process is that routes to many
   customers will be aggregated together, and will appear to other
   providers as a single route [RFC1518], [RFC1519].  In order for route
   aggregation to be effective, Internet providers encourage customers
   joining their network to use the provider's block, and thus renumber
   their computers. Such encouragement may become a requirement in the
   future.

   With the current size of the Internet and its growth rate it is no
   longer realistic to assume that by virtue of acquiring globally
   unique IP addresses out of an Internet registry an organization that
   acquires such addresses would have Internet-wide IP connectivity once
   the organization gets connected to the Internet. To the contrary, it
   is quite likely that when the organization would connect to the
   Internet to achieve Internet-wide IP connectivity the organization
   would need to change IP addresses (renumber) all of its public hosts
   (hosts that require Internet-wide IP connectivity), regardless of
   whether the addresses used by the organization initially were
   globally unique or not.

   It has been typical to assign globally unique addresses to all hosts
   that use TCP/IP. In order to extend the life of the IPv4 address
   space, address registries are requiring more justification than ever
   before, making it harder for organizations to acquire additional
   address space [RFC1466].

   Hosts within enterprises that use IP can be partitioned into three
   categories:

      Category 1: hosts that do not require access to hosts in other
                  enterprises or the Internet at large; hosts within
                  this category may use IP addresses that are
                  unambiguous within an enterprise, but may be
                  ambiguous between enterprises.

      Category 2: hosts that need access to a limited set of outside
                  services (e.g., E-mail, FTP, netnews, remote login)
                  which can be handled by mediating gateways (e.g.,
                  application layer gateways). For many hosts in this
                  category an unrestricted external access (provided

Rekhter, et al           Best Current Practice                  [Page 2]
RFC 1918        Address Allocation for Private Internets   February 1996

                  via IP connectivity) may be unnecessary and even
                  undesirable for privacy/security reasons. Just like
                  hosts within the first category, such hosts may use
                  IP addresses that are unambiguous within an
                  enterprise, but may be ambiguous between
                  enterprises.

      Category 3: hosts that need network layer access outside the
                  enterprise (provided via IP connectivity); hosts in
                  the last category require IP addresses that are
                  globally unambiguous.

   We will refer to the hosts in the first and second categories as
   "private".  We will refer to the hosts in the third category as
   "public".

   Many applications require connectivity only within one enterprise and
   do not need external (outside the enterprise) connectivity for the
   majority of internal hosts. In larger enterprises it is often easy to
   identify a substantial number of hosts using TCP/IP that do not need
   network layer connectivity outside the enterprise.

   Some examples, where external connectivity might not be required,
   are:

         - A large airport which has its arrival/departure displays
           individually addressable via TCP/IP. It is very unlikely
           that these displays need to be directly accessible from
           other networks.

         - Large organizations like banks and retail chains are
           switching to TCP/IP for their internal communication. Large
           numbers of local workstations like cash registers, money
           machines, and equipment at clerical positions rarely need
           to have such connectivity.

         - For security reasons, many enterprises use application
           layer gateways to connect their internal network to the
           Internet.  The internal network usually does not have
           direct access to the Internet, thus only one or more
           gateways are visible from the Internet. In this case, the
           internal network can use non-unique IP network numbers.

         - Interfaces of routers on an internal network usually do not
           need to be directly accessible from outside the enterprise.

Rekhter, et al           Best Current Practice                  [Page 3]
RFC 1918        Address Allocation for Private Internets   February 1996

3. Private Address Space

   The Internet Assigned Numbers Authority (IANA) has reserved the
   following three blocks of the IP address space for private internets:

     10.0.0.0        -   10.255.255.255  (10/8 prefix)
     172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
     192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

   We will refer to the first block as "24-bit block", the second as
   "20-bit block", and to the third as "16-bit" block. Note that (in
   pre-CIDR notation) the first block is nothing but a single class A
   network number, while the second block is a set of 16 contiguous
   class B network numbers, and third block is a set of 256 contiguous
   class C network numbers.

   An enterprise that decides to use IP addresses out of the address
   space defined in this document can do so without any coordination
   with IANA or an Internet registry. The address space can thus be used
   by many enterprises. Addresses within this private address space will
   only be unique within the enterprise, or the set of enterprises which
   choose to cooperate over this space so they may communicate with each
   other in their own private internet.

   As before, any enterprise that needs globally unique address space is
   required to obtain such addresses from an Internet registry. An
   enterprise that requests IP addresses for its external connectivity
   will never be assigned addresses from the blocks defined above.

   In order to use private address space, an enterprise needs to
   determine which hosts do not need to have network layer connectivity
   outside the enterprise in the foreseeable future and thus could be
   classified as private. Such hosts will use the private address space
   defined above.  Private hosts can communicate with all other hosts
   inside the enterprise, both public and private. However, they cannot
   have IP connectivity to any host outside of the enterprise. While not
   having external (outside of the enterprise) IP connectivity private
   hosts can still have access to external services via mediating
   gateways (e.g., application layer gateways).

   All other hosts will be public and will use globally unique address
   space assigned by an Internet Registry. Public hosts can communicate
   with other hosts inside the enterprise both public and private and
   can have IP connectivity to public hosts outside the enterprise.
   Public hosts do not have connectivity to private hosts of other
   enterprises.

quot;
      ::= { mfrMibGroups 2 }

   mfrMibTrapGroup NOTIFICATION-GROUP
      NOTIFICATIONS {
         mfrMibTrapBundleLinkMismatch
         }
      STATUS current
      DESCRIPTION
          "Group of objects describing notifications (traps)."
      ::= { mfrMibGroups 3 }

END

Pate, et al.                Standards Track                    [Page 31]
RFC 3020               MIB for FRF.16 UNI/NNI MFR          December 2000

4.  Acknowledgments

   This document was produced by the Frame Relay Service MIB (frnetmib)
   Working Group in conjunction with the Frame Relay Forum.

5.  References

   [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture
             for Describing SNMP Management Frameworks", RFC 2571, April
             1999.

   [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
             of Management Information for TCP/IP-based Internets", STD
             16, RFC 1155, May 1990.

   [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD
             16, RFC 1212, March 1991.

   [RFC1215] Rose, M., "A Convention for Defining Traps for use with the
             SNMP", RFC 1215, March 1991.

   [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
             Rose, M. and S. Waldbusser, "Structure of Management
             Information Version 2 (SMIv2)", STD 58, RFC 2578, April
             1999.

   [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
             Rose, M. and S. Waldbusser, "Textual Conventions for
             SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
             Rose, M. and S. Waldbusser, "Conformance Statements for
             SMIv2", STD 58, RFC 2580, April 1999.

   [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
             Network Management Protocol", STD 15, RFC 1157, May 1990.

   [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
             "Introduction to Community-based SNMPv2", RFC 1901, January
             1996.

   [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
             "Transport Mappings for Version 2 of the Simple Network
             Management Protocol (SNMPv2)", RFC 1906, January 1996.

   [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
             Processing and Dispatching for the Simple Network
             Management Protocol (SNMP)", RFC 2572, April 1999.

Pate, et al.                Standards Track                    [Page 32]
RFC 3020               MIB for FRF.16 UNI/NNI MFR          December 2000

   [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model
             (USM) for version 3 of the Simple Network Management
             Protocol (SNMPv3)", RFC 2574, April 1999.

   [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
             "Protocol Operations for Version 2 of the Simple Network
             Management Protocol (SNMPv2)", RFC 1905, January 1996.

   [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications",
             RFC 2573, April 1999.

   [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
             Access Control Model (VACM) for the Simple Network
             Management Protocol (SNMP)", RFC 2575, April 1999.

   [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
             "Introduction to Version 3 of the Internet-standard Network
             Management Framework", RFC 2570, April 1999.

   [Q.922]   ITU-T, Recommendation Q.922: "ISDN Data Link Layer
             Specification For Frame Mode Bearer Services"

   [Q.933]   ITU-T, Recommendation Q.933: "Signalling Specification For
             Frame Mode Basic Call Control"

   [FRF.4]   R. Cherukuri (ed), FRF.4: "Frame Relay User-to-Network SVC
             Implementation Agreement" January 5, 1994.

   [FRF.16]  M. Sheehan (ed), FRF.16: "UNI/NNI Multilink Frame Relay
             Interworking Implementation Agreement" August 20, 1999.

   [RFC1604] Rehbehn, K. and D. Fowler, "Definitions of Managed Objects
             for Frame Relay Service", RFC 2954, October 2000.

   [RFC2494] Fowler, D., "Definitions of Managed Objects for the DS0 and
             DS0 Bundle Interface Type", RFC 2494, November 1997.

   [RFC2863] McCloghrie, D. and F. Kastenholz, "The Interfaces Group MIB
             using SMIv2", RFC 2233, June 2000.

   [ATMLANE] T. Newton, ed., "LAN Emulation Client Management
             Specification Version 2.0" AF-LANE-0093.000, ATM Forum,
             October, 1998

   [ATMIMA]  R. Vallee, ed., "Inverse Multiplexing for ATM Specification
             Version 1.1" (Appendix A) AF-PHY-0086.001, ATM Forum,
             March, 1999

Pate, et al.                Standards Track                    [Page 33]
RFC 3020               MIB for FRF.16 UNI/NNI MFR          December 2000

   [RFC2115] Brown, C. and F. Baker, "Management Information Base for
             Frame Relay DTEs Using SMIv2", RFC 2115, September 1997.

6.  Security Considerations

   There are a number of management objects defined in this MIB that
   have a MAX-ACCESS clause of read-write and/or read-create.  Such
   objects may be considered sensitive or vulnerable in some network
   environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.

   No managed objects in this MIB contain sensitive information.

   SNMPv1 by itself is not a secure environment.  Even if the network
   itself is secure (for example by using IPSec), even then, there is no
   control as to who on the secure network is allowed to access and
   GET/SET (read/change/create/delete) the objects in this MIB.

   It is recommended that the implementers consider the security
   features as provided by the SNMPv3 framework.  Specifically, the use
   of the User-based Security Model RFC 2574 [RFC2574] and the View-
   based Access Control Model RFC 2575 [RFC2575] is recommended.

   It is then a customer/user responsibility to ensure that the SNMP
   entity giving access to an instance of this MIB, is properly
   configured to give access to the objects only to those principals
   (users) that have legitimate rights to indeed GET or SET
   (change/create/delete) them.

Pate, et al.                Standards Track                    [Page 34]
RFC 3020               MIB for FRF.16 UNI/NNI MFR          December 2000

7.  Authors' Addresses

   Prayson Pate
   Overture Networks
   P. O. Box 14864
   RTP, NC, USA 27709

   Phone: +1 919 558 2200
   EMail: prayson.pate@overturenetworks.com

   Bob Lynch
   Overture Networks
   P. O. Box 14864
   RTP, NC, USA 27709

   Phone: +1 919 558-2200
   EMail: bob.lynch@overturenetworks.com

   Kenneth Rehbehn
   Megisto Systems, Inc.
   20251 Century Boulevard
   Germantown, MD, USA 20874

   Phone: +1 301 529-4427
   EMail: krehbehn@megisto.com

Pate, et al.                Standards Track                    [Page 35]
RFC 3020               MIB for FRF.16 UNI/NNI MFR          December 2000

8.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Pate, et al.                Standards Track                    [Page 36]