How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

Owen DeLong owen at
Sat Oct 3 19:44:23 UTC 2015

> On Oct 2, 2015, at 08:05 , Justin M. Streiner <streiner at> wrote:
> On Fri, 2 Oct 2015, Rob McEwen wrote:
>> 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".
>> Likewise, sub-allocations can come into play, where a hoster is delegated a /48, but then subdivides it for various customers.
> 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 “pattern of abuse” that leads to blocking on a larger level (/48, /32, shorter?).

> 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… If they are shortchanging their customers in this way, they have created their own pain. It’s not your fault.


More information about the NANOG mailing list