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.
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.
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 [IF-MIB].
5. Definitions
NAT-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
Integer32,
Unsigned32,
Gauge32,
Counter64,
TimeTicks,
mib-2,
NOTIFICATION-TYPE
FROM SNMPv2-SMI
TEXTUAL-CONVENTION,
StorageType,
RowStatus
FROM SNMPv2-TC
MODULE-COMPLIANCE,
NOTIFICATION-GROUP,
OBJECT-GROUP
FROM SNMPv2-CONF
ifIndex,
ifCounterDiscontinuityGroup
FROM IF-MIB
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
InetAddressType,
InetAddress,
InetPortNumber
FROM INET-ADDRESS-MIB;
natMIB MODULE-IDENTITY
LAST-UPDATED "200502040000Z"
ORGANIZATION "IETF Transport Area"
CONTACT-INFO
"
Rohit
Mascon Global Limited
#59/2 100 ft Ring Road
Banashankari II Stage
Bangalore 560 070
India
Phone: +91 80 2679 6227
Email: rrohit74@hotmail.com
P. Srisuresh
Caymas Systems, Inc.
1179-A North McDowell Blvd.
Petaluma, CA 94954
Tel: (707) 283-5063
Email: srisuresh@yahoo.com
Rajiv Raghunarayan
Cisco Systems Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone: +1 408 853 9612
Email: raraghun@cisco.com
Nalinaksh Pai
Cisco Systems, Inc.
Prestige Waterford
No. 9, Brunton Road
Bangalore - 560 025
India
Phone: +91 80 532 1300
Email: npai@cisco.com
Cliff Wang
Information Security
Bank One Corp
1111 Polaris Pkwy
Columbus, OH 43240
Phone: +1 614 213 6117
Email: cliffwang2000@yahoo.com
"
DESCRIPTION
"This MIB module defines the generic managed objects
for NAT.
Copyright (C) The Internet Society (2005). This version
of this MIB module is part of RFC 4008; see the RFC
itself for full legal notices."
REVISION "200502040000Z" -- 4th February 2005
DESCRIPTION
"Initial version, published as RFC 4008."
::= { mib-2 123 }
natMIBObjects OBJECT IDENTIFIER ::= { natMIB 1 }
NatProtocolType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION