Request to participate in 2-min study survey on IPv6 Adoption

Mon Jan 31 14:46:17 UTC 2022

Matt Harris|Infrastructure Lead
816-256-5446|Direct
Looking for help?
Helpdesk|Email Support
We build customized end-to-end technology solutions powered by NetFire Cloud.
On Sun, Jan 30, 2022 at 7:07 PM Töma Gavrichenkov <ximaera at gmail.com> wrote:

> Peace,
>
> On Thu, Jan 27, 2022, 4:38 PM Smahena Amakran <smahenamakran at gmail.com>
> wrote:
>
>> For my studies, I am researching IPv6 adoption.
>>
>
> For your consideration, there's one thing that's always overlooked.
>
> E.g. I've been talking once to a big employee of a large content provider,
> and that person told me they don't enable IPv6 because doing otherwise
> produces tons of comment spam.
>
> The thing is, we have this spam problem. This is not really the
> "information security issue" you've mentioned, this is just a glimpse of a
> real issue.
>
> IPv6 is now cheap as chips. It's very dirty therefore. All kinds of bots,
> spammers, password brute force programs live in there, and it's
> significantly harder to correlate and ditch these with the sparse IPv6
> address space.
>
> ISPs don't typically focus on these kinds of things but ISPs, speaking of
> large ones, are also typically champions in IPv6 deployment.  It's usually
> content providers who don't do their stuff.  And, as sad as it gets, it's
> not getting away any time soon since it's there for a reason.
>

Have you tried treating a /64 in IPv6 in the same way that you'd treat a
/32 in IPv4 (and thusly, a /32 in IPv6 in the same way you'd treat larger
IPv4 blocks targeting bad provider space, etc?) rather than fighting every
/128? This seems to be a pretty common practice that has worked for others
in dealing with abuse issues on IPv6.

- mdh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220131/0c9ca58b/attachment.html>