Subject: (NAT) draft-ietf-nat-snmp-alg-02 - new version

From: Dan Raz <[email-masked]>
Date: Tue, 19 Oct 1999 17:40:06 -0400

We have just submitted draft-ietf-nat-snmp-alg-02.txt.
I attach it here since there may be some backlogs.

We tried to address the points pointed out 
by the working group (mainly by Juergen Schoenwaelder)

Main differences:

1. The scope, requirements, and limitations are stated 
   in a clearer way.  
2. We defined two levels of implementation for SNMP ALG: 
   basic and advanced.
3. References have been updated.

Please send me any additional feedback and comments. 

Danny

-- 

Danny Raz                       Tel: 732-949-6712
Room 4G-637                     Fax: 732-949-0399
Bell-Labs                       email: [email-masked]
101 Crawfords Corner Road       
Holmdel, NJ 07733 - 3030
WWW: http://www.cs.bell-labs.com/~raz

  Transport Working Group                         D. Raz 
  INTERNET-DRAFT                         Bell-Labs, Lucent Technologies
  Category: Informational                        B. Sugla
  Expire in six months                   Bell-Labs, Lucent Technologies 
                                              October 1999

An SNMP Application Level Gateway for Payload Address Translation
		<draft-ietf-nat-snmp-alg-02.txt>

  Status of this Memo

     This document is an Internet-Draft and is in full conformance
     with all provisions of Section 10 of RFC2026.  Internet-Drafts
     are working documents of the Internet Engineering Task Force
     (IETF), its areas, and its working groups.  Note that other
     groups may also distribute working documents as Internet- Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months.  Internet-Drafts may be updated, replaced, or obsoleted
     by other documents at any time.  It is not appropriate to use
     Internet-Drafts as reference material or to cite them other than
     as a "working draft" or "work in progress".

     To learn the current status of any Internet-Draft, please check
     the 1id-abstracts.txt listing contained in the Internet-Drafts
     Shadow Directories on ds.internic.net (US East Coast),
     nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
     munnari.oz.au (Pacific Rim).

  Preface
  
     The SNMP Application Level Gateway for Payload Address
     Translation described in this document is a specific case of an
     Application Level Gateway (ALG), as described in [SH 99] and [FE
     98].  In some settings, there is a need to use the SNMP (Simple
     Network Management Protocol) with NAT in order to manage several
     addressing realms with conflicting IP addresses.  This document
     includes detailed description of the requirements for an
     implementation of such a gateway.

  Abstract
  
     The SNMP Application Level Gateway (SNMP ALG) is a feature by
     which IP addresses in the payload of SNMP packets are statically
     mapped from one group to another, transparent to management
     applications.  This requires Bi-directional NAT enroute, using
     static address assignment [3.1.1.  in SH99].  Further, this
     document describes a mechanism by which a management device can

Raz Sugla                                                       [Page 1]

Internet Draft                  SNMP ALG                    October 1999

     manage multiple networks that use conflicting IP addresses when
     operating within the scope described below.

  1. Introduction
  
     The need for IP address translation arises when a network's
     internal IP addresses cannot be used outside the network either
     for security reasons or because they are invalid for use outside
     the network.  Topology outside a local domain can change in many
     ways.  Customers may change providers, company backbones may be
     reorganized, or providers may merge or split.  Address
     translation allows hosts in such private networks to
     transparently access an external network and vice versa.

     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 networks is problematic.  Most available
     management applications use SNMP (Simple Network Management
     Protocol) to retrieve address 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 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.

     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 all IP address related
     information is translated if needed.  In this context SNMP ALG
     can be an additional component in any NAT implementation, or 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.

 2. Problem scope and requirements on NAT
     
     This section describes the scope of the SNMP ALG solution, and
     points out the main limitations of using it.

     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
     NM service providers who provide network management services from

Raz Sugla                                                       [Page 2]

