tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7659

Proposed STD
Pages: 84
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~nat

Definitions of Managed Objects for Network Address Translators (NATs)

Part 1 of 4, p. 1 to 18
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                      S. Perreault
Request for Comments: 7659                           Jive Communications
Category: Standards Track                                        T. Tsou
ISSN: 2070-1721                                      Huawei Technologies
                                                            S. Sivakumar
                                                           Cisco Systems
                                                               T. Taylor
                                                    PT Taylor Consulting
                                                            October 2015


 Definitions of Managed Objects for Network Address Translators (NATs)

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for devices implementing the Network Address Translator (NAT)
   function.  The new MIB module defined in this document, NATV2-MIB, is
   intended to replace module NAT-MIB (RFC 4008).  NATV2-MIB is not
   backwards compatible with NAT-MIB, for reasons given in the text of
   this document.  A companion document deprecates all objects in NAT-
   MIB.  NATV2-MIB can be used for the monitoring of NAT instances on a
   device capable of NAT function.  Compliance levels are defined for
   three application scenarios: basic NAT, pooled NAT, and
   carrier-grade NAT (CGN).

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7659.

Page 2 
Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  The Internet-Standard Management Framework  . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Content Provided by the NATV2-MIB Module  . . . . . . . .   5
       3.1.1.  Configuration Data  . . . . . . . . . . . . . . . . .   5
       3.1.2.  Notifications . . . . . . . . . . . . . . . . . . . .   6
       3.1.3.  State Information . . . . . . . . . . . . . . . . . .   9
       3.1.4.  Statistics  . . . . . . . . . . . . . . . . . . . . .   9
     3.2.  Outline of MIB Module Organization  . . . . . . . . . . .  12
     3.3.  Detailed MIB Module Walk-Through  . . . . . . . . . . . .  13
       3.3.1.  Textual Conventions . . . . . . . . . . . . . . . . .  13
       3.3.2.  Notifications . . . . . . . . . . . . . . . . . . . .  14
       3.3.3.  The Subscriber Table: natv2SubscriberTable  . . . . .  14
       3.3.4.  The Instance Table: natv2InstanceTable  . . . . . . .  15
       3.3.5.  The Protocol Table: natv2ProtocolTable  . . . . . . .  15
       3.3.6.  The Address Pool Table: natv2PoolTable  . . . . . . .  16
       3.3.7.  The Address Pool Address Range Table:
               natv2PoolRangeTable . . . . . . . . . . . . . . . . .  17
       3.3.8.  The Address Map Table: natv2AddressMapTable . . . . .  17
       3.3.9.  The Port Map Table: natv2PortMapTable . . . . . . . .  17
     3.4.  Conformance: Three Application Scenarios  . . . . . . . .  18
   4.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .  19
   5.  Operational and Management Considerations . . . . . . . . . .  74
     5.1.  Configuration Requirements  . . . . . . . . . . . . . . .  74
     5.2.  Transition from and Coexistence with NAT-MIB (RFC 4008) .  76
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  78
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  81
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  81
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  81
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  82
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  84

Top      ToC       Page 3 
1.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

2.  Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for devices implementing NAT functions.  This MIB module, NATV2-MIB,
   may be used for the monitoring of such devices.  NATV2-MIB supersedes
   NAT-MIB [RFC4008], which did not fit well with existing NAT
   implementations, and hence was not itself much implemented.
   [RFC7658] provides a detailed analysis of the deficiencies of
   NAT-MIB.

   Relative to [RFC4008] and based on the analysis just mentioned, the
   present document introduces the following changes:

   o  removed all writable configuration except that related to control
      of the generation of notifications and the setting of quotas on
      the use of NAT resources;

   o  minimized the read-only exposure of configuration to what is
      needed to provide context for the state and statistical
      information presented by the MIB module;

   o  removed the association between mapping and interfaces, retaining
      only the mapping aspect;

   o  replaced references to NAT types with references to NAT behaviors
      as specified in [RFC4787];

   o  replaced a module-specific enumeration of protocols with the
      standard protocol numbers provided by the IANA Protocol Numbers
      registry.

