[rbldnsd] PATCH: 6to4 and v4-in-v6 - Plea for a new release

[Michael Tokarev]

26.05.2015 22:05, Alex Lasoriti wrote:
...
> WITH THIS PATCH:
> ----------------
> 
> Listing of an IPv4 address means that all the IPv6 addresses 
> resulting from the mappings described above (the /128 and the /48 
> network from 6to4) are also implicitly listed.  So, from a v6 lookup
> we go check the v4 data structures.
> 
> There is a inherent asymmetry here: we do _not_ go the other way
> (that would be: from a v4 lookup go check the v6 data structures).
> Of course, in principle this could be done as well, but now it would 
> mean checking _two_ v6 addresses for every single v4 lookup.  The code 
> would become more complex and frankly we do not have any need to do 
> this, so we decided to break the symmetry and go only one way.
> This can be a limitation for someone, but I would be surprised if 
> other DNSBL operators really require preservation of bidirectionality.

How about one step further in breaking the symmethry and by
omitting the v6 lookup of both forms of 4-in-6 addresses?

In the terms of the patch, this means resetting qi_ip6valid
to 0 when we set qi_ip4valid.  What do you think?

What happens with the other bits from the resulting /48 address
of the 2002: prefix?  Should these be ignored entirely?

     if (qi->qi_ip6valid && (flags & DSTF_IP4REV) &&
        ((is6to4 = (qi->qi_ip6[0] == 0x20 && qi->qi_ip6[1] == 0x02)) ||
        memcmp(qi->qi_ip6, ip6mapped_pfx, sizeof(ip6mapped_pfx)) == 0)) {
       /* construct IP4 from 6to4 or IP4MAPPED */
       qi->qi_ip4 = unpack32(qi->qi_ip6 + (is6to4 ? 2 : sizeof(ip6mapped_pfx)));
       qi->qi_ip4valid = 1;
     }

I'll split this into two nested if's with comments, or else it is
unreadable and comment makes no sense.

Thanks,

/mjt