Internet Draft                  SNMP ALG                    October 1999

     a remote site.  Such providers may have many customers, each
     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 and make the application be aware of
         it.

     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.

     The need is then 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).  SNMP ALG is such a
     solution.

     The SNMP ALG requires Bi-directional NAT devices enroute, that
     support static address mapping for all nodes in the respective
     private realms.  Further, 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.

     We suggest two levels of implementation: 
     
     (1) Basic SNMP ALG:  this is an SNMP ALG implementation in which
         only IpAddress type in the BER encoding is translated.

     (2) Advanced SNMP ALG:  this is an SNMP ALG implementation which
	 is generally MIB aware and is capable of handling and
	 replacing IpAddress values encoded in instance identifiers.

     The basic SNMP ALG does not require knowledge of the MIBs, is
     easier to implement, and does not change the messages size.
     However, the translation of IP related information which is
     encoded using other SNMP data types may be needed for some
     applications.  In such a case, advanced SNMP ALG should be used.
     Note that using advanced SNMP ALG may increase the packet size
     and change the lexicographic order in the presented MIB.  A more
     detailed discussion of the various limitations associated with

Raz Sugla                                                       [Page 3]

Internet Draft                  SNMP ALG                    October 1999

     the different levels of implementation and discussion of other
     possible solutions can be found in section 7.0.

  3. Terminology and concepts used 
  
     In general we adapt the terminology used in [SH 99].  Our main
     concern is packets used by the SNMP protocol.  These are
     typically UDP packets that contain SNMP messages.  SNMP messages
     contain PDUs (Protocol Data Units) which defines the parameters
     for SNMP protocol operations.  The notion of flow is less
     relevant in this case, and hence we will focus on the information
     contained in a single packet.

     SNMP version 1 is defined in RFC 1157.  Other RFCs (1155, 1213,
     1215) define the structure of the managed information (SMI) and
     the management information base (MIB).  There are many versions
     of SNMP.  For simplicity, unless otherwise mentioned, we refer to
     SNMP version 1 as SNMP.  See RFC 2570 for introduction to related
     SNMP standards.

     SNMP uses ASN.1 to define the abstract syntax of the messages.
     The actual encoding of the messages is done using the basic
     encoding rules (BER), which provide the transfer syntax.  These
     standards are defined in ISO 8824-1, and ISO 8825-1.

     We also consider in this document IPv4, and thus we refer to IPv4
     addresses as just IP addresses.

     We use the terms basic and advanced SNMP ALG to describe the
     different levels of implementation, as explained in Section 3.
     We also refer to packets that go from the management station to
     the network elements as "outgoing", and packets that go from the
     network elements to the management station as "incoming".

  4. Overview of the SNMP application level gateway
  
     Using basic address translation allows local hosts on a private
     network (addressing realm) to transparently access the external
     global network and enables access to selective local hosts from
     the outside.  This solution is becoming widely popular as the
     range of IPv4 addresses is limited.  In particular it is not
     unlikely to have several addressing realms that are using the
     same private IP address space within the same organization.

     However, managing such a network presents unique problems and
     challenges.  Managing devices execute management applications
     that typically use the SNMP simple network management protocol,
     to exchanges IP address related information.  Thus, in order for

Raz Sugla                                                       [Page 4]

Internet Draft                  SNMP ALG                    October 1999

     the SNMP application to work transparently across NAT,
     Application Level Gateways, or ALGs, may be used to perform
     translation on SNMP packets.  This translation of the payload of
     SNMP packets is called an SNMP Application Level Gateway - or
     just SNMP ALG.

     A typical scenario where SNMP ALG is deployed as part of NAT is
     presented in figure 1.  A manager device is managing a remote
     stub, with translated IP addresses.
     
          \ | /               .                                
     +---------------+  WAN   .        +------------------------------+
     |Regional Router|-----------------|Stub Router w/NAT and SNMP ALG|
     +---------------+        .        +------------------------------+
             |                .                   |         
             |                .                   |  LAN
        +----------+          .            ---------------
        |Manager   |    Stub border         Managed network
        +----------+
                    
                    Figure 1: NAT+SNMP ALG configuration

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

Raz Sugla                                                       [Page 5]

Internet Draft                  SNMP ALG                    October 1999

     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.

     A management payload translator 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.

  5.0  Parsing and translating data in SNMP packets
  
     SNMP packets are built using 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 and
     ISO-8825.  A good description of ASN.1/BER can be found in the
     book Managing Internetworks with SNMP, by M.  A.  Miller [Mi 97],
     or in Appendix A of the book Understanding SNMP MIBs, by D.
     Perkins, and E.  McGinnis [PM 97].

  5.1. General description of the encoding of data in 
       SNMP PDU's (ASN.1 and BER)

     In general, each variable that is referred to in an SNMP packet
     has a unique OID (Object Identifier) which is a set of numbers
     separated by a dot (for example:  1.2.4.56.12.34).  This OID
     gives a unique identification to each variable.
     Each variable also has a type (this is not very
     accurate but good enough for this level of description).  One
     possible type is the IP address type.  The type of each piece of
     data, and its OID are part of 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.  The managed
     element then responds by sending a get-response PDU that has in
     it the same OID, the type of the variable, and the current value.
     Here is an example of real data in an SNMP get-response PDU
     packet:

Raz Sugla                                                       [Page 6]

Internet Draft                  SNMP ALG                    October 1999

     +-----------------------------------------+
     |       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 = public                     |     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 length 31                | SEQUENCE |     82 00 1F 30
     |  of length 27                | OID      |     82 00 1B 06
     | length=19 |                             |     13 2B 06 01
     |                                         |     02 01 07 05
     |                                         |     01 01 81 40
     |                                         |     81 34 81 0C  
     |                                         |     81 4A 84 08
     |  IP Type            | 135    | 180      |     40 04 87 B4
     |  140      | 202     +-------------------+     8C CA
     +---------------------+

     The first 20 bytes are the IP header.  The next 8 bytes are the
     UDP header, with the last two bytes in it 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
     payload in bytes (62).  Next come the Version (02 01 00) and the
     Community (04 06 ..  63 = public).  The next part is the PDU,
     first item is the PDU type (A2 82 00 2F = GetResponse), the
     request ID (02 04 6C F2 0C 5C), the Error Status (02 01 00 = No
     Error), and the Error Index (02 01 00).  Now come the variables
     (i.e.  the real data):  SEQUENCE OF of length 31 (30 82 00 1F).
     The first element is a SEQUENCE of length 27 (30 82 00 1B).  In
     it, the first object is an OID of length 19 (06 13), then comes
     the OID:  1.3.6.1.2.1.7.5.1.1.192.180.140.202.520.  The last 6
     octets 40 04 87 B4 8C CA represent an IP address:  40 is the type
     IP address, 04 is the length, and the next four octets are the IP
     address:  135.180.140.202.

Raz Sugla                                                       [Page 7]

Internet Draft                  SNMP ALG                    October 1999

  5.2. Translating IP address type
  
     The basic requirement from SNMP ALG is that it will be able to
     detect IP addresses in the SNMP packets' payload.  Once an IP
     address is detected, SNMP ALG should check the translation table
     and decide whether this address should be translated.  If so, the
     4 bytes representing the IPv4 address should be replaced by the
     translated address, and the UDP checksum should be adjusted.

     Therefore, SNMP ALG should parse the ASN.1/BER encoding, looking
     for an IP address type.  If it sees a different object type it
     can jump to the beginning of the next object, unless the object
     is a SEQUENCE Of.  In that case the sequence should be parsed as
     it may contain an IP address type inside.  If an object is of
     type IP address, the translation table is checked to see if this
     address needs to be translated, and if so what the new value
     should be.  The translating function then should replace the 4
     octets with the new address, and continue to parse the packet.

  5.3. Advanced SNMP ALG
  
     For some applications it may be necessary to translate IP
     addresses that are not encoded in the standard way.  It may be a
     part of a proprietary or a private MIB, which uses some other way
     to represent an IP address (Integers or ASCII).  In that case,
     some external information is needed, which states the OID of the
     objects that are IP addresses and the way they are encoded.  The
     translation function, then, 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.

  5.4. Forwarding tables, and IP address type as a table index
  
     IP address type is used in the standard MIB-II (as defined in RFC
     1213) as the index (or part of the index) of several tables.
     Some of the proprietary MIBs may also use it, since this is a
     very convenient way to store information related to IP addresses,
     e.g.:  The following MIB-II tables have IP address type in their
     indexes:  atTable, ipAddrTable, ipRouteTable, tcpConnTable,
     udpConnTable, egpNeighTable.

     The problem now is that if the manager is trying to retrieve a

Raz Sugla                                                       [Page 8]

