Subject: RE: ipv6IfStateChange traps in RFC2465

From: "Dave Thaler" <[email-masked]>
Date: Mon, 20 Aug 2001 16:12:41 -0700

> From: Daniel Chuang [mailto:[email-masked]]
>
> [...] 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 !!

It looks to me like the answer is (1).

Cc'ing SNMPv3 list, where other experts reside.

-Dave
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Steve Moulton <[email-masked]>
Date: Tue, 21 Aug 2001 10:37:10 -0400

> Cc'ing SNMPv3 list, where other experts reside.

Currently, as best as I can tell, this can't be done.

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.

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.

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.

Dave, thanks for tossing this over the wall. 

        - Steve
---
Steve Moulton        SNMP Research, Inc            voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
[email-masked]     Knoxville, TN 37920-9716 USA  http://www.snmp.com

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 21 Aug 2001 09:26:57 -0700

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
>>  > 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.

>Currently, as best as I can tell, this can't be done.
Incorrect. Do more homework.

>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.

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

>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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Aug 2001 18:07:00 +0200

>>>>> Steve Moulton writes:

Steve> though as far as I can tell, no domain has been defined in an
Steve> RFC for IPv6 addresses.

Correct. This is one of the infrastructure pieces we are really bad in
getting done in a timely manner.

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

I prefer a standard definition and that is why I started to write
<draft-ops-taddress-mib-00.txt> a while back. For those interested,
you can find a copy at:
<http://www.ibr.cs.tu-bs.de/~schoenw/draft-ops-taddress-mib-00.txt>

One problem with TAddress/TDomain is that the community does not have
a clear concensus whether definitions contain specific SNMP semantics
or not. The current usage of TAddress/TDomain outside the SNMP specs
of course assumes that there are no special SNMP semantics associated
with TAddress/TDomain definitions...

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>