rfc2962.txt

RFC 的详细文档！

Raz, et al.                  Informational                      [Page 5]

RFC 2962            SNMP Payload Address Translation        October 2000


   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.

   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.

   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.

3.1 IP Addresses in SNMP Messages

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

   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




Raz, et al.                  Informational                      [Page 6]

RFC 2962            SNMP Payload Address Translation        October 2000


   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.

   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.

3.2 Requirements

   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.

   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.

4. Translating IP Addresses in SNMP Packets

   This section describes several ways to translate IP addresses in SNMP
   packets.

   A general SNMP ALG must be capable to translate IP addresses in
   outgoing and incoming SNMP packets.

   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





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 SNMP
   implementations also set the don't fragment (DF) bit in the IP header
   [1] to avoid fragmentation.

4.1 Basic SNMP Application Level Gateway

   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.

   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.

   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.

   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).

4.2 Advanced SNMP Application Level Gateway

   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.






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

   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.

   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.

   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.

4.3 Packet Size and UDP Checksum

   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.

   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



Raz, et al.                  Informational                      [Page 9]

RFC 2962            SNMP Payload Address Translation        October 2000


   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.

   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.

        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;
        }

5. Limitations and Alternate Solutions

   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






Raz, et al.                  Informational                     [Page 10]