SNMP Research International, Inc.

Secure Your Network


About SNMP Research

IPv6 and SNMP

Internet Protocol version 6 (IPv6), the successor of IPv4, provides a much larger address space and greater flexibility when assigning addresses. SNMP Research products can support IPv6 on systems which support IPv6 and can use both IPv4 and IPv6 addresses.


In the figure below, the icon on the left side, marked Manager, represents a network manager application installed on a server. BRASS™ is an SNMP Research manager product.

The icon on the right side, marked Agents, represents the multiple devices in your network with a SNMP agent installed. EMANATE® and CIAgent® are SNMP Research agent products.

The communication link between the network manager application and network devices is the Internet Protocol IPv6. We recognize two forms of communication: talk over and talk about.

Talk over means the SNMP agent can receive and respond to SNMP messages that are sent to it on an IPv6 transport. Talk over also means that the SNMP agent can transmit notifications to IPv6 addresses. Examples showing how to configure an IPv6 address and how to send an SNMP Get request to an IPv6 destination are provided in a separate section below.

Talk about means that information about IPv6 interfaces and network activity is exposed by the agent in SNMP MIB objects. Details about some of these MIB objects are provided in a separate section below, including a list of MIB documents and RFCs in which they are defined.

IPv6 Talk Over and Talk About
IPv6 communication between an SNMP manager and and an SNMP agent.

IPv6 Notation in SNMP Research Products

On an IPv6-enabled network, each machine may have multicast, anycast, and unicast addresses. IPv6 is most secure when used in a unicast (one host to another host) situation. Multicast and anycast use one-to-many connections and are not recommended in a SNMPv3 environment.

IPv6 addresses are 128-bits in length and are written as eight groups of four hexadecimal digits. The loopback interface address (or localhost) for IPv4 is This same address in IPv6 notation would be written as 0:0:0:0:0:0:0:1 (or more simply, ::1).

IPv4 addresses can be mapped to IPv6 addresses using several methods. If a server has an IPv4 address of, then the IPv4-mapped IPv6 address would be ::CO93:8E59. Other valid IPv4-mapped IPv6 addresses are:

0000:0000:0000:0000:0000:0000:C093:8E50 ::C093:8E50 0000:0000:0000:0000:0000:0000: ::

The same machine might have a link-local address of fe80::203:47ff:feb4:c30. Link-local IPv6 addresses, indicated by the fe80: prefix, are only valid on the immediate network link to which that host interface is connected.

