Re: IPv6-QUESTION ON SQUID MIB.TXT TABLE

Rafael Martinez (Squid development) wrote:
> 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
>

Aha, my mistake. Thank you for knowing these things and clarifying.

Where I was referring to 4113 I should have been saying 4001 it appears.

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

True. I don't understand the context most of SNMP/MIB fall into.

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

Lot of those ;-)

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

Having now read 4001. I feel the squid tables with IP fall under section
1, pg 3, "type 1" objects.

Which leaves us with:
- "SHOULD implement" InetAddress
- "strongly discouraged" from using the split method

Section 5 covers a table index usage case pretty close to the reality in
squid. That said, their way of neutral is way more complex than I had
thought.

To alleviate we have:
   InetAddressIPv6 - "MAY be used either on its own or in conjunction
with InetAddressType, as a pair".
   InetAddressIPv4 - same.

Making cachePeerAddr -> InetAddressIPv6 would be cleanest of all three
if not entirely neutral.

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

Where is this? I could not find it anywhere in 4001.
Seemed 2465 had much more about routers and updates. Which yes, doesn't
apply.

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

?? by My full reading of 4001 and skim of 2465 I get the opposite.
  4001 appears to define enough available to use neutral fairly easily.
  2465 still seems major overkill, and itself imports the IPv6Address TC
from somewhere else that we would otherwise be importing through it.

> 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 - 06:11:15 MDT