IPv6 black lists?

[Jeroen Massar]

[******************

Quick Sidenote:
http://www.sixxs.net/tools/grh/dfp/

RIPE: "Thus 1049 (51.07%) networks are currently correctly announced."
ARIN: "Thus 472 (37.97%) networks are currently correctly announced."
APNIC: "Thus 327 (36.41%) networks are currently correctly announced."

Come on US and Asia, you can do better than that!!!
And that is just routing the thing, not even getting connectivity to any
of your users, thus far from hard at all...

I find it good to see that ISPs actually get a prefix, I find it very
BAD that they are not even bothering announcing it, thus clearly they
just reserve them and then maybe one day they'll turn it on. Better
start doing that sooner than later folks!

(most of the ARIN prefixes are /48s, while most of the RIPE prefixes are
/32's btw)

*****************]

Mikael Abrahamsson wrote:
> On Wed, 10 Mar 2010, Mark Schouten wrote:
> 
>> customers. With IPv6, a /64 is a site-network. So the chance that many
>> customers reside in this /64 isn't that big. Router-advertisements only
>> work in a /64, so you would be really dumb if you start chopping
>> up /64's to different customers.
> 
> I'd say it's going to be quite common that there are multiple customers
> in a single /64.

Customers (eg sharing one host with one IP address) or hosts (eg sharing
one host with multiple IPs) or different hosts (one host per customer).
In the case of the middle one compromising one host would compromise all
those IPs.

What one has to see though is that a Black List should be used for
*SCORING* as such. If you have a BL that lists a /64 (because it
triggered virusses/spams/whatevermetric from 5 different /128s) then you
know "the people operating this /64 is not cleaning up quick enough".

Outright blocking/rejecting on that kind of information is of course
silly. If you have a database which you 100% trust to have absolutely no
false-positives then you might want to consider indeed directly rejecting.

IMHO the metric of about /128, 8 of those -> /64, 16 of those -> /48,
128 of those /32 is a good one. Larger prefixes will be covered in the
same way as they will just be hurt per /32 of their /13 (oh yeah, that
is possible, to get a chunked up /13 from ARIN; they still haven't
figured out this aggregation thing and seem to endorse de-aggregation
already in the registry).

Clearly if the ISP is not cleaning their mess up, then there is not much
need to accept their nonsense. Still *SCORING* it is the keyword here.
The Black List will then help a lot (maybe 50% of the score) to push the
score into the 'reject' category. Of course in the case of SMTP, always
do 'SMTP reject after DATA' and don't go accepting the email and then
bounce it because you actually didn't like what you got.
Sending a DSN then will just cause some innocent From: address to get
flooded.

> There really should be some kind of mechanism so the ISP can indicate
> entity/subnet relationship

There is whois.ripe.net ;)

Maybe try and get the RIPE-DB folks to add an RPSL property stating what
kind of usage the network has and hoping that BL providers use that
information.

Of course that requires people to actually fill in information there and
people seem to be reluctant to do so.


Additional note there: whois.ripe.net can ALSO be used for non-RIPE
blocks. This is especially handy for people who want to let the rest of
the world know about their routing policies in the form of IRR data.
whois.ripe.net already has a large amount of data there thus don't
hesitate to add your own!

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100310/105a664e/attachment.sig>