Network Working Group                                           R. Rohit
Request for Comments: 4008                         Mascon Global Limited
Category: Standards Track                                   P. Srisuresh
                                                    Caymas Systems, Inc.
                                                         R. Raghunarayan
                                                                  N. Pai
                                                     Cisco Systems, Inc.
                                                                 C. Wang
                                                           Bank One Corp
                                                              March 2005


  Definitions of Managed Objects for Network Address Translators (NAT)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for devices implementing Network Address Translator (NAT) function.
   This MIB module may be used for configuration as well as monitoring
   of a device capable of NAT function.

Table of Contents

   1.  Introduction .................................................  2
   2.  The Internet-Standard Management Framework ...................  2
   3.  Terminology ..................................................  3
   4.  Overview .....................................................  4
       4.1.  natInterfaceTable.......................................  4
       4.2.  natAddrMapTable.........................................  5
       4.3.  Default Timeouts, Protocol Table, and Other Scalars.....  6
       4.4.  natAddrBindTable and natAddrPortBindTable...............  6
       4.5.  natSessionTable.........................................  6
       4.6.  RFC 3489 NAPT Variations, NAT Session and Bind Tables...  7
       4.7.  Notifications...........................................  7
       4.8.  Relation Among Tables...................................  8
       4.9.  Configuration via the MIB...............................  8
       4.10. Relationship to Interface MIB...........................  9
   5.  Definitions ..................................................  9
   6.  Acknowledgements ............................................. 59
   7.  Security Considerations ...................................... 59
   8.  References ................................................... 60
   Authors' Addresses ............................................... 62
   Full Copyright Statement.......................................... 64

1.  Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for devices implementing NAT function.  This MIB module may be used
   for configuration and monitoring of a device capable of NAT function.
   NAT types and their characteristics are defined in[RFC2663].
   Traditional NAT function, in particular is defined in [RFC3022].
   This MIB does not address the firewall functions and must not be used
   for configuring or monitoring these.  Section 2 provides references
   to the SNMP management framework, which was used as the basis for the
   MIB module definition.  Section 3 describes the terms used throughout
   the document.  Section 4 provides an overview of the key objects,
   their inter-relationship, and how the MIB module may be used to
   configure and monitor a NAT device.  Lastly, section 5 has the
   complete NAT MIB definition.

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

2.  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].

3.  Terminology

   Definitions for a majority of the terms used throughout the document
   may be found in RFC 2663 [RFC2663].  Additional terms that further
   classify NAPT implementations are defined in RFC 3489 [RFC3489].
   Listed below are terms used in this document.

   Address realm - An address realm is a realm of unique network
   addresses that are routable within the realm.  For example, an
   enterprise address realm could be constituted of private IP addresses
   in the ranges specified in RFC 1918 [RFC1918], which are routable
   within the enterprise, but not across the Internet.  A public realm
   is constituted of globally unique network addresses.

   Symmetric NAT - Symmetric NAT, as defined in RFC 3489 [RFC3489], is a
   variation of Network Address Port Translator (NAPT).  Symmetric NAT
   does not use port bind for translation across all sessions
   originating from the same private host.  Instead, it assigns a new
   public port to each new session, irrespective of whether the new
   session used the same private end-point as before.

   Bind or Binding - Several variations of the term 'Bind' (or
   'Binding') are used throughout the document.  Address Bind (or
   Address Binding) is a tuple of (Private IP address, Public IP
   Address) used for translating an IP address end-point in IP packets.
   Port Bind (or, Port Binding, or Address Port Bind, or Address Port
   Binding) is a tuple of (transport protocol, Private IP address,
   Private port, Public IP Address, Public port) used for translating a
   port end-point tuple of (transport protocol, IP address, port).  Bind
   is used to refer to either Address Bind or Port Bind.  Bind Mode
   identifies whether a bind is Address Bind or Port Bind.

   NAT Session - A NAT session is an association between a session as
   seen in the private realm and a session as seen in the public realm,
   by virtue of NAT translation.  If a session in the private realm were
   to be represented as (PrivateSrcAddr, PrivateDstAddr,
   TransportProtocol, PrivateSrcPort, PrivateDstPort) and the same
   session in the public realm were to be represented as (PublicSrcAddr,

   PublicDstAddr, TransportProtocol, PublicSrcPort, PublicDstPort), the
   NAT session will provide the translation glue between the two session
   representations.  NAT sessions in the document are restricted to
   sessions based on TCP and UDP only.  In the future, NAT sessions may
   be extended to be based on other transport protocols such as SCTP,
   UDP-lite and DCCP.

   The terms 'local' and 'private' are used interchangeably throughout
   the document when referring to private networks, IP addresses, and
   ports.  Likewise, the terms 'global' and 'public' are used
   interchangeably when referring to public networks, IP addresses, and
   ports.

