FW: ipv6IfStateChange traps in RFC2465

["Dave Thaler" <dthaler@windows.microsoft.com>]

During the meeting, Itojun mentioned a problem with traps
prior to SNMPv3, and I indicated this is not in fact a problem.

Here's the relevant exchange which took place on the ipng 
and snmpv3 lists last year.

-Dave

-----Original Message-----
From: David T. Perkins [mailto:dperkins@dsperkins.com] 
Sent: Tuesday, August 21, 2001 9:27 AM
To: Steve Moulton; Dave Thaler
Cc: Daniel Chuang; ipng@sunroof.eng.sun.com; snmpv3@lists.tislabs.com
Subject: Re: ipv6IfStateChange traps in RFC2465 

HI,

There is NO PROBLEM in sending a v1TRAP (or sending v2TRAP or INFORM
with SNMPv2c) using IPv6! NO PROBLEM!

Comments below...

At 10:37 AM 8/21/2001 -0400, Steve Moulton wrote
>On Monday, August 20 2001, "Dave Thaler" 
><dthaler@windows.microsoft.com> wrote:
>>  > From: Daniel Chuang [mailto:ipv6_dchuang@yahoo.com]
>>  >
>>  > [...] what kind of information
>>  > will be put into the "agent-addr" in the v1 Trap
>>  > PDU in the ipv6-only node?
>>  >
>>  > A couple of options:
>>  > 
>>  > 1. SNMPv1 traps are not allowed for ipv6-only node.
>>  > 
>>  > 2. modify RFC1157.
>>  > 
>>  > 3. any other creative methods !!
This question is ALREADY asked and answered. The value is 0.0.0.0, which
should be the value ALWAYS. I'll leave it for Steve to find the
documents. Hint: what do you put in the field when running over IPX, see
RFC 1420.

>> It looks to me like the answer is (1).
No, the value 0.0.0.0 MUST be used.

>> Cc'ing SNMPv3 list, where other experts reside.
>
>Currently, as best as I can tell, this can't be done.
Incorrect. Do more homework.

>Please pardon me for being didactic - I'm figuring this out for the 
>first time myself.
>
>Talking to:
>
>If you are using the coexistence framework (rfc2576), the
>notification destination is specified in the snmpTargetAddrTable.
>The address is specified using the TDomain and TAddress
>textual conventions.  rfc1906 defines the OIDs for TDomain,
>but they can also be defined elsewhere, though as far as
>I can tell, no domain has been defined in an RFC for IPv6 addresses.
Well, one of the "wonderful properties" of OID values is that they can
be defined by anyone, and, thus, there is 1) no way of knowing all
assignments, or 2) no way of knowing if there are duplicate assignments.
So it is possible for some WG to have defined an OID that identifies the
value as an IPv6 transport address, or that one or more vendors have
created definitions.

>There is a proposal to add new transport domain OIDs for IPv6 in 
>draft-ops-taddress-mib-00.txt.  I'm pretty sure this is also in 
>draft-ops-taddress-mib-01.txt, but both have expired, and I don't have 
>the text for it. So, there is currently no way to specify an IPv6 
>target address in a standard fashion, though either the IETF or vendors

>will have to deal with this as IPv6 support demand increases.
If your data is accurate, then there is no "standard" identification,
but there is a standard way to specify IPv6 addresses.

>Juergen, Mike, am I up to date here?
>
>Talking about:
>
>As for the trap contents itself, the agent address
>parameter is a NetworkAddress, a choice that has
>only one defined type, IpAddress, an implicit octet
>string of length 4.
>
>So it appears that either the NetworkAddress type must
>change, or the Trap-PDU (an obsolete pdu) must change, to convey IPv6 
>addresses in an SNMPv1 packet.  In both cases, interoperability would 
>be lost.
No, the NetworkAddress type does not need to change, and 
v1Traps do not need to be changed. The agent address is 0.0.0.0.

One determines the "source" of the information contained in
the v1 TRAP (and v2Trap and Inform used in SNMPv2c) from the transport
address of the sender (the "reporter") and the community string value.
On receiving a v1Trap (or v2Trap or Inform with SNMPv2c), the trap
receiver must use the pair of the transport address (more likely just
the Network address) and the community string together to figure out the
source. In v3 speak, the source is an EngineID and context string.
Remember the community string field and the transport address is just an
associative key pair to get the triple: isProxy(and, if so, proxy info),
context, and security info. (Table snmpCommunityTable is just one way,
which is not too useful in an SNMPv1 or SNMPv2c environment, of
describing the triple.)

If the above is not clear, please provide example scenarios
and I'll fill in the values.

>        - Steve
Regards,
/david t. perkins