> On Oct 2, 2015, at 08:05 , Justin M. Streiner <strei...@cluebyfour.org> 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. Owen