SNMP - The Simple Network Management Protocol

MIB Tables

• Table Indexes
• Table Examples - ifTable
• Table Examples - ipAddrTable
• Table Examples - ipNetToMediaTable
• Updated IP Tables

Table Indexes

We typically think of a table as a data structure that contains rows and columns, though it might also be three-dimensional, or more (or even one-dimensional). Let's first think about a simplified example. Say we have a six-port Ethernet switch. For each port, we have a number of objects defined: frames in, frames out, port name (e.g. "third from left"), port status ("up" or "down"), and port number. We could envision a table of this information looking like this:

Figure 18: Port Table

Using syntax types that you've already seen, how would you define the syntax of each of these object types? I'd suggest an INTEGER for the Port Number, a DisplayString for the Port Name, an INTEGER for the Status, where 0=down and 1=up, and Counter32 (or perhaps Counter64) for each of the statistics. Everything but the Port Name would be read-only, but the Port Name could be read/write. I might want to name the ports according to the room or floor that it serves, for example. We'd also need a way to refer to a particular port when we want to access information on the table. Obviously, the easiest way to refer to a port is by its number. The Port Number would then be defined as the Table Index. So, if we want the number of inbound frames for port whose number is 3, we'd request the value for index=3.

In the next section, where we look at some real examples, you'll see how you do that, but first I'm going to complicate this example. Suppose, for each port, instead of the total inbound and the total outbound frames, I wish to keep a table of statistics of inbound and outbound frames for each MAC address that is connected to that port (a port on a switch might be connected to a small LAN and not just one station). Now, I've added a dimension to the table. It's as if I replaced the Frames In and Frames Out columns with one column such that the column entries are tables themselves. Let's call the column "Port Address Traffic Table", as depicted in Figure 19.

Figure 19: Three-Dimensional Port Table

The smaller table on the right of Figure 19 depicts the table for Port 1. Port 1 has three MAC addresses associated with it. In order to refer to the statistics for the MAC addressAA:BB:CC:DD:EE:FF, we need another index. We don't know how many MAC addresses might be on any one port - it is not a physical characteristic - and they might come and go, depending upon who is active on the LAN that is connected to that port. Therefore, my index can't be as simple as the port number. Rather, a reasonable index is the MAC address. Then, if I want the statistics for Port 1, AA:BB:CC:DD:EE:FF, I can refer to them by those two indexes. But there is a difficulty! Not only don't I know how many MAC addresses there are on Port 1 - I don't know what they are! We will see how we deal with that problem when we look at the SNMP messages.

Another way to think of multiple indexes, rather than envisioning a three-dimensional (or more) table, is that the indexes define how to sort the rows. Each index provides a finer resolution to sort the rows, so that we could actually think of our table of tables above as a two-dimensional table, as shown in Figure 19a.

Figure 19a: Two-Index Port Table

I didn't fill in the whole table, but you can see that for each port I might have multiple rows, one for each MAC address on that port. So, after sorting the rows according to port, the rows are sorted again according to MAC address, in lexicographic order. The two indexes would define a particular row. In reality, the managed device does not maintain duplicate information (such as Port 1 up, Port 1 up), but it is easier to display a table in two dimensions, and thus a multiple-indexed table would be displayed as a two-dimensional table.

Now that you have an idea about how to index tables, let's look at some real examples.

Table Examples - ifTable

We're going to look at three tables, starting with a relatively simple two-dimensional table. It is relatively simple because,like my first fictitious example above, the index is integral and the number of rows is clearly defined for us. The second example will be a two-dimensional table, but the index will not be integral, and the third example will be a three-dimensional table (i.e., a table with two indexes).

To look at the first example, once again, I want to import the latest version of one of the groups - the Interfaces group. Do you still have your MIB browser open? (No? Did I say you could close it?!) I won't take you through the iterations I went through to get this to work. (I've already pointed out certain "features" that this program has.) But, the latest MIB for the Interfaces group, called the IF-MIB (your browswer shows this in the available MIBs, but it is not really there) has a dependency on what is called the IANAifType-MIB. This is not an RFC, but it is a MIB maintained at the IANA (Internet Assigned Numbers Authority) website. This MIB contains a current list of integers (as of February 9, 2009 there were 250 !) that are used to indicate types of network interfaces.