Internet Draft                  SNMP ALG                    October 1999

     specific value from one of these tables using the IP address as
     an index, it should use the local address and not the translated
     one.  If the translated address is used then the index should be
     translated by SNMP ALG.  However, if the access to the table is
     done in order to get the entire table, or the next entry in the
     table, such a translation may result in an unpredicted result.
     Note that in such cases translation of the queries is also
     required.

     The ability to translate IP addresses that are part of the
     tables' indexes is thus another required feature of advanced SNMP
     ALG.  In this case the OID of the table should be predefined (by
     parsing the MIBs offline).  This is a special case of the General
     MIB depended translation discussed in the last subsection.  In
     this case the encoding of the address is known (and different
     from the IP address type).  For example the IP address
     135.180.140.202 is encoded as 87 B4 8C CA when it is IP address
     type (each byte is a number), and 81 40 81 34 81 0C 81 4A as an
     IP address index to a table (this is due to the OID encoding
     scheme).

     In this case the function searches for objects with an OID that
     matches one of the OIDs in the translating table.  If such an
     object is found the next four OID numbers (it may be four to
     eight bytes, depending on the ranges of the specific IP address)
     of the OID are checked in the IP translation tables, and replaced
     if needed.  This mechanism allows us to replace table entries in
     MIB tables indexed by IP addresses.  A similar but a bit more
     complicated mechanism, can handle tables that are indexed by more
     than one IP address (like tcpConnTable).

  5.5. Translation of outgoing and incoming packets 
  
     If we only use basic SNMP ALG then we only need to translate
     packets that are going from the managed network to the management
     station (i.e.  GetResponse and Trap packets), since they are the
     only ones containing IP addresses.  Note that the outgoing SNMP
     messages contain only the OIDs of the requested variables, and do
     not have (in the payload) any IP address information.  This is no
     longer true when IP addresses are used as table indexes.  Thus,
     advanced SNMP ALG may require the translation of both outgoing
     and incoming messages.

  6.0 Package size and UDP checksum 
     
     Changing the IP address in the payload should not change the size
     of a packet, as we only replace 4 bytes by 4 bytes.  Advanced
     SNMP ALG may require a change in the size as a different number

Raz Sugla                                                       [Page 9]

Internet Draft                  SNMP ALG                    October 1999

     of bytes may be used to encode different IP addresses.  This is
     highly undesirable.  The BER encoding allows the use of both
     short and long length encoding to represent a small index (i.e.
     smaller than 127).  Therefore, in the table index case one can
     always translate to long encoding.  As a result, the encoded
     length will not decrease.  However if a byte smaller than 127 in
     an IP address is translated to a value bigger than 127, an
     additional byte may be required (this depends on the encoding
     used by the agent application).  This will require additional
     changes in the headers (UDP and IP).  In any case the UDP
     checksum should be adjusted when making an IP translation.  We
     can use the algorithm from [FE 98], but a small modification must
     be introduced as the 4 bytes may start on an odd position.  The
     following C code 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;}
       
     Unlike TCP, the UDP checksum can be set to 0, which makes all the
     applications ignore it.  This can be used by SNMP ALG if the
     computational resources are limited.

7.0. Limitations of SNMP ALG and possible alternative solutions
  
     As described before, making SNMP ALG completely transparent to
     all management applications is not an achievable task.  SNMP ALG
     deals only with SNMP traffic, and therefore it does not modify

Raz Sugla                                                      [Page 10]