Top      ToC       Page 4 
   This MIB module adds the following features not present in [RFC4008]:

   o  additional writable protective limits on NAT state data;

   o  additional objects to report state, statistics, and notifications;

   o  support for the carrier-grade NAT (CGN) application, including
      subscriber-awareness, support for an arbitrary number of address
      realms, and support for multiple NAT instances running on a single
      device;

   o  expanded support for address pools;

   o  revised indexing of port map entries to simplify traceback from
      externally observable packet parameters to the corresponding
      internal endpoint.

   These features are described in more detail below.

   The remainder of this document is organized as follows:

   o  Section 3 provides a verbal description of the content and
      organization of the MIB module.

   o  Section 4 provides the MIB module definition.

   o  Section 5 discusses operational and management issues relating to
      the deployment of NATV2-MIB.  One of these issues is NAT
      management when both NAT-MIB [RFC4008] and NATV2-MIB are deployed.

   o  Sections 6 and 7 provide a security discussion and a request to
      IANA for allocation of an object identifier for the module in the
      mib-2 tree, respectively.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   This document uses the following terminology:

   Upper-layer protocol:  The protocol following the outer IP header of
      a packet.  This follows the terminology of [RFC2460], but as that
      document points out, "upper" is not necessarily a correct
      description of the protocol relationships (e.g., where IP is
      encapsulated in IP).  The abbreviated term "protocol" will often
      be used where it is unambiguous.

Top      ToC       Page 5 
   Trigger:  With respect to notifications, the logical recognition of
      the event that the notification is intended to report.

   Report:  The actual production of a notification message.  Reporting
      can happen later than triggering, or may never happen for a given
      notification instance, because of the operation of notification
      rate controls.

   Address realm:  A network domain in which the network addresses are
      uniquely assigned to entities such that datagrams can be routed to
      them.  (Definition taken from [RFC2663], Section 2.1.)  The
      abbreviated term "realm" will often be used.

3.  Overview

   This section provides a prose description of the contents and
   organization of the NATV2-MIB module.

3.1.  Content Provided by the NATV2-MIB Module

   The content provided by the NATV2-MIB module can be classed under
   four headings: configuration data, notifications, state information,
   and statistics.

3.1.1.  Configuration Data

   As mentioned above, the intent in designing the NATV2-MIB module was
   to minimize the amount of configuration data presented to that needed
   to give a context for interpreting the other types of information
   provided.  Detailed descriptions of the configuration data are
   included with the descriptions of the individual tables.  In general,
   that data is limited to what is needed for indexing and cross-
   referencing between tables.  The two exceptions are the objects
   describing NAT instance behavior in the NAT instance table and the
   detailed enumeration of resources allocated to each address pool in
   the pool table and its extension.

   The NATV2-MIB module provides three sets of read-write objects,
   specifically related to other aspects of the module content.  The
   first set controls the rate at which specific notifications are
   generated.  The second set provides thresholds used to trigger the
   notifications.  These objects are listed in Section 3.1.2.

   A third set of read-write objects sets limits on resource consumption
   per NAT instance and per subscriber.  When these limits are reached,
   packets requiring further consumption of the given resource are

Top      ToC       Page 6 
   dropped rather than translated.  Statistics described in
   Section 3.1.4 record the numbers of packets dropped.  Limits are
   provided for:

   o  total number of address map entries over the NAT instance.  Limit
      is set by object natv2InstanceLimitAddressMapEntries in table
      natv2InstanceTable.  Dropped packets are counted in
      natv2InstanceAddressMapEntryLimitDrops in that table.

   o  total number of port map entries over the NAT instance.  Limit is
      set by object natv2InstanceLimitPortMapEntries in table
      natv2InstanceTable.  Dropped packets are counted in
      natv2InstancePortMapEntryLimitDrops in that table.

   o  total number of held fragments (applicable only when the NAT
      instance can receive fragments out of order; see [RFC4787],
      Section 11).  Limit is set by object
      natv2InstanceLimitPendingFragments in table natv2InstanceTable.
      Dropped packets are counted by natv2InstanceFragmentDrops in the
      same table.

   o  total number of active subscribers (i.e., subscribers having at
      least one mapping table entry) over the NAT instance.  Limit is
      set by object natv2InstanceLimitSubscriberActives in table
      natv2InstanceTable.  Dropped packets are counted by
      natv2InstanceSubscriberActiveLimitDrops in the same table.

   o  number of port map entries for an individual subscriber.  Limit is
      set by object natv2SubscriberLimitPortMapEntries in table
      natv2SubscriberTable.  Dropped packets are counted by
      natv2SubscriberPortMapFailureDrops in the same table.  Note that,
      unlike in the instance table, the per-subscriber count is lumped
      in with the count of packets dropped because of failures to
      allocate a port map entry for other reasons to save on storage.

3.1.2.  Notifications

   NATV2-MIB provides five notifications, intended to provide warning of
   the need to provision or reallocate NAT resources.  As indicated in
   the previous section, each notification is associated with two read-
   write objects: a control on the rate at which that notification is
   generated and a threshold value used to trigger the notification in
   the first place.  The default setting within the MIB module
   specification is that all notifications are disabled.  The setting of
   threshold values is discussed in Section 5.

Top      ToC       Page 7 
   The five notifications are as follows:

   o  Two notifications relate to the management of address pools.  One
      indicates that usage equals or exceeds an upper threshold and is
      therefore a warning that the pool may be over-utilized unless more
      addresses are assigned to it.  The other notification indicates
      that usage equals or has fallen below a lower threshold,
      suggesting that some addresses allocated to that pool could be
      reallocated to other pools.  Address pool usage is calculated as
      the percentage of the total number of ports allocated to the
      address pool that are already in use, for the most-mapped protocol
      at the time the notification is generated.  The notifications
      identify that protocol and report the number of port map entries
      for that protocol in the given address pool at the moment the
      notification was triggered.

   o  Two notifications relate to the number of address and port map
      entries, respectively, in total over the whole NAT instance.  In
      both cases, the threshold that triggers the notification is an
      upper threshold.  The notifications return the number of mapping
      entries of the given type, plus a cumulative counter of the number
      of entries created in that mapping table at the moment the
      notification was triggered.  The intent is that the notifications
      provide a warning that the total number of address or port map
      entries is approaching the configured limit.

   o  The final notification is generated on a per-subscriber basis when
      the number of port map entries for that subscriber crosses the
      associated threshold.  The objects returned by this notification
      are similar to those returned for the instance-level mapping
      notifications.  This notification is a warning that the number of
      port map entries for the subscriber is approaching the configured
      limit for that subscriber.

   Here is a detailed specification of the notifications.  A given
   notification can be disabled by setting the threshold to -1
   (default).

   Notification: natv2NotificationPoolUsageLow.  Indicates that address
   pool usage for the most-mapped protocol equals or is less than the
   threshold value.

   Compared value:  natv2PoolNotifiedPortMapEntries as a percentage of
      total available ports in the pool.

   Threshold:  natv2PoolThresholdUsageLow in natv2PoolTable.