Would you believe that with 249 other choices it might be "none of the above" (value=1)?! That's because I didn't find the "yogurt cups and a string" network interface among them. They also are missing one of the all-time favorites, the Avian Carriers. (If you don't know what that is, it is worth taking out a few minutes when you are bored and looking at that RFC.) In any event, to import the IANAifType-MIB, click on the URL button and enter the following in the space: http://www.iana.org/assignments/ianaiftype-mib and click "OK". That works without a hitch; go ahead and load it, even though doesn't add anything to the tree. (My "experience" showed that it needs to be loaded for other things to work.)

Now import the IF-MIB, which is contained in RFC 2863, but do it by clicking on the URL button and entering the following URL:
http://www.simpleweb.org/ietf/mibs/modules/IETF/txt/IF-MIB; click "OK". (I have not been able to figure out why importing from the IETF resulted in an unloadable MIB. By importing the text, at least it can be loaded, even though it still complains of errors. This software does contain some challenging "features".) Now, load the IF-MIB. If you've been following along, the left side of your browswer should look as shown in Figure 20. (If you have difficulty, drop me a note from the RAD University home page using the Contact the Dean box, and I'll try to assist you.)

Figure 20: After Loading the IF-MIB

Return to the tree view, as in Figure 16 in the previous chapter. But, this time, open the Interfaces group (click on the + sign). Your browser should look like what is shown in Figure 21.

Figure 21: Two Nodes in the Interfaces Group

You can see two nodes in the Interfaces group. One is a scalar (ifNumber) and one is a table. ifNumber is defined as "The number of network interfaces (regardless of their current state) present on this system." You should know how to find this definition (either in the tiny font in the little frame on the bottom, or switching to the MIB view in the IF-MIB and scrolling until you find it). So, since the ifTable will contain information about all the interfaces on the managed device, to see how many rows there are in the ifTable we could first find out the value of ifNumber.

The object ifNumber is the first object under the node interfaces, which is the second group under the node mib-2. Refresh your memory by looking back at the Management Information Tree, if you need, to answer the following question: What is the OID (object ID) of ifNumber? Aside from my answer (hover your mouse over the question), you can see it on the upper right of the browser frame, but, remember, the appended 0 represents the single instance of this scalar object.

Now, expand the ifTable object. You get only one node - the ifEntry, which represents the row definition of a table. When you expand on ifEntry, you will see the objects that define the columns. I think it is worth taking out a bit of time to depict this in several ways, to be sure that the table structure is clear. Once you understand one table well, it is pretty easy to understand any of them. If I expand upon the Management Information Tree by adding the object nodes of the Interfaces group, it would look like this:

Figure 22: Interfaces Group in the MIB Tree

Remember, for each one of those objects under the ifEntry there are as many instances as the value of ifNumber, so that ifNumber is equal to 27, there are 27 instances of ifIndex (which have the integral values 1-27), 27 instances of ifDescr, 27 instances of ifType, etc. These instances do not show up on the tree - the tree is a logical representation of the data structure. The instances will be identified (indexed) according to the index value, so, in this case, since the index is integral, the instances will be .1, .2, .... .27. Let's see how this information would be shown in a table. I used our MIB browswer to request the ifTable (you'll see how send SNMP requests in the chapter on SNMP messages) from an Ethernet switch and the results (partially) appear in Figure 23.

Figure 23: Interfaces Table for an Ethernet Switch

This particular switch has 94 interfaces, so you can't see all the rows - just the first 24. You also can't see all of the columns, even if you scroll your web browser window to the right. But you can see enough to understand how this works. The first column - for the convenience of the user - shows the instance identifier. This is the index value for each row, but there is no such column defined in the table. It is the BlackOwl software that added this column to its display (and other management software might have a different format to displaying the information). The table index is defined in the row definition, ifEntry, and in this case it is ifIndex. That is why the index value and the ifIndex value are identical, except that there is a dot before the index value (as this is appended to the OID, just as .0 is appended to the OID for the single instance of a scalar object). Following the column with the instance values are all the columns actually defined under ifEntry.

Try to figure this out yourself: What is the OID (object ID) of the ifSpeed of the third interface?

Lastly, for this table, let's see how this table is defined in the MIB itself, which should now make sense. Switch to the MIB view in your browser and select IF-MIB from your Available MIBs frame. On the right-hand side, you should show the Text view, and scroll down until you see the beginning of the ifTable, as shown in Figure 24.

Figure 24: ifTable Definition

