One document matched: draft-ietf-nat-snmp-alg-01.txt
Differences from draft-ietf-nat-snmp-alg-00.txt
Transport Working Group D. Raz
INTERNET-DRAFT Bell-Labs, Lucent Technologies
Category: Informational B. Sugla
Expire in six months Bell-Labs, Lucent Technologies
September 1999
An SNMP Application Level Gateway for Payload Address Translation
<draft-ietf-nat-snmp-alg-01.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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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 September 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, the
limitations of using it, and compares it to other possible
solutions.
As mentioned before, in many cases, there is a need to manage a
local addressing realm that is using NAT, from a manager site
Raz Sugla [Page 2]
Internet Draft SNMP ALG September 1999
outside the realm. A particular important example is the case of
NM service providers who provide network management services from
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 requires both a potentially large set of IP
addresses, and the reconfiguration of a large portion of the
network which is problematic. 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 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,
supporting static address mapping for all nodes in the respective
private realms the NAT device(s) supports. Further, when there
are multiple private realms supported by a single SNMP ALG, the
external addressing assumed by each of the NAT devices must not
collide with each other.
The SNMP ALG solution suggested fits predominantly the SNMP V1
based applications, not using proprietary MIBs. The solution, as
presented, does not require knowledge of the MIBs. However,
extension to this approach may be adapted, as necessary to fit
specific situations.
The scope of the problems solved by this solution and discussion
of other possible solutions may be further found in sections
5.3-5.5 and 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
Raz Sugla [Page 3]
Internet Draft SNMP ALG September 1999
typically UDP packets that contain PDUs - Protocol Data Units.
The notion of flow is less relevant in this case, and hence we
will focus on the information contained in a single packet. The
main definition of SNMP is from 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.
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.
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 typically use the SNMP simple
network management protocol, which is an application that
exchanges IP address related information. Thus, in order for 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.
Raz Sugla [Page 4]
Internet Draft SNMP ALG September 1999
\ | / .
+---------------+ 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
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
Raz Sugla [Page 5]
Internet Draft SNMP ALG September 1999
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 both in time and
space. Each such an element 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 September 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
+-----------------------------------------+
| PDU | 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 PDU: 30
is SEQUENCE OF, 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 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 September 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. Proprietary MIB translation
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 very 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 September 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. A more detailed discussion of the need and ability to
translate queries can be found in Section 5.5.
The ability to translate IP addresses that are part of the tables'
indexes is thus another required feature of 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. Full transparency and forward/backward translation
As described before, making SNMP ALG completely transparent to
all management applications may be a very hard task. In some
cases it may also be undesirable. A big part of the manual
management is done by establishing a telnet session to the
appropriate device, and changing some of the local configuration
data. This data contains local addresses. Therefore, it is
clear that the full address structure should be available to the
administrators of the network. 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
questions of how to use SNMP ALG, what information to translate,
and what not. If we only need the basic IP address type
translation 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
Raz Sugla [Page 9]
Internet Draft SNMP ALG September 1999
containing IP addresses. However, if we need to use the general
OID translation, and in particular the table indexes, we must
also translate outgoing packets.
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. General MIB
translation may require a change in the size as a different
number 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
Raz Sugla [Page 10]
Internet Draft SNMP ALG September 1999
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 the address translation completely
transparent to all management applications is not an achievable
task. SNMP ALG deals only with SNMP traffic, and therefore it
does not modify 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. Another
possible problem is the additional complexity introduced to the
over all management system by using SNMP ALG.
Using the general and OID translation features of 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
station will be aware of the NAT situation, which is a feature
that cannot be found in many existing management systems. It
also involves reconfiguration of both the network elements and
the management station.
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
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
Raz Sugla [Page 11]
Internet Draft SNMP ALG September 1999
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 <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
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. Francis, and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)",
Raz Sugla [Page 12]
Internet Draft SNMP ALG September 1999
<draft-ietf-nat-traditional-01.txt> - Work in
progress
[SH 99] P. Srisuresh, and M. Holdrege, "The IP Network
Address Translator (NAT) terminology and
considerations", <draft-ietf-nat-terminology-02.txt>
- Work in progress
[RFC-1631] P. Srisuresh, and K. Egevang, "The IP Network Address
Translator (NAT)", RFC 1631 February 1998.
[RFC-1066] McCloghrie K., and M. Rose, "Management Information
Base for Network Management of TCP/IP-based
internets", RFC 1066 August 1988.
[RFC-1067] Case, J., M. Fedor, M. Schoffstall, and J. Davin,
"The Simple Network Management Protocol", RFC 1067,
August 1988.
[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 Mars 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 2261] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for describing SNMP Management
Frameworks", RFC 2261, January 1998.
Raz Sugla [Page 13]
Internet Draft SNMP ALG September 1999
[RFC 2262] Case, J., Harrington, D., Presuhn, R., and B.
Wijnen, "Message Processing and Dispatching for the
Simple Network Management Protocol (SNMP)", RFC 2262,
January 1998.
[RFC 2263] SNMPv3 Applications. D. Levi, P. Meyer, B.
Stewart. RFC 2263, January 1998.
[RFC 2264] User-based Security Model (USM) for version 3 of the
Simple Network Management Protocol (SNMPv3). U.
Blumenthal, B. Wijnen. RFC 2264, January 1998.
[RFC 2265] Wijnen, B., Presuhn, R., and K. McCloghrie,
"View-based Access Control Model for the Simple
Network Management Protocol (SNMP)", RFC 2265,
January 1998.
[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
Framework, <draft-ietf-snmpv3-coex-03.txt>, Feb 1999.
Authors' Addresses
Danny Raz
Bell Labs, Lucent Technologies
Raz Sugla [Page 14]
Internet Draft SNMP ALG September 1999
Room 4G-637
101 Crawfords Corner Rd
Holmdel, NJ 07733-3030
U.S.A.
Voice: (732) 949-6712
Fax: (732) 949-0399
EMail: raz@lucent.com
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: sugla@lucent.com
Raz Sugla [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 05:47:40 |