rfc2962.txt

RFC 的详细文档！

RFC 2962            SNMP Payload Address Translation        October 2000


   [16] Miller, M., "Managing Internetworks with SNMP", MT Books, 1997.

   [17] Perkins, D. and E. McGinnis, "Understanding SNMP MIBs", Prentice
        Hall, ISBN 0-13-437708-7, 1997.

   [18] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
        Translator (Traditional NAT)", Work in Progress.

   [19] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder,
        "Textual Conventions for Internet Network Addresses", RFC 2851,
        June 2000.

11. Authors' Addresses

   Danny Raz
   Lucent Technologies
   101 Crawfords Corner Rd
   Holmdel, NJ  07733-3030
   USA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]
   URI:   http://www.bell-labs.com/


   Juergen Schoenwaelder
   TU Braunschweig
   Bueltenweg 74/75
   38106 Braunschweig
   Germany

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]
   URI:   http://www.ibr.cs.tu-bs.de/


   Binay Sugla
   ISPSoft Inc.
   106 Apple Street
   Tinton Falls, NJ  07724
   USA

   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.ispsoft.com/




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


12. Appendix A. Description of the Encoding of SNMP Packets

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

   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.

   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.

   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.















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


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

   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







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


   4A) and the udpLocalPort 520 (84 08). The SNMP packet actually 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).















































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


13.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   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.



















Raz, et al.                  Informational                     [Page 20]