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

[Alex Lasoriti]

Hello list,

here at Spamhaus Technology we are proceeding - although not as
quickly as hoped - toward the general rollout of the IPv6 DNSBL service
(with zones coming as combined datasets, a single file per zone) 
and we are now approaching the stage where we would like to reach the 
majority of users and have them enjoying IPv6 entries in our databases,
(regardless of their connectivity - there could be IPv6s in Received 
lines and in bodies to be considered by content scanners even for 
people on IPv4).

For maximum effectiveness and minimum effort on behalf of users,
we would like to propose a new rbldnsd release incorporating the 
patches included here, that address a couple of issues associated with 
mappings of IPv4 addresses into the IPv6 space.

An IPv4 address can have two IPv6 representations:

* IPv4-mapped IPv6 addresses  [RFC4291]
	80 bits of 0's, 16 bits of 1's, the last 32 bits are the IPv4,
	So these are /128 addresses starting with ::ffff .

* 6to4  [RFC3056]
	The IPv4 address is appended to the 2002: prefix, giving
        a whole network 2002:V4ADDR::/48 that corresponds to a single 
        IPv4.

Testing on the field has shown that IPv6 lookups of both kind
of addresses are rather frequent.  So the main goal of this patch is 
to achieve automatic blocking of IPv6 addresses that result from 
_either_ of the two mappings described above of a listed IPv4 address.

Our strategy is to refrain from explicitly listing ::ffff or 2002: 
addresses on the IPv6 side, focusing only on the corresponding IPv4.
This reduces chaos and makes it easier for listees to understand
the problem.  This strategy however requires the widespread availability 
of a new rbldnsd implementing both mappings internally.

                       - o - o - o - o - o -

UP TO NOW:
----------

Rbldnsd already has provisions to deal with the v4-in-v6 mapping in 
a symmetric, bidirectional way.  So the same address could be
listed in its IPv4 form or in its ::ffff:(ipv4) form and it
would make no difference.

There was however a bug in the code doing this, that we found and 
patched in August 2014
[ http://www.corpit.ru/pipermail/rbldnsd/2014q3/001243.html ].
But this fix has not yet found its way into a production release as far
as we know, so all the existing copies are not really dealing with the
::ffff mapping.

The current rbldnsd does not make any attempt to deal with 6to4.  
So 2002: IPs would have to be separately listed in the IPv6 space to 
achieve blocking.

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.

This is a real life example (from today's IPv6 spam flows) of the 6to4 
patch in action:

IPv4 address: 119.254.105.202  (today listed in our SBL zone)
Corresponding 6to4 network: 2002:77fe:69ca::/48

Actual connecting IPv6 address: 2002:77fe:69ca::77fe:69ca

Result of DNSBL lookup:
a.c.9.6.e.f.7.7.0.0.0.0.0.0.0.0.0.0.0.0.a.c.9.6.e.f.7.7.2.0.0.2.sbl.spamhaus.org. 60	IN A 127.0.0.2

Postfix log entry:
Client host [2002:77fe:69ca::77fe:69ca] blocked using sbl.spamhaus.org; 
http://www.spamhaus.org/sbl/query/SBL257650

No explicit listing for this IPv6 in the zone - SBL257650 was for
119.254.105.202 only.

                       - o - o - o - o - o -

The attached patch has been obtained against the rbldnsd-0.997a source tree
using
LC_ALL=C TZ=UTC0 diff -Naur rbldnsd-0.997a rbldnsd-0.997a-v4-v6-map-patch > rbldnsd-0.997a-v4-v6-map-patch.diff

The code here has undergone rather extensive testing for a couple
of months, but we would be of course very happy if further testing 
can be done by others, leading to a new release in the shortest 
possible time frame :)

Thanks,

Alex Lasoriti
Spamhaus Technology

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rbldnsd-0.997a-v4-v6-map-patch.diff
Type: text/x-diff
Size: 1637 bytes
Desc: not available
URL: <http://www.corpit.ru/pipermail/rbldnsd/attachments/20150526/c674a85b/attachment.diff>