Re: IPv6-QUESTION ON SQUID MIB.TXT TABLE

Rafael Martinez (Squid development) wrote:
>> 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
>>
> OK
>
>> 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.
>>
> Hmmm... Why ?
> - Because backwards-compatibility (squid 2.X) is lost ?
> - Because squid snmp_agent must be recoded ?

  I was hoping to find a MIB that would map 1:1 (bonus for compatible)
possibly with type built-in as part of the field. Instead its another
layer and a type field in a neighboring leaf.
  Oh well, could be worse.

>
> We can almost borrow that bunch of specification for ours... Take a
> look for the "diff" proposal below ( it is not commit )
>
>> 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.
>>
> And coding IPv4 cachePeerAddr as IPv6-mapped addresses ?
> This would also destroy backwards-compatibility, sizes are different.

Yes, True.

>
>> ?? 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.
>>
> Absolute agree.
>
> Some proposal.
> ===========================================================================
> 16,17c16,17
> < Ipv6Address
> < FROM IPV6-TC;
> ---
>> InetAddressType, InetAddress
>> FROM INET-ADDRESS-MIB;
> 722c722
> < INDEX { cachePeerAddr }
> ---
>> INDEX { cachePeerAddressType, cachePeerAddress }
> 727c727,728
> < cachePeerAddr IpAddress,
> ---
>> cachePeerAddressType InetAddressType,
>> cachePeerAddress InetAddress,
> 750,756c751,785
> < cachePeerAddr OBJECT-TYPE
> < SYNTAX IpAddress
> < MAX-ACCESS read-only
> < STATUS current
> < DESCRIPTION
> < " The IP Address of the peer cache "
> < ::= { cachePeerEntry 2 }
> ---
>> cachePeerAddressType OBJECT-TYPE
>> SYNTAX InetAddressType
>> MAX-ACCESS not-accessible
>> STATUS current
>> DESCRIPTION
>> "The type of Internet address by which the peer
>> is reachable."
>>
>> ::= { cachePeerEntry 2 }
>>
>> cachePeerAddress OBJECT-TYPE
>> SYNTAX InetAddress (SIZE (1..64))
>> MAX-ACCESS not-accessible
>> STATUS current
>> DESCRIPTION
>> "The Internet address for the peer. The type of this
>> address is determined by the value of the peerAddressType
>> object. Note that implementations must limit themselves
>> to a single entry in this table per reachable peer.
>> The peerAddress may not be empty due to the SIZE
>> restriction.
>>
>> If a row is created administratively by an SNMP
>> operation and the address type value is dns(16), then
>> the agent stores the DNS name internally. A DNS name
>> lookup must be performed on the internally stored DNS
>> name whenever it is being used to contact the peer.

Do we actually use the DNS type in peer cache?

>>
>> If a row is created by the managed entity itself and
>> the address type value is dns(16), then the agent
>> stores the IP address internally. A DNS reverse lookup
>> must be performed on the internally stored IP address
>> whenever the value is retrieved via SNMP."
>> ::= { cachePeerEntry 3 }
>>
<snip remaining>

Looks great.
If you are OK coding that, Its a go from me now.

Amos
Received on Mon Oct 22 2007 - 05:46:48 MDT