Port numbers are added to IPv6 addresses by enclosing the IP address in square brackets then a colon (:) followed by the port number. Because square brackets can be interpreted as regular expressions, the IP address and port number should be enclosed in double quotes (").


Specific requirements for IPv6 addresses may vary depending upon configuration. Please check with a system or network administrator for details.

IPv6 Notation in DR‑Web Manager

DR‑Web™ Manager is an SNMP Research product built on BRASS™ that enables any Web browser to access SNMP-based management information within any available SNMP agent. Simply point the browser at DR‑Web Manager, and it will retrieve the requested information from the SNMP agents.

To specify an IPv6 address in a URL, a semicolon (`;') must be used instead of a colon (`:'). For example, the IPv6 address fe89::203:baff:fe0f:78ad is represented as follows:


With DR‑Web Manager, it is also possible to create web pages that retrieve and display customized sets of management data. These web pages contain special tags called "mibobj" tags that indicate where live data from an SNMP agent should be placed and where to get it. For mibobj tags, a "normal" IPv6 address with colons can be used, but brackets (`[' and `]') may not be used because brackets are special in HTML. An example mibobj tag with an IPv6 address is as follows:

<mibobj addr="fe89::203:baff:fe0f:78ad"; port="161'; ... </mibobj>

IPv6 Talk-Over

All SNMP Research agents, including EMANATE®, CIAgent®, and others support IPv6 for communication of SNMP management requests. The agent can be directed to listen for SNMP messages on:

The default behavior for the agent is to bind to UDP port 161 and listen for SNMP messages on both IPv4 and IPv6 addresses. There are two different controls that can modify the default behavior. First, there is a command-line argument called -bind_ip_proto. Second, the agent's configuration file snmpd.cnf recognizes an entry type called TransportStack.

The following example shows how the IPv6 address fe80::a00:20ff:fec0:5b62 is configured in snmpd.cnf. The agent will check the source address of an incoming SNMP Get or Set request to make sure that the message is received from a manager sending from an authorized computer system.

usmUserEntry localSnmpID ipv6V3NoAuthNoPrivUser usmNoAuthProtocol \ usmNoPrivProtocol nonVolatile whereValidRequestsOriginate - - vacmAccessEntry ipv6V3NoAuthNoPrivGroup - usm noAuthNoPriv exact \ All All - nonVolatile vacmSecurityToGroupEntry usm ipv6V3NoAuthNoPrivUser \ ipv6V3NoAuthNoPrivGroupnonVolatile vacmViewTreeFamilyEntry All iso - included nonVolatile snmpTargetAddrEntry ipv6_test transportDomainUdpIpv6 \ [fe80::a00:20ff:fec0:5b62]:0 0 0 whereValidRequestsOriginate none \ nonVolatile [ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff]:0 2048

The following example shows how to send an SNMP Get request to an IPv6 destination.

% ./getone -v3 -ipv6 fe80::a00:20ff:feff:d674 ipv6V3NoAuthNoPrivUser sysDescr.0 Enter Authentication password : sysDescr.0 = SunOS release:5.8 version:Generic_108528-07 machine:sun4u

IPv6 Talk-About

The implementation of MIB-II supports the following list of RFCs, which define MIB objects capable of representing either IPv4 or IPv6 information:

In previous versions of MIB-II, MIB table definitions were based on the assumption that IP addresses are always 32 bits (4 bytes), which is no longer true. In RFC2578, an IpAddress is defined as follows:


In RFC4001, an InetAddress is defined like this:


An InetAddress is always used in conjunction with another object that is an InetAddressType, defined as follows:

InetAddressType ::= TEXTUAL-CONVENTION STATUS current SYNTAX INTEGER { unknown(0), ipv4(1), ipv6(2), ipv4z(3), ipv6z(4), dns(16) }

As an example, the previous version of MIB-II defined a table called the ipNetToMediaTable, which is indexed with an object of type IpAddress called ipNetToMediaNetAddress. Here is the definition of an entry in this table from RFC4293 (originally, RFC1213):

ipNetToMediaEntry OBJECT-TYPE SYNTAX IpNetToMediaEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "Each entry contains one IpAddress to `physical' address equivalence." INDEX { ipNetToMediaIfIndex, ipNetToMediaNetAddress } ::= { ipNetToMediaTable 1 }

The latest version of MIB-II replaces the ipNetToMediaTable with an IP version-neutral table called the ipNetToPhysicalEntry. This table is indexed not with an IpAddress, but with a pair of objects that follows the new conventions. The second index, ipNetToPhysicalNetAddressType is an InetAddressType. The third index, ipNetToPhysicalNetAddress is an InetAddress. Here is the definition of an entry in this table from RFC4293:

ipNetToPhysicalEntry OBJECT-TYPE SYNTAX IpNetToPhysicalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one IP address to `physical' address equivalence." INDEX { ipNetToPhysicalIfIndex, ipNetToPhysicalNetAddressType, ipNetToPhysicalNetAddress } ::= { ipNetToPhysicalTable 1 }

The following example shows a manager (the BRASS™ command-line utility getmany) retrieving the same information out of the two different MIB tables mentioned above, both of which are implemented in agents with support enabled for IPv6 talk about.

Note: to avoid confusion with IPv6 talk over, the destination address used in this example is the IPv4 loopback address,, which is usually referred to as localhost. Also, this request is not being sent on behalf of the SNMPv3 user named ``ipv6V3NoAuthNoPrivUser.'' Instead, the IPv6 information is carried in an SNMPv2c message containing the well-known public community string. In a secure environment, the agent should probably reject these example queries.

% getmany -v2c public ipNetToMediaType ipNetToMediaType. = dynamic(3) ipNetToMediaType. = dynamic(3) ipNetToMediaType. = dynamic(3) ipNetToMediaType. = dynamic(3) ipNetToMediaType. = dynamic(3) ipNetToMediaType. = dynamic(3) ipNetToMediaType. = dynamic(3) ipNetToMediaType. = dynamic(3) ipNetToMediaType. = dynamic(3) ipNetToMediaType. = dynamic(3) % % getmany -v2c public ipNetToPhysicalType ipNetToPhysicalType. = dynamic(3) ipNetToPhysicalType. = dynamic(3) ipNetToPhysicalType. = dynamic(3) ipNetToPhysicalType. = dynamic(3) ipNetToPhysicalType. = dynamic(3) ipNetToPhysicalType. = dynamic(3) ipNetToPhysicalType. = dynamic(3) ipNetToPhysicalType. = dynamic(3) ipNetToPhysicalType. = dynamic(3) ipNetToPhysicalType. = dynamic(3) ipNetToPhysicalType. = dynamic(3) %

The first execution of getmany retrieves all instances of the ipNetToMediaType object, which is in the ipNetToMediaTable. The first number in the index ('2') refers to the interface number (ipNetToMediaIfIndex). Notice that the remaining numbers in the index form an IPv4 address (ipNetToMediaNetAddress), which always has a length of four so the length is not needed.

The second execution of getmany retrieves all instances of the ipNetToPhysicalType object, which is in the ipNetToPhysicalTable. The first number in the index ('1' or '2') refers to the interface number (ipNetToPhysicalIfIndex). The second number in the index refers to network address type (ipNetToPhysicalNetAddressType), which is '1' for IPv4 and '4' for an autoconfigured IPv6 address. The third number in the index ('4' or '16') is the length of the address that follows. The remaining numbers in the index form the IPv4 or IPv6 address (ipNetToPhysicalNetAddress).

The purpose of this demonstration is twofold:

  1. It shows that the same information for IPv4 and RFC1213 MIB-II (first getmany) is also represented as new MIB-II objects defined by the new MIB-II RFCs (second getmany).
  2. It shows that the new MIB-II tables (second getmany) also contain information about IPv6. The instance of ipNetToPhysicalType that has an index of ``'' pertains to an IPv6 address.

Other MIB-II tables defined in RFC1213 are replaced in the same way as ipNetToMediaTable.

Sales Inquiries

For more information, please call +1 865 579-3311, or send email to You can also fill out a Sales Query and one of our sales people will respond to your request quickly.

Licensing terms are available from

1. The external links provided on this page are intended for reference and are not necessarily endorsed by SNMP Research International.