Re: DNSBL and IPv6
Matthias Leisi <[email protected]>
| Newsgroups | gmane.ietf.asrg |
|---|---|
| Message-ID | <CALgnk9rEPZwR5UHqeqSWQOPLYMOdLCF=hP1u+oeFatoVoavv3w@mail.gmail.com> |
On Fri, Oct 19, 2012 at 8:22 AM, Mikael Abrahamsson <[email protected]> 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