Top      ToC       Page 8 
   Objects returned:  natv2PoolNotifiedPortMapEntries and
      natv2PoolNotifiedPortMapProtocol in natv2PoolTable.

   Rate control:  natv2PoolNotificationInterval in natv2PoolTable.

   Notification: natv2NotificationPoolUsageHigh.  Indicates that address
   pool usage for the most-mapped protocol has risen to the threshold
   value or more.

   Compared value:  natv2PoolNotifiedPortMapEntries as a percentage of
      total available ports in the pool.

   Threshold:  natv2PoolThresholdUsageHigh in natv2PoolTable.

   Objects returned:  natv2PoolNotifiedPortMapEntries and
      natv2PoolNotifiedPortMapProtocol in natv2PoolTable.

   Rate control:  natv2PoolNotificationInterval in natv2PoolTable.

   Notification: natv2NotificationInstanceAddressMapEntriesHigh.
   Indicates that the total number of entries in the address map table
   over the whole NAT instance equals or exceeds the threshold value.

   Compared value:  natv2InstanceAddressMapEntries in
      natv2InstanceTable.

   Threshold:  natv2InstanceThresholdAddressMapEntriesHigh in
      natv2InstanceTable.

   Objects returned:  natv2InstanceAddressMapEntries and
      natv2InstanceAddressMapCreations in natv2InstanceTable.

   Rate control:  natv2InstanceNotificationInterval in
      natv2InstanceTable.

   Notification: natv2NotificationInstancePortMapEntriesHigh.  Indicates
   that the total number of entries in the port map table over the whole
   NAT instance equals or exceeds the threshold value.

   Compared value:  natv2InstancePortMapEntries in natv2InstanceTable.

   Threshold:  natv2InstanceThresholdPortMapEntriesHigh in
      natv2InstanceTable.

   Objects returned:  natv2InstancePortMapEntries and
      natv2InstancePortMapCreations in natv2InstanceTable.

Top      ToC       Page 9 
   Rate control:  natv2InstanceNotificationInterval in
      natv2InstanceTable.

   Notification: natv2NotificationSubscriberPortMapEntriesHigh.
   Indicates that the total number of entries in the port map table for
   the given subscriber equals or exceeds the threshold value configured
   for that subscriber.

   Compared value:  natv2SubscriberPortMapEntries in
      natv2SubscriberTable.

   Threshold:  natv2SubscriberThresholdPortMapEntriesHigh in
      natv2SubscriberTable.

   Objects returned:  natv2SubscriberPortMapEntries and
      natv2SubscriberPortMapCreations in natv2SubscriberTable.

   Rate control:  natv2SubscriberNotificationInterval in
      natv2SubscriberTable.

3.1.3.  State Information

   State information provides a snapshot of the content and extent of
   the NAT mapping tables at a given moment of time.  The address and
   port mapping tables are described in detail below.  In addition to
   these tables, two state variables are provided: current number of
   entries in the address mapping table, and current number of entries
   in the port mapping table.  With one exception, these are provided at
   four levels of granularity: per NAT instance, per protocol, per
   address pool, and per subscriber.  Address map entries are not
   tracked per protocol, since address mapping is protocol independent.

3.1.4.  Statistics

   NATV2-MIB provides a number of counters, intended to help with both
   the provisioning of the NAT and the debugging of problems.  As with
   the state data, these counters are provided at the four levels of NAT
   instance, protocol, address pool, and subscriber when they make
   sense.  Each counter is cumulative, beginning from a "last
   discontinuity time" recorded by an object that is usually in the
   table containing the counter.

   The basic set of counters, as reflected in the NAT instance table, is
   as follows:

   Translations:  number of packets processed and translated (in this
      case, in total for the NAT instance).

Top      ToC       Page 10 
   Address map entry creations:  cumulative number of address map
      entries created, including static mappings.

   Port map entry creations:  cumulative number of port map entries
      created, including static mappings.

   Address map limit drops:  cumulative number of packets dropped rather
      than translated because the packet would have triggered the
      creation of a new address mapping, but the configured limit on
      number of address map entries has already been reached.

   Port map limit drops:  cumulative number of packets dropped rather
      than translated because the packet would have triggered the
      creation of a new port mapping, but the configured limit on number
      of port map entries has already been reached.

   Active subscriber limit drops:  cumulative number of packets dropped
      rather than translated because the packet would have triggered the
      creation of a new address and/or port mapping for a subscriber
      with no existing entries in either table, but the configured limit
      on number of active subscribers has already been reached.

   Address mapping failure drops:  cumulative number of packets dropped
      because the packet would have triggered the creation of a new
      address mapping, but no address could be allocated in the external
      realm concerned because all addresses from the selected address
      pool (or the whole realm, if no address pool has been configured
      for that realm) have already been fully allocated.

   Port mapping failure drops:  cumulative number of packets dropped
      because the packet would have triggered the creation of a new port
      mapping, but no port could be allocated for the protocol
      concerned.  The precise conditions under which these packet drops
      occur depend on the pooling behavior [RFC4787] configured or
      implemented in the NAT instance.  See the DESCRIPTION clause for
      the natv2InstancePortMapFailureDrops object for a detailed
      description of the different cases.  These cases were defined with
      care to ensure that address mapping failure could be distinguished
      from port mapping failure.

   Fragment drops:  cumulative number of packets dropped because the
      packet contains a fragment, and the fragment behavior [RFC4787]
      configured or implemented in the NAT instance indicates that the
      packet should be dropped.  The main case is a NAT instance that
      meets REQ-14 of [RFC4787], hence it can receive and process out-
      of-order fragments.  In that case, dropping occurs only when the

Top      ToC       Page 11 
      configured limit on pending fragments provided by NATV2-MIB has
      already been reached.  The other cases are detailed in the
      DESCRIPTION clause of the natv2InstanceFragmentBehavior object.

   Other resource drops:  cumulative number of packets dropped because
      of unavailability of some other resource.  The most likely case
      would be packets where the upper-layer protocol is not one
      supported by the NAT instance.

   Table 1 indicates the granularities at which these statistics are
   reported.

   +-----------------------+------------+----------+------+------------+
   | Statistic             |    NAT     | Protocol | Pool | Subscriber |
   |                       |  Instance  |          |      |            |
   +-----------------------+------------+----------+------+------------+
   | Translations          |    Yes     |   Yes    |  No  |    Yes     |
   |                       |            |          |      |            |
   | Address map entry     |    Yes     |    No    | Yes  |    Yes     |
   | creations             |            |          |      |            |
   |                       |            |          |      |            |
   | Port map entry        |    Yes     |   Yes    | Yes  |    Yes     |
   | creations             |            |          |      |            |
   |                       |            |          |      |            |
   | Address map limit     |    Yes     |    No    |  No  |     No     |
   | drops                 |            |          |      |            |
   |                       |            |          |      |            |
   | Port map limit drops  |    Yes     |    No    |  No  |    Yes     |
   |                       |            |          |      |            |
   | Active subscriber     |    Yes     |    No    |  No  |     No     |
   | limit drops           |            |          |      |            |
   |                       |            |          |      |            |
   | Address mapping       |    Yes     |    No    | Yes  |    Yes     |
   | failure drops         |            |          |      |            |
   |                       |            |          |      |            |
   | Port mapping failure  |    Yes     |   Yes    | Yes  |    Yes     |
   | drops                 |            |          |      |            |
   |                       |            |          |      |            |
   | Fragment drops        |    Yes     |    No    |  No  |     No     |
   |                       |            |          |      |            |
   | Other resource drops  |    Yes     |    No    |  No  |     No     |
   +-----------------------+------------+----------+------+------------+

           Table 1: Statistics Provided By Level of Granularity

Top      ToC       Page 12 
3.2.  Outline of MIB Module Organization

   Figure 1 shows how object identifiers are organized in the NATV2-MIB
   module.  Under the general natv2MIB object identifier in the mib-2
   tree, the objects are classed into four groups:

   natv2MIBNotifications(0):  identifies the five notifications
      described in Section 3.1.2.

   natv2MIBDeviceObjects(1):  identifies objects relating to the whole
      device, specifically, the subscriber table.

   natv2MIBInstanceObjects(2):  identifies objects relating to
      individual NAT instances.  These include the NAT instance table,
      the protocol table, the address pool table and its address range
      expansion, the address map table, and the port map table.

   natv2MIBConformance(3):  identifies the group and compliance clauses,
      specified for the three application scenarios described in
      Section 3.4.

Top      ToC       Page 13 
                              natv2MIB
                                  |
              +-------------+-------------+-------------+
              |             |             |             |
                            |             |             |
              0             |             |             |
    natv2MIBNotifications   |             |             |
       |                                  |             |
       |                    1             |             |
       |          natv2MIBDeviceObjects   |             |
      Five            |                                 |
   notifications      |                   2             |
                      |         natv2MIBInstanceObjects |
                      |             |
                  Subscriber        |                   3
                  table             |         natv2MIBConformance
                                    |                   |
                                    |                   |
                                    Six per-NAT-        |
                                instance tables         |
                                                        |
                          +----------------------+-------
                          |                      |
                          |                      |

                          1                      2
                 natv2MIBCompliances       natv2MIBGroups
                          |                      |
                          |                      |
                        Basic                  Basic
                        pooled                 pooled
                   carrier-grade NAT     carrier-grade NAT

        Figure 1: Organization of Object Identifiers for NATV2-MIB

3.3.  Detailed MIB Module Walk-Through

   This section reviews the contents of the NATV2-MIB module.  The table
   descriptions include references to subsections of Section 3.1 where
   desirable to avoid repetition of that information.

3.3.1.  Textual Conventions

   The module defines four key textual conventions: ProtocolNumber,
   Natv2SubscriberIndex, Natv2InstanceIndex, and Natv2PoolIndex.
   ProtocolNumber is based on the IANA registry of protocol numbers and
   hence is potentially reusable by other MIB modules.

Top      ToC       Page 14 
   Objects of type Natv2SubscriberIndex identify individual subscribers
   served by the NAT device.  The values of these identifiers are
   administered and, in intent, are permanently associated with their
   respective subscribers.  Reuse of a value after a subscriber has been
   deleted is discouraged.  The scope of the subscriber index was
   defined to be at the device rather than the NAT instance level to
   make it easier to shift subscribers between instances (e.g., for load
   balancing).

   Objects of type Natv2InstanceIndex identify specific NAT instances on
   the device.  Again, these are administered values intended to be
   permanently associated with the NAT instances to which they have been
   assigned.

   Objects of type Natv2PoolIndex identify individual address pools in a
   given NAT instance.  As with the subscriber and instance index
   objects, the pool identifiers are administered and intended to be
   permanently associated with their respective pools.

3.3.2.  Notifications

   Notifications were described in Section 3.1.2.

3.3.3.  The Subscriber Table: natv2SubscriberTable

   Table natv2SubscriberTable is indexed by the subscriber index.  One
   conceptual row contains information relating to a specific
   subscriber: the subscriber's internal address or prefix for
   correlation with other management information; state and statistical
   information as described in Sections 3.1.3 and 3.1.4; the per-
   subscriber control objects described in Section 3.1.1; and
   natv2SubscriberDiscontinuityTime, which provides a timestamp of the
   latest time following, which the statistics have accumulated without
   discontinuity.

   Turning back to the address information for a moment: this
   information includes the identity of the address realm in which the
   address is routable.  That enables support of an arbitrary number of
   address realms on the same NAT instance.  Address realm identifiers
   are administered values in the form of a limited-length
   SnmpAdminString.  In the absence of configuration to the contrary,
   the default realm for all internal addresses as recorded in mapping
   entries is "internal".

      The term "address realm" is defined in [RFC2663], Section 2.1 and
      reused in subsequent NAT-related documents.

Top      ToC       Page 15 
   In the special case of Dual-Stack Lite (DS-Lite) [RFC6333], for
   unique matching of the subscriber data to other information in the
   MIB module, it is necessary that the address information should
   relate to the outer IPv6 header of packets going to or from the host,
   with the address realm being the one in which that IPv6 address is
   routable.  The presentation of address information for other types of
   tunneled access to the NAT is out of scope.

