home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1449 < prev    next >
Text File  |  1993-05-02  |  41KB  |  1,476 lines
  1.  
  2.  
  3.  
  4.           Network Working Group                                  J. Case
  5.           Request for Comments: 1449                 SNMP Research, Inc.
  6.                                                            K. McCloghrie
  7.                                                       Hughes LAN Systems
  8.                                                                  M. Rose
  9.                                             Dover Beach Consulting, Inc.
  10.                                                            S. Waldbusser
  11.                                               Carnegie Mellon University
  12.                                                               April 1993
  13.  
  14.  
  15.                                 Transport Mappings
  16.                                for version 2 of the
  17.                    Simple Network Management Protocol (SNMPv2)
  18.  
  19.  
  20.           Status of this Memo
  21.  
  22.           This RFC specifes an IAB standards track protocol for the
  23.           Internet community, and requests discussion and suggestions
  24.           for improvements.  Please refer to the current edition of the
  25.           "IAB Official Protocol Standards" for the standardization
  26.           state and status of this protocol.  Distribution of this memo
  27.           is unlimited.
  28.  
  29.  
  30.           Table of Contents
  31.  
  32.  
  33.           1 Introduction ..........................................    2
  34.           1.1 A Note on Terminology ...............................    2
  35.           2 Definitions ...........................................    3
  36.           3 SNMPv2 over UDP .......................................    7
  37.           3.1 Serialization .......................................    7
  38.           3.2 Well-known Values ...................................    7
  39.           4 SNMPv2 over OSI .......................................    8
  40.           4.1 Serialization .......................................    8
  41.           4.2 Well-known Values ...................................    8
  42.           5 SNMPv2 over DDP .......................................    9
  43.           5.1 Serialization .......................................    9
  44.           5.2 Well-known Values ...................................    9
  45.           5.3 Discussion of AppleTalk Addressing ..................    9
  46.           5.3.1 How to Acquire NBP names ..........................   10
  47.           5.3.2 When to Turn NBP names into DDP addresses .........   11
  48.           5.3.3 How to Turn NBP names into DDP addresses ..........   11
  49.           5.3.4 What if NBP is broken .............................   12
  50.           6 SNMPv2 over IPX .......................................   13
  51.           6.1 Serialization .......................................   13
  52.           6.2 Well-known Values ...................................   13
  53.           7 Proxy to SNMPv1 .......................................   14
  54.           7.1 Transport Domain: rfc1157Domain .....................   14
  55.           7.2 Authentication Algorithm: rfc1157noAuth .............   14
  56.  
  57.  
  58.           Case, McCloghrie, Rose & Waldbusser                   [Page i]
  59.  
  60.  
  61.  
  62.  
  63.  
  64.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  65.  
  66.  
  67.           8 Serialization using the Basic Encoding Rules ..........   16
  68.           8.1 Usage Example .......................................   17
  69.           9 Acknowledgements ......................................   18
  70.           10 References ...........................................   22
  71.           11 Security Considerations ..............................   24
  72.           12 Authors' Addresses ...................................   24
  73.           13 Security Considerations ..............................   25
  74.           14 Authors' Addresses ...................................   25
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.           Case, McCloghrie, Rose & Waldbusser                   [Page 1]
  118.  
  119.  
  120.  
  121.  
  122.  
  123.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  124.  
  125.  
  126.           1.  Introduction
  127.  
  128.           A network management system contains: several (potentially
  129.           many) nodes, each with a processing entity, termed an agent,
  130.           which has access to management instrumentation; at least one
  131.           management station; and, a management protocol, used to convey
  132.           management information between the agents and management
  133.           stations.  Operations of the protocol are carried out under an
  134.           administrative framework which defines both authentication and
  135.           authorization policies.
  136.  
  137.           Network management stations execute management applications
  138.           which monitor and control network elements.  Network elements
  139.           are devices such as hosts, routers, terminal servers, etc.,
  140.           which are monitored and controlled through access to their
  141.           management information.
  142.  
  143.           The management protocol, version 2 of the Simple Network
  144.           Management Protocol [1], may be used over a variety of
  145.           protocol suites.  It is the purpose of this document to define
  146.           how the SNMPv2 maps onto an initial set of transport domains.
  147.           Other mappings may be defined in the future.
  148.  
  149.           Although several mappings are defined, the mapping onto UDP is
  150.           the preferred mapping.  As such, to provide for the greatest
  151.           level of interoperability, systems which choose to deploy
  152.           other mappings should also provide for proxy service to the
  153.           UDP mapping.
  154.  
  155.  
  156.           1.1.  A Note on Terminology
  157.  
  158.           For the purpose of exposition, the original Internet-standard
  159.           Network Management Framework, as described in RFCs 1155, 1157,
  160.           and 1212, is termed the SNMP version 1 framework (SNMPv1).
  161.           The current framework is termed the SNMP version 2 framework
  162.           (SNMPv2).
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.           Case, McCloghrie, Rose & Waldbusser                   [Page 2]
  177.  
  178.  
  179.  
  180.  
  181.  
  182.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  183.  
  184.  
  185.           2.  Definitions
  186.  
  187.           SNMPv2-TM DEFINITIONS ::= BEGIN
  188.  
  189.           IMPORTS
  190.               snmpDomains, snmpProxys
  191.                   FROM SNMPv2-SMI
  192.               TEXTUAL-CONVENTION
  193.                   FROM SNMPv2-TC;
  194.  
  195.           -- SNMPv2 over UDP
  196.  
  197.           snmpUDPDomain  OBJECT IDENTIFIER ::= { snmpDomains 1 }
  198.           -- for a SnmpUDPAddress of length 6:
  199.           --
  200.           -- octets   contents        encoding
  201.           --  1-4     IP-address      network-byte order
  202.           --  5-6     UDP-port        network-byte order
  203.           --
  204.           SnmpUDPAddress ::= TEXTUAL-CONVENTION
  205.               DISPLAY-HINT "1d.1d.1d.1d/2d"
  206.               STATUS       current
  207.               DESCRIPTION
  208.                       "Represents a UDP address."
  209.               SYNTAX       OCTET STRING (SIZE (6))
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.           Case, McCloghrie, Rose & Waldbusser                   [Page 3]
  236.  
  237.  
  238.  
  239.  
  240.  
  241.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  242.  
  243.  
  244.           -- SNMPv2 over OSI
  245.  
  246.           snmpCLNSDomain OBJECT IDENTIFIER ::= { snmpDomains 2 }
  247.           snmpCONSDomain OBJECT IDENTIFIER ::= { snmpDomains 3 }
  248.           -- for a SnmpOSIAddress of length m:
  249.           --
  250.           -- octets   contents            encoding
  251.           --    1     length of NSAP      "n" as an unsigned-integer
  252.           --                                (either 0 or from 3 to 20)
  253.           -- 2..(n+1) NSAP                concrete binary representation
  254.           -- (n+2)..m TSEL                string of (up to 64) octets
  255.           --
  256.           SnmpOSIAddress ::= TEXTUAL-CONVENTION
  257.               DISPLAY-HINT "*1x:/1x:"
  258.               STATUS       current
  259.               DESCRIPTION
  260.                       "Represents an OSI transport-address."
  261.               SYNTAX       OCTET STRING (SIZE (1 | 4..85))
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.           Case, McCloghrie, Rose & Waldbusser                   [Page 4]
  295.  
  296.  
  297.  
  298.  
  299.  
  300.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  301.  
  302.  
  303.           -- SNMPv2 over DDP
  304.  
  305.           snmpDDPDomain  OBJECT IDENTIFIER ::= { snmpDomains 4 }
  306.           -- for a SnmpNBPAddress of length m:
  307.           --
  308.           --    octets      contents         encoding
  309.           --       1        length of object "n" as an unsigned integer
  310.           --     2..(n+1)   object           string of (up to 32) octets
  311.           --      n+2       length of type   "p" as an unsigned integer
  312.           -- (n+3)..(n+2+p) type             string of (up to 32) octets
  313.           --     n+3+p      length of zone   "q" as an unsigned integer
  314.           -- (n+4+p)..m     zone             string of (up to 32) octets
  315.           --
  316.           -- for comparison purposes, strings are case-insensitive
  317.           --
  318.           -- all strings may contain any octet other than 255 (hex ff)
  319.           --
  320.           SnmpNBPAddress ::= TEXTUAL-CONVENTION
  321.               STATUS       current
  322.               DESCRIPTION
  323.                       "Represents an NBP name."
  324.               SYNTAX       OCTET STRING (SIZE (3..99))
  325.  
  326.  
  327.           -- SNMPv2 over IPX
  328.  
  329.           snmpIPXDomain  OBJECT IDENTIFIER ::= { snmpDomains 5 }
  330.           -- for a SnmpIPXAddress of length 12:
  331.           --
  332.           -- octets   contents            encoding
  333.           --  1-4     network-number      network-byte order
  334.           --  5-10    physical-address    network-byte order
  335.           -- 11-12    socket-number       network-byte order
  336.           --
  337.           SnmpIPXAddress ::= TEXTUAL-CONVENTION
  338.               DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
  339.               STATUS       current
  340.               DESCRIPTION
  341.                       "Represents an IPX address."
  342.               SYNTAX       OCTET STRING (SIZE (12))
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.           Case, McCloghrie, Rose & Waldbusser                   [Page 5]
  354.  
  355.  
  356.  
  357.  
  358.  
  359.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  360.  
  361.  
  362.           -- for proxy to community-based SNMPv1 (RFC 1157)
  363.  
  364.           rfc1157Proxy   OBJECT IDENTIFIER ::= { snmpProxys 1 }
  365.  
  366.           -- uses SnmpUDPAddress
  367.           rfc1157Domain  OBJECT IDENTIFIER ::= { rfc1157Proxy 1 }
  368.  
  369.           -- the community-based noAuth
  370.           rfc1157noAuth  OBJECT IDENTIFIER ::= { rfc1157Proxy 2 }
  371.  
  372.  
  373.           END
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.           Case, McCloghrie, Rose & Waldbusser                   [Page 6]
  413.  
  414.  
  415.  
  416.  
  417.  
  418.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  419.  
  420.  
  421.           3.  SNMPv2 over UDP
  422.  
  423.           This is the preferred transport mapping.
  424.  
  425.  
  426.           3.1.  Serialization
  427.  
  428.           Each instance of a message is serialized onto a single UDP[2]
  429.           datagram, using the algorithm specified in Section 8.
  430.  
  431.  
  432.           3.2.  Well-known Values
  433.  
  434.           Although the partyTable gives transport addressing information
  435.           for an SNMPv2 party, it is suggested that administrators
  436.           configure their SNMPv2 entities acting in an agent role to
  437.           listen on UDP port 161.  Further, it is suggested that
  438.           notification sinks be configured to listen on UDP port 162.
  439.  
  440.           The partyTable also lists the maximum message size which a
  441.           SNMPv2 party is willing to accept.  This value must be at
  442.           least 484 octets.  Implementation of larger values is
  443.           encouraged whenever possible.
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.           Case, McCloghrie, Rose & Waldbusser                   [Page 7]
  472.  
  473.  
  474.  
  475.  
  476.  
  477.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  478.  
  479.  
  480.           4.  SNMPv2 over OSI
  481.  
  482.           This is an optional transport mapping.
  483.  
  484.  
  485.           4.1.  Serialization
  486.  
  487.           Each instance of a message is serialized onto a single TSDU
  488.           [3,4] for the OSI Connectionless-mode Transport Service
  489.           (CLTS), using the algorithm specified in Section 8.
  490.  
  491.  
  492.           4.2.  Well-known Values
  493.  
  494.           Although the partyTable gives transport addressing information
  495.           for an SNMPv2 party, it is suggested that administrators
  496.           configure their SNMPv2 entities acting in an agent role to
  497.           listen on transport selector "snmp-l" (which consists of six
  498.           ASCII characters), when using a CL-mode network service to
  499.           realize the CLTS.  Further, it is suggested that notification
  500.           sinks be configured to listen on transport selector "snmpt-l"
  501.           (which consists of seven ASCII characters) when using a CL-
  502.           mode network service to realize the CLTS.  Similarly, when
  503.           using a CO-mode network service to realize the CLTS, the
  504.           suggested transport selectors are "snmp-o"  and "snmpt-o", for
  505.           agent and notification sink, respectively.
  506.  
  507.           The partyTable also lists the maximum message size which a
  508.           SNMPv2 party is willing to accept.  This value must be at
  509.           least 484 octets.  Implementation of larger values is
  510.           encouraged whenever possible.
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.           Case, McCloghrie, Rose & Waldbusser                   [Page 8]
  531.  
  532.  
  533.  
  534.  
  535.  
  536.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  537.  
  538.  
  539.           5.  SNMPv2 over DDP
  540.  
  541.           This is an optional transport mapping.
  542.  
  543.  
  544.           5.1.  Serialization
  545.  
  546.           Each instance of a message is serialized onto a single DDP
  547.           datagram [5], using the algorithm specified in Section 8.
  548.  
  549.  
  550.           5.2.  Well-known Values
  551.  
  552.           SNMPv2 messages are sent using DDP protocol type 8.  SNMPv2
  553.           entities acting in an agent role listens on DDP socket number
  554.           8, whilst notification sinks listen on DDP socket number 9.
  555.  
  556.           Although the partyTable gives transport addressing information
  557.           for an SNMPv2 party, administrators must configure their
  558.           SNMPv2 entities acting in an agent role to use NBP type "SNMP
  559.           Agent" (which consists of ten ASCII characters), whilst
  560.           notification sinks must be configured to use NBP type "SNMP
  561.           Trap Handler" (which consists of seventeen ASCII characters).
  562.  
  563.           The NBP name for agents and notification sinks should be
  564.           stable - NBP names should not change any more often than the
  565.           IP address of a typical TCP/IP node.  It is suggested that the
  566.           NBP name be stored in some form of stable storage.
  567.  
  568.           The partyTable also lists the maximum message size which a
  569.           SNMPv2 party is willing to accept.  This value must be at
  570.           least 484 octets.  Implementation of larger values is
  571.           encouraged whenever possible.
  572.  
  573.  
  574.           5.3.  Discussion of AppleTalk Addressing
  575.  
  576.           The AppleTalk protocol suite has certain features not manifest
  577.           in the TCP/IP suite.  AppleTalk's naming strategy and the
  578.           dynamic nature of address assignment can cause problems for
  579.           SNMPv2 entities that wish to manage AppleTalk networks.
  580.           TCP/IP nodes have an associated IP address which distinguishes
  581.           each from the other.  In contrast, AppleTalk nodes generally
  582.           have no such characteristic.  The network-level address, while
  583.           often relatively stable, can change at every reboot (or more
  584.  
  585.  
  586.  
  587.  
  588.  
  589.           Case, McCloghrie, Rose & Waldbusser                   [Page 9]
  590.  
  591.  
  592.  
  593.  
  594.  
  595.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  596.  
  597.  
  598.           frequently).
  599.  
  600.           Thus, when SNMPv2 is mapped over DDP, nodes are identified by
  601.           a "name", rather than by an "address".  Hence, all AppleTalk
  602.           nodes that implement this mapping are required to respond to
  603.           NBP lookups and confirms (e.g., implement the NBP protocol
  604.           stub), which guarantees that a mapping from NBP name to DDP
  605.           address will be possible.
  606.  
  607.           In determining the SNMP identity to register for an SNMPv2
  608.           entity, it is suggested that the SNMP identity be a name which
  609.           is associated with other network services offered by the
  610.           machine.
  611.  
  612.           NBP lookups, which are used to map NBP names into DDP
  613.           addresses, can cause large amounts of network traffic as well
  614.           as consume CPU resources.  It is also the case that the
  615.           ability to perform an NBP lookup is sensitive to certain
  616.           network disruptions (such as zone table inconsistencies) which
  617.           would not prevent direct AppleTalk communications between two
  618.           SNMPv2 entities.
  619.  
  620.           Thus, it is recommended that NBP lookups be used infrequently,
  621.           primarily to create a cache of name-to-address mappings.
  622.           These cached mappings should then be used for any further SNMP
  623.           traffic.  It is recommended that SNMPv2 entities acting in a
  624.           manager role should maintain this cache between reboots.  This
  625.           caching can help minimize network traffic, reduce CPU load on
  626.           the network, and allow for (some amount of) network trouble
  627.           shooting when the basic name-to-address translation mechanism
  628.           is broken.
  629.  
  630.  
  631.           5.3.1.  How to Acquire NBP names
  632.  
  633.           An SNMPv2 entity acting in a manager role may have a pre-
  634.           configured list of names of "known" SNMPv2 entities acting in
  635.           an agent role.  Similarly, an SNMPv2 entity acting in a
  636.           manager role might interact with an operator.  Finally, an
  637.           SNMPv2 entity acting in a manager role might communicate with
  638.           all SNMPv2 entities acting in an agent role in a set of zones
  639.           or networks.
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.           Case, McCloghrie, Rose & Waldbusser                  [Page 10]
  649.  
  650.  
  651.  
  652.  
  653.  
  654.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  655.  
  656.  
  657.           5.3.2.  When to Turn NBP names into DDP addresses
  658.  
  659.           When an SNMPv2 entity uses a cache entry to address an SNMP
  660.           packet, it should attempt to confirm the validity mapping, if
  661.           the mapping hasn't been confirmed within the last T1 seconds.
  662.           This cache entry lifetime, T1, has a minimum, default value of
  663.           60 seconds, and should be configurable.
  664.  
  665.           An SNMPv2 entity acting in a manager role may decide to prime
  666.           its cache of names prior to actually communicating with
  667.           another SNMPv2 entity.  In general, it is expected that such
  668.           an entity may want to keep certain mappings "more current"
  669.           than other mappings, e.g., those nodes which represent the
  670.           network infrastructure (e.g., routers) may be deemed "more
  671.           important".
  672.  
  673.           Note that an SNMPv2 entity acting in a manager role should not
  674.           prime its entire cache upon initialization - rather, it should
  675.           attempt resolutions over an extended period of time (perhaps
  676.           in some pre-determined or configured priority order).  Each of
  677.           these resolutions might, in fact, be a wildcard lookup in a
  678.           given zone.
  679.  
  680.           An SNMPv2 entity acting in an agent role must never prime its
  681.           cache.  Such an entity should do NBP lookups (or confirms)
  682.           only when it needs to send an SNMP trap.  When generating a
  683.           response, such an entity does not need to confirm a cache
  684.           entry.
  685.  
  686.  
  687.           5.3.3.  How to Turn NBP names into DDP addresses
  688.  
  689.           If the only piece of information available is the NBP name,
  690.           then an NBP lookup should be performed to turn that name into
  691.           a DDP address.  However, if there is a piece of stale
  692.           information, it can be used as a hint to perform an NBP
  693.           confirm (which sends a unicast to the network address which is
  694.           presumed to be the target of the name lookup) to see if the
  695.           stale information is, in fact, still valid.
  696.  
  697.           An NBP name to DDP address mapping can also be confirmed
  698.           implicitly using only SNMP transactions.  For example, an
  699.           SNMPv2 entity acting in a manager role issuing a retrieval
  700.           operation could also retrieve the relevant objects from the
  701.           NBP group [6] for the SNMPv2 entity acting in an agent role.
  702.  
  703.  
  704.  
  705.  
  706.  
  707.           Case, McCloghrie, Rose & Waldbusser                  [Page 11]
  708.  
  709.  
  710.  
  711.  
  712.  
  713.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  714.  
  715.  
  716.           This information can then be correlated with the source DDP
  717.           address of the response.
  718.  
  719.  
  720.           5.3.4.  What if NBP is broken
  721.  
  722.           Under some circumstances, there may be connectivity between
  723.           two SNMPv2 entities, but the NBP mapping machinery may be
  724.           broken, e.g.,
  725.  
  726.           o    the NBP FwdReq (forward NBP lookup onto local attached
  727.                network) mechanism might be broken at a router on the
  728.                other entity's network; or,
  729.  
  730.           o    the NBP BrRq (NBP broadcast request) mechanism might be
  731.                broken at a router on the entity's own network; or,
  732.  
  733.           o    NBP might be broken on the other entity's node.
  734.  
  735.           An SNMPv2 entity acting in a manager role which is dedicated
  736.           to AppleTalk management might choose to alleviate some of
  737.           these failures by directly implementing the router portion of
  738.           NBP.  For example, such an entity might already know all the
  739.           zones on the AppleTalk internet and the networks on which each
  740.           zone appears.  Given an NBP lookup which fails, the entity
  741.           could send an NBP FwdReq to the network in which the agent was
  742.           last located.  If that failed, the station could then send an
  743.           NBP LkUp (NBP lookup packet) as a directed (DDP) multicast to
  744.           each network number on that network.  Of the above (single)
  745.           failures, this combined approach will solve the case where
  746.           either the local router's BrRq-to-FwdReq mechanism is broken
  747.           or the remote router's FwdReq-to-LkUp mechanism is broken.
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.           Case, McCloghrie, Rose & Waldbusser                  [Page 12]
  767.  
  768.  
  769.  
  770.  
  771.  
  772.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  773.  
  774.  
  775.           6.  SNMPv2 over IPX
  776.  
  777.           This is an optional transport mapping.
  778.  
  779.  
  780.           6.1.  Serialization
  781.  
  782.           Each instance of a message is serialized onto a single IPX
  783.           datagram [7], using the algorithm specified in Section 8.
  784.  
  785.  
  786.           6.2.  Well-known Values
  787.  
  788.           SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet
  789.           Exchange Packet).
  790.  
  791.           Although the partyTable gives transport addressing information
  792.           for an SNMPv2 party, it is suggested that administrators
  793.           configure their SNMPv2 entities acting in an agent role to
  794.           listen on IPX socket 36879 (900f hexadecimal).  Further, it is
  795.           suggested that notification sinks be configured to listen on
  796.           IPX socket 36880 (9010 hexadecimal)
  797.  
  798.           The partyTable also lists the maximum message size which a
  799.           SNMPv2 party is willing to accept.  This value must be at
  800.           least 546 octets.  Implementation of larger values is
  801.           encouraged whenever possible.
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.           Case, McCloghrie, Rose & Waldbusser                  [Page 13]
  826.  
  827.  
  828.  
  829.  
  830.  
  831.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  832.  
  833.  
  834.           7.  Proxy to SNMPv1
  835.  
  836.           In order to provide proxy to community-based SNMP [8], some
  837.           definitions are necessary for both transport domains and
  838.           authentication protocols.
  839.  
  840.  
  841.           7.1.  Transport Domain: rfc1157Domain
  842.  
  843.           The transport domain, rfc1157Domain, indicates the transport
  844.           mapping for community-based SNMP messages defined in RFC 1157.
  845.           When a party's transport domain (partyTDomain) is
  846.           rfc1157Domain:
  847.  
  848.           (1)  the party's transport address (partyTAddress) shall be 6
  849.                octets long, the initial 4 octets containing the IP-
  850.                address in network-byte order, and the last two octets
  851.                containing the UDP port in network-byte order; and,
  852.  
  853.           (2)  the party's authentication protocol (partyAuthProtocol)
  854.                shall be rfc1157noAuth.
  855.  
  856.           When a proxy relationship identifies a proxy destination party
  857.           which has rfc1157Domain as its transport domain:
  858.  
  859.           (1)  the proxy source party (contextSrcPartyIndex) and proxy
  860.                context (contextProxyContext) components of the proxy
  861.                relationship are irrelevant; and,
  862.  
  863.           (2)  Section 3.1 of [9] specifies the behavior of the proxy
  864.                agent.
  865.  
  866.  
  867.           7.2.  Authentication Algorithm: rfc1157noAuth
  868.  
  869.           A party's authentication protocol (partyAuthProtocol)
  870.           specifies the protocol and mechanism by which the party
  871.           authenticates the integrity and origin of the SNMPv1 or SNMPv2
  872.           PDUs it generates.  When a party's authentication protocol is
  873.           rfc1157noAuth:
  874.  
  875.           (1)  the party's public authentication key (partyAuthPublic),
  876.                clock (partyAuthClock), and lifetime (partyAuthLifetime)
  877.                are irrelevant; and,
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.           Case, McCloghrie, Rose & Waldbusser                  [Page 14]
  885.  
  886.  
  887.  
  888.  
  889.  
  890.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  891.  
  892.  
  893.           (2)  the party's private authentication key
  894.                (partySecretsAuthPrivate) shall be used as the 1157
  895.                community for the proxy destination, and shall be at
  896.                least one octet in length.  (No maximum length is
  897.                specified.)
  898.  
  899.           Note that when setting the party's private authentication key,
  900.           the exclusive-OR semantics specified in [10] still apply.
  901.  
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.           Case, McCloghrie, Rose & Waldbusser                  [Page 15]
  944.  
  945.  
  946.  
  947.  
  948.  
  949.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  950.  
  951.  
  952.           8.  Serialization using the Basic Encoding Rules
  953.  
  954.           When the Basic Encoding Rules [11] are used for serialization:
  955.  
  956.           (1)  When encoding the length field, only the definite form is
  957.                used; use of the indefinite form encoding is prohibited.
  958.                Note that when using the definite-long form, it is
  959.                permissible to use more than the minimum number of length
  960.                octets necessary to encode the length field.
  961.  
  962.           (2)  When encoding the value field, the primitive form shall
  963.                be used for all simple types, i.e., INTEGER, OCTET
  964.                STRING, OBJECT IDENTIFIER, and BIT STRING (either
  965.                IMPLICIT or explicit).  The constructed form of encoding
  966.                shall be used only for structured types, i.e., a SEQUENCE
  967.                or an IMPLICIT SEQUENCE.
  968.  
  969.           (3)  When a BIT STRING is serialized, all named-bits are
  970.                transferred regardless of their truth-value.  Further, if
  971.                the number of named-bits is not an integral multiple of
  972.                eight, then the fewest number of additional zero-valued
  973.                bits are transferred so that an integral multiple of
  974.                eight bits is transferred.
  975.  
  976.           These restrictions apply to all aspects of ASN.1 encoding,
  977.           including the message wrappers, protocol data units, and the
  978.           data objects they contain.
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.           Case, McCloghrie, Rose & Waldbusser                  [Page 16]
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  1009.  
  1010.  
  1011.           8.1.  Usage Example
  1012.  
  1013.           As an example of applying the Basic Encoding Rules, suppose
  1014.           one wanted to encode an instance of the GetBulkRequest-PDU
  1015.           [1]:
  1016.  
  1017.                [5] IMPLICIT SEQUENCE {
  1018.                        request-id      1414684022,
  1019.                        non-repeaters   1,
  1020.                        max-repetitions 2,
  1021.                        variable-bindings {
  1022.                            { name sysUpTime,
  1023.                              value { unspecified NULL } },
  1024.                            { name ipNetToMediaPhysAddress,
  1025.                              value { unspecified NULL } },
  1026.                            { name ipNetToMediaType,
  1027.                              value { unspecified NULL } }
  1028.                        }
  1029.                    }
  1030.  
  1031.           Applying the BER, this would be encoded (in hexadecimal) as:
  1032.  
  1033.           [5] IMPLICIT SEQUENCE          a5 82 00 39
  1034.               INTEGER                    02 04 52 54 5d 76
  1035.               INTEGER                    02 01 01
  1036.               INTEGER                    02 01 02
  1037.               SEQUENCE                   30 2b
  1038.                   SEQUENCE               30 0b
  1039.                       OBJECT IDENTIFIER  06 07 2b 06 01 02 01 01 03
  1040.                       NULL               05 00
  1041.                   SEQUENCE               30 0d
  1042.                       OBJECT IDENTIFIER  06 09 2b 06 01 02 01 04 16 01 02
  1043.                       NULL               05 00
  1044.                   SEQUENCE               30 0d
  1045.                       OBJECT IDENTIFIER  06 09 2b 06 01 02 01 04 16 01 04
  1046.                       NULL               05 00
  1047.  
  1048.           Note that the initial SEQUENCE is not encoded using the
  1049.           minimum number of length octets.  (The first octet of the
  1050.           length, 82, indicates that the length of the content is
  1051.           encoded in the next two octets.)
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.           Case, McCloghrie, Rose & Waldbusser                  [Page 17]
  1062.  
  1063.  
  1064.  
  1065.  
  1066.  
  1067.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  1068.  
  1069.  
  1070.           9.  Acknowledgements
  1071.  
  1072.           The UDP-based mapping is based, in part, on RFC 1157.
  1073.  
  1074.           The OSI-based mapping is based, in part, on RFC 1283.
  1075.  
  1076.           The DDP-based mapping is based, in part, on earlier work by
  1077.           Greg Minshall of Novell, Inc., and Mike Ritter of Apple
  1078.           Computer, Inc.
  1079.  
  1080.           The IPX-based mapping is based, in part, on RFC 1298.
  1081.  
  1082.           The section on proxy to community-based SNMP is based on
  1083.           earlier work that was based in part on a suggestion by
  1084.           Jonathan Biggar of Netlabs, Inc.
  1085.  
  1086.           Finally, the comments of the SNMP version 2 working group are
  1087.           gratefully acknowledged:
  1088.  
  1089.                Beth Adams, Network Management Forum
  1090.                Steve Alexander, INTERACTIVE Systems Corporation
  1091.                David Arneson, Cabletron Systems
  1092.                Toshiya Asaba
  1093.                Fred Baker, ACC
  1094.                Jim Barnes, Xylogics, Inc.
  1095.                Brian Bataille
  1096.                Andy Bierman, SynOptics Communications, Inc.
  1097.                Uri Blumenthal, IBM Corporation
  1098.                Fred Bohle, Interlink
  1099.                Jack Brown
  1100.                Theodore Brunner, Bellcore
  1101.                Stephen F. Bush, GE Information Services
  1102.                Jeffrey D. Case, University of Tennessee, Knoxville
  1103.                John Chang, IBM Corporation
  1104.                Szusin Chen, Sun Microsystems
  1105.                Robert Ching
  1106.                Chris Chiotasso, Ungermann-Bass
  1107.                Bobby A. Clay, NASA/Boeing
  1108.                John Cooke, Chipcom
  1109.                Tracy Cox, Bellcore
  1110.                Juan Cruz, Datability, Inc.
  1111.                David Cullerot, Cabletron Systems
  1112.                Cathy Cunningham, Microcom
  1113.                James R. (Chuck) Davin, Bellcore
  1114.                Michael Davis, Clearpoint
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.           Case, McCloghrie, Rose & Waldbusser                  [Page 18]
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  1127.  
  1128.  
  1129.                Mike Davison, FiberCom
  1130.                Cynthia DellaTorre, MITRE
  1131.                Taso N. Devetzis, Bellcore
  1132.                Manual Diaz, DAVID Systems, Inc.
  1133.                Jon Dreyer, Sun Microsystems
  1134.                David Engel, Optical Data Systems
  1135.                Mike Erlinger, Lexcel
  1136.                Roger Fajman, NIH
  1137.                Daniel Fauvarque, Sun Microsystems
  1138.                Karen Frisa, CMU
  1139.                Shari Galitzer, MITRE
  1140.                Shawn Gallagher, Digital Equipment Corporation
  1141.                Richard Graveman, Bellcore
  1142.                Maria Greene, Xyplex, Inc.
  1143.                Michel Guittet, Apple
  1144.                Robert Gutierrez, NASA
  1145.                Bill Hagerty, Cabletron Systems
  1146.                Gary W. Haney, Martin Marietta Energy Systems
  1147.                Patrick Hanil, Nokia Telecommunications
  1148.                Matt Hecht, SNMP Research, Inc.
  1149.                Edward A. Heiner, Jr., Synernetics Inc.
  1150.                Susan E. Hicks, Martin Marietta Energy Systems
  1151.                Geral Holzhauer, Apple
  1152.                John Hopprich, DAVID Systems, Inc.
  1153.                Jeff Hughes, Hewlett-Packard
  1154.                Robin Iddon, Axon Networks, Inc.
  1155.                David Itusak
  1156.                Kevin M. Jackson, Concord Communications, Inc.
  1157.                Ole J. Jacobsen, Interop Company
  1158.                Ronald Jacoby, Silicon Graphics, Inc.
  1159.                Satish Joshi, SynOptics Communications, Inc.
  1160.                Frank Kastenholz, FTP Software
  1161.                Mark Kepke, Hewlett-Packard
  1162.                Ken Key, SNMP Research, Inc.
  1163.                Zbiginew Kielczewski, Eicon
  1164.                Jongyeoi Kim
  1165.                Andrew Knutsen, The Santa Cruz Operation
  1166.                Michael L. Kornegay, VisiSoft
  1167.                Deirdre C. Kostik, Bellcore
  1168.                Cheryl Krupczak, Georgia Tech
  1169.                Mark S. Lewis, Telebit
  1170.                David Lin
  1171.                David Lindemulder, AT&T/NCR
  1172.                Ben Lisowski, Sprint
  1173.                David Liu, Bell-Northern Research
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179.           Case, McCloghrie, Rose & Waldbusser                  [Page 19]
  1180.  
  1181.  
  1182.  
  1183.  
  1184.  
  1185.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  1186.  
  1187.  
  1188.                John Lunny, The Wollongong Group
  1189.                Robert C. Lushbaugh Martin, Marietta Energy Systems
  1190.                Michael Luufer, BBN
  1191.                Carl Madison, Star-Tek, Inc.
  1192.                Keith McCloghrie, Hughes LAN Systems
  1193.                Evan McGinnis, 3Com Corporation
  1194.                Bill McKenzie, IBM Corporation
  1195.                Donna McMaster, SynOptics Communications, Inc.
  1196.                John Medicke, IBM Corporation
  1197.                Doug Miller, Telebit
  1198.                Dave Minnich, FiberCom
  1199.                Mohammad Mirhakkak, MITRE
  1200.                Rohit Mital, Protools
  1201.                George Mouradian, AT&T Bell Labs
  1202.                Patrick Mullaney, Cabletron Systems
  1203.                Dan Myers, 3Com Corporation
  1204.                Rina Nathaniel, Rad Network Devices Ltd.
  1205.                Hien V. Nguyen, Sprint
  1206.                Mo Nikain
  1207.                Tom Nisbet
  1208.                William B. Norton, MERIT
  1209.                Steve Onishi, Wellfleet Communications, Inc.
  1210.                David T. Perkins, SynOptics Communications, Inc.
  1211.                Carl Powell, BBN
  1212.                Ilan Raab, SynOptics Communications, Inc.
  1213.                Richard Ramons, AT&T
  1214.                Venkat D. Rangan, Metric Network Systems, Inc.
  1215.                Louise Reingold, Sprint
  1216.                Sam Roberts, Farallon Computing, Inc.
  1217.                Kary Robertson, Concord Communications, Inc.
  1218.                Dan Romascanu, Lannet Data Communications Ltd.
  1219.                Marshall T. Rose, Dover Beach Consulting, Inc.
  1220.                Shawn A. Routhier, Epilogue Technology Corporation
  1221.                Chris Rozman
  1222.                Asaf Rubissa, Fibronics
  1223.                Jon Saperia, Digital Equipment Corporation
  1224.                Michael Sapich
  1225.                Mike Scanlon, Interlan
  1226.                Sam Schaen, MITRE
  1227.                John Seligson, Ultra Network Technologies
  1228.                Paul A. Serice, Corporation for Open Systems
  1229.                Chris Shaw, Banyan Systems
  1230.                Timon Sloane
  1231.                Robert Snyder, Cisco Systems
  1232.                Joo Young Song
  1233.  
  1234.  
  1235.  
  1236.  
  1237.  
  1238.           Case, McCloghrie, Rose & Waldbusser                  [Page 20]
  1239.  
  1240.  
  1241.  
  1242.  
  1243.  
  1244.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  1245.  
  1246.  
  1247.                Roy Spitier, Sprint
  1248.                Einar Stefferud, Network Management Associates
  1249.                John Stephens, Cayman Systems, Inc.
  1250.                Robert L. Stewart, Xyplex, Inc. (chair)
  1251.                Kaj Tesink, Bellcore
  1252.                Dean Throop, Data General
  1253.                Ahmet Tuncay, France Telecom-CNET
  1254.                Maurice Turcotte, Racal Datacom
  1255.                Warren Vik, INTERACTIVE Systems Corporation
  1256.                Yannis Viniotis
  1257.                Steven L. Waldbusser, Carnegie Mellon Universitty
  1258.                Timothy M. Walden, ACC
  1259.                Alice Wang, Sun Microsystems
  1260.                James Watt, Newbridge
  1261.                Luanne Waul, Timeplex
  1262.                Donald E. Westlake III, Digital Equipment Corporation
  1263.                Gerry White
  1264.                Bert Wijnen, IBM Corporation
  1265.                Peter Wilson, 3Com Corporation
  1266.                Steven Wong, Digital Equipment Corporation
  1267.                Randy Worzella, IBM Corporation
  1268.                Daniel Woycke, MITRE
  1269.                Honda Wu
  1270.                Jeff Yarnell, Protools
  1271.                Chris Young, Cabletron
  1272.                Kiho Yum, 3Com Corporation
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290.  
  1291.  
  1292.  
  1293.  
  1294.  
  1295.  
  1296.  
  1297.           Case, McCloghrie, Rose & Waldbusser                  [Page 21]
  1298.  
  1299.  
  1300.  
  1301.  
  1302.  
  1303.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  1304.  
  1305.  
  1306.           10.  References
  1307.  
  1308.           [1]  Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
  1309.                "Protocol Operations for version 2 of the Simple Network
  1310.                Management Protocol (SNMPv2)", RFC 1448, SNMP Research,
  1311.                Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,
  1312.                Carnegie Mellon University, April 1993.
  1313.  
  1314.           [2]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
  1315.                USC/Information Sciences Institute, August 1980.
  1316.  
  1317.           [3]  Information processing systems - Open Systems
  1318.                Interconnection - Transport Service Definition,
  1319.                International Organization for Standardization.
  1320.                International Standard 8072, (June, 1986).
  1321.  
  1322.           [4]  Information processing systems - Open Systems
  1323.                Interconnection - Transport Service Definition - Addendum
  1324.                1: Connectionless-mode Transmission, International
  1325.                Organization for Standardization.  International Standard
  1326.                8072/AD 1, (December, 1986).
  1327.  
  1328.           [5]  G. Sidhu, R. Andrews, A. Oppenheimer, Inside AppleTalk
  1329.                (second edition).  Addison-Wesley, 1990.
  1330.  
  1331.           [6]  Waldbusser, S., "AppleTalk Management Information Base",
  1332.                RFC 1243, Carnegie Mellon University, July 1991.
  1333.  
  1334.           [7]  Network System Technical Interface Overview.  Novell,
  1335.                Inc, (June, 1989).
  1336.  
  1337.           [8]  Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple
  1338.                Network Management Protocol", STD 15, RFC 1157, SNMP
  1339.                Research, Performance Systems International, MIT
  1340.                Laboratory for Computer Science, May 1990.
  1341.  
  1342.           [9]  Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
  1343.                "Coexistence between version 1 and version 2 of the
  1344.                Internet-standard Network Management Framework", RFC
  1345.                1452, SNMP Research, Inc., Hughes LAN Systems, Dover
  1346.                Beach Consulting, Inc., Carnegie Mellon University, April
  1347.                1993.
  1348.  
  1349.           [10] McCloghrie, K., and Galvin, J., "Party MIB for version 2
  1350.                of the Simple Network Management Protocol (SNMPv2)", RFC
  1351.  
  1352.  
  1353.  
  1354.  
  1355.  
  1356.           Case, McCloghrie, Rose & Waldbusser                  [Page 22]
  1357.  
  1358.  
  1359.  
  1360.  
  1361.  
  1362.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  1363.  
  1364.  
  1365.                1447, Hughes LAN Systems, Trusted Information Systems,
  1366.                April 1993.
  1367.  
  1368.           [11] Information processing systems - Open Systems
  1369.                Interconnection - Specification of Basic Encoding Rules
  1370.                for Abstract Syntax Notation One (ASN.1), International
  1371.                Organization for Standardization.  International Standard
  1372.                8825, (December, 1987).
  1373.  
  1374.  
  1375.  
  1376.  
  1377.  
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391.  
  1392.  
  1393.  
  1394.  
  1395.  
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402.  
  1403.  
  1404.  
  1405.  
  1406.  
  1407.  
  1408.  
  1409.  
  1410.  
  1411.  
  1412.  
  1413.  
  1414.  
  1415.           Case, McCloghrie, Rose & Waldbusser                  [Page 23]
  1416.  
  1417.  
  1418.  
  1419.  
  1420.  
  1421.           RFC 1449        Transport Mappings for SNMPv2       April 1993
  1422.  
  1423.  
  1424.           11.  Security Considerations
  1425.  
  1426.           Security issues are not discussed in this memo.
  1427.  
  1428.  
  1429.           12.  Authors' Addresses
  1430.  
  1431.                Jeffrey D. Case
  1432.                SNMP Research, Inc.
  1433.                3001 Kimberlin Heights Rd.
  1434.                Knoxville, TN  37920-9716
  1435.                US
  1436.  
  1437.                Phone: +1 615 573 1434
  1438.                Email: case@snmp.com
  1439.  
  1440.  
  1441.                Keith McCloghrie
  1442.                Hughes LAN Systems
  1443.                1225 Charleston Road
  1444.                Mountain View, CA  94043
  1445.                US
  1446.  
  1447.                Phone: +1 415 966 7934
  1448.                Email: kzm@hls.com
  1449.  
  1450.  
  1451.                Marshall T. Rose
  1452.                Dover Beach Consulting, Inc.
  1453.                420 Whisman Court
  1454.                Mountain View, CA  94043-2186
  1455.                US
  1456.  
  1457.                Phone: +1 415 968 1052
  1458.                Email: mrose@dbc.mtview.ca.us
  1459.  
  1460.                Steven Waldbusser
  1461.                Carnegie Mellon University
  1462.                4910 Forbes Ave
  1463.                Pittsburgh, PA  15213
  1464.                US
  1465.  
  1466.                Phone: +1 412 268 6628
  1467.                Email: waldbusser@cmu.edu
  1468.  
  1469.  
  1470.  
  1471.  
  1472.  
  1473.  
  1474.           Case, McCloghrie, Rose & Waldbusser                  [Page 24]
  1475.  
  1476.