You can see in the description of the ifTable that the number of entries (=rows) is equal to the value of ifNumber, as I explained before. We also see the the ifTable is the second object under the Interfaces group, as we saw in the expanded MIB tree. And, as we saw in that tree, the ifEntry is the first (and only) object under the ifTable node. In the definition of the ifEntry we see the table index defined, using an INDEX statement. Then, as a continuation of the ifEntry definition, you see all the column headers (you need to scroll down further to see them all). But to see the full definition of each of these objects, continuing scrolling, and you will see all the properties of each, including its textual description, and where each one is placed under the ifEntry node. For example, ifPhysAddress is the 6th column in the table, as it is defined to be the 6th object under the ifEntry node, as seen in Figure 25.

Figure 25: ifPhysAddr Definition

Table Examples - ipAddrTable

Now I want to show you a two-dimensional table with an index that is not integral. I mentioned in the previous chapter that the IP group was updated with a new RFC, RFC 4293.It turns out that because of the support for IPv6 in the new MIBs and because of other, more sophisticated, features that have been added, it is quite hard to find such an example of a two-dimensional table, unless we turn to the original MIB-2. So, even though the original IP Address Table, called ipAddrTable was deprecated in the IP-MIB and replaced with the newer, extended ipAddressTable (yes, the name is different, and it is a different node under the IP Group), we will use the old ipAddrTable as our second table example. We'll take a look at the replacement table in the last section of this chapter.

Before proceeding, be sure you can think of why there is a need for a table of IP addresses on a device. Now, go back to the tree view, and expand the ip node, and then the ipAddrTable node, and lastly the ipAddrEntry, and then scroll down so that your tree looks like Figure 26.

Figure 26: ipAddrTable

Now, do you remember how to find out what the index is for a table? Before we do that, just looking at the scalar row objects, can you guess which object is used as the table index? OK, I told you what it is not - let's look at the text of the MIB and see what index is defined. Switch back to the MIB view and select RFC1213-MIB (that's the original MIB-2) in the Available MIBs frame. Scroll down in the text frame until you get the beginning of the ipAddrTable definition. It is less than half way down, and your text frame should look like Figure 27.

Figure 27: Start of ipAddrTable Definition

We can see the index of the table defined in an INDEX statement. It is ipAdEntAddr. If you scroll down a bit more to see the defintion for this object, you'll see that it is "The IP address to which this entry's addressing information pertains." In other words, a given row has information about a particular IP address and the IP address serves as the index for the table. The information provided about a given IP address is defined in the other entry objects (you can scroll and look at the formal definitions): the physical interface that the IP address is associated with (this is the same ifIndex value that we saw in the ifTable), the subnet mask associated with that IP address, the broadcast address associated with that IP address, and the largest IP datagram that can be reassembled for that IP address.

We don't know how many rows are in the table - there are as many rows as IP addresses. Since physical interfaces can have multiple IP addresses, and the number of logical addresses defined on any physical interface can change, the ipAddrTable does not have a fixed number of rows. The number of rows can change. When we examine SNMP messages, you'll see how you find out how many rows are in a table.

Another thing that we can't know about a device (unless the network manager told us) is what the IP addresses on it are. So, how can we refer to a particular row by its index, i.e., the corresponding IP address, if we don't know the index values? You'll find out the answer to that question in the chapter on SNMP messages, also.

In the meantime, we can take a look at an example of such a table, shown in Figure 28.

Figure 28: IP Address Table

The first column shows the instance identifiers (index values) - as in the previous example, this is for the convenience of the user, but there is no such column defined in the MIB. But in this case, unlike the ifTable, the instance identifiers are not integral. They are IP addresses, and they are listed in lexicographic order. The only difference between the first column and the column that was actually defined to be the index (ipAdEntAddr) is the dot that appears before the IP address. Test yourself again - but now it is a bit trickier! What is the OID (object ID) of the ipAdEntNetMask (subnet mask) associated with the IP address 10.201.2.3?OK, this time I'll explain how we get that answer, in case you are getting confused. Starting from the top of the tree, 1.3.6.1.2.1 brings us to the mib-2 node. The IP Group is the fourth group under mib-2. The IP Address Table(=ipAddrTable) is the twentieth object in the IP Group. Under that we have the ipAddrEntry, which is the first and only node under the ipAddrTable node, and under that we have the row objects. ipAdEntNetMask is the third row object (the third column in the table). So, so far we have 1.3.6.1.2.1.4.20.1.3. Now we have to add the index to identify which instance of this column we want. The index value for the instance that I asked for is 10.201.2.3, and there you have it. Make sure you "have it", because we will complicate this further with the next example, a three-dimensional table.

