Network Working Group D. Raz
Request for Comments: 2962 Lucent Technologies
Category: Informational J. Schoenwaelder
TU Braunschweig
B. Sugla
ISPSoft Inc.
October 2000
Network Working Group D. Raz
Request for Comments: 2962 Lucent Technologies
Category: Informational J. Schoenwaelder
TU Braunschweig
B. Sugla
ISPSoft Inc.
October 2000
An SNMP Application Level Gateway for Payload Address Translation
用于有效负载地址转换的SNMP应用程序级网关
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
IESG Note
IESG注释
This document describes an SNMP application layer gateway (ALG), which may be useful in certain environments. The document does also list the issues and problems that can arise when used as a generic SNMP ALG. Specifically, when using SNMPv3's authentication and privacy mechanisms this approach may be very problematic and jeopardize the SNMP security. The reader is urged to carefully consider these issues before deciding to deploy this type of SNMP ALG.
本文档介绍SNMP应用层网关（ALG），它在某些环境中可能很有用。本文档还列出了用作通用SNMP ALG时可能出现的问题。具体来说，当使用SNMPv3的身份验证和隐私机制时，这种方法可能会有很大的问题，并危及SNMP安全。在决定部署这种类型的SNMP ALG之前，请读者仔细考虑这些问题。
Abstract
摘要
This document describes the ALG (Application Level Gateway) for the SNMP (Simple Network Management Protocol) by which IP (Internet Protocol) addresses in the payload of SNMP packets are statically mapped from one group to another. The SNMP ALG is a specific case of an Application Level Gateway as described in [15].
本文档描述了SNMP（简单网络管理协议）的ALG（应用程序级网关），通过该协议，SNMP数据包有效负载中的IP（互联网协议）地址从一个组静态映射到另一个组。SNMP ALG是[15]中所述的应用程序级网关的一种特殊情况。
An SNMP ALG allows network management stations to manage multiple networks that use conflicting IP addresses. This can be important in environments where there is a need to use SNMP with NAT (Network Address Translator) in order to manage several potentially overlapping addressing realms.
SNMP ALG允许网络管理站管理使用冲突IP地址的多个网络。在需要将SNMP与NAT（网络地址转换器）结合使用以管理多个可能重叠的寻址领域的环境中，这一点非常重要。
This document includes a detailed description of the requirements and limitations for an implementation of an SNMP Application Level Gateway. It also discusses other approaches to exchange SNMP packets across conflicting addressing realms.
本文档详细描述了SNMP应用程序级网关实现的要求和限制。本文还讨论了跨冲突寻址域交换SNMP数据包的其他方法。
Table of Contents
目录
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. 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
The need for IP address translation arises when a network's internal IP addresses cannot be used outside the network. Using basic network address translation allows local hosts on such private networks (addressing realms) to transparently access the external global Internet and enables access to selective local hosts from the outside. In particular it is not unlikely to have several addressing realms that are using the same private IPv4 address space within the same organization.
当网络的内部IP地址不能在网络外部使用时，就需要进行IP地址转换。使用基本网络地址转换允许此类专用网络（寻址领域）上的本地主机透明地访问外部全球互联网，并允许从外部访问选择性本地主机。特别是，在同一个组织中不太可能有多个寻址域使用相同的专用IPv4地址空间。
In many of these cases, there is a need to manage the local 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 Network Management Protocol) to retrieve information from the network elements. For example, a router may be queried by the management application about the addresses of its neighboring elements. This information is then sent by the router back to the management
在许多情况下，需要从域外的管理器站点管理本地寻址域。然而，管理这样一个网络带来了独特的问题和挑战。大多数可用的管理应用程序使用SNMP（简单网络管理协议）从网络元素检索信息。例如，管理应用程序可以向路由器查询其相邻元素的地址。该信息随后由路由器发送回管理层
station as part of the payload of an SNMP packet. In order to retain consistency in the view as seen by the management station we need to be able to locate and translate IP address related information in the payload of such packets.
站点作为SNMP数据包有效负载的一部分。为了保持管理站所看到的视图的一致性，我们需要能够定位和转换此类数据包有效负载中的IP地址相关信息。
The SNMP Application Level Gateway for Payload Address Translation, or SNMP ALG, is a technique in which the payload of SNMP packets (PDUs) is scanned and IP address related information is translated if needed. In this context, an SNMP ALG can be an additional component in a NAT implementation, or it can be a separate entity, that may reside in the same gateway or even on a separate node. Note that in our context of management application all devices in the network are assumed to have a fixed IP address. Thus, SNMP ALG should only be combined with NAT that uses static address assignment for all the devices in the network.
用于有效负载地址转换的SNMP应用程序级网关或SNMP ALG是一种扫描SNMP数据包（PDU）的有效负载并在需要时转换IP地址相关信息的技术。在此上下文中，SNMP ALG可以是NAT实现中的附加组件，也可以是单独的实体，可以驻留在同一网关中，甚至可以驻留在单独的节点上。请注意，在我们的管理应用程序上下文中，网络中的所有设备都假定具有固定的IP地址。因此，SNMP ALG只应与NAT结合使用，NAT对网络中的所有设备使用静态地址分配。
A typical scenario where SNMP ALG is deployed as part of NAT is presented in figure Figure 1. A manager device is managing a remote stub, with translated IP addresses.
图1显示了一个典型的场景，其中SNMP ALG作为NAT的一部分进行部署。管理器设备正在管理具有已转换IP地址的远程存根。
\ | / .
+---------------+ WAN . +------------------------------+
|Regional Router|-----------------|Stub Router w/NAT and SNMP ALG|
+---------------+ . +------------------------------+
| . |
| . | LAN
+----------+ . ---------------
| Manager | Stub border Managed network
+----------+
\ | / .
+---------------+ WAN . +------------------------------+
|Regional Router|-----------------|Stub Router w/NAT and SNMP ALG|
+---------------+ . +------------------------------+
| . |
| . | LAN
+----------+ . ---------------
| Manager | Stub border Managed network
+----------+
Figure 1: SNMP ALG in a NAT configuration
图1:NAT配置中的SNMP ALG
A similar scenario occurs when several subnetworks with private (and possibly conflicting) IP addresses are to be managed by the same management station. This scenario is presented in Figure 2.
当具有专用（可能冲突）IP地址的多个子网由同一管理站管理时，也会出现类似的情况。此场景如图2所示。
+---------------+ +-----------------+
| SNMP ALG |-----|Management device|
+---------------+ +-----------------+
T1 | | T1
| |
Stub A .............|.... ....|............ Stub B
| |
+---------------+ +----------------+
|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.y
/____\ /____\
+---------------+ +-----------------+
| SNMP ALG |-----|Management device|
+---------------+ +-----------------+
T1 | | T1
| |
Stub A .............|.... ....|............ Stub B
| |
+---------------+ +----------------+
|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.y
/____\ /____\
Figure 2: Using external SNMP ALG to manage two private networks
图2：使用外部SNMP ALG管理两个专用网络
Since the devices in the managed network are monitored by the manager device they must obtain a fixed IP address. Therefore, the NAT used in this case must be a basic NAT with a static one to one mapping.
由于管理网络中的设备由管理器设备监控，因此它们必须获得固定的IP地址。因此，本例中使用的NAT必须是具有静态一对一映射的基本NAT。
An SNMP ALG is required to scan all the payload of SNMP packets, to 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 retain acceptable performance. In these cases it may be better to locate the SNMP ALG outside the router, as described in Figure 2.
SNMP ALG需要扫描SNMP数据包的所有有效负载，检测IP地址相关数据，并在需要时转换这些数据。这是一个比双向NAT更需要计算的过程，但是它们都使用相同的转换表。在许多情况下，路由器可能无法处理SNMP ALG并保持可接受的性能。在这些情况下，最好将SNMP ALG定位在路由器外部，如图2所示。
In general we adapt the terminology defined in [15]. Our main concern are SNMP messages exchanged between SNMP engines. This document only discusses SNMP messages that are send over UDP, which is the preferred transport mapping for SNMP messages [5]. SNMP messages send over other transports can be handled in a similar way. Thus, the term SNMP packet is used throughout this document to refer to an SNMP message contained in an UDP packet.
通常，我们采用[15]中定义的术语。我们主要关注的是SNMP引擎之间交换的SNMP消息。本文档仅讨论通过UDP发送的SNMP消息，UDP是SNMP消息的首选传输映射[5]。通过其他传输发送的SNMP消息可以以类似的方式处理。因此，在本文档中，术语SNMP数据包用于指UDP数据包中包含的SNMP消息。
SNMP messages contain SNMP PDUs (Protocol Data Units). An SNMP PDU defines the parameters for a specific SNMP protocol operation. The notion of flow is less relevant in this case, and hence we will focus on the information contained in a single SNMP packet.
SNMP消息包含SNMP PDU（协议数据单元）。SNMP PDU定义特定SNMP协议操作的参数。在本例中，流的概念不太相关，因此我们将重点关注单个SNMP数据包中包含的信息。
There are currently three versions of SNMP. SNMP version 1 (SNMPv1) protocol is defined in STD 15, RFC 1157 [2]. The SNMP version 2c (SNMPv2c) protocol is defined in RFC 1901 [3], RFC 1905 [4] and RFC 1906 [5]. Finally, the SNMP version 3 (SNMPv3) protocol is defined in RFC 1905 [4], 1906 [5], RFC 2572 [10] and RFC 2574 [12]. See RFC 2570 [9] for a more detailed overview over the SNMP standards. In the following, unless otherwise mentioned, we use the term SNMP in statements that are applicable to all three SNMP versions.
目前有三个版本的SNMP。SNMP版本1（SNMPv1）协议在STD 15 RFC 1157[2]中定义。SNMP版本2c（SNMPv2c）协议在RFC 1901[3]、RFC 1905[4]和RFC 1906[5]中定义。最后，SNMP版本3（SNMPv3）协议在RFC 1905[4]、1906[5]、RFC 2572[10]和RFC 2574[12]中定义。有关SNMP标准的更详细概述，请参见RFC 2570[9]。在下文中，除非另有说明，否则我们在适用于所有三个SNMP版本的语句中使用术语SNMP。
SNMP uses ASN.1 [13] to define the abstract syntax of the messages. The actual encoding of the messages is done by using the Basic Encoding Rules (BER) [14], which provide the transfer syntax.
SNMP使用ASN.1[13]定义消息的抽象语法。消息的实际编码是使用基本编码规则（BER）[14]完成的，它提供了传输语法。
We refer to packets that go from a management station to the network elements as "outgoing", and packets that go from the network elements to the management station as "incoming".
我们将从管理站到网元的数据包称为“传出”，将从网元到管理站的数据包称为“传入”。
A basic SNMP ALG is an SNMP ALG implementation in which only IP address values encoded in the IpAddress type are translated. A basic SNMP ALG therefore does not need to be MIB aware.
基本SNMP ALG是一种SNMP ALG实现，其中仅转换以IpAddress类型编码的IP地址值。因此，基本SNMP ALG不需要具有MIB意识。
An advanced SNMP ALG is an SNMP ALG implementation which is capable of handling and replacing IP address values encoded in well known IP address data types and instance identifiers derived from those data types. This implies that an advanced SNMP ALG is MIB aware.
高级SNMP ALG是一种SNMP ALG实现，它能够处理和替换在众所周知的IP地址数据类型中编码的IP地址值以及从这些数据类型派生的实例标识符。这意味着高级SNMP ALG支持MIB。
As mentioned before, in many cases, there is a need to manage a local addressing realm that is using NAT, from a manager site outside the realm. A particular important example is the case of network management service providers who provide network management services from a remote site. Such providers may have many customers, each
如前所述，在许多情况下，需要从域外的管理器站点管理使用NAT的本地寻址域。一个特别重要的例子是网络管理服务提供商从远程站点提供网络管理服务的情况。这些提供商可能有许多客户，每个客户
using the same private address space. When all these addressing realms are to be managed from a single management station address collision occurs. There are two straight forward ways to overcome the address collision. One can
使用相同的专用地址空间。当所有这些寻址域都要从单个管理站进行管理时，会发生地址冲突。有两种直接的方法可以克服地址冲突。一罐
1. reassign IP addresses to the different addressing realms, or 2. use static address NAT to hide the address collisions from the network management application.
1. 将IP地址重新分配到不同的寻址域，或2。使用静态地址NAT对网络管理应用程序隐藏地址冲突。
The first solution is problematic as it requires both a potentially large set of IP addresses, and the reconfiguration of a large portion of the network. The problem with the second solution is that many network management applications are currently unaware of NAT, and because of the large investment needed in order to make them NAT aware are likely to remain so in the near future.
第一种解决方案是有问题的，因为它既需要一组潜在的大量IP地址，也需要重新配置大部分网络。第二种解决方案的问题是，许多网络管理应用程序目前不知道NAT，并且由于需要大量投资才能使它们知道NAT，因此在不久的将来很可能仍然如此。
Hence, there is a need for a solution that is transparent to the network management application (but not to the user), and that does not require a general reconfiguration of a large portion of the network (i.e. the addressing realm). The SNMP ALG described in this memo is such a solution.
因此，需要一种对网络管理应用程序透明（但对用户透明）且不需要对大部分网络（即寻址域）进行一般重新配置的解决方案。本备忘录中描述的SNMP ALG就是这样一种解决方案。
SNMP messages can contain IP addresses in various places and formats. The following four categories have been identified:
SNMP消息可以包含不同位置和格式的IP地址。已确定以下四类：
1. IP version 4 addresses and masks stored in the IpAddress tagged ASN.1 data type which are not part of an instance identifier. An example is the ipAdEntNetMask object defined in the IP-MIB [6]. 2. IP version 4 addresses contained in instance identifiers derived from index objects using the IpAddress data type. An example is the ipAdEntAddr index object of the IP-MIB [6]. 3. IP addresses (any version) contained in OCTET STRINGS. Examples include addressMapNetworkAddress object of the RMON2-MIB [7], and IP addresses contained in OCTET STRINGS derived from well-known textual conventions (e.g. TAddress [5] or Ipv6Address [8] or InetAddress [19]). 4. IP addresses (any version) contained in instance identifiers derived from OCTET STRINGS. This may derived from well-known textual conventions (e.g. TAddress [5] or Ipv6Address [8] or InetAddress [19]) like the ipv6AddrAddress index object of the IPV6-MIB [8].
1. IP版本4地址和掩码存储在标记为ASN.1数据类型的IpAddress中，这些地址和掩码不属于实例标识符的一部分。例如，IP-MIB[6]中定义的ipAdEntNetMask对象。2.使用IpAddress数据类型从索引对象派生的实例标识符中包含的IP版本4地址。IP-MIB的ipAdEntAddr索引对象就是一个例子[6]。3.包含在八位字节字符串中的IP地址（任何版本）。示例包括RMON2-MIB的addressMapNetworkAddress对象[7]，以及源于众所周知的文本约定的八位字节字符串中包含的IP地址（例如TadAddress[5]或Ipv6Address[8]或InetAddress[19]）。4.从八位字节字符串派生的实例标识符中包含的IP地址（任何版本）。这可能源于众所周知的文本约定（例如TadAddress[5]或Ipv6Address[8]或InetAddress[19]），如IPV6-MIB[8]的IPV6AddAddress索引对象。
Textual conventions that can contain IP addresses can be further divided in NAT friendly and NAT unfriendly ones. A NAT friendly textual convention ensures that the encoding on the wire contains
可以包含IP地址的文本约定可以进一步分为NAT友好型和NAT非友好型。NAT友好的文本约定可确保线路上的编码包含
sufficient information that an advanced SNMP ALG which understands the textual convention and which has the necessary MIB knowledge can do a proper translation. An example of this type is the Ipv6Address textual convention.
充分的信息，使理解文本约定并具备必要MIB知识的高级SNMP ALG能够正确翻译。这种类型的一个示例是Ipv6Address文本约定。
A NAT unfriendly textual convention requires that an SNMP ALG, which understands the textual convention and which has the necessary MIB knowledge, has access to additional information in order to do a proper translation. Examples of this type are the TAddress and the InetAddress textual conventions which require that an additional varbind is present in an SNMP packet to determine what type of IP address a given value represents. Such a varbind may or may not be present depending on the way a management applications retrieves data.
NAT不友好的文本约定要求理解文本约定并具备必要MIB知识的SNMP ALG能够访问附加信息，以便进行正确的翻译。这种类型的示例包括TadAddress和InetAddress文本约定，它们要求SNMP数据包中存在额外的varbind，以确定给定值表示的IP地址类型。根据管理应用程序检索数据的方式，这种varbind可能存在，也可能不存在。
An SNMP ALG should provide transparent IP address translation to management applications. An SNMP ALG must be compatible with the behavior of the SNMP protocol operations as defined by RFC 1157 [2] and RFC 1905 [4] and must not have negative impact on the security provided by the SNMP protocol. A fully transparent SNMP ALG must be able to translate all categories of IP addresses as described above, when provided with the specified OID's and the encoding details.
SNMP ALG应向管理应用程序提供透明的IP地址转换。SNMP ALG必须与RFC 1157[2]和RFC 1905[4]定义的SNMP协议操作行为兼容，并且不得对SNMP协议提供的安全性产生负面影响。当提供指定的OID和编码详细信息时，完全透明的SNMP ALG必须能够转换上述所有类别的IP地址。
The SNMP ALG requires bi-directional NAT devices enroute, that support static address mapping for all nodes in the respective private realms. When there are multiple private realms supported by a single SNMP ALG, the external addresses assumed by each of the NAT devices must not collide with each other.
SNMP ALG要求在路由过程中使用双向NAT设备，这些设备支持各自私有领域中所有节点的静态地址映射。当单个SNMP ALG支持多个私有领域时，每个NAT设备假定的外部地址不得相互冲突。
This section describes several ways to translate IP addresses in SNMP packets.
本节介绍在SNMP数据包中转换IP地址的几种方法。
A general SNMP ALG must be capable to translate IP addresses in outgoing and incoming SNMP packets.
通用SNMP ALG必须能够转换传出和传入SNMP数据包中的IP地址。
SNMP messages send over UDP may experience fragmentation at the IP layer. In an extreme case, fragmentation may cause an IP address type to be partitioned into two different fragments. In order to translate IP addresses in SNMP messages, the complete SNMP message must be available. As described in [18], fragments of UDP packets do not carry the destination/source port number with them. Hence, an SNMP ALG must reassemble IP packets which contain SNMP messages. The
通过UDP发送的SNMP消息可能会在IP层出现碎片。在极端情况下，碎片可能会导致IP地址类型被划分为两个不同的碎片。为了转换SNMP消息中的IP地址，必须提供完整的SNMP消息。如[18]所述，UDP数据包的片段不携带目标/源端口号。因此，SNMP ALG必须重新组装包含SNMP消息的IP数据包。这个
good news is, however, that usually SNMP agents are aware of the MTU, and that SNMP packets are usually relatively small. Some SNMP implementations also set the don't fragment (DF) bit in the IP header [1] to avoid fragmentation.
然而，好消息是，SNMP代理通常知道MTU，并且SNMP数据包通常相对较小。一些SNMP实现还在IP头[1]中设置“不分段”（DF）位以避免分段。
A basic SNMP ALG is an SNMP ALG implementation in which only IP address values encoded in the IpAddress base type are translated. A basic SNMP ALG implementation parses an ASN.1/BER encoded SNMP packet looking for elements that are encoded using the IpAddress base type. Appendix A contains a more detailed description of the structure and encoding used by SNMP.
基本SNMP ALG是一种SNMP ALG实现，其中仅转换IP地址基类型中编码的IP地址值。基本SNMP ALG实现解析ASN.1/BER编码的SNMP数据包，查找使用IpAddress基类型编码的元素。附录A包含SNMP使用的结构和编码的更详细说明。
An IpAddress value can be identified easily by its tag value (0x40). Once an IpAddress has been detected, the SNMP ALG checks the translation table and decides whether the address should be translated. If the address needs translation, the 4 bytes representing the IPv4 address are replaced with the translated IPv4 address and the UDP checksum is adjusted. Section 4.3 describes an efficient algorithm to adjust the UDP checksum without recalculating it.
IpAddress值可以通过其标记值（0x40）轻松识别。一旦检测到IP地址，SNMP ALG将检查转换表并决定是否应转换该地址。如果地址需要转换，则表示IPv4地址的4个字节将替换为转换后的IPv4地址，并调整UDP校验和。第4.3节描述了一种在不重新计算UDP校验和的情况下调整UDP校验和的有效算法。
The basic SNMP ALG does not require knowledge of any MIBs since it relies on the ASN.1/BER encoding of SNMP packets. It is therefore easy to implement. A basic SNMP ALG does not change the overall messages size and hence it does not cause translated messages to be lost due to message size constraints.
基本SNMP ALG不需要了解任何MIB，因为它依赖于SNMP数据包的ASN.1/BER编码。因此，它很容易实现。基本SNMP ALG不会更改消息的总体大小，因此不会由于消息大小限制而导致已翻译的消息丢失。
However, a basic SNMP ALG is only able to translate IPv4 addresses in objects that use the IpAddress base type. Furthermore, a basic SNMP ALG is not capable to translate IP addresses in objects that are index components of conceptual tables. This is especially problematic on index components that are not accessible. Hence, the basic SNMP ALG is restricted to the first out of the four possible ways to represent IP addresses in SNMP messages (see Section 3.1).
但是，基本SNMP ALG只能转换使用IpAddress基类型的对象中的IPv4地址。此外，基本SNMP ALG无法转换作为概念表索引组件的对象中的IP地址。这在不可访问的索引组件上尤其有问题。因此，基本SNMP ALG仅限于在SNMP消息中表示IP地址的四种可能方式中的第一种（请参阅第3.1节）。
An advanced SNMP ALG is an SNMP ALG implementation which is capable of handling and replacing IP address values encoded in well known IP address data types and instance identifiers derived from those data types. Hence, an advanced SNMP ALG may be able to transparently map 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.
高级SNMP ALG是一种SNMP ALG实现，它能够处理和替换在众所周知的IP地址数据类型中编码的IP地址值以及从这些数据类型派生的实例标识符。因此，高级SNMP ALG可能能够透明地映射格式为1-4的IP地址，如第3.1节所述。这意味着高级SNMP ALG必须能够识别MIB。
An advanced SNMP ALG must maintain an OBJECT IDENTIFIER (OID) translation table in order to identify IP addresses that are not encoded in an IpAddress base type. The OID translation table needs to maintain information about the OIDs where translation may be needed. Furthermore, the translation table needs to keep information about instance identifiers for conceptual tables that contain IP addresses. Such an OID translation table may be populated offline by using a MIB compiler which loads the MIBs used within an addressing realm and searches for types, textual conventions and table indexes that may contain IP addresses.
高级SNMP ALG必须维护对象标识符（OID）转换表，以便识别未编码在IP地址基类型中的IP地址。OID翻译表需要维护关于可能需要翻译的OID的信息。此外，转换表需要为包含IP地址的概念表保留有关实例标识符的信息。这样的OID转换表可以通过使用MIB编译器离线填充，该编译器加载寻址域中使用的MIB，并搜索可能包含IP地址的类型、文本约定和表索引。
The translation function scans the packet for these specific OIDs, checks the translation table and replaces the data if needed. Note that since OIDs do not have a fixed size this search is much more computationally consuming, and the lookup operation may be expensive.
翻译功能扫描数据包中的这些特定OID，检查翻译表，并在需要时替换数据。请注意，由于OID没有固定的大小，因此此搜索的计算量要大得多，并且查找操作可能很昂贵。
The ability to translate IP addresses that are part of the index of a conceptual table is a required feature of an advanced SNMP ALG. IP addresses embedded in an instance identifier are ASN.1/BER encoded according to the OID encoding rules. For example, the OID for the 10.1.2.3 instance of the ipAdEntIfIndex object of the IP-MIB [6] is encoded as 06 0D 2B 06 01 02 01 04 14 01 02 0A 01 02 03. Replacing the embedded private IPv4 address with 135.180.140.202 leads to the OID 06 11 2B 06 01 02 01 04 14 01 02 81 07 81 34 81 0C 81 4A. This example shows that an advanced SNMP ALG may change the overall packet size since IP addresses embedded in an OID can change the size of the ASN.1/BER encoded OID.
翻译作为概念表索引一部分的IP地址的能力是高级SNMP ALG所必需的功能。嵌入实例标识符中的IP地址根据OID编码规则进行ASN.1/BER编码。例如，IP-MIB[6]的IPIdentificationIndex对象的10.1.2.3实例的OID编码为06 0D 2B 06 01 01 04 14 01 02 0A 01 02 03。将嵌入式专用IPv4地址替换为135.180.140.202将导致OID 06 11 2B 06 01 02 01 04 14 01 02 81 07 81 34 81 0C 81 4A。此示例显示，高级SNMP ALG可能会更改整个数据包大小，因为OID中嵌入的IP地址可以更改ASN.1/BER编码OID的大小。
Another effect of an advanced SNMP ALG is that it changes the lexicographic ordering of rows in conceptual tables as seen by the SNMP manager. This may have severe side-effects for management applications that use lexicographic ordering to retrieve only parts of a conceptual table. Many SNMP managers check lexicographic ordering to detect loops caused by broken agents. Such a manager will incorrectly report agents behind an advanced SNMP ALG as broken SNMP agents.
高级SNMP ALG的另一个效果是，它改变了SNMP管理器看到的概念表中行的字典顺序。对于使用字典排序仅检索概念表的一部分的管理应用程序，这可能会产生严重的副作用。许多SNMP管理器检查字典顺序，以检测由断开的代理引起的循环。这样的管理器会将高级SNMP ALG后面的代理错误地报告为损坏的SNMP代理。
Changing an IpAddress value in an SNMP packet does not change the size of the SNMP packet. A basic SNMP ALG does therefore never change the size of the underlying UDP packet.
更改SNMP数据包中的IpAddress值不会更改SNMP数据包的大小。因此，基本SNMP ALG不会更改底层UDP数据包的大小。
An advanced SNMP ALG may change the size of an SNMP packet since a different number of bytes may be needed to encode a different IP address. This is highly undesirable but unavoidable in the general case. A change of the SNMP packet size requires additional changes in the UDP and IP headers. Increasing packet sizes are especially
高级SNMP ALG可能会更改SNMP数据包的大小，因为可能需要不同的字节数来编码不同的IP地址。这是非常不可取的，但在一般情况下是不可避免的。更改SNMP数据包大小需要对UDP和IP头进行额外更改。增加数据包大小尤其重要
problematic with SNMPv3. The SNMPv3 message header contains the msgMaxSize field so that agents can generate Response PDUs for GetBulkRequest PDUs that are close to the maximum message size the receiver can handle. An SNMP ALG which increases the size of an SNMP packet may have the effect that the Response PDU can not be processed anymore. Thus, an advanced SNMP ALG may cause some SNMPv3 interactions to fail.
SNMPv3有问题。SNMPv3消息头包含msgMaxSize字段，以便代理可以为GetBulkRequest PDU生成响应PDU，这些PDU接近接收方可以处理的最大消息大小。增加SNMP数据包大小的SNMP ALG可能会导致无法再处理响应PDU。因此，高级SNMP ALG可能会导致某些SNMPv3交互失败。
In both cases, the UDP checksum must be adjusted when making an IP address translation. We can use the algorithm from [18], but a small modification must be introduced as the modified bytes may start on an odd position. The C code shown in Figure 3 adjusts the checksum to a replacement of one byte in an odd or even position.
在这两种情况下，进行IP地址转换时必须调整UDP校验和。我们可以使用[18]中的算法，但必须进行小的修改，因为修改的字节可能从奇数位置开始。图3所示的C代码将校验和调整为奇数或偶数位置的一个字节的替换。
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 packet
- optr points to the old byte in the packet
- nptr points to the new byte in the packet
- odd is 1 if the byte is in an odd position 0 otherwise
*/
{ 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;
}
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 packet
- optr points to the old byte in the packet
- nptr points to the new byte in the packet
- odd is 1 if the byte is in an odd position 0 otherwise
*/
{ 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;
}
Making SNMP ALGs completely transparent to all management applications is not an achievable task. The basic SNMP ALG described in Section 4.1 only translates IP addresses encoded in the IpAddress base type. Such an SNMP ALG achieves only very limited transparency since IP addresses are frequently used as part of an index into a conceptual table. A management application will therefore see both the translated as well as the original address, which can lead to
使SNMP ALG对所有管理应用程序完全透明不是一项可以实现的任务。第4.1节中描述的基本SNMP ALG仅转换IP地址基类型中编码的IP地址。这样的SNMP ALG实现的透明度非常有限，因为IP地址经常用作概念表索引的一部分。因此，管理应用程序将同时看到翻译后的地址和原始地址，这可能导致
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 basic SNMP ALG in place.
管理应用程序的混乱和错误行为。但是，某些类别的管理应用程序（如网络发现工具）可能在NAT上运行良好，并配备了基本的SNMP ALG。
An advanced SNMP ALG described in Section 4.2 achieves better transparency. However, an advanced SNMP ALG can only claim to be transparent for the set of data types (textual conventions) understood by the advanced SNMP ALG implementation and for a given set of MIB modules. The price paid for better transparency is additional complexity, potentially increased SNMP packet sizes and mixed up lexicographic ordering. Especially with SNMPv3, there is an opportunity that communication fails due to increased packet sizes. Management applications that rely on lexicographic ordering will show erroneous behavior.
第4.2节中描述的高级SNMP ALG实现了更好的透明度。但是，高级SNMP ALG只能声明对于高级SNMP ALG实现所理解的数据类型集（文本约定）和给定的MIB模块集是透明的。为提高透明度付出的代价是额外的复杂性、可能增加的SNMP数据包大小和混淆的词典排序。特别是在SNMPv3中，由于数据包大小增加，通信可能会失败。依赖词典排序的管理应用程序将显示错误行为。
Both, basic and advanced SNMP ALGs, introduce problems when using SNMPv3 security features. The SNMPv3 authentication mechanism protects the whole SNMP message against modifications while the SNMPv3 privacy mechanism protects the payload of SNMPv3 messages against unauthorized access. Thus, an SNMP ALG must have access to all localized keys in use in order to modify SNMPv3 messages without invalidating them. Furthermore, the SNMP ALG must track any key changes in order to function. More details on the security implications of using SNMP ALGs can be found in Section 6.
基本和高级SNMP ALG在使用SNMPv3安全功能时都会带来问题。SNMPv3身份验证机制保护整个SNMP消息不受修改，而SNMPv3隐私机制保护SNMPv3消息的有效负载不受未经授权的访问。因此，SNMP ALG必须能够访问正在使用的所有本地化密钥，以便在不使SNMPv3消息失效的情况下修改这些消息。此外，SNMP ALG必须跟踪任何关键更改才能正常工作。有关使用SNMP ALG的安全影响的更多详细信息，请参见第6节。
Finally, an SNMP ALG only deals with SNMP traffic and does not modify the payload of any other protocol. However, management systems usually use a set of protocols to manage a network. In particular the telnet protocol is often used to configure or troubleshoot managed devices. Hence, a management system and the human network operator must generally be aware that a network address translation is occurring, even in the presence of an SNMP ALG.
最后，SNMP ALG只处理SNMP流量，不修改任何其他协议的有效负载。然而，管理系统通常使用一组协议来管理网络。特别是，telnet协议通常用于配置或排除受管设备的故障。因此，管理系统和人工网络运营商通常必须知道，即使在存在SNMP ALG的情况下，也会发生网络地址转换。
A possible alternative to SNMP ALGs are SNMP proxies, as defined in RFC 2573 [11]. An SNMP proxy forwarder application forwards SNMP messages to other SNMP engines according to the context, and irrespective of the specific managed object types being accessed. The proxy forwarder also forwards the response to such previously forwarded messages back to the SNMP engine from which the original message was received. Such a proxy forwarder can be used in a NAT environment to address SNMP engines with conflicting IP addresses. (Just replace the box SNMP ALG with a box labeled SNMP PROXY in Figure 2.) The deployment of SNMP proxys has the advantage that different security levels can be used inside and outside of the conflicting addressing realms.
SNMP ALG的一个可能替代方案是SNMP代理，如RFC 2573[11]中所定义。SNMP代理转发器应用程序根据上下文将SNMP消息转发给其他SNMP引擎，而与正在访问的特定托管对象类型无关。代理转发器还将对此类先前转发的消息的响应转发回接收原始消息的SNMP引擎。这种代理转发器可以在NAT环境中用于解决IP地址冲突的SNMP引擎。（只需将方框SNMP ALG替换为图2中标记为SNMP PROXY的方框即可。）SNMP proxys的部署有一个优点，即可以在冲突寻址领域内外使用不同的安全级别。
The proxy solution, which is structurally preferable, requires that the management application is aware of the proxy situation. Furthermore, management applications have to use internal data structures for network elements that allow for conflicting IP addresses since conflicting IP addresses are not translated by the SNMP proxy. Deployment of proxies may also involve the need to reconfigure network elements and management stations to direct their traffic (notifications and requests) to the proxy forwarder.
结构上更可取的代理解决方案要求管理应用程序了解代理情况。此外，管理应用程序必须为允许IP地址冲突的网元使用内部数据结构，因为SNMP代理不会转换冲突的IP地址。代理的部署还可能需要重新配置网元和管理站，以将其流量（通知和请求）定向到代理转发器。
SNMPv1 and SNMPv2c have very week security services based on community strings. All management information is sent in cleartext without encryption and/or authentication. In such an environment, SNMP messages can be modified by any intermediate node and management application are not able to verify the integrity of SNMP messages. Furthermore, an SNMP ALG does not need to have knowledge of the community strings in order to translate embedded IP addresses. Thus, deployment of SNMP ALGs in an SNMPv1/SNMPv2c environment introduces no additional security problems.
SNMPv1和SNMPv2c有基于社区字符串的每周安全服务。所有管理信息均以明文形式发送，无需加密和/或身份验证。在这样的环境中，任何中间节点都可以修改SNMP消息，并且管理应用程序无法验证SNMP消息的完整性。此外，SNMP ALG不需要了解社区字符串就可以转换嵌入的IP地址。因此，在SNMPv1/SNMPv2c环境中部署SNMP ALG不会带来额外的安全问题。
SNMPv3 supports three security levels: no authentication and no encryption (noAuth/noPriv), authentication and no encryption (auth/noPriv), and authentication and encryption (auth/priv). SNMPv3 messages without authentication and encryption (noAuth/noPriv) are send in cleartext. In such a case the usage of SNMP ALGs introduces no additional security problems.
SNMPv3支持三个安全级别：无身份验证和无加密（noAuth/noPriv）、身份验证和无加密（auth/noPriv）以及身份验证和加密（auth/priv）。未经身份验证和加密（noAuth/noPriv）的SNMPv3消息以明文形式发送。在这种情况下，使用SNMP ALGs不会带来额外的安全问题。
However, the usage of SNMP ALG introduces new problems when SNMPv3 authentication and optionally encryption is used. First, SNMPv3 messages with authentication and optionally encryption (auth/noPriv and auth/priv) can only be processed by an SNMP ALG which supports the corresponding cryptographic algorithms and which has access to the keys in use. Furthermore, as keys may be updated, the SNMP ALG must have a mechanism that tracks key changes (either by analyzing the key change interactions or by propagating key changes by other mechanisms). Second, the computational complexity of processing SNMP messages may increase dramatically. The message has to be decrypted before the translation takes place. If any translation is done the hash signature used to authenticate the message and to protect its integrity must be recomputed.
但是，当使用SNMPv3身份验证和可选加密时，使用SNMP ALG会带来新的问题。首先，具有身份验证和可选加密（auth/noPriv和auth/priv）的SNMPv3消息只能由支持相应加密算法并有权访问正在使用的密钥的SNMP ALG处理。此外，由于密钥可能会更新，SNMP ALG必须具有跟踪密钥更改的机制（通过分析密钥更改交互或通过其他机制传播密钥更改）。其次，处理SNMP消息的计算复杂性可能会显著增加。在进行翻译之前，必须对消息进行解密。如果进行了任何转换，则必须重新计算用于验证消息并保护其完整性的哈希签名。
In general, key exchange protocols are complicated and designing an SNMP ALG which maintains the keys for a set of SNMP engines is a non-trivial task. The User-based Security Model for SNMPv3 [12] defines a mechanism which takes a password and generates localized
一般来说，密钥交换协议是复杂的，设计一个维护一组SNMP引擎密钥的SNMP ALG是一项非常重要的任务。SNMPv3的基于用户的安全模型[12]定义了一种机制，该机制接受密码并生成本地化的
keys for every SNMP engine. The localized keys have the property that a compromised single localized key does not automatically give an attacker access to other SNMP engines, even if the key for other SNMP engines is derived from the same password.
每个SNMP引擎的密钥。本地化密钥具有以下属性：即使其他SNMP引擎的密钥来自同一密码，受损的单个本地化密钥也不会自动让攻击者访问其他SNMP引擎。
An SNMP ALG implementation which maintains lists of (localized) keys is a potential target to attack the security of all the systems which use these keys. An SNMP ALG implementation which maintains passwords in order to generate localized keys is a potential target to attack the security of all systems that use the same password. Hence, an SNMP ALG implementation must be properly secured so that people who are not authorized to access keys or passwords can not access them.
维护（本地化）密钥列表的SNMP ALG实现是攻击使用这些密钥的所有系统安全的潜在目标。维护密码以生成本地化密钥的SNMP ALG实现是攻击使用相同密码的所有系统安全性的潜在目标。因此，必须正确保护SNMP ALG实现，以便未经授权访问密钥或密码的人无法访问它们。
Finally, SNMP ALGs do not allow a network operator to use different security levels on both sides of the NAT. Using a secure SNMP version outside of a private addressing realm while the private addressing realm runs an unsecured version of SNMP may be highly desirable in many scenarios, e.g. management outsourcing scenarios. The deployment of SNMPv3 proxies instead of SNMP ALGs should be considered in these cases since SNMP proxies can be configured to use different security levels and parameters on both sides of the proxies.
最后，SNMP ALG不允许网络运营商在NAT的两侧使用不同的安全级别。在许多情况下，例如管理外包情况下，在私有寻址领域之外使用安全的SNMP版本，而私有寻址领域运行不安全的SNMP版本可能是非常理想的。在这些情况下，应考虑部署SNMPv3代理而不是SNMP ALG，因为可以将SNMP代理配置为在代理的两侧使用不同的安全级别和参数。
Several approaches to address SNMP agents across NAT devices have been discussed in this memo.
本备忘录讨论了跨NAT设备解决SNMP代理的几种方法。
1. Basic SNMP ALGs as described in Section 4.1 provide very limited transparency since they only translate IPv4 addresses encoded in the IpAddress base type. They are fast and efficient and may be 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 the limited transparency provided by a basic SNMP ALG. Basic SNMP ALGs are problematic in a secure SNMP environment since they need to maintain lists of keys or passwords in order to function. 2. Advanced SNMP ALGs as described in Section 4.2 provide better transparency. They can be transparent for the set of data types they understand and for a given set of MIB modules. However, an advanced SNMP ALG is much more complex and less efficiency than a basic SNMP ALG. An advanced SNMP ALG may break the lexicographic ordering when IP addresses are used to index conceptual tables and it may change the SNMP packet sizes. Especially with SNMPv3, there is an opportunity that communication fails due to increased message sizes. Advanced SNMP ALGs are problematic in a secure SNMP environment, since they need to maintain lists of keys or passwords in order to function.
1. 第4.1节中描述的基本SNMP ALG提供了非常有限的透明度，因为它们只转换IpAddress基类型中编码的IPv4地址。它们快速高效，可能足以在NAT环境中执行简单的管理应用程序（例如拓扑发现应用程序）。但是，由于基本SNMP ALG提供的透明度有限，其他管理应用程序可能会失败。基本SNMP ALG在安全的SNMP环境中存在问题，因为它们需要维护密钥或密码列表才能正常工作。2.第4.2节所述的高级SNMP ALG提供了更好的透明度。对于他们理解的数据类型集和给定的MIB模块集，它们可以是透明的。但是，高级SNMP ALG比基本SNMP ALG更复杂，效率更低。当IP地址用于索引概念表时，高级SNMP ALG可能会破坏字典顺序，并且可能会更改SNMP数据包的大小。特别是对于SNMPv3，由于消息大小增加，通信可能会失败。高级SNMP ALG在安全的SNMP环境中存在问题，因为它们需要维护密钥或密码列表才能正常工作。
3. SNMP proxies as described in RFC 2573 [11] allow management applications to access SNMP agents with conflicting IP addresses. No address translation is performed on the SNMP payload by an SNMP proxy forwarder. Hence, management applications must be able to deal with network elements that have conflicting IP addresses. This solution requires that management applications are aware of the proxy situation. Deployment of proxies may also involve the need to reconfigure network elements and management stations to direct their traffic (notifications and requests) to the proxy forwarder. SNMP proxies have the advantage that they allow to use different security levels inside and outside of a given addressing realm.
3. RFC 2573[11]中描述的SNMP代理允许管理应用程序访问IP地址冲突的SNMP代理。SNMP代理转发器不会对SNMP有效负载执行地址转换。因此，管理应用程序必须能够处理具有冲突IP地址的网络元素。此解决方案要求管理应用程序了解代理情况。代理的部署还可能需要重新配置网元和管理站，以将其流量（通知和请求）定向到代理转发器。SNMP代理的优点是，它们允许在给定的寻址域内外使用不同的安全级别。
It is recommended that network operators who need to manage networks in a NAT environment make a careful analysis before deploying a solution. In particular, it must be analyzed whether the management applications will work with the transparency and the side-effects provided by SNMP ALGs. Furthermore, it should be researched whether the management applications are able to deal with conflicting IP addresses for network devices. Finally, the additional complexity introduced to the over all management system by using SNMP ALGs must be compared to the complexity introduced by the structurally preferable SNMP proxy forwarders.
建议需要在NAT环境中管理网络的网络运营商在部署解决方案之前进行仔细分析。特别是，必须分析管理应用程序是否能够与SNMP ALG提供的透明度和副作用一起工作。此外，还应研究管理应用程序是否能够处理网络设备的冲突IP地址。最后，必须将通过使用SNMP ALG引入总体管理系统的额外复杂性与结构上更可取的SNMP代理转发器引入的复杂性进行比较。
A basic SNMP ALG as described in Section 4.1 was implemented for SNMPv1 at Bell-Labs, running on a Solaris Machine. The solution described in Figure 2, where SNMP ALG was combined with the NAT implementation of Lucent's PortMaster3, was deployed successfully in a large network management service organization.
如第4.1节所述，贝尔实验室在Solaris机器上为SNMPv1实现了一个基本的SNMP ALG。图2中描述的解决方案将SNMP ALG与朗讯PortMaster3的NAT实现相结合，并成功地部署在大型网络管理服务组织中。
We thank Pyda Srisuresh, for the support, encouragement, and advice throughout the work on this document. We also thank Brett A. Denison for his contribution to the work that led to this document. Additional useful comments have been made by members of the NAT working group.
我们感谢Pyda Srisuresh在本文件编写过程中给予的支持、鼓励和建议。我们还感谢Brett A.Denison为编写本文件所做的贡献。NAT工作组成员还提出了其他有用的意见。
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[1] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[2] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[2] Case，J.，Fedor，M.，Schoffstall，M.和J.Davin，“简单网络管理协议（SNMP）”，STD 15，RFC 1157，1990年5月。
[3] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[3] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“基于社区的SNMPv2简介”，RFC 19011996年1月。
[4] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[4] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的协议操作”，RFC 1905，1996年1月。
[5] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[5] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的传输映射”，RFC 1906，1996年1月。
[6] McCloghrie, K., "SNMPv2 Management Information Base for the Internet Protocol using SMIv2", RFC 2011, November 1996.
[6] McCloghrie，K.，“使用SMIv2的互联网协议的SNMPv2管理信息库”，RFC 2011，1996年11月。
[7] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997.
[7] Waldbusser，S.，“使用SMIv2的远程网络监控管理信息库版本2”，RFC 2021，1997年1月。
[8] Haskin, D. and S. Onishi, "Management Information Base for IP Version 6: Textual Conventions and General Group", RFC 2465, December 1998.
[8] Haskin，D.和S.Onishi，“IP版本6的管理信息库：文本约定和一般组”，RFC 2465，1998年12月。
[9] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999.
[9] Case，J.，Mundy，R.，Partain，D.和B.Stewart，“互联网标准网络管理框架第3版简介”，RFC 25701999年4月。
[10] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.
[10] Case，J.，Harrington，D.，Presohn，R.和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，RFC 2572，1999年4月。
[11] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999.
[11] Levi，D.，Meyer，P.和B.Stewart，“SNMP应用”，RFC2573，1999年4月。
[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.
[12] Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）第3版的基于用户的安全模型（USM）”，RFC 2574，1999年4月。
[13] ISO, "Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)", International Standard 8824, December 1987.
[13] ISO，“信息处理系统-开放系统互连-抽象语法符号1规范（ASN.1）”，国际标准88241987年12月。
[14] ISO, "Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", International Standard 8825, December 1987.
[14] ISO，“信息处理系统-开放系统互连-抽象语法符号1（ASN.1）基本编码规则规范”，国际标准88251987年12月。
[15] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[15] Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[16] Miller, M., "Managing Internetworks with SNMP", MT Books, 1997.
[16] Miller，M.“使用SNMP管理互联网”，MT图书，1997年。
[17] Perkins, D. and E. McGinnis, "Understanding SNMP MIBs", Prentice Hall, ISBN 0-13-437708-7, 1997.
[17] Perkins，D.和E.McGinnis，“理解SNMP MIB”，Prentice Hall，ISBN 0-13-437708-71997。
[18] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", Work in Progress.
[18] Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，正在进行中。
[19] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 2851, June 2000.
[19] Daniele，M.，Haberman，B.，Routhier，S.和J.Schoenwaeld，“因特网网络地址的文本约定”，RFC 28512000年6月。
Danny Raz Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733-3030 USA
丹尼·拉兹·朗讯科技公司，美国新泽西州霍姆德尔克劳福德角路101号，邮编：07733-3030
Phone: +1 732 949-6712
Fax: +1 732 949-0399
EMail: raz@lucent.com
URI: http://www.bell-labs.com/
Phone: +1 732 949-6712
Fax: +1 732 949-0399
EMail: raz@lucent.com
URI: http://www.bell-labs.com/
Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany
德国布埃尔滕韦格布伦瑞克大学74/75 38106
Phone: +49 531 391-3266
Fax: +49 531 391-5936
EMail: schoenw@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/
Phone: +49 531 391-3266
Fax: +49 531 391-5936
EMail: schoenw@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/
Binay Sugla ISPSoft Inc. 106 Apple Street Tinton Falls, NJ 07724 USA
Binay Sugla ISPSoft Inc.美国新泽西州丁顿瀑布苹果街106号，邮编：07724
Phone: +1 732 936-1763
EMail: sugla@ispsoft.com
URI: http://www.ispsoft.com/
Phone: +1 732 936-1763
EMail: sugla@ispsoft.com
URI: http://www.ispsoft.com/
SNMP packets use the ASN.1/BER encoding. We will not cover the full details of this encoding in this document. These details can be 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 "Managing Internetworks with SNMP", by M. A. Miller [16], or in Appendix A of the book "Understanding SNMP MIBs", by D. Perkins, and E. McGinnis [17].
SNMP数据包使用ASN.1/BER编码。我们将不在本文档中介绍此编码的全部细节。这些详细信息可在国际标准ISO-8824[13]和ISO-8825[14]中找到。有关ASN.1/BER的详细说明，请参见M.A.Miller[16]的《使用SNMP管理互联网》一书，或D.Perkins和E.McGinnis[17]的《理解SNMP MIB》一书的附录A。
Each variable that is referred to in an SNMP packet is uniquely identified by an OID (Object Identifier), usually written as a sequence of numbers separated by dots (e.g. 1.3.6.1.2.1.1.3.0). Each variable also has an associated base type (this is not very accurate but good enough for this level of description). One possible base type is the IpAddress type. The base type of each variable and its OID are conveyed by the ASN.1/BER encoding. Note that it is possible to associate additional type information with a variable by using textual conventions. The additional type semantics provided by textual conventions are not conveyed by the ASN.1/BER encoding.
SNMP数据包中引用的每个变量都由OID（对象标识符）唯一标识，通常以点分隔的数字序列（例如1.3.6.1.2.1.1.3.0）形式写入。每个变量也有一个相关的基类型（这不是很准确，但对于这种级别的描述来说已经足够了）。一种可能的基类型是IpAddress类型。每个变量的基本类型及其OID由ASN.1/BER编码传递。请注意，通过使用文本约定，可以将其他类型信息与变量关联起来。ASN.1/BER编码不传递文本约定提供的附加类型语义。
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. The managed element then responds by sending a get-response PDU that contains the same OID, the base type of the variable, and the current value. Figure 4 shows an example of real data contained in an SNMPv1 GetResponse PDU.
当管理器需要某个变量的值时，它会发送一个get请求PDU，其中包含该变量的OID和一个空值。然后，托管元素通过发送包含相同OID、变量的基类型和当前值的get响应PDU进行响应。图4显示了SNMPv1 GetResponse PDU中包含的真实数据示例。
The first 20 bytes contain the IPv4 4 header. The next 8 bytes contain the UDP header. The last two bytes of the UDP header contain the UDP checksum (D3 65). The next four bytes 30 82 00 3E are the beginning of the SNMP message: 30 is SEQUENCE, and 82 00 3E is the length of the data in the SEQUENCE in bytes (62). The data in the 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 SNMPv1 message is the SNMP PDU.
前20个字节包含IPv4 4标头。接下来的8个字节包含UDP报头。UDP报头的最后两个字节包含UDP校验和（D365）。接下来的四个字节30 82 00 3E是SNMP消息的开头：30是序列，82 00 3E是序列中数据的长度，以字节为单位（62）。序列中的数据是版本（02 01 00）和社区字符串（04 06 70 75 62 6C 69 63）。SNMPv1消息序列中的最后一个元素是SNMP PDU。
+-----------------------------------------+
| IP Header | 45 00 00 5E
| | 47 40 00 00
| | 3F 11 39 00
| | 87 B4 8C CA
| | 87 B4 8C 16
+-----------------------------------------+
| UDP Header | 00 A1 05 F5
| | 00 4A D3 65
+-----------------------------------------+
| SNMP Message | 30 82 00 3E
| Version | | 02 01 00 04
| Community | 06 70 75 62
| | | 6C 69 63 A2
| PDU Type | | 82 00 2F 02
| Request ID | 04 6C F2 0C
| | 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 0C
| | 81 4A 84 08
| IpAddress | 135 | 180 | 40 04 87 B4
| 140 | 202 +-------------------+ 8C CA
+---------------------+
+-----------------------------------------+
| IP Header | 45 00 00 5E
| | 47 40 00 00
| | 3F 11 39 00
| | 87 B4 8C CA
| | 87 B4 8C 16
+-----------------------------------------+
| UDP Header | 00 A1 05 F5
| | 00 4A D3 65
+-----------------------------------------+
| SNMP Message | 30 82 00 3E
| Version | | 02 01 00 04
| Community | 06 70 75 62
| | | 6C 69 63 A2
| PDU Type | | 82 00 2F 02
| Request ID | 04 6C F2 0C
| | 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 0C
| | 81 4A 84 08
| IpAddress | 135 | 180 | 40 04 87 B4
| 140 | 202 +-------------------+ 8C CA
+---------------------+
The SNMP PDU itself is a tagged SEQUENCE: A2 indicates a GetResponse PDU and 82 00 2F is the length of the data in the GetResponse PDU in 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: A SEQUENCE OF of length 31 (30 82 00 1F) containing a SEQUENCE of length 27 (30 82 00 1B). In it, the first object is an OID of length 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 the identification of the base type IpAddress, 04 is the length, and the next four bytes are the IP address value (135.180.140.202).
SNMP PDU本身是一个标记序列：A2表示GetResponse PDU，82 00 2F表示GetResponse PDU中数据的长度（字节）（47）。GetResponse PDU中的数据是请求id（02 04 6C F2 0C 5C）、错误状态（02 01 00）和错误索引（02 01 00）。现在跟随包含真实有效载荷的变量：长度为31（3082001f）的序列包含长度为27（3082001b）的序列。其中，第一个对象是长度为19（06 13）的OID，值为1.3.6.1.2.1.7.5.1.1.192.180.140.202.520。最后6个字节40 04 87 B4 8C CA表示一个IP地址：40是基类型IP地址的标识，04是长度，接下来4个字节是IP地址值（135.180.140.202）。
The example also shows an IP address embedded in an OID. The OID prefix resolves to the udpLocalAddress of the UDP-MIB, which is indexed by the udpLocalAddress 192.180.140.202 (81 40 81 34 81 0C 81
该示例还显示了OID中嵌入的IP地址。OID前缀解析为UDP-MIB的udpLocalAddress，该地址由udpLocalAddress 192.180.140.202（81 40 81 34 81 0C 81）索引
4A) and the udpLocalPort 520 (84 08). The SNMP packet actually shows an internal contradiction caused by a basic SNMP ALG since the udpLocalAddress encoded in the OID (192.180.140.202) is not equal to the value of the udpLocalAddress object instance (135.180.140.202).
4A）和udpLocalPort 520（84 08）。SNMP数据包实际上显示了由基本SNMP ALG引起的内部矛盾，因为OID（192.180.140.202）中编码的udpLocalAddress不等于udpLocalAddress对象实例（135.180.140.202）的值。
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。