[184461] in North American Network Operators' Group
Re: How to wish you hadn't forced ipv6 adoption (was "How to force
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sat Oct 3 15:45:57 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <Pine.LNX.4.64.1510021054450.8117@whammy.cluebyfour.org>
Date: Sat, 3 Oct 2015 12:44:23 -0700
To: "Justin M. Streiner" <streiner@cluebyfour.org>
Cc: nanog group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> On Oct 2, 2015, at 08:05 , Justin M. Streiner =
<streiner@cluebyfour.org> wrote:
>=20
> On Fri, 2 Oct 2015, Rob McEwen wrote:
>=20
>> it then seems like dividing lines can get really blurred here and =
this statement might betray your premise. A site needing more than 1 =
address... subtly implies different usage case scenarios... for =
different parts or different addresses on that block... which could slip =
back into... "you blocked my whole /48... but the spam was only coming =
from this tiny corner of the block over here (whether that be a one IP, =
a /64, or a /56)... and now other parts of the block that were sending =
out legit mail, are suffering".
>>=20
>> Likewise, sub-allocations can come into play, where a hoster is =
delegated a /48, but then subdivides it for various customers.
>=20
> That touches on the tough part of doing things like ingress/egress =
filtering
> and spam blacklisting for IPv6. Net every network assigns IPv6 space =
to
> end-users the same way, and even fewer still provide good data on how =
they
> assign to end-users (SWIP, rwhois, etc). Networks that are blocking =
traffic are left to make a decision that straddles the line between =
providing the necessary level of protection for their services and =
minimizing the potential of collateral damage by blocking legitimate =
traffic from other users.
Or you can take the approach that there are guidelines published out =
there that encourage /48 per end-site, /64 per subnet, and figure that =
anyone who chooses to do otherwise has brought about their own problems.
> Blocking a single IPv6 address is generally not effective because it's =
trivial for a host to switch to a different address in the same /64, and =
hosts that have privacy extensions enabled will do so with no further =
action needed by the owner. This turns into an endless game of =
whack-a-mole. The same thing can happen with blocking /64s.
Which is why I advocate playing a very short game of whack-a-mole with =
the first few /64s inside a given block and then detecting a =E2=80=9Cpatt=
ern of abuse=E2=80=9D that leads to blocking on a larger level (/48, =
/32, shorter?).
>=20
> It's often not clear if provider XYZ is assigning /56, /48, or =
something else to end-users, especially if the provider doesn't provide =
any publicly accessible information to that end.
Who cares=E2=80=A6 If they are shortchanging their customers in this =
way, they have created their own pain. It=E2=80=99s not your fault.
Owen