Table Examples - ipNetToMediaTable

The next table that we will look at is called the ipNetToMediaTable, known to all of you as the ARP Table. This table, like the IP Address Table, was deprecated in the new IP MIB and was replaced with the ipNetToPhysicalTable. The update is actually quite substantial, as this new table supports the IPv4 ARP Table and the IPv6 Neighbor Cache (IPv6 does not use ARP, but, instead, uses a procedure called Neighbor Discovery to find the physical address of an IP destination). But the concepts are the same, the indexing is similar, and the (old) device that I will use to show you a sample table does not support the new MIB. Each table is located at a different node under the mib-2 node, so that even though the ipNetToMediaTable is deprecated, a management station can manage both newer and older devices. So, for the time being we'll work with the original MIB-2 version and in the last section of this chapter, we'll take a look at the replacement.

This is probably as good a time as any to explain the AT Group. Go back to the tree view and expand the at node, as in Figure 29.

Figure 29: AT Group

As you can see, the AT Group has one object - a table. AT stands for "Address Translation", and it is a deprecated relic from MIB-1, which, of course, was just called "the MIB" when it was defined. The atTable was intended to be the ARP Table, but it became clear that this was a rather IP-centric definition, considering that its situation directly under the mib-2 node would imply that it is the address translation table. In the 1990s, when SNMP was coming of age, the world was still rather multi-protocol (Appletalk, IPX, OSI, etc.), and so in MIB-2, the Address Translation Table was correctly placed under the IP Group, to be an IP Address Translation Table, and to permit other protocols to have their own groups under the mib-2 node with their own translation tables, if they so require.

Thus, the Appletalk MIB was defined in RFC 1742 (which replaces an earlier version), and this MIB is defined to be appletalk OBJECT IDENTIFIER ::= { mib-2 13 }, i.e., node 13 under the mib-2 node. (Considering that Appletalk is a proprietary protocol, it is surprising that it merited a node under mib-2. IPX, also a proprietary protocol, did not, and its MIB was placed under the private branch of the Management Information Tree.) The Appletalk MIB has its own aarpTable (that's the Appletalk ARP Table, and not a table for the American Association for Retired Persons, though probably anyone who remembers the Appletalk protocol is old enough to join AARP - it's for the 50+ folks).

Of course, we know how the course of history can have the last laugh. The real reason we needed to replace the AT Table seems to be because of IPv6 - not to make room for non-IP protocols. But we never know what the future will bring.

OK. Enough digression. Let's get back to the ipNetToMediaTable. This time, I won't ask you to play guessing games. Go right to the MIB view, make sure RFC1213-MIB is selected in the Available MIBs frame, and scroll down the text until you find the definition of the ipNetToMediaTable and the definition of its index, as shown in Figure 30.

Figure 30: Definition of ipNetToMediaTable Indexes

We see two indexes defined: the ipNetToMediaIfIndex and the ipNetToMediaNetAddress. I'll leave it to you to scroll down further to see the definition of each of these objects, but you can probabaly guess what each of them is. The first is the physical interface on which a particular resolution from IP address to physical address was learned and the second is the IP address in that resolution.

A physical address might actually occur more than once on a particular interface, because more than one IP address can resolve to the same physical address (remember, I pointed out when discussing the ipAddrTable that one physical interface can have more than one IP address), so the physical address would not be an appropriate index - it could not define a unique row. Clearly, the interface number alone is not a sufficient index, because many IP address/physical address pairs can be learned on one interface of a device. However, you might wonder why the IP address is not a sufficient index. Can two different interfaces have the same IP address as a neighbor and send ARP requests to that neighbor? Not likely (though it is feasible if the two interfaces are connected to the same network, but then the resulting pair would be the same). So why not just use the IP address as an index, since it is unique and therefore defines a unique row?

Remember that I said that indexes can be looked at as a way to define how to sort the rows. If we used only the IP address as an index, the table would be ordered in lexicographic order of the IP addresses. But it is much more convenient to look at a table sorted by the interface number. Using the interface number as the first index will sort the rows according to interface and then, for each interface, will lexicographically order the IP address that are resolved on that interface, as we can see in the example in Figure 31.

