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

["Justin M. Streiner" <streiner () cluebyfour org>]

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.

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.

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.

jms