Forwarding traps from an IPv6 agent: How to preserve that address

SNMP4J
1

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?

2

In general I agree, that a standard definition for the OBJECT-TYPEs:

  1. Source Transport Domain
  2. Source Transport Address (including port)

would address a demand that exists for decades now.

Regardless whether the conceptual idea to forward the source addresses of intermediate systems to the notification receiver is helpful or not, it would standardise the approaches that have been often implemented vendor specific. So, it would improve interoperability.

On the other hand side, it might be shortcoming if the general concept is not properly defined by its specification.

I mean, what are the benefits for the notification receiver?

  • Would the receiver be able to do trap-directed polling with the source address? (Most likely not, I guess)
  • Would the receiver use the source address to identify/separate sub-systems behind a proxy application?
  • Would the information be used for security measures?