The meaning of the status values is as follows:

• submitted means that the issue was submitted but no decision has been made whether the problem is within scope.
• accepted means that the problem was accepted to be within the scope. Note that this applies only to the problem description and the solution might be completely different than the proposed solution.
• rejected means that the problem was reject as being out of scope.

From: dthaler@dthaler.microsoft.com
Status: submitted

One thing I'd like to see on the list of IPv6-address issues being compiled deals with addresses in INDEX clauses.

One solution I've seen is in the RTP MIB draft, where they've made the table be indexed by an integer unrelated to the addresses. While this has the advantage of making the table work for all address families, it's a bad thing in this case where you want to be able to efficiently locate the entry for a specific address in the table. In the current RTP MIB draft, you cannot do this without walking the entire table, since the order is essentially random.

In contrast, the IP Tunnel MIB has IpAddress objects in INDEX clauses, so that lookups are very efficient, but doesn't work for IPv6.

So the issue is what I would term "efficient table lookups by address".

I would like to see some discussion on creating generic address objects that could be used in INDEX clauses. For example, could one define a TC which uses one subidentifier for the address family and a set of following subidentifiers for the address-family-specific address? (Hence, the IPv4 address 131.107.1.30 would appear inside an OID as 1.131.107.1.30.) If so, then is there any nice way to allow multiple such objects in the same INDEX clause? Maybe allow IMPLIED and .0?

From: kzm@cisco.com
Status: submitted

To solve the basic problem requires that the difference between IPv4 and IPv6 addresses be expressed without requiring new SMI rules; instead, the difference needs to be expressed in the value of MIB object(s) which are encoded using the *existing* SMI.

For example,

1. two objects: one for type, and the other for the address encoded according to the value of type, or
2. one object which has encoded *inside* its value: both a type and an address

The second option would use a newly-defined TC, defining how the type and address are encoded in a single OCTET STRING. The first could (should?) use TDomain and TAddress, except that TDomain is an OID and it's not attractive for an INDEX clause to contain objects which have OID as their underlying syntax.

I think the separate address-type object has an advantage if other address-types need to be accommodated in the future. The philosophy behind enumerated INTEGERs and OIDs is to expect new assignments, whereas that's harder to achieve when structure is embedded into OCTET STRINGs. The more compact single-object representation has an advantage if only IPv4 and IPv6 types need to considered.

From: schoenw@ibr.cs.tu-bs.de
Status: submitted

It should be possible for a management application to render (network) addresses into the 'usual representation'.

A solution which uses one object which has encoded inside both the address and the address type will not work with SMIv2 display hints since they are not conditional.

A solution which uses two objects (one for the type and another for the address) works with display hints if the manager is able to cast a value from a generic TC to the concrete TC indicated by the type value. Note that the SMIv2 has no mechanism to formally represent the relationship "this objects TC depends on the value of another object".

The second approach is used by the TDomain/TAddress pair for quite some time. It seems that with some heuristic rules (e.g. by interpreting naming conventions on the descriptors), this cast is indeed feasible. If the second approach is followed, then such heuristic rules and naming conventions should be documented.

From: schoenw@ibr.cs.tu-bs.de
Status: submitted

It is possible to represent an IPv4 and an IPv6 in a single object by defining a TC like IPv4v6Address ::= OCTET STRING (SIZE 4|16). The length of the value will determine the address type.

The conversion of the TCP and UDP MIBs to IPv6 however shows that (at least in these cases) you need to have the interface index as an additional value in order to get a unique value. If a combined IPv4/IPv6 addres type is defined, then there should be a clear statement in which cases this new TC is useful and in which cases not.

From: schoenw@ibr.cs.tu-bs.de
Status: submitted

The definition of TDomain/TAddress in RFC 2579 (STD58) refers to transport services. It is unclear whether it is legal to store a network layer address or even a MAC layer address in a TDomain/TAddress pair (assuming proper definitions have been made).

If it is legal, then this should be documented. Otherwise, there may be a need to add similar TDomain/TAddress constructions for other layers. This raises the questions about how many layers there are...

From: daniele@zk3.dec.com
Status: submitted

The primary issue (to me) hasn't been explicitly stated.

MIB developers use IpAddress because it's there, and because there is nothing written down to tell them not to, or to tell them what else to do.

So we need to document what the choices are when considering objects that pertain to IP addressing, provide guidelines and examples, and somehow make this design step part of the process of developing MIBs.

It's correct to use IpAddress for some objects, but it should be chosen by design.

From: pcn@tbit.dk
Status: submitted

[This is an excerpt from a longer message. Please refer to the archive of the MIBs mailing list in order to read the original message.]

The flexible low-level addressing mechanism that network administrators would need would be something where the domain refers to the network layer address. Three values, IPv4, IPv6, DNS.

When we start using SNMP in the IPv6 area seriously, we don't want our agents or notification receivers be designated via either IPv4 padded with port/256 and port modulo 256, or IPv6 padded the same way. We want the agents and receivers to be designated via a DNS name and a port number!

From: pcn@tbit.dk
Status: submitted

The issue is a suggestion to update the IPV6-TC and dependent MIBs (IPV6-MIB, IPV6-TCP-MIB, IPV6-UDP-MIB) such that the Ipv6IfIndex and Ipv6IfIndexOrZero Textual Conventions are dropped, and replaced with the IF-MIB InterfaceIndex and InterfaceIndexOrZero textual convention. The ipv6IfLowerLayer object is deprecated as a consequence.

Pro: No convincing argument have been presented for having to maintain an independent abstraction for IPv6 interfaces. Moreover, although this update is formally incompatible, the practical consequences are quite small.

Counter: This update is entirely incompatible and pretty drastic as it changes the semantics of the index object of several tables.

From: dthaler@dthaler.microsoft.com
Status: submitted

RFC 2465's use of Ipv6IfIndex and ipv6LowerLayer duplicates the functionality of the interface stack table, and so is redundant with RFC 2233. It also appears to be trying to create a new method of referring to IPv6-over-IPv4 tunnels which duplicates the functionality available with RFC 2233 + the IP Tunnel MIB. All of this unnecessary duplication would have been avoided if it just used InterfaceIndex to begin with.