On Fri, 19 Oct 2012, Matthias Leisi wrote:
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.
Yes.
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.
Yes, and that reputation is derived from what subnet it's a subset of.
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.
Sounds good to me.
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.
Yes, which will be less than effective when customers are handed /48s and
can send from anything within that /48.
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.
RIPE already does (basically), as in "this /42 contains customers where
each customer has a /56". I don't know about other RIRs.
--
Mikael Abrahamsson email: swmike(_at_)swm(_dot_)pp(_dot_)se
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg