Re: IPv6-QUESTION ON SQUID MIB.TXT TABLE

Rafael Martinez (Squid development) wrote:
> Hi:
> Before commit any change, I ask for help.
>
> The file mib.txt under src, describes the MIB tree for Squid.
>
>
> For incoming IPv6 Squid server, we must import a new MIB definition to
> deal with IPv6 addresses.
>
> IMPORTS
> enterprises, Unsigned32, TimeTicks, Gauge32, Counter32,
> MODULE-IDENTITY, OBJECT-TYPE
> FROM SNMPv2-SMI
>
> DisplayString
> FROM SNMPv2-TC
>
> Ipv6Address
> FROM IPV6-TC; -- This is already commit.
>
>
> ------------------------------------------------------------------------------
>
> Theses are two IP-related OIDs in actual SQUID MIB.
>
> cachePeerAddr IpAddress,
> cacheClientAddr IpAddress,
>
>
> The question:
>
> 1) If we get an IPv6 Squid server:
> 1a)- should these OIDS be _modified_ to hold IPv6 addreeses ? or
> 1b)- should be _added_ new OIDS to hold IPv6 addresses
> (i.e., cachePeerAddr6, cacheClientAddr6)
>
> HINTS:
>
> 2) Pre-processor techniques (#ifdef IPv6) are not allowed in the mib.txt
> grammar file and IpAddress-Ipv6Address formats are incompatible. So if
> we want to keep original squid "--disable-ipv6", 1b) is the choice.
>
>
> In my opinion, 1b) is the right choice. However, snmp_agent must be
> reprogrammed acordingly.
>
>
>
> It should NOT answer when asked either for IpAddress-OID and the IP is
> not IPv4 and viceversa: NOT answer when asked for Ipv6Addr when the IP
> is IPv4 (though it can be IPv6 mapped!).
>
> 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".

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.

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.

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

>
>
> case MESH_PTBL_IP:
> if (laddr.IsIPv4()) {
> struct in_addr iaddr4;
> laddr.GetInAddr(iaddr4);
> Answer = snmp_var_new_integer(Var->name, Var->name_length,
> (snint) iaddr4.s_addr,
> SMI_IPADDRESS);
> }
> break;
> /* Added enumerated type to process cachePeerAddr6 */
> case MESH_PTBL_IPv6:
> if (laddr.IsIPv6()) {{
> Answer = snmp_var_new(Var->name, Var->name_length);
> Answer->type = ASN_OCTET_STR;
> Answer->val_len = sizeof(struct in6_addr);// Use a symbolic
> constant.
> struct in6_addr *iaddr6 = (struct in6_addr
> *)Answer->val.string;
> laddr.GetInAddr(*iaddr6);
> }
> break;
>
Received on Tue Oct 09 2007 - 06:35:23 MDT