rfc-3417

Transport Mappings for the Simple Network Management Protocol (SNMP)

R. Presuhn (Editor)
date2002-12 streamIETF areaops wgsnmpv3 statusINTERNET STANDARD pages19 canonicalhttps://www.rfc-editor.org/rfc/rfc3417 doi10.17487/RFC3417
This document defines the transport of Simple Network Management Protocol (SNMP) messages over various protocols. This document obsoletes RFC 1906. [STANDARDS-TRACK]

obsoletes

updated by

also

Extracted elements (30)

design-rationale §5.3

NBP lookups should be used infrequently and results cached; SNMP entities supporting command generators should maintain the cache between reboots to minimize network traffic, reduce CPU load, and enable troubleshooting when basic name-to-address translation is broken.

snmp

design-rationale §5.3

SNMP over DDP uses NBP names rather than DDP addresses to identify nodes because AppleTalk network-level addresses are dynamically assigned and can change at every reboot, unlike the relatively stable IP addresses used in TCP/IP.

snmp

design-rationale §7

The rfc1157Domain transport domain is marked deprecated but retained to support proxy to SNMPv1 (RFC 1157/RFC 2576); it is not intended for new deployments.

snmp

interoperability-note §5.3.4

An SNMP entity dedicated to AppleTalk management may implement the router portion of NBP directly to work around broken NBP FwdReq or BrRq mechanisms on remote or local routers.

snmp

interoperability-note §5.3.2

The NBP cache entry lifetime T1 has a minimum default value of 60 seconds and should be configurable. Cache entries should be confirmed if not validated within T1 seconds before use.

snmp

interoperability-note §1

This document does not define an IPv6 transport mapping; at time of publication, work was in progress in RFC 3419 to define IPv6 textual conventions for transport addresses.

snmp, ip

normative-requirement §5.2 MUST

Administrators must configure SNMP entities supporting command responder applications to use NBP type 'SNMP Agent' (ten ASCII characters), and notification receiver applications must use NBP type 'SNMP Trap Handler' (seventeen ASCII characters).

snmp

normative-requirement §5.3 REQUIRED

All AppleTalk nodes implementing the DDP mapping are required to respond to NBP lookups and confirms (i.e., implement the NBP protocol stub), guaranteeing that a mapping from NBP name to DDP address is possible.

snmp

normative-requirement §5.3.2 MUST NOT

An SNMP entity supporting command responder applications must never prime its NBP name-to-address cache; when generating a response, it does not need to confirm a cache entry.

snmp

normative-requirement §8 MUST

BER serialization must use only the definite form for length encoding; the indefinite form is prohibited. Primitive form must be used for simple types (INTEGER, OCTET STRING, OBJECT IDENTIFIER); constructed form only for SEQUENCE types.

snmp

normative-requirement §1 MUST

Systems implementing IPv4 MUST implement the mapping onto UDP over IPv4. Systems supporting other mappings SHOULD also provide for access via the UDP over IPv4 mapping to maximize interoperability.

snmp

normative-requirement §6.2 MUST

When an SNMP entity uses the IPX transport mapping, it must be capable of accepting messages that are at least 546 octets in size.

snmp

normative-requirement §4.2 MUST

When an SNMP entity uses the OSI transport mapping, it must be capable of accepting messages that are at least 484 octets in size. Implementation of larger values is encouraged.

snmp

normative-requirement §3.2 MUST

When an SNMP entity uses the UDP over IPv4 transport mapping, it must be capable of accepting messages up to and including 484 octets in size. It is recommended that implementations accept messages up to 1472 octets.

snmp

normative-requirement §8 MUST

When encoding an object with BITS syntax, the value is encoded as an OCTET STRING placing named bits from first to last into bits 8-1 of successive octets; remaining bits of the final octet are set to zero on generation and ignored on receipt.

snmp

protocol-element §5.2

For SNMP over DDP, SNMP messages use DDP protocol type 8; command responders listen on DDP socket 8 and notification receivers on DDP socket 9.

snmp

protocol-element §6.2

For SNMP over IPX, command responders listen on IPX socket 36879 (0x900F) and notification receivers on socket 36880 (0x9010).

snmp

protocol-element §2

rfc1157Domain (OID rfc1157Proxy 1, status deprecated) is the transport domain for SNMPv1 over UDP over IPv4, defined to support proxy to SNMPv1 as defined in RFC 2576.

snmp

protocol-element §2

snmpCLNSDomain (OID snmpDomains 2) and snmpCONSDomain (OID snmpDomains 3) are optional transport domains for SNMP over OSI connectionless and connection-oriented network services, respectively. Both use SnmpOSIAddress.

snmp

protocol-element §2

snmpDDPDomain (OID snmpDomains 4) is the optional transport domain for SNMP over AppleTalk DDP; nodes are identified by NBP names (SnmpNBPAddress) rather than network addresses due to dynamic address assignment.

snmp

protocol-element §2

snmpIPXDomain (OID snmpDomains 5) is the optional transport domain for SNMP over Novell IPX; uses SnmpIPXAddress. SNMP messages are sent using IPX packet type 4 (Packet Exchange Protocol).

snmp

protocol-element §2

snmpUDPDomain (OID snmpDomains 1) is the transport domain for SNMP over UDP over IPv4; the preferred transport mapping. The corresponding transport address type is SnmpUDPAddress.

snmp, udp, ip

protocol-element §3.2

Well-known port assignments for UDP/IPv4: command responder applications listen on UDP port 161; notification receiver applications listen on UDP port 162.

snmp, udp

protocol-element §4.2

Well-known transport selectors for SNMP over OSI: command responders use 'snmp-l' (CL-mode) or 'snmp-o' (CO-mode); notification receivers use 'snmpt-l' or 'snmpt-o' respectively.

snmp

registry §11

The SNMPv2-TM MIB module (MODULE-IDENTITY snmpv2tm) requires allocation of a single object identifier in the snmpModules subtree defined in SNMPv2-SMI; IANA has allocated this OID as snmpModules 19.

snmp, registry

security-consideration §12

SNMPv1 by itself is not a secure environment; even on a network secured with IPSec, there is no control over which principals on that network may GET or SET MIB objects. Implementors are recommended to use the SNMPv3 User-based Security Model (RFC 3414) and the View-based Access Control Model (RFC 3415).

snmp, security

wire-format §2

SnmpIPXAddress is a 12-octet OCTET STRING encoding an IPX address: octets 1-4 network-number, octets 5-10 physical address, octets 11-12 socket-number, all in network-byte order. Display hint: '4x.1x:1x:1x:1x:1x:1x.2d'.

snmp

wire-format §2

SnmpNBPAddress is a variable-length OCTET STRING (SIZE 3..99) encoding an AppleTalk NBP name with three length-prefixed fields: object (up to 32 octets), type (up to 32 octets), and zone (up to 32 octets). Strings are case-insensitive and may contain any octet except 0xFF.

snmp

wire-format §2

SnmpOSIAddress is a variable-length OCTET STRING (SIZE 1 or 4..85) encoding an OSI transport address: 1 octet NSAP length n (0 or 3-20), followed by n octets of NSAP, followed by up to 64 octets of TSEL.

snmp

wire-format §2

SnmpUDPAddress is a 6-octet OCTET STRING encoding a UDP over IPv4 transport address: octets 1-4 are the IPv4 address in network-byte order, octets 5-6 are the UDP port in network-byte order. Display hint: '1d.1d.1d.1d/2d'.

snmp, udp, ip