-- global IPv4 and/or IPv6 addresses, depending
-- on its support for IPv4 and IPv6."
-- OBJECT natAddrPortBindLocalAddr
-- SYNTAX InetAddress (SIZE(4|16))
-- DESCRIPTION
-- "An implementation is required to support
-- global IPv4 and/or IPv6 addresses, depending
-- on its support for IPv4 and IPv6."
MODULE IF-MIB -- The interfaces MIB, RFC2863
MANDATORY-GROUPS {
ifCounterDiscontinuityGroup
}
MODULE -- this module
MANDATORY-GROUPS { natConfigGroup, natTranslationGroup,
natStatsInterfaceGroup }
GROUP natStatsProtocolGroup
DESCRIPTION
"This group is optional."
GROUP natStatsAddrMapGroup
DESCRIPTION
"This group is optional."
GROUP natMIBNotificationGroup
DESCRIPTION
"This group is optional."
OBJECT natInterfaceRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and active is the only
status that needs to be supported."
OBJECT natAddrMapLocalAddrType
SYNTAX InetAddressType { ipv4(1), ipv6(2) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. An implementation is
required to support global IPv4 and/or IPv6 addresses,
depending on its support for IPv4 and IPv6."
OBJECT natAddrMapLocalAddrFrom
SYNTAX InetAddress (SIZE(4|16))
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. An implementation is
required to support global IPv4 and/or IPv6 addresses,
depending on its support for IPv4 and IPv6."
OBJECT natAddrMapLocalAddrTo
SYNTAX InetAddress (SIZE(4|16))
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. An implementation is
required to support global IPv4 and/or IPv6 addresses,
depending on its support for IPv4 and IPv6."
OBJECT natAddrMapGlobalAddrType
SYNTAX InetAddressType { ipv4(1), ipv6(2) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. An implementation is
required to support global IPv4 and/or IPv6 addresses,
depending on its support for IPv4 and IPv6."
OBJECT natAddrMapGlobalAddrFrom
SYNTAX InetAddress (SIZE(4|16))
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. An implementation is
required to support global IPv4 and/or IPv6 addresses,
depending on its support for IPv4 and IPv6."
OBJECT natAddrMapGlobalAddrTo
SYNTAX InetAddress (SIZE(4|16))
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. An implementation is
required to support global IPv4 and/or IPv6 addresses,
depending on its support for IPv4 and IPv6."
OBJECT natAddrMapRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and active is the only
status that needs to be supported."
OBJECT natAddrBindGlobalAddrType
SYNTAX InetAddressType { ipv4(1), ipv6(2) }
DESCRIPTION
"An implementation is required to support global IPv4
and/or IPv6 addresses, depending on its support for
IPv4 and IPv6."
OBJECT natAddrBindGlobalAddr
SYNTAX InetAddress (SIZE(4|16))
DESCRIPTION
"An implementation is required to support global IPv4
and/or IPv6 addresses, depending on its support for
IPv4 and IPv6."
OBJECT natAddrPortBindGlobalAddrType
SYNTAX InetAddressType { ipv4(1), ipv6(2) }
DESCRIPTION
"An implementation is required to support global IPv4
and/or IPv6 addresses, depending on its support for
IPv4 and IPv6."
OBJECT natAddrPortBindGlobalAddr
SYNTAX InetAddress (SIZE(4|16))
DESCRIPTION
"An implementation is required to support global IPv4
and/or IPv6 addresses, depending on its support for
IPv4 and IPv6."
OBJECT natSessionPrivateAddrType
SYNTAX InetAddressType { ipv4(1), ipv6(2) }
DESCRIPTION
"An implementation is required to support global IPv4
and/or IPv6 addresses, depending on its support for
IPv4 and IPv6."
OBJECT natSessionPrivateSrcAddr
SYNTAX InetAddress (SIZE(4|16))
DESCRIPTION
"An implementation is required to support global IPv4
and/or IPv6 addresses, depending on its support for
IPv4 and IPv6."
OBJECT natSessionPrivateDstAddr
SYNTAX InetAddress (SIZE(4|16))
DESCRIPTION
"An implementation is required to support global IPv4
and/or IPv6 addresses, depending on its support for
IPv4 and IPv6."
OBJECT natSessionPublicAddrType
SYNTAX InetAddressType { ipv4(1), ipv6(2) }
DESCRIPTION
"An implementation is required to support global IPv4
and/or IPv6 addresses, depending on its support for
IPv4 and IPv6."
OBJECT natSessionPublicSrcAddr
SYNTAX InetAddress (SIZE(4|16))
DESCRIPTION
"An implementation is required to support global IPv4
and/or IPv6 addresses, depending on its support for
IPv4 and IPv6."
OBJECT natSessionPublicDstAddr
SYNTAX InetAddress (SIZE(4|16))
DESCRIPTION
"An implementation is required to support global IPv4
and/or IPv6 addresses, depending on its support for
IPv4 and IPv6."
::= { natMIBCompliances 2 }
END
6. Acknowledgements
The authors of the document would like to thank Randy Turner, Ashwini
S.T., Kevin Luehrs, Sam Sankoorikal, and Juergen Quittek for their
valuable feedback.
The authors would like to especially thank Juergen Schoenwaelder for
his patient and fine-combed review and detailed comments as a MIB
doctor. The NAT MIB is much clearer and flatter as a result of
Juergen’s suggestions.
7. Security Considerations
It is clear that this MIB can potentially be useful for
configuration. Unauthorized access to the write-able objects could
cause a denial of service and/or widespread network disturbance.
Hence, the support for SET operations in a non-secure environment
without proper protection can have a negative effect on network
operations.
At this writing, no security holes have been identified beyond those
that SNMP Security is itself intended to address. These relate
primarily to controlled access to sensitive information and the
ability to configure a device - or which might result from operator
error, which is beyond the scope of any security architecture.
There are a number of managed objects in this MIB that may contain
information that may be sensitive from a business perspective, in
that they may represent NAT bind and session information. The NAT
bind and session objects reveal the identity of private hosts that
are engaged in a session with external end nodes. A curious outsider
could monitor these two objects to assess the number of private hosts
being supported by the NAT device. Further, a disgruntled former
employee of an enterprise could use the NAT bind and session
information to break into specific private hosts by intercepting the
existing sessions or originating new sessions into the host. There
are no objects that are sensitive in their own right, such as
passwords or monetary amounts. It may even be important to control
GET access to these objects and possibly to encrypt the values of
these objects when they are sent over the network via SNMP. Not all
versions of SNMP provide features for such a secure environment.
SNMP versions prior to SNMPv3 did not include adequate security.
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 (see [RFC3410], section
8), including full support for the SNMPv3 cryptographic mechanisms
(for authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module 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.
8. References
8.1. Normative References
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580, April
1999.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC 2663,
August 1999.
[3291bis] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, J.,
"Textual Conventions for Internet Network Addresses", RFC
4001, February 2005.
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
792, September 1981.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC2463] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62, RFC 3413,
December 2002.
8.2. Informative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
Authors’ Addresses
R. Rohit
Mascon Global Limted
#59/2 100 ft Ring Road
Banashankari II Stage
Bangalore 560 070
India
Phone: +91 80 679 6227
EMail: rrohit74@hotmail.com
P. Srisuresh
Caymas Systems, Inc.
1179-A North McDowell Blvd.
Petaluma, CA 94954
Phone: (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 extn. 6354
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
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.