3.3.4.  The Instance Table: natv2InstanceTable

   Table natv2InstanceTable is indexed by an object of type
   Natv2InstanceIndex.  A conceptual row of this table provides
   information relating to a particular NAT instance configured on the
   device.

   Configuration information provided by this table includes an instance
   name of type DisplayString that may have been configured for this
   instance and a set of objects indicating, respectively, the port
   mapping, filtering, pooling, and fragment behaviors configured or
   implemented in the instance.  These behaviors are all defined in
   [RFC4787].  Their values affect the interpretation of some of the
   statistics provided in the instance table.

   Read-write objects listed in Section 3.1.2 set the notification rate
   for instance-level notifications and set the thresholds that trigger
   them.  Additional read-write objects described in Section 3.1.1 set
   limits on the number of address and port mapping entries, number of
   pending fragments, and number of active subscribers for the instance.

   The state and statistical information provided by this table consists
   of the per-instance items described in Sections 3.1.3 and 3.1.4,
   respectively. natv2InstanceDiscontinuityTime is a timestamp giving
   the time beyond which all of the statistical counters in
   natv2InstanceTable are guaranteed to have accumulated continuously.

3.3.5.  The Protocol Table: natv2ProtocolTable

   The protocol table is indexed by the NAT instance number and an
   object of type ProtocolNumber as described in Section 3.3.1 (i.e., an
   IANA-registered protocol number).  The set of protocols supported by
   the NAT instance is implementation dependent, but they MUST include
   ICMP(1), TCP(6), UDP(17), and ICMPv6(58).  Depending on the
   application, it SHOULD include IPv4 encapsulation(4), IPv6
   encapsulation(41), IPsec AH(51), and SCTP(132).  Support of PIM(103)
   is highly desirable.

Top      ToC       Page 16 
   This table includes no configuration information.  The state and
   statistical information provided by this table consists of the per-
   protocol items described in Sections 3.1.3 and 3.1.4, respectively.
   natv2InstanceDiscontinuityTime in natv2InstanceTable is reused as the
   timestamp giving the time beyond which all of the statistical
   counters in natv2ProtocolTable are guaranteed to have accumulated
   continuously.  The reasoning is that any event affecting the
   continuity of per-protocol statistics will affect the continuity of
   NAT instance statistics, and vice versa.

3.3.6.  The Address Pool Table: natv2PoolTable

   The address pool table is indexed by the NAT instance identifier for
   the instance on which it is provisioned, plus a pool index of type
   Natv2PoolIndex.  Configuration information provided includes the
   address realm for which the pool provides addresses, the type of
   address (IPv4 or IPv6) supported by the realm, plus the port range it
   makes available for allocation.  The same set of port numbers (or, in
   the ICMP case, identifier values) is made available for every
   protocol supported by the NAT instance.  The port range is specified
   in terms of minimum and maximum port number.

   The state and statistical information provided by this table consists
   of the per-pool items described in Sections 3.1.3 and 3.1.4
   respectively, plus two additional state objects described below.
   natv2PoolTable provides the pool-specific object
   natv2PoolDiscontinuityTime to indicate the time since the statistical
   counters have accumulated continuously.

   Read-write objects to set high and low thresholds for pool usage
   notifications and for governing the notification rate were identified
   in Section 3.1.2.

      Implementation note: the thresholds are defined in terms of
      percentage of available port utilization.  The number of available
      ports in a pool is equal to (max port - min port + 1) (from the
      natv2PoolTable configuration information) multiplied by the number
      of addresses provisioned in the pool (sum of number of addresses
      provided by each natv2PoolRangeTable conceptual row relating to
      that pool).  At configuration time, the thresholds can be
      recalculated in terms of total number of port map entries
      corresponding to the configured percentage, so that runtime
      comparisons to the current number of port map entries require no
      further arithmetic operations.

   natv2PoolTable also provides two state objects that are returned with
   the notifications.  natv2PoolNotifiedPortMapProtocol identifies the
   most-mapped protocol at the time the notification was triggered.

Top      ToC       Page 17 
   natv2PoolNotifiedPortMapEntries provides the total number of port map
   entries for that protocol using addresses owned by this pool at that
   same time.

3.3.7.  The Address Pool Address Range Table: natv2PoolRangeTable

   natv2PoolRangeTable provides configuration information only.  It is
   an expansion of natv2PoolTable giving the address ranges with which a
   given address pool has been configured.  As such, it is indexed by
   the combination of NAT instance index, address pool index, and a
   conceptual row index, where each conceptual row conveys a different
   address range.  The address range is specified in terms of lowest
   address, highest address rather than the usual prefix notation to
   provide maximum flexibility.

3.3.8.  The Address Map Table: natv2AddressMapTable

   The address map table provides a table of mappings from internal to
   external address at a given moment.  It is indexed by the combination
   of NAT instance index, internal realm, internal address type (IPv4 or
   IPv6) in that realm, the internal address of the local host for which
   the map entry was created, and a conceptual row index to traverse all
   of the entries relating to the same internal address.

   In the special case of DS-Lite [RFC6333], the internal address and
   realm used in the index are those of the IPv6 outer header.  The IPv4
   source address for the inner header, for which [RFC6333] has reserved
   addresses in the 192.0.0.0/29 range, is captured in two additional
   objects in the corresponding conceptual row:
   natv2AddressMapInternalMappedAddressType and
   natv2AddressMapInternalMappedAddress.  In cases other than DS-Lite
   access, these objects have no meaning.  (Other tunneled access is out
   of scope.)

   The additional information provided by natv2AddressMapTable consists
   of the external realm, address type in that realm, and mapped
   external address.  Depending on implementation support, the table
   also provides the index of the address pool from which the external
   address was drawn and the index of the subscriber to which the map
   entry belongs.

3.3.9.  The Port Map Table: natv2PortMapTable

   The port map table provides a table of mappings by protocol from
   external port, address, and realm to internal port, address, and
   realm.  As such, it is indexed by the combination of NAT instance
   index, protocol number, external realm identifier, address type in
   that realm, external address, and external port.  The mapping from

Top      ToC       Page 18 
   external realm, address, and port to internal realm, address, and
   port is unique, so no conceptual row index is needed.  The indexing
   is designed to make it easy to trace individual sessions back to the
   host, based on the contents of packets observed in the external
   realm.

   Beyond the indexing, the information provided by the port map table
   consists of the internal realm, address type, address, and port
   number, and, depending on implementation support, the index of the
   subscriber to which the map entry belongs.

   As with the address map table, special provision is made for the case
   of DS-Lite [RFC6333].  The realm and outgoing source address are
   those for the outer header, and the address type is IPv6.  Additional
   objects natv2PortMapInternalMappedAddressType and
   natv2PortMapInternalMappedAddress capture the outgoing source address
   in the inner header, which will be in the well-known 192.0.0.0/29
   range.

3.4.  Conformance: Three Application Scenarios

   The conformance statements in NATV2-MIB provide for three application
   scenarios: basic NAT, NAT supporting address pools, and CGN.

   A basic NAT MAY limit the number of NAT instances it supports to one,
   but it MUST support indexing by NAT instance.  Similarly, a basic NAT
   MAY limit the number of realms it supports to two.  By definition, a
   basic NAT is not required to support the subscriber table, the
   address pool table, or the address pool address range table.  Some
   individual objects in other tables are also not relevant to basic
   NAT.

   A NAT supporting address pools adds the address pool table and the
   address pool address range table to what it implements.  Some
   individual objects in other tables also need to be implemented.  A
   NAT supporting address pools MUST support more than two realms.

   Finally, a CGN MUST support the full contents of the MIB module.
   That includes the subscriber table, but it also includes the special
   provision for DS-Lite access in the address and port map tables.


Next RFC Part