On Fri, Oct 19, 2012 at 8:22 AM, Mikael Abrahamsson
<swmike(_at_)swm(_dot_)pp(_dot_)se> wrote:
Fundamentally in IPv6, a "customer" (or entity or whatever) will in a lot of
cases not a single IP address, but a network.
At the beginning of an SMTP transaction, all you have is a single IP.
Households will get /64s, or get a /56 via DHCPv6-PD. Phones get a /64 or a
network via DHCPv6-PD. Companies get /48 (or something else, but a bunch of
As a spam filter (software developer), you may want to know more about
the reputation of the IP address connecting to you.
So for spam detection to happen, detection of what is a "customer" needs to
happen, and this needs to be on a network level, not single IPv6 address
level. The RIR databases (at least RIPE) contain information about what kind
of per-customer subnet size is for a certain large block of addresses.
You need an algorithm where you start from a single IP address and
then potentially "move up" until you get a meaningful result. That's
more or less what the B-tree algorithm suggested by John Levine some
months ago would offer: variable "depth" and "density" of data
controlled by the DNSxL operator optimized for the (on average) lowest
number of lookups needed.
At the same time, having a standardised and light-weight protocol to
determine the allocation policy by the ISP would be hugely helpful
(this will likely then be mirrored by the DNSxL operator). Absent such
data,third parties have to fall back to some default /64 etc.
What I feel needs to happen is that policy needs to put in place to RIRs
(via ISPs) can present "what is a customer" on a network level, and then
this information can be put into DNS somehow, and used for DNSBL.
I don't know whether RIRs can mandate the publication of this data
through policy.
-- Matthias
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg