How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")
Justin M. Streiner
streiner at cluebyfour.org
Fri Oct 2 15:05:21 UTC 2015
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.
More information about the NANOG