4.  Overview

   NAT MIB is configurable on a per-interface basis and depends in
   several parts on the IF-MIB [RFC2863].

   NAT MIB requires that an interface for which NAT is configured be
   connected to either a private or a public realm.  The realm
   association of the interface plays an important role in the
   definition of address maps for the interface.  An address map entry
   identifies the orientation of the session (inbound or outbound to the
   interface) for which the entry may be used for NAT translation.  The
   address map entry also identifies the end-point of the session that
   must be subject to translation.  An SNMP Textual-Convention
   'NatTranslationEntity' is defined to capture this important
   characteristic that combines session orientation and applicable
   session endpoint for translation.

   An address map may consist of static or dynamic entries.  NAT creates
   static binds from a static address map entry.  Each static bind has a
   direct one-to-one relationship with a static address map entry.  NAT
   creates dynamic binds from a dynamic address map entry upon seeing
   the first packet of a new session.

   The following subsections define the key objects used in NAT MIB,
   their inter-relationship, and how to configure a NAT device using the
   MIB module.

4.1.  natInterfaceTable

   natInterfaceTable is defined in the MIB module to configure interface
   specific realm type and the NAT services enabled for the interface.
   natInterfaceTable is indexed by ifIndex and also includes interface
   specific NAT statistics.

   The first step for an operator in configuring a NAT device is
   determining the interface over which NAT service is to be configured.
   When NAT service is operational, translated packets traverse the NAT
   device by ingressing on a private interface and egressing on a public
   interface or vice versa.  An operator may configure the NAT service
   on either the public interface or the private interface in the
   traversal path.

   As the next step, the operator must identify the NAT service(s)
   desired for the interface.  The operator may configure one or more
   NAT services on the same interface.  The MIB module identifies four
   types of NAT services: Basic NAT, NAPT, twice NAT and bidirectional
   NAT.  These are NAT varieties as defined in RFC 2663 [RFC2663].  Note
   that RFC 3489 [RFC3489] further classifies NAPT implementations based
   on the behavior exhibited by the NAPT devices from different vendors.
   However, the MIB module does not explicitly distinguish between the
   NAPT implementations.  NAPT implementations may be distinguished
   between one another by monitoring the BIND and NAT Session objects
   generated by the NAT device as described in section 4.6.

4.2.  natAddrMapTable

   natAddrMapTable is defined in the MIB module to configure address
   maps on a per-interface basis.  natAddrMapTable is indexed by the
   tuple of (ifIndex, natAddrMapIndex).  The same table is also used to
   collect Statistics for the address map entries.  Address maps are key
   to NAT configuration.  An operator may configure one or more address
   map entries per interface.  NAT looks up address map entries in the
   order in which they are defined to determine the translation function
   at the start of each new session traversing the interface.  An
   address map may consist of static or dynamic entries.  A static
   address map entry has a direct one-to-one relationship with binds.
   NAT will dynamically create binds from a dynamic address map entry.

   The operator must be careful in selecting address map entries for an
   interface based on the interface realm-type and the type of NAT
   service desired.  The operator can be amiss in the selection of
   address map entries when not paying attention to the associated
   interface characteristics defined in natInterfaceTable (described in
   section 4.1).  For example, say the operator wishes to configure a
   NAPT map entry on an interface of a NAT device.  If the operator
   chooses to configure the NAPT map entry on a public interface (i.e.,
   interface realm-type is public), the operator should set the
   TranslationEntity of the NAPT address map entry to be
   outboundSrcEndPoint.  On the other hand, if the operator chooses to
   configure the NAPT map entry on a private interface (i.e., interface
   realm-type is private), the operator should set the TranslationEntity
   of the NAPT address map entry to be InboundSrcEndPoint.

4.3.  Default Timeouts, Protocol Table, and Other Scalars

   DefTimeouts is defined in the MIB module to configure idle Bind
   timeout and IP protocol specific idle NAT session timeouts.  The
   timeouts defined are global to the system and are not interface
   specific.

   Protocol specific statistics are maintained in natProtocolTable,
   which is indexed by the protocol type.

   The scalars natAddrBindNumberOfEntries and
   natAddrPortBindNumberOfEntries hold the number of entries that
   currently exist in the Address Bind and the Address Port Bind tables,
   respectively.

   The generation of natPacketDiscard notifications can be configured by
   using the natNotifThrottlingInterval scalar MIB object.

4.4.  natAddrBindTable and natAddrPortBindTable

   Two Bind tables, natAddrBindTable and natAddrPortBindTable, are
   defined to hold the bind entries.  Entries are derived from the
   address map table and are not configurable.  natAddrBindTable
   contains Address Binds, and natAddrPortBindTable contains Address
   Port Binds.  natAddrBindTable is indexed by the tuple of (ifIndex,
   LocalAddrType, LocalAddr).  natAddrPortBindTable is indexed by the
   tuple of (ifIndex, LocalAddrType, LocalAddr, LocalPort, Protocol).
   These tables also maintain bind specific statistics.  A Symmetric NAT
   will have no entries in the Bind tables.

4.5.  natSessionTable

   natSessionTable is defined to hold NAT session entries.  NAT session
   entries are derived from NAT Binds (except in the case of Symmetric
   NAT) and are not configurable.

   The NAT session provides the necessary translation glue between two
   session representations of the same end-to-end session; that is, a
   session as seen in the private realm and in the public realm.
   Session orientation (inbound or outbound) is determined from the
   orientation of the first packet traversing the NAT interface.
   Address map entries and bind entries on the interface determine
   whether a session is subject to NAT translation.  One or both
   endpoints of a session may be subject to translation.

   With the exception of symmetric NAT, all other NAT functions use
   end-point specific bind to perform individual end-point translations.
   Multiple NAT sessions would use the same bind as long as they share

   the same endpoint.  Symmetric NAT does not retain a consistent port
   bind across multiple sessions using the same endpoint.  For this
   reason, the bind identifier for a NAT session in symmetric NAT is set
   to zero.  natSessionTable is indexed by the tuple of (ifIndex,
   natSessionIndex).  Statistics for NAT sessions are also maintained in
   the same table.

4.6.  RFC 3489 NAPT Variations, NAT Session and Bind Tables

   [RFC3489] defines four variations of NAPT - Full Cone, Restricted
   Cone, Port Restricted Cone, and Symmetric NAT.  These can be
   differentiated in the NAT MIB based on different values for the
   objects in the session and the bind tables, as indicated below.

   In a Port Restricted Cone NAT, NAT Session objects will contain a
   non-zero PrivateSrcEPBindId object.  Further, all address and port
   objects within a NAT session will have non-zero values (i.e., no
   wildcard matches).

   An Address Restricted Cone NAT may have been implemented in the same
   way as a Port Restricted Cone NAT, except that the UDP NAT Sessions
   may use ANY match on PrivateDstPort and PublicDstPort objects; i.e.,
   PrivateDstPort and PublicDstPort objects within a NAT session may be
   set to zero.

   A Full Cone NAT may have also been implemented in the same way as a
   Port Restricted Cone NAT, except that the UDP NAT Sessions may use
   ANY match on PrivateDstAddr, PrivateDstPort, PublicDstAddr, and
   PublicDstPort objects.  Within a NAT Session, all four of these
   objects may be set to zero.  Alternately, all address and port
   objects within a NAT Session may have non-zero values, yet the
   TranslationEntity of the PrivateSrcEPBindId for the NAT Sessions may
   be set bi-directionally, i.e., as a bit mask of (outboundSrcEndPoint
   and inboundDstEndPoint) or (inboundSrcEndPoint and
   outboundDstEndPoint), depending on the interface realm type.  Lastly,
   a Symmetric NAT does not maintain Port Bindings.  As such, the NAT
   Session objects will have the PrivateSrcEPBindId set to zero.

4.7.  Notifications

   natPacketDiscard notifies the end user/manager of packets being
   discarded due to lack of address mappings.

4.8.  Relation Among Tables

   The association between the various NAT tables can be represented as
   follows:

                         Interface
                             |
                             |
                             |
                        Address map
                             |
                             |
                             |
        ----------------------------------------------
       |                                              |
       |                                              |
       |                                              |
   Address Bind                                   Port Bind
       |                                              |
       |                                              |
       |                                              |
        ----------------------------------------------
                             |
                             |
                             |
                         NAT Session

   All NAT functions, with the exception of Symmetric NAT, use Bind(s)
   to provide the glue necessary for a NAT Session.
   natSessionPrivateSrcEPBindId and natSessionPrivateDstEPBindId objects
   represent the endpoint Binds used by NAT Sessions.

4.9.  Configuration via the MIB

   Sections 4.1 and 4.2 and part of section 4.3 refer to objects that
   are configurable on a NAT device.  NAT derives Address Bind and
   Address Port Bind entries from the Address Map table.  Hence, an
   Address Bind or an Address Port Bind entry must not exist without an
   associated entry in the Address Map table.

   Further, NAT derives NAT session entries from NAT Binds, except in
   the case of symmetric NAT, which derives translation parameters for a
   NAT session directly from an address map entry.  Hence, with the
   exception of Symmetric NAT, a NAT session entry must not exist in the
   NAT Session table without a corresponding bind.

   A Management station may use the following steps to configure entries
   in the NAT-MIB:

   -  Create an entry in the natInterfaceTable specifying the value of
      ifIndex as the interface index of the interface on which NAT is
      being configured.  Specify appropriate values, as applicable, for
      the other objects (e.g., natInterfaceRealm,
      natInterfaceServiceType) in the table (refer to Section 4.1).

   -  Create one or more address map entries sequentially in reduced
      order of priority in the natAddrMapTable, specifying the value of
      ifIndex to be the same for all entries.  The ifIndex specified
      would be the same as that specified for natInterfaceTable (refer
      to Section 4.2).

   -  Configure the maximum permitted idle time duration for BINDs and
      TCP, UDP, and ICMP protocol sessions by setting the relevant
      scalars in natDefTimeouts object (refer to Section 4.3).

4.10.  Relationship to Interface MIB

   The natInterfaceTable specifies the NAT configuration attributes on
   each interface.  The concept of "interface" is as defined by
   InterfaceIndex/ifIndex of the IETF Interfaces MIB [RFC2863].