[rbldnsd] ip6tset and the RFC5782 test IPv6 don't like each other

[Jeff Dairiki]

On Thu, Oct 10, 2013 at 12:21:45AM +0200, Alex Lasoriti wrote:
> Hi all,
> 
> I am working on the IPv6 setup for the Spamhaus lists that will soon be
> extended to cover the v6 space.

Good news!
 
> I stumbled on this problem.
> 
> For XBL (malware-infected systems) the plan is to use ip6tset: all 
> listings will be /64, so it seems to be exactly the right dataset type 
> for this BL, and in fact I think this type was designed for this kind
> of applications. Surely using ip6trie instead would be a waste of resources.

Out of curiousity, how many /64 prefixes do you have?  Have you compared
resource usage between ip6tset and ip6trie?  Yes, ip6trie does use
2-3 times the memory of ip6tset, but unless you have really large datasets,
or run on very old or memory-constrained hardware, I suspect the difference
is not really a back-breaker.

> As the man page says regarding ip6tset:
> 
> 	This dataset wants the /64s listed as four ip6 words, for example:
> 	2001:20fe:23:41ed
> 
> So the last 64 bits are simply thrown away, they do not appear as they
> are not relevant.  So far, so good.
> 
> Now, let us meet RFC5782 which defines (in section 5) the proper
> test addresses.  It says:
> 
> 	IPv6-based DNSxLs MUST contain an entry for ::FFFF:7F00:2 (::FFFF:
>   	127.0.0.2), and MUST NOT contain an entry for ::FFFF:7F00:1 (::FFFF:
>   	127.0.0.1), the IPv4-Mapped IPv6 Address [RFC4291] equivalents of the
>   	IPv4 test addresses.
> 
> You now see the problem.  The full expanded version of the test address is
> 
> 	0000:0000:0000:0000:0000:ffff:7f00:0002
> 
> but if I cut away the last 64 bits I remain with
> 
> 	0000:0000:0000:0000
> 
> and that is obviously _not_ a meaningful test address.
> 
> Solutions, considering that not including a functional IPv6 test 
> address is out of question:
> 
> 1) we go ip6trie
> 2) we ignore RFC5782 and choose another test address in the
>    most significant 64 bits
> 3) rbldnsd is changed somehow (/128 made possible in ip6tset at
>    least for "special" records)

FWIW, someone did offer patches to support listing /128s in ip6tset.
(See https://github.com/dairiki/rbldnsd/issues/2)  I can't vouch for
the code in the patch, and the idea was dismissed at the time (both
by myself and Michael Tokarev.)  But it would probably be possible to
add /128 support without too much trouble (not that I'm volunteering
to do it.)

> 4) RFC5782 is changed and the revised version picks up a test address
>    in the high 64 bits.  For instance, one could adopt the 6to4 scheme
>    and choose 2002:7f00:0002:0000 as test address.
> 
> No one of them seems particularly desirable.
> 
> Thoughts? 

5) I haven't tested this, and it's pretty hackish (apologies for both)
   but ip6tset supports /128 exclusions.  So you could list 0:: (which
   includes ::FFFF:7F00:2 among many others) and then exclude
   ::FFFF:7F00:1.  That would give you a whole bunch of test addresses
   — perhaps too many — but it would appear to conform to RFC5782.

Jeff