Internet Draft                  SNMP ALG                    October 1999

     the payload of any other protocol.  In particular the telnet
     utility which is often used by system administrators to configure
     the managed devices in the managed domain is not affected.  In
     such a case, the administrator must be aware that a translation
     is occurring between the two realms.

     The main purpose of SNMP ALG is to be a transparent IP address
     translation mechanism for the automated discovery and management
     tools.  This raises the issues of how to use SNMP ALG, what
     information and what not to translate.  As described in Section
     5, when IP address are used as table indices SNMP ALG cannot be
     transparent.  Otherwise, an advanced SNMP ALG can only claim to
     be transparent for a given set of MIB modules.  This
     implementation should have the additional knowledge needed to
     replace IP addresses embedded in all other SNMP data types (e.g.
     TAddress) that are used in this particular set of MIBs.

     Another possible problem is the additional complexity introduced
     to the over all management system by using SNMP ALG.  This
     complexity should be compared to the complexity introduced by
     using alternative solutions.

     Using the general and OID translation features of advanced SNMP
     ALG may create additional problems such as:  increasing the
     packet size and changing the lexicographic order in the presented
     MIB, as described in Section 5.

     One alternative solution to SNMP ALG may be to use SNMP proxies
     and to use SNMP contexts (or community strings in SNMPv1/SNMPv2c)
     to let the manager address the right destination.  This solution,
     which is structurally preferable, requires that the management
     application will be aware of the proxy situation.  Since SNMP
     proxies were originally designed to allow SNMP managers to manage
     legacy systems, in some applications the naming space for the
     network elements and the IP numbers are not appropriately
     separate.  In such cases the application should also be aware of
     the NAT situation.  Using proxies may also involve
     reconfiguration of both the network elements to redirect their
     traps to the proxy agent and the management station, to redirect
     traffic to the proxy.

  7.1. Privacy, security, and debugging considerations
  
     We assume that all the management information is sent on the
     clear, i.e.  without encryption and/or authentication.  If such
     encryption tools are used, then the SNMP ALG must have access to
     the keys/protocols in order to be able to perform the translation

Raz Sugla                                                      [Page 11]

Internet Draft                  SNMP ALG                    October 1999

     and/or to verify authentication.  This should not be a problem
     since in many cases there is only one source for the management
     applications (i.e.  this type of applications are not run by
     general users, and the same administrative organization is
     responsible both for the management application and NAT).
     However, the complexity and resources needed to perform the
     translation under these conditions will be much higher.

  7.2. Translation of fragmented UDP packets
  
     As described in [FE 98], fragments of UDP packets do not carry
     the destination/source port number with them.  In order to parse
     an SNMP packet the complete PDU must be built, and then sent to
     the translation function.  Note that in an extreme case,
     fragmentation may cause an IP address type to be partitioned into
     two different fragments.  The good news is, however, that usually
     the SNMP agents are aware of the MTU, and the SNMP packets are
     usually relatively small.

  8.  SNMP versions

     The use of the name SNMP may be confusing, since there are
     several versions of the Simple Network Management Protocol.  The
     reader is referred to RFC 2570 or to the more detailed discussion 
     in <draft-ietf-snmpv3-coex-03.txt> [FLRW 99] for details.  
     An informal description of the different versions can be found in:
     http://www.simple-times.org/pub/simple-times/issues/5-1.html#alternative.

     This document covers SNMPv1.  However, since the basic encoding
     of the PDU, including the use of the IP address type, in SNMPv2
     is very much similar to SNMPv1, the principles of SNMP ALG as
     described in Sections 4 and 5 are valid for SNMPv2c.  The use of
     SNMP ALG for SNMPv3 is not covered by this document.

  9. Current implementations
    
     An SNMP ALG as described in this document was implemented in
     Bell-Labs in C, 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.

  10. Acknowledgments
   
     We thank Pyda Srisuresh, for the support, encouragement, and

Raz Sugla                                                      [Page 12]

Internet Draft                  SNMP ALG                    October 1999

     advice throughout the work on this document.  We also thank
     Brett A.  Denison for his contribution to the work that led to
     this document.  Very useful comments have been made by members
     of the NAT working group, in particular we thank Juergen
     Schoenwaelder for his suggestions.

  REFERENCES
  
     [FE 98]     P. Srisuresh , and K.  Egevang, "Traditional IP Network
		 Address Translator (Traditional NAT)",
		 <draft-ietf-nat-traditional-03.txt> - Work in
		 progress

     [RFC 2663]  P. Srisuresh, and M.  Holdrege, "The IP Network
		 Address Translator (NAT) Terminology and
		 Considerations", August 1999.

     [RFC-1631]  K.  Egevang, and P. Francis,  "The IP Network Address
		 Translator (NAT)", RFC 1631 May 1994.
		 
     [RFC-1466]  E.  Gerich, "Guidelines for Management of IP Address
		 Space", RFC 1466, May 1993.

     [RFC-768]   J.  Postel, "User Datagram Protocol (UDP)", RFC 768.

     [RFC-950]   J.  Mogul, J.  Postel, "Internet Standard Subnetting
	         Procedure", RFC 950.

     [RFC 1157]  J.  Case, M.  Fedor, M.  Schoffstall, and J.  Davin,
		 "The Simple Network Management Protocol", RFC 1157,
		 May 1990.

     [RFC 1213]  K.  McCloghrie, and M.T. Rose, "Management
		 Information Base for Network Management of
		 TCP/IP-based Internets: MIB-II", RFC 1213 March 1991.

     [RFC 1215]  M.T.  Rose, "Convention for Defining Traps for Use
		 with the SNMP", RFC 1215 Mars 1991.

     [RFC 1155]  K.  McCloghrie, and M.T.  Rose, "Structure and
		 Identification of Management Information for
		 TCP/IP-based Internets", RFC 1155 May 1990.

     [RFC 2003]  C.  Perkins, "IP Encapsulation within IP", RFC 2003,
		 October 1996.

     [RFC 2570]  J. Case, R. Mundy, D. Partain, and B. Stewart, 