Figure 31: Example of ipNetToMediaTable

Not every interface on a device would have address resolution information - point-to-point WAN links have no need for such a procedure. Since the device that I have access to has only one LAN interface, the ipNetToMediaTable that I could generate using the MIB Browser would only show one value for the ipNetToMediaIfIndex, so I took my example from a cool website that I'll tell you about right after we discuss the example.

In the example shown in Figure 31, there are three interfaces (2, 3, and 6) that have ARP information. The first column shows the corresponding interface number for each of the rows (entries) on the ARP table, in lexicographic order (which, in this case, is integral order). The first column contains the first index for this table, which is why the number (1) appears in the column title. The second index (indicated by (2)) is the ipNetToMediaNetAddress, and for each ifIndex value, these IP addresses appear in lexicographic order. The resolution of an IP address appears in the ipNetToMediaPhysAddress column, and the last column tells how the resolution was learned (dynamic would mean using the ARP protocol.) This table display does not have a column for the instance identification - remember I said that was a software feature of the MIB Browser we are using.

The index of any entry, i.e., instance identification, would consist of a concatenation of the two indexes, so that if I want to specify the physical address associated with 130.89.144.79, this instance of the ipNetToMediaPhysAddress would be
ipNetToMediaPhysAddress.3.130.89.144.79. What would the complete OID (object ID) of that object be?

To view the ipNetToMediaTable on the Management Tree, return to the Tree View and expand the ip node and then expand the ipNetToMediaTable, as in Figure 32.

Figure 32: ipNetToMediaTable

Now I'll tell you about the cool website that the table I displayed is from. The website is called The Simpleweb and it has loads of great stuff about SNMP. The table that I showed you was generated from a particularly useful section of this website, which contains a displayable collection of MIBs. But what is even niftier, after you select a MIB, you get a tree on the left, similar to our MIB Browswer, and if you select on an object, you can get the values of that object as contained in one of several devices that you can select. So, for example, find RFC1213-MIB on the list (that's the original MIB-2) and select it. Then find and select the ipNetToMediaTable on the tree, just as we have on our MIB Browswer tree. Your web browser should be like Figure 33. If you select any one of the devices listed on the bottom right, you will see its table. You can now explore any of the MIB objects in this manner! Unfortunately, these devices do not support the latest MIBs (nor does the device that I have access to for this tutorial). In the next section, for those who are interested, we'll take a look at the table that replaced the ipNetToMediaTable, and we'll need to import the IP-MIB to our MIB browswer to do so. But for those who would rather move on to the next chapter, in which I'll discuss other standard MIBs, you can do so.

Updated IP Tables

For the two previous examples, we looked at two tables that have been deprecated in RFC 4293, the IP-MIB. You will find that many devices support those original tables and not the replacements. But we protocol- savvy people should strive to be up-to-date, so in this section we'll bring our MIB browser up-to- date - at least for the IP Group. I'll have to leave it as an exercise to the reader to bring the browswer totally up-to-date, and to keep it that way, as new MIBs are issued all the time. In real life, people will update a management station as the devices call for it. If they have to manage a device that supports a new MIB, then the new MIB would be imported to the management station. Our purpose here is educational.

So, import the IP-MIB, but, again, do it by clicking on the URL button and enter the following URL:
http://www.simpleweb.org/ietf/mibs/modules/IETF/txt/IP-MIB, and then click "OK". Go ahead and load the MIB.

Unfortunately, to overcome another quirk that I can't figure out, if we want to look at the text of IP-MIB, the program will complain that it can't find the RFC. So, you can do the following: Locate the directory into which you installed Blackowl. If you used the default, it isC:/program files/Asclep/BlackOwl MIB Browser. If you defined a different directory, you should know what you defined! In that directory, there is a folder called MIBDIR. Save the following file (right click and "save file as" - see Figure 34) into that directory (for example, into C:/program files/Asclep/BlackOwl MIB Browser/MIBDIR: IP-MIB.rfc.

Figure 34: Saving the IP-MIB.rfc File

The file you just saved is actually just the plain text RFC 4293, but since the file has to be renamed, it is easiest for me to rename it for you. (Otherwise, you have to change the .txt extension, which can be a pain in Windows.) If you found this too complicated, skip it and when we want to look at the text of the MIB, you can alternatively just go to that URL, which I will remind you about. Or, you can decide that you want to move on to the next chapter.

But, if you are still with me, we will now look at the ipNetToPhysicalTable, which is the substantially different replacement to the ipNetToMediaTable that we saw in the previous section.

If you did go to that effort of saving the IP-MIB.rfc file and you don't see the IP-MIB text, navigating around the MIB Browswer should "cure" it, but otherwise you can close and reopen the MIB Browser. (I admit to being challenged by this software! You might wonder why I've suggested that you use it. Well, it's for demo purposes; it's free; the other free software that I found does not have the ability to "set" - that is, write - object values; I don't want to use a free demo version of a commercial product because I don't want to advertise any particular company, if I can avoid doing so.)

