Eine Möglichkeit wäre, SNMPv2 und dessen SMI um einen derartigen Datentyp zu erweitern. Eine andere wäre, diesen Datentyp erst in der Version 3 von SNMP, die derzeit diskutiert wird, einzubauen. Beide Lösungen haben den Nachteil, daß die Benutzung der IPv6-MIBs erst nach Änderungen am Informationsmodell und am Protokoll möglich wäre. Bezieht man die Erfahrungen mit der schleppenden Verbreitung von SNMPv2 in die Überlegung mit ein, erscheint dies nicht sinnvoll.
Der Entwurf zur RSVP-MIB (siehe Abschnitt 6.2.9) repräsentiert IPv4- und IPv6-Adressen als OCTET STRING (SIZE(4..16)). Eine IPv6-Adresse benötigt 16 Bytes zu ihrer Darstellung, also könnte man den Typ OCTET STRING (SIZE (16)) verwenden.
Eine praktische Lösung, die ohne Änderungen am Informationsmodell
auskommt, ist die Vereinbarung des Datentyps der IPv6-Adresse als
textuelle Konvention. Diesen Weg gehen auch die oben genannten
Entwürfe für die IPv6-MIBs:
Ipv6Address ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2x:"
STATUS current
DESCRIPTION
"This data type is used to model IPv6 addresses.
This is a binary string of 16 octets in network
byte-order."
SYNTAX OCTET STRING (SIZE (16))
Weitere nützliche Typvereinbarungen werden für das Adreßpräfix und für
das Adreßtoken gemacht:
Ipv6AddressPrefix ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2x:"
STATUS current
DESCRIPTION
"This data type is used to model IPv6 address
prefixes. This is a binary string of up to 16
octets in network byte-order."
SYNTAX OCTET STRING (SIZE (0..16))
Ipv6AddressToken ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2x:"
STATUS current
DESCRIPTION
"This data type is used to model IPv6 address
tokens. This is a binary string of up to 8
octets in network byte-order."
SYNTAX OCTET STRING (SIZE (0..8))