Raz Sugla                                                      [Page 13]

Internet Draft                  SNMP ALG                    October 1999

                 "Introduction to Version 3 of the Internet-standard
                 Network Management Framework", RFC 2570, April 1999.
		 
     [RFC 2571]  D. Harrington, R. Presuhn, and B. Wijnen, "An
		 Architecture for describing SNMP Management
		 Frameworks", RFC 2571, May 1999.

     [RFC 2572]  J. Case, D. Harrington, R. Presuhn, and B.
		 Wijnen, "Message Processing and Dispatching for the
		 Simple Network Management Protocol (SNMP)", RFC 2572,
		 May 1999.

     [RFC 2573]  D. Levi, B. Meyer, and B. Stewart, "SNMP Applications",  
		 RFC 2573, April 1999.

     [RFC 2574]  U. Blumenthal, and B. Wijnen, "User-based Security 
                 Model (USM) for Version 3 of the Simple Network
                 Management Protocol (SNMPv3)", RFC 2574, April 1999.

     [RFC 2575]  B. Wijnen, R. Presuhn, and K.  McCloghrie,
		 "View-based Access Control Model (VACM) for the Simple
		 Network Management Protocol (SNMP)", RFC 2575,
		 April 1999.
   
     [RFC 2570]  J. Case, R. Mundy, D. Partain, and B. Stewart, 
                 "Introduction to Version 3 of the Internet-standard 
                 Network Management Framework",  April 1999.

     [ISO-8824]  International Organization for Standardization,
		 Information Technology:  Abstract Syntax Notation One
		 (ASN.1):  Specification of Basic Notation, ISO/IEC 8824-1:
		 1995.

     [ISO-8825]  International Organization for Standardization,
		 Information Technology:  ASN.1 Encoding Rules:
		 Specification of Basic Encoding Rules (BER),
		 Canonical Encoding Rules (CER) and Distinguished
		 Encoding Rules (DER), ISO/IEC 8825-1:  1995.

     [Mi 97]     M. A. Miller, "Managing Internetworks with SNMP", M&T
		 Books,1997.

     [PM 97]     D.  Perkins, and E.  McGinnis, "Understanding SNMP
		 MIBs", Prentice-Hall, 1997.

     [FLRW 99]   R. Fry, D.  B. Routhier, and B. Wijnen,
		 "Coexistence between Version 1, Version 2, and Version
		 3 of the Internet-standard Network Management

Raz Sugla                                                      [Page 14]

Internet Draft                  SNMP ALG                    October 1999

		 Framework", <draft-ietf-snmpv3-coex-03.txt>, Feb 1999.

  Authors' Addresses
  
     Danny Raz
     Bell Labs,  Lucent Technologies
     Room 4G-637
     101 Crawfords Corner Rd
     Holmdel, NJ 07733-3030   
     U.S.A.
  
     Voice: (732) 949-6712
     Fax:   (732) 949-0399
     EMail: [email-masked]
  
     Binay Sugla
     Bell Labs,  Lucent Technologies
     Room 4F-621
     101 Crawfords Corner Rd
     Holmdel, NJ 07733-3030   
     U.S.A.
     
     Voice: (732) 949-0850
     Fax:   (732) 949-0399
     EMail: [email-masked]

Raz Sugla                                                      [Page 15]