Whew! Now, go back to the tree view and expand the tree until you can see mib-2. Expand that and expand the ip node. Scroll down until you see the ipNetToPhysicalTable and expand that node and the ipNetToPhysicalEntry. Your tree should now look like this:

Figure 35: ipNetToPhysicalTable

Notice that the now deprecated ipNetToMediaTable is at the top of my frame. It is node 22 in the IP Group, while the new ipNetToPhysicalTable is node 35 in the IP Group. How can you tell this quickly (rather than by referring to the definition in the RFC)?

Now, do you remember how to find out what the index is for this table? OK, let's look at the text of the MIB and see what index is defined. Switch back to the MIB view and be sure the IP-MIB is selected in the Available MIBs frame. Scroll down in the text frame until you get the beginning of the ipNetToPhysicalTable definition. It is about half way down, and your text frame should look like Figure 36.

Figure 36: Start of ipNetToPhysicalTable Definition

If we scroll a bit more (Figure 37), we'll see that there are three indexes defined for this table - two are identical to those in the ipNetToMediaTable as we saw above, with the name changed to reflect the new table. The third index is the ipNetToPhysicalNetAddressType.

Figure 37: Start of ipNetToPhysicalTable DefinitionIndexes

The description of this object (scroll down a bit more) - "The type of ipNetToPhysicalNetAddress" - is not very helpful. The syntax is defined as InetAddressType, but to know what that means, we need to look at the INET-ADDRESS-MIB. You might notice that our MIB browser can't find the RFC for this, and I could put you through an exercise to save another file to the MIBDIR directory, as I did before, but I won't (or you, too, might decide to move on). Instead, you can look at the link that I just gave you, or at what I copied and pasted here:

InetAddressType ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "A value that represents a type of Internet address.

         unknown(0)  An unknown address type.  This value MUST
                     be used if the value of the corresponding
                     InetAddress object is a zero-length string.
                     It may also be used to indicate an IP address
                     that is not in one of the formats defined
                     below.

         ipv4(1)     An IPv4 address as defined by the
                     InetAddressIPv4 textual convention.

         ipv6(2)     An IPv6 address as defined by the
                     InetAddressIPv6 textual convention.

         ipv4z(3)    A non-global IPv4 address including a zone
                     index as defined by the InetAddressIPv4z
                     textual convention.

         ipv6z(4)    A non-global IPv6 address including a zone
                     index as defined by the InetAddressIPv6z
                     textual convention.

         dns(16)     A DNS domain name as defined by the
                     InetAddressDNS textual convention.
    SYNTAX       INTEGER {
                         unknown(0),
                         ipv4(1),
                         ipv6(2),
                         ipv4z(3),
                         ipv6z(4),
                         dns(16)
                     }

I omitted a few paragraphs of explanatory text (all part of the TEXTUAL-CONVENTION definition), but you can understand from this that our additional index is an integer that tells us what kind of Internet address is in the ipNetToPhysicalNetAddress field in a particular row in the table. It is important to add this index because the same physical address of a device might be associated with an IPv4 address and an IPv6 address, for example. So, now the table will order the rows first according to the interface number, then for each interface number according to the IP address type (IPv4 before IPv6, etc.), and then lexicographically order the IP address for each address type.

Just as the ipNetToMediaTable was replaced with the ipNetToPhysicalTable, the ipAddrTable was replaced with the ipAddressTable (yes, very subtle name change), which is the node just before the ipNetToPhysicalTable in your tree. I leave it as an exercise to the curious reader to explore this table. You'll see that it, too, added support for the InetAddressType, so that the table will support IPv4 and IPv6.