As per Relevance of the word translation, we have this rfc below:
Network Working Group D.
Request for Comments: 2962 Lucent
Category: Informational J.
TU
B.
ISPSoft Inc
October 2000
An SNMP Application Level Gateway for Payload Address
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
IESG
This document describes an SNMP application layer gateway (ALG),
which may be useful in certain environments. The document does
list the issues and problems that can arise when used as a
SNMP ALG. Specifically, when using SNMPv3's authentication
privacy mechanisms this approach may be very problematic
jeopardize the SNMP security. The reader is urged to
consider these issues before deciding to deploy this type of
ALG
This document describes the ALG (Application Level Gateway) for
SNMP (Simple Network Management Protocol) by which IP (
Protocol) addresses in the payload of SNMP packets are
mapped from one group to another. The SNMP ALG is a specific case
an Application Level Gateway as described in [15].
An SNMP ALG allows network management stations to manage
networks that use conflicting IP addresses. This can be important
environments where there is a need to use SNMP with NAT (
Address Translator) in order to manage several
overlapping addressing realms
Raz, et al. Informational [Page 1]
RFC 2962 SNMP Payload Address Translation October 2000
This document includes a detailed description of the requirements
limitations for an implementation of an SNMP Application
Gateway. It also discusses other approaches to exchange SNMP
across conflicting addressing realms
Table of
1. Introduction ..................................................2
2. Terminology and Concepts Used ................................5
3. Problem Scope and Requirements ................................5
3.1 IP Addresses in SNMP Messages ................................6
3.2 Requirements ..................................................7
4. Translating IP Addresses in SNMP Packets ......................7
4.1 Basic SNMP Application Level Gateway ..........................8
4.2 Advanced SNMP Application Level Gateway ......................8
4.3 Packet Size and UDP Checksum ..................................9
5. Limitations and Alternate Solutions .........................10
6. Security Considerations .....................................12
7. Summary and Recommendations .................................13
8. Current Implementations .....................................14
9. Acknowledgments .............................................14
10. References ...................................................14
11. Authors' Addresses ...........................................16
12. Description of the Encoding of SNMP Packets .................17
13. Full Copyright Statement .....................................20
1.
The need for IP address translation arises when a network's
IP addresses cannot be used outside the network. Using basic
address translation allows local hosts on such private
(addressing realms) to transparently access the external
Internet and enables access to selective local hosts from
outside. In particular it is not unlikely to have several
realms that are using the same private IPv4 address space within
same organization
In many of these cases, there is a need to manage the
addressing realm from a manager site outside the domain. However
managing such a network presents unique problems and challenges
Most available management applications use SNMP (Simple
Management Protocol) to retrieve information from the
elements. For example, a router may be queried by the
application about the addresses of its neighboring elements.
information is then sent by the router back to the
Raz, et al. Informational [Page 2]
RFC 2962 SNMP Payload Address Translation October 2000
station as part of the payload of an SNMP packet. In order to
consistency in the view as seen by the management station we need
be able to locate and translate IP address related information in
payload of such packets
The SNMP Application Level Gateway for Payload Address Translation
or SNMP ALG, is a technique in which the payload of SNMP
(PDUs) is scanned and IP address related information is translated
needed. In this context, an SNMP ALG can be an additional
in a NAT implementation, or it can be a separate entity, that
reside in the same gateway or even on a separate node. Note that
our context of management application all devices in the network
assumed to have a fixed IP address. Thus, SNMP ALG should only
combined with NAT that uses static address assignment for all
devices in the network
A typical scenario where SNMP ALG is deployed as part of NAT
presented in figure Figure 1. A manager device is managing a
stub, with translated IP addresses
\ | / .
+---------------+ WAN . +------------------------------+
|Regional Router|-----------------|Stub Router w/NAT and SNMP ALG
+---------------+ . +------------------------------+
| . |
| . |
+----------+ . ---------------
| Manager | Stub border Managed
+----------+
Figure 1: SNMP ALG in a NAT
Raz, et al. Informational [Page 3]
RFC 2962 SNMP Payload Address Translation October 2000
A similar scenario occurs when several subnetworks with private (
possibly conflicting) IP addresses are to be managed by the
management station. This scenario is presented in Figure 2.
+---------------+ +-----------------+
| SNMP ALG |-----|Management device
+---------------+ +-----------------+
T1 | | T
| |
Stub A .............|.... ....|............ Stub
| |
+---------------+ +----------------+
|Bi-directional | |Bi-directional |
|NAT Router w/ | |NAT Router w/ |
|static address | |static address |
|mapping | |mapping |
+---------------+ +---------------+
| |
| LAN LAN |
------------- -------------
192.10.x.y | | 192.10.x.
/____\ /____\
Figure 2: Using external SNMP ALG to manage two private
Since the devices in the managed network are monitored by the
device they must obtain a fixed IP address. Therefore, the NAT
in this case must be a basic NAT with a static one to one mapping
An SNMP ALG is required to scan all the payload of SNMP packets,
detect IP address related data, and to translate this data if needed
This is a much more computationally involved process than the bi
directional NAT, however they both use the same translation tables
In many cases the router may be unable to handle SNMP ALG and
acceptable performance. In these cases it may be better to locate
SNMP ALG outside the router, as described in Figure 2.
Raz, et al. Informational [Page 4]
RFC 2962 SNMP Payload Address Translation October 2000
2. Terminology and Concepts
In general we adapt the terminology defined in [15]. Our
concern are SNMP messages exchanged between SNMP engines.
document only discusses SNMP messages that are send over UDP,
is the preferred transport mapping for SNMP messages [5].
messages send over other transports can be handled in a similar way
Thus, the term SNMP packet is used throughout this document to
to an SNMP message contained in an UDP packet
SNMP messages contain SNMP PDUs (Protocol Data Units). An SNMP
defines the parameters for a specific SNMP protocol operation.
notion of flow is less relevant in this case, and hence we will
on the information contained in a single SNMP packet
There are currently three versions of SNMP. SNMP version 1 (SNMPv1)
protocol is defined in STD 15, RFC 1157 [2]. The SNMP version 2
(SNMPv2c) protocol is defined in RFC 1901 [3], RFC 1905 [4] and
1906 [5]. Finally, the SNMP version 3 (SNMPv3) protocol is
in RFC 1905 [4], 1906 [5], RFC 2572 [10] and RFC 2574 [12]. See
2570 [9] for a more detailed overview over the SNMP standards.
the following, unless otherwise mentioned, we use the term SNMP
statements that are applicable to all three SNMP versions
SNMP uses ASN.1 [13] to define the abstract syntax of the messages
The actual encoding of the messages is done by using the
Encoding Rules (BER) [14], which provide the transfer syntax
We refer to packets that go from a management station to the
elements as "outgoing", and packets that go from the network
to the management station as "incoming".
A basic SNMP ALG is an SNMP ALG implementation in which only
address values encoded in the IpAddress type are translated. A
SNMP ALG therefore does not need to be MIB aware
An advanced SNMP ALG is an SNMP ALG implementation which is
of handling and replacing IP address values encoded in well known
address data types and instance identifiers derived from those
types. This implies that an advanced SNMP ALG is MIB aware
3. Problem Scope and
As mentioned before, in many cases, there is a need to manage a
addressing realm that is using NAT, from a manager site outside
realm. A particular important example is the case of
management service providers who provide network management
from a remote site. Such providers may have many customers,
Raz, et al. Informational [Page 5]
RFC 2962 SNMP Payload Address Translation October 2000
using the same private address space. When all these
realms are to be managed from a single management station
collision occurs. There are two straight forward ways to
the address collision. One
1. reassign IP addresses to the different addressing realms,
2. use static address NAT to hide the address collisions from
network management application
The first solution is problematic as it requires both a
large set of IP addresses, and the reconfiguration of a large
of the network. The problem with the second solution is that
network management applications are currently unaware of NAT,
because of the large investment needed in order to make them
aware are likely to remain so in the near future
Hence, there is a need for a solution that is transparent to
network management application (but not to the user), and that
not require a general reconfiguration of a large portion of
network (i.e. the addressing realm). The SNMP ALG described in
memo is such a solution
3.1 IP Addresses in SNMP
SNMP messages can contain IP addresses in various places and formats
The following four categories have been identified
1. IP version 4 addresses and masks stored in the IpAddress
ASN.1 data type which are not part of an instance identifier.
example is the ipAdEntNetMask object defined in the IP-MIB [6].
2. IP version 4 addresses contained in instance identifiers
from index objects using the IpAddress data type. An example
the ipAdEntAddr index object of the IP-MIB [6].
3. IP addresses (any version) contained in OCTET STRINGS.
include addressMapNetworkAddress object of the RMON2-MIB [7],
IP addresses contained in OCTET STRINGS derived from well-
textual conventions (e.g. TAddress [5] or Ipv6Address [8]
InetAddress [19]).
4. IP addresses (any version) contained in instance
derived from OCTET STRINGS. This may derived from well-
textual conventions (e.g. TAddress [5] or Ipv6Address [8]
InetAddress [19]) like the ipv6AddrAddress index object of
IPV6-MIB [8].
Textual conventions that can contain IP addresses can be
divided in NAT friendly and NAT unfriendly ones. A NAT
textual convention ensures that the encoding on the wire
Raz, et al. Informational [Page 6]
RFC 2962 SNMP Payload Address Translation October 2000
sufficient information that an advanced SNMP ALG which
the textual convention and which has the necessary MIB knowledge
do a proper translation. An example of this type is the Ipv6
textual convention
A NAT unfriendly textual convention requires that an SNMP ALG,
understands the textual convention and which has the necessary
knowledge, has access to additional information in order to do
proper translation. Examples of this type are the TAddress and
InetAddress textual conventions which require that an
varbind is present in an SNMP packet to determine what type of
address a given value represents. Such a varbind may or may not
present depending on the way a management applications
data
3.2
An SNMP ALG should provide transparent IP address translation
management applications. An SNMP ALG must be compatible with
behavior of the SNMP protocol operations as defined by RFC 1157 [2]
and RFC 1905 [4] and must not have negative impact on the
provided by the SNMP protocol. A fully transparent SNMP ALG must
able to translate all categories of IP addresses as described above
when provided with the specified OID's and the encoding details
The SNMP ALG requires bi-directional NAT devices enroute,
support static address mapping for all nodes in the
private realms. When there are multiple private realms supported
a single SNMP ALG, the external addresses assumed by each of the
devices must not collide with each other
4. Translating IP Addresses in SNMP
This section describes several ways to translate IP addresses in
packets
A general SNMP ALG must be capable to translate IP addresses
outgoing and incoming SNMP packets
SNMP messages send over UDP may experience fragmentation at the
layer. In an extreme case, fragmentation may cause an IP address
to be partitioned into two different fragments. In order
translate IP addresses in SNMP messages, the complete SNMP
must be available. As described in [18], fragments of UDP packets
not carry the destination/source port number with them. Hence,
SNMP ALG must reassemble IP packets which contain SNMP messages.
Raz, et al. Informational [Page 7]
RFC 2962 SNMP Payload Address Translation October 2000
good news is, however, that usually SNMP agents are aware of the MTU
and that SNMP packets are usually relatively small. Some
implementations also set the don't fragment (DF) bit in the IP
[1] to avoid fragmentation
4.1 Basic SNMP Application Level
A basic SNMP ALG is an SNMP ALG implementation in which only
address values encoded in the IpAddress base type are translated.
basic SNMP ALG implementation parses an ASN.1/BER encoded SNMP
looking for elements that are encoded using the IpAddress base type
Appendix A contains a more detailed description of the structure
encoding used by SNMP
An IpAddress value can be identified easily by its tag value (0x40).
Once an IpAddress has been detected, the SNMP ALG checks
translation table and decides whether the address should
translated. If the address needs translation, the 4
representing the IPv4 address are replaced with the translated IPv
address and the UDP checksum is adjusted. Section 4.3 describes
efficient algorithm to adjust the UDP checksum without
it
The basic SNMP ALG does not require knowledge of any MIBs since
relies on the ASN.1/BER encoding of SNMP packets. It is
easy to implement. A basic SNMP ALG does not change the
messages size and hence it does not cause translated messages to
lost due to message size constraints
However, a basic SNMP ALG is only able to translate IPv4 addresses
objects that use the IpAddress base type. Furthermore, a basic
ALG is not capable to translate IP addresses in objects that
index components of conceptual tables. This is
problematic on index components that are not accessible. Hence,
basic SNMP ALG is restricted to the first out of the four
ways to represent IP addresses in SNMP messages (see Section 3.1).
4.2 Advanced SNMP Application Level
An advanced SNMP ALG is an SNMP ALG implementation which is
of handling and replacing IP address values encoded in well known
address data types and instance identifiers derived from those
types. Hence, an advanced SNMP ALG may be able to transparently
IP addresses that are in the format 1-4 as described in Section 3.1.
This implies that an advanced SNMP ALG must be MIB aware
Raz, et al. Informational [Page 8]
RFC 2962 SNMP Payload Address Translation October 2000
An advanced SNMP ALG must maintain an OBJECT IDENTIFIER (OID
translation table in order to identify IP addresses that are
encoded in an IpAddress base type. The OID translation table
to maintain information about the OIDs where translation may
needed. Furthermore, the translation table needs to keep
about instance identifiers for conceptual tables that contain
addresses. Such an OID translation table may be populated offline
using a MIB compiler which loads the MIBs used within an
realm and searches for types, textual conventions and table
that may contain IP addresses
The translation function scans the packet for these specific OIDs
checks the translation table and replaces the data if needed.
that since OIDs do not have a fixed size this search is much
computationally consuming, and the lookup operation may be expensive
The ability to translate IP addresses that are part of the index of
conceptual table is a required feature of an advanced SNMP ALG.
addresses embedded in an instance identifier are ASN.1/BER
according to the OID encoding rules. For example, the OID for
10.1.2.3 instance of the ipAdEntIfIndex object of the IP-MIB [6]
encoded as 06 0D 2B 06 01 02 01 04 14 01 02 0A 01 02 03.
the embedded private IPv4 address with 135.180.140.202 leads to
OID 06 11 2B 06 01 02 01 04 14 01 02 81 07 81 34 81 0C 81 4A.
example shows that an advanced SNMP ALG may change the overall
size since IP addresses embedded in an OID can change the size of
ASN.1/BER encoded OID
Another effect of an advanced SNMP ALG is that it changes
lexicographic ordering of rows in conceptual tables as seen by
SNMP manager. This may have severe side-effects for
applications that use lexicographic ordering to retrieve only
of a conceptual table. Many SNMP managers check
ordering to detect loops caused by broken agents. Such a manager
incorrectly report agents behind an advanced SNMP ALG as broken
agents
4.3 Packet Size and UDP
Changing an IpAddress value in an SNMP packet does not change
size of the SNMP packet. A basic SNMP ALG does therefore
change the size of the underlying UDP packet
An advanced SNMP ALG may change the size of an SNMP packet since
different number of bytes may be needed to encode a different
address. This is highly undesirable but unavoidable in the
case. A change of the SNMP packet size requires additional
in the UDP and IP headers. Increasing packet sizes are
Raz, et al. Informational [Page 9]
RFC 2962 SNMP Payload Address Translation October 2000
problematic with SNMPv3. The SNMPv3 message header contains
msgMaxSize field so that agents can generate Response PDUs
GetBulkRequest PDUs that are close to the maximum message size
receiver can handle. An SNMP ALG which increases the size of an
packet may have the effect that the Response PDU can not be
anymore. Thus, an advanced SNMP ALG may cause some SNMPv
interactions to fail
In both cases, the UDP checksum must be adjusted when making an
address translation. We can use the algorithm from [18], but a
modification must be introduced as the modified bytes may start on
odd position. The C code shown in Figure 3 adjusts the checksum to
replacement of one byte in an odd or even position
void checksumbyte(unsigned char *chksum, unsigned char *optr
unsigned char *nptr, int odd
/* assuming: unsigned char is 8 bits, long is 32 bits
we replace one byte by one byte in an odd position
- chksum points to the chksum in the
- optr points to the old byte in the
- nptr points to the new byte in the
- odd is 1 if the byte is in an odd position 0
*/
{ long x, old, new
x=chksum[0]*256+chksum[1];
x=~x & 0xFFFF
if (odd) old=optr[0]*256; else old=optr[0];
x-=old & 0xFFFF
if (x<=0) { x--; x&=0xFFFF; }
if (odd) new=nptr[0]*256; else new=nptr[0];
x+=new & 0xFFFF
if (x & 0x10000) { x++; x&=0xFFFF; }
x=~x & 0xFFFF
chksum[0]=x/256; chksum[1]=x & 0xFF
}
5. Limitations and Alternate
Making SNMP ALGs completely transparent to all
applications is not an achievable task. The basic SNMP ALG
in Section 4.1 only translates IP addresses encoded in the
base type. Such an SNMP ALG achieves only very limited
since IP addresses are frequently used as part of an index into
conceptual table. A management application will therefore see
the translated as well as the original address, which can lead
Raz, et al. Informational [Page 10]
RFC 2962 SNMP Payload Address Translation October 2000
confusion and erroneous behavior of management applications
However, a certain class of management applications like e.g
network discovery tools may work pretty well across NATs with a
SNMP ALG in place
An advanced SNMP ALG described in Section 4.2 achieves
transparency. However, an advanced SNMP ALG can only claim to
transparent for the set of data types (textual conventions
understood by the advanced SNMP ALG implementation and for a
set of MIB modules. The price paid for better transparency
additional complexity, potentially increased SNMP packet sizes
mixed up lexicographic ordering. Especially with SNMPv3, there is
opportunity that communication fails due to increased packet sizes
Management applications that rely on lexicographic ordering will
erroneous behavior
Both, basic and advanced SNMP ALGs, introduce problems when
SNMPv3 security features. The SNMPv3 authentication
protects the whole SNMP message against modifications while
SNMPv3 privacy mechanism protects the payload of SNMPv3
against unauthorized access. Thus, an SNMP ALG must have access
all localized keys in use in order to modify SNMPv3 messages
invalidating them. Furthermore, the SNMP ALG must track any
changes in order to function. More details on the
implications of using SNMP ALGs can be found in Section 6.
Finally, an SNMP ALG only deals with SNMP traffic and does not
the payload of any other protocol. However, management
usually use a set of protocols to manage a network. In
the telnet protocol is often used to configure or
managed devices. Hence, a management system and the human
operator must generally be aware that a network address
is occurring, even in the presence of an SNMP ALG
A possible alternative to SNMP ALGs are SNMP proxies, as defined
RFC 2573 [11]. An SNMP proxy forwarder application forwards
messages to other SNMP engines according to the context,
irrespective of the specific managed object types being accessed
The proxy forwarder also forwards the response to such
forwarded messages back to the SNMP engine from which the
message was received. Such a proxy forwarder can be used in a
environment to address SNMP engines with conflicting IP addresses
(Just replace the box SNMP ALG with a box labeled SNMP PROXY
Figure 2.) The deployment of SNMP proxys has the advantage
different security levels can be used inside and outside of
conflicting addressing realms
Raz, et al. Informational [Page 11]
RFC 2962 SNMP Payload Address Translation October 2000
The proxy solution, which is structurally preferable, requires
the management application is aware of the proxy situation
Furthermore, management applications have to use internal
structures for network elements that allow for conflicting
addresses since conflicting IP addresses are not translated by
SNMP proxy. Deployment of proxies may also involve the need
reconfigure network elements and management stations to direct
traffic (notifications and requests) to the proxy forwarder
6. Security
SNMPv1 and SNMPv2c have very week security services based
community strings. All management information is sent in
without encryption and/or authentication. In such an environment
SNMP messages can be modified by any intermediate node and
application are not able to verify the integrity of SNMP messages
Furthermore, an SNMP ALG does not need to have knowledge of
community strings in order to translate embedded IP addresses. Thus
deployment of SNMP ALGs in an SNMPv1/SNMPv2c environment
no additional security problems
SNMPv3 supports three security levels: no authentication and
encryption (noAuth/noPriv), authentication and no
(auth/noPriv), and authentication and encryption (auth/priv). SNMPv
messages without authentication and encryption (noAuth/noPriv)
send in cleartext. In such a case the usage of SNMP ALGs
no additional security problems
However, the usage of SNMP ALG introduces new problems when SNMPv
authentication and optionally encryption is used. First, SNMPv
messages with authentication and optionally encryption (auth/
and auth/priv) can only be processed by an SNMP ALG which
the corresponding cryptographic algorithms and which has access
the keys in use. Furthermore, as keys may be updated, the SNMP
must have a mechanism that tracks key changes (either by
the key change interactions or by propagating key changes by
mechanisms). Second, the computational complexity of processing
messages may increase dramatically. The message has to be
before the translation takes place. If any translation is done
hash signature used to authenticate the message and to protect
integrity must be recomputed
In general, key exchange protocols are complicated and designing
SNMP ALG which maintains the keys for a set of SNMP engines is
non-trivial task. The User-based Security Model for SNMPv3 [12]
defines a mechanism which takes a password and generates
Raz, et al. Informational [Page 12]
RFC 2962 SNMP Payload Address Translation October 2000
keys for every SNMP engine. The localized keys have the
that a compromised single localized key does not automatically
an attacker access to other SNMP engines, even if the key for
SNMP engines is derived from the same password
An SNMP ALG implementation which maintains lists of (localized)
is a potential target to attack the security of all the systems
use these keys. An SNMP ALG implementation which maintains
in order to generate localized keys is a potential target to
the security of all systems that use the same password. Hence,
SNMP ALG implementation must be properly secured so that people
are not authorized to access keys or passwords can not access them
Finally, SNMP ALGs do not allow a network operator to use
security levels on both sides of the NAT. Using a secure
version outside of a private addressing realm while the
addressing realm runs an unsecured version of SNMP may be
desirable in many scenarios, e.g. management outsourcing scenarios
The deployment of SNMPv3 proxies instead of SNMP ALGs should
considered in these cases since SNMP proxies can be configured to
different security levels and parameters on both sides of
proxies
7. Summary and
Several approaches to address SNMP agents across NAT devices
been discussed in this memo
1. Basic SNMP ALGs as described in Section 4.1 provide very
transparency since they only translate IPv4 addresses encoded
the IpAddress base type. They are fast and efficient and may
sufficient to execute simple management applications (e.g
topology discovery applications) in a NAT environment. However
other management applications are likely to fail due to
limited transparency provided by a basic SNMP ALG. Basic
ALGs are problematic in a secure SNMP environment since they
to maintain lists of keys or passwords in order to function
2. Advanced SNMP ALGs as described in Section 4.2 provide
transparency. They can be transparent for the set of data
they understand and for a given set of MIB modules. However,
advanced SNMP ALG is much more complex and less efficiency than
basic SNMP ALG. An advanced SNMP ALG may break the
ordering when IP addresses are used to index conceptual
and it may change the SNMP packet sizes. Especially with SNMPv3,
there is an opportunity that communication fails due to
message sizes. Advanced SNMP ALGs are problematic in a
SNMP environment, since they need to maintain lists of keys
passwords in order to function
Raz, et al. Informational [Page 13]
RFC 2962 SNMP Payload Address Translation October 2000
3. SNMP proxies as described in RFC 2573 [11] allow
applications to access SNMP agents with conflicting IP addresses
No address translation is performed on the SNMP payload by
SNMP proxy forwarder. Hence, management applications must
able to deal with network elements that have conflicting
addresses. This solution requires that management
are aware of the proxy situation. Deployment of proxies may
involve the need to reconfigure network elements and
stations to direct their traffic (notifications and requests)
the proxy forwarder. SNMP proxies have the advantage that
allow to use different security levels inside and outside of
given addressing realm
It is recommended that network operators who need to manage
in a NAT environment make a careful analysis before deploying
solution. In particular, it must be analyzed whether the
applications will work with the transparency and the side-
provided by SNMP ALGs. Furthermore, it should be researched
the management applications are able to deal with conflicting
addresses for network devices. Finally, the additional
introduced to the over all management system by using SNMP ALGs
be compared to the complexity introduced by the
preferable SNMP proxy forwarders
8. Current
A basic SNMP ALG as described in Section 4.1 was implemented
SNMPv1 at Bell-Labs, running on a Solaris Machine. The
described in Figure 2, where SNMP ALG was combined with the
implementation of Lucent's PortMaster3, was deployed successfully
a large network management service organization
9.
We thank Pyda Srisuresh, for the support, encouragement, and
throughout the work on this document. We also thank Brett A.
for his contribution to the work that led to this document
Additional useful comments have been made by members of the
working group
10.
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[2] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A
Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
Raz, et al. Informational [Page 14]
RFC 2962 SNMP Payload Address Translation October 2000
[3] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser
"Introduction to Community-based SNMPv2", RFC 1901,
1996.
[4] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "
Operations for Version 2 of the Simple Network
Protocol (SNMPv2)", RFC 1905, January 1996.
[5] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "
Mappings for Version 2 of the Simple Network Management
(SNMPv2)", RFC 1906, January 1996.
[6] McCloghrie, K., "SNMPv2 Management Information Base for
Internet Protocol using SMIv2", RFC 2011, November 1996.
[7] Waldbusser, S., "Remote Network Monitoring
Information Base Version 2 using SMIv2", RFC 2021, January 1997.
[8] Haskin, D. and S. Onishi, "Management Information Base for
Version 6: Textual Conventions and General Group", RFC 2465,
December 1998.
[9] Case, J., Mundy, R., Partain, D. and B. Stewart, "
to Version 3 of the Internet-standard Network
Framework", RFC 2570, April 1999.
[10] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "
Processing and Dispatching for the Simple Network
Protocol (SNMP)", RFC 2572, April 1999.
[11] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications",
2573, April 1999.
[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM
for version 3 of the Simple Network Management
(SNMPv3)", RFC 2574, April 1999.
[13] ISO, "Information processing systems - Open
Interconnection - Specification of Abstract Syntax Notation
(ASN.1)", International Standard 8824, December 1987.
[14] ISO, "Information processing systems - Open
Interconnection - Specification of Basic Encoding Rules
Abstract Syntax Notation One (ASN.1)", International
8825, December 1987.
[15] Srisuresh, P. and M. Holdrege, "IP Network Address
(NAT) Terminology and Considerations", RFC 2663, August 1999.
Raz, et al. Informational [Page 15]
RFC 2962 SNMP Payload Address Translation October 2000
[16] Miller, M., "Managing Internetworks with SNMP", MT Books, 1997.
[17] Perkins, D. and E. McGinnis, "Understanding SNMP MIBs",
Hall, ISBN 0-13-437708-7, 1997.
[18] Srisuresh, P. and K. Egevang, "Traditional IP Network
Translator (Traditional NAT)", Work in Progress
[19] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder
"Textual Conventions for Internet Network Addresses", RFC 2851,
June 2000.
11. Authors'
Danny
Lucent
101 Crawfords Corner
Holmdel, NJ 07733-3030
Phone: +1 732 949-6712
Fax: +1 732 949-0399
EMail: raz@lucent.
URI: http://www.bell-labs.com
Juergen
TU
Bueltenweg 74/75
38106
Phone: +49 531 391-3266
Fax: +49 531 391-5936
EMail: schoenw@ibr.cs.tu-bs.
URI: http://www.ibr.cs.tu-bs.de
Binay
ISPSoft Inc
106 Apple
Tinton Falls, NJ 07724
Phone: +1 732 936-1763
EMail: sugla@ispsoft.
URI: http://www.ispsoft.com
Raz, et al. Informational [Page 16]
RFC 2962 SNMP Payload Address Translation October 2000
12. Appendix A. Description of the Encoding of SNMP
SNMP packets use the ASN.1/BER encoding. We will not cover the
details of this encoding in this document. These details can
found in the International Standards ISO-8824 [13] and ISO-8825 [14].
A good description of ASN.1/BER can be found in the book "
Internetworks with SNMP", by M. A. Miller [16], or in Appendix A
the book "Understanding SNMP MIBs", by D. Perkins, and E.
[17].
Each variable that is referred to in an SNMP packet is
identified by an OID (Object Identifier), usually written as
sequence of numbers separated by dots (e.g. 1.3.6.1.2.1.1.3.0).
variable also has an associated base type (this is not very
but good enough for this level of description). One possible
type is the IpAddress type. The base type of each variable and
OID are conveyed by the ASN.1/BER encoding. Note that it is
to associate additional type information with a variable by
textual conventions. The additional type semantics provided
textual conventions are not conveyed by the ASN.1/BER encoding
When a value of a variable is needed by a manager it sends a get
request PDU with the OID of that variable, and a NULL value.
managed element then responds by sending a get-response PDU
contains the same OID, the base type of the variable, and the
value. Figure 4 shows an example of real data contained in an SNMPv
GetResponse PDU
The first 20 bytes contain the IPv4 4 header. The next 8
contain the UDP header. The last two bytes of the UDP header
the UDP checksum (D3 65). The next four bytes 30 82 00 3E are
beginning of the SNMP message: 30 is SEQUENCE, and 82 00 3E is
length of the data in the SEQUENCE in bytes (62). The data in
SEQUENCE is the version (02 01 00) and the community string (04 06 70
75 62 6C 69 63). The last element in the SEQUENCE of the SNMPv
message is the SNMP PDU
Raz, et al. Informational [Page 17]
RFC 2962 SNMP Payload Address Translation October 2000
+-----------------------------------------+
| IP Header | 45 00 00 5
| | 47 40 00 00
| | 3F 11 39 00
| | 87 B4 8C
| | 87 B4 8C 16
+-----------------------------------------+
| UDP Header | 00 A1 05 F
| | 00 4A D3 65
+-----------------------------------------+
| SNMP Message | 30 82 00 3
| Version | | 02 01 00 04
| Community | 06 70 75 62
| | | 6C 69 63 A
| PDU Type | | 82 00 2F 02
| Request ID | 04 6C F2 0
| | Error Status | 5C 02 01 00
| Error Index | SEQUENCE | 02 01 00 30
| OF | SEQUENCE | 82 00 1F 30
| | OID | 82 00 1B 06
| | | 13 2B 06 01
| | 02 01 07 05
| | 01 01 81 40
| | 81 34 81 0
| | 81 4A 84 08
| IpAddress | 135 | 180 | 40 04 87 B
| 140 | 202 +-------------------+ 8C
+---------------------+
The SNMP PDU itself is a tagged SEQUENCE: A2 indicates a
PDU and 82 00 2F is the length of the data in the GetResponse PDU
bytes (47). The data in the GetResponse PDU is the request-id (02 04
6C F2 0C 5C), the error-status (02 01 00), and the error-index (02 01
00). Now follow the variables which contain the real payload:
SEQUENCE OF of length 31 (30 82 00 1F) containing a SEQUENCE
length 27 (30 82 00 1B). In it, the first object is an OID of
19 (06 13) with the value 1.3.6.1.2.1.7.5.1.1.192.180.140.202.520.
The last 6 bytes 40 04 87 B4 8C CA represent an IpAddress: 40 is
identification of the base type IpAddress, 04 is the length, and
next four bytes are the IP address value (135.180.140.202).
The example also shows an IP address embedded in an OID. The
prefix resolves to the udpLocalAddress of the UDP-MIB, which
indexed by the udpLocalAddress 192.180.140.202 (81 40 81 34 81 0C 81
Raz, et al. Informational [Page 18]
RFC 2962 SNMP Payload Address Translation October 2000
4A) and the udpLocalPort 520 (84 08). The SNMP packet actually
an internal contradiction caused by a basic SNMP ALG since
udpLocalAddress encoded in the OID (192.180.140.202) is not equal
the value of the udpLocalAddress object instance (135.180.140.202).
Raz, et al. Informational [Page 19]
RFC 2962 SNMP Payload Address Translation October 2000
13. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Raz, et al. Informational [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
