Re: IPv6-QUESTION ON SQUID MIB.TXT TABLE

Hi ! (Soory for the long e-mail)

I've been studing SNMP fundamentals and I want to clarify some aspects.

IP-MIB (IPv6 or protocol-neutral) has two parts:
- textual conventions (TC)
- General group which provides for the basic management of IP.

IPv6 only: rfc2465
protocol-netral: rfc4001

> > Amos ?
>
> Hmm, I as thinking yes 1b. Then I went to check the RFC2454 which I
> recall mentioning these design choices. Turns out to be obsolete now and
> its replacement 4113 has a protocol-neutral alternative "InetAddress".
>

Both RFCs, the latter protocol-neutral, refer to UDP-MIB, not to the
IP-MIB. "An implementation must implement the UDP group if and only if
it implements the UDP over IPv6 protocol."

well, all we know Squid-SNMP agent to listen on UDP. Would you say that
Squid-SNMP agent is properly implementing UDP ? I don't think so. A
router would be an example of such un entity.

In the SQUID tree we are not interested on

  "The total number of UDP datagrams delivered to UDP
            users".

Rather we are interested on " Number of ICP messages received ", "
Number of ICP KB's transmitted "

In the above sense, I undesrtand Squid as an ICP-entity. I don't if
there exists any, but I could lift the squid-mib.txt to RFC proposal.
ICP-IP.txt (This is another task in a long term).

> Perfect chance to jump to a higher level of RFC compliance:
> http://www.ietf.org/rfc/rfc4113.txt
>
> it also lets you leverage the NtoA logics to write the content directly
> to MIB buffer in whichever format.
>
rfc4113 is UDP-IP-MIB protocol-neutral.
The IP-MIB neutral is 4001.

However, even IP-MIB neutral provides more than what we need.
F.e, the next is mandatory to implement:

"The indication of whether this entity is acting as an IPv6
   router on any interface in respect to the forwarding of
     datagrams received by, but not addressed to, this entity".

It is useless on ourt SNMP-Squid agent.

We should only borrow the Textual Convention (TC) for addresses (inside
IP-MIB, we get INET-ADDRES-MIB), needed to keep track of

cachePeerAddr " The IP Address of the peer cache "

>
> Falling short of that use 1b) and import rfc2454 to the doc/rfc references.
> We DO want to keep the original behaviour for legacy systems.
>
OK. Acording to above reasoning, I should import rfc2465 (TC plus IPv6
General Group).

And the OIDs would remain:

cachePeerAddr " The IP Address of the peer cache "
cachePeerAddr6 " The IPv6 Address of the peer cache "
cacheClientAdd "The client's IP address "
cacheClientAdd6 "The client's IPv6 address "

Hmmm... I agree this is the transient solution.

> The conversion process has been followed few steps:
> - don't make the old stuff worse
> - if code can be done neutral / RFC compliant do so, marking the RFC
> - if traffic can be done IPv6 do so (v4-mapped if needed)
> - if IPv6 fails try again with IPv4 where possible
> - if the remote asks for specifics, hand 'em over
>
> Amos
Received on Fri Oct 19 2007 - 03:00:36 MDT