references: http://www.ietf.org/rfc/rfc4001.txt
The SNMP trap receiver assumes that any SNMP TrapVarbind of type inetaddress is an IPv4 inet address; this presents a problem with devices sending IPv6 addresses in the trapvarbinds
An example is shown below:
| jnxBgpM2PeerRemoteAddr..... | 38.7.64.0 | |
| jnxBgpM2PeerRemoteAddrType..... | 2 | |
| jnxBgpM2PeerLocalAddr..... | 38.7.64.0 | |
| jnxBgpM2PeerLocalAddrType..... | 2 |
The length of these VarBinds was 16 octets -- an IPv6 address, but these have been truncated to the first four octets.
this should have been:
| jnxBgpM2PeerRemoteAddr..... | 2607:4000:xxxx:xxxx:0000:0000:0000:0001 | |
| jnxBgpM2PeerRemoteAddrType..... | 2 | |
| jnxBgpM2PeerLocalAddr..... | 2607:4000:xxxx:xxxx:0000:0000:0000:0001 | |
| jnxBgpM2PeerLocalAddrType..... | 2 |
proposal:
a) if the length of the inetAddress varbind is 16 octets represent it as an IPv6 address
this is the simplest case to code up, basically don't truncate the IP address to 4 characters and expose it as a IPv6 address
b) if for a varbind of X.Y there exists a varbind of prefix XType.Y then decide the varbind of X using the textual conventions described in RFC4001
this is harder to code up, but not impractically so.
[note: the truncation is taking place on table insert, if the trap is forwarded then the contents of the varbind is preserved]
