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

Alex Lasoriti lasoriti at spamteq.com
Thu Oct 10 02:21:45 MSK 2013


Hi all,

I am working on the IPv6 setup for the Spamhaus lists that will soon be
extended to cover the v6 space.

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.

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

Alex



More information about the rbldnsd mailing list