Hi. I need to forward traps received from an agent with an IPv6 address (that cannot be converted to IPv4). However as you know, both an SNMPv1 agent field, and a v2/v3 snmpTrapAddress varbind can hold only IPv4 (4-byte) addresses, so when the source address is IPv6, those values are set to 0.0.0.0. Of course that makes all such traps anonymous (useless), unless the SNMP manager can access the UDP packet’s source address, which is a rather non-SNMP requirement. Worse, it is impossible to forward such traps, since the original packet’s source address is then lost (replaced by the forwarder’s address).
From what I’ve researched, proxy developers that need to forward IPv6 traps must append their own custom varbinds to hold the agent’s IPv6 address, (and leave snmpTrapAddress/agent as 0.0.0.0). The RFCs do suggest a more-generic way to communicate an address, incorporating two varbinds: one to hold a code for the address’s type (e.g. IPv6), and an OctetString to hold the address bytes. But there is no definition for varbind OIDs that should store an agent.
So my questions are: 1) Does that sound correct so far, and/or got any advice?; and 2) Since this seems like an important RFC oversight that should be corrected with a standard (rather than vendor-specific) solution, do you/anyone have any interest in maybe co-authoring an RFC?
FYI, years ago I exchanged emails with one of the original SNMP RFC authors about a similar problem: how to store the address of an “aggregator” such as a hardware vendor’s management station that would send traps on behalf of multiple agents that it managed. The author suggested that I write an RFC to add the necessary OID for the extra “man-in-the-middle” address. Unfortunately I never found the time to do that, but it was nice to know the RFC community may be open to new ideas for this old protocol. Maybe now is a good time to fix both issues with an RFC. What do you think?