IPv6 black lists?
Benedikt Stockebrand
me at benedikt-stockebrand.de
Fri Mar 12 13:47:29 CET 2010
Hi Gert and list,
Gert Doering <gert at space.net> writes:
> There are no other customers in the same /64 subnet.
ok, so how do you do that as a mass web hoster with >60k machines
(e.g. United Internet, last time I talked to them) if your customers
expect both IPv4 and IPv6 to work? Put every machine in its own
subnet?
At Spacenet you might be able to do that, but in the low cost hosting
business it doesn't necessarily work. (Neither does it when you are
running the WLAN infrastructure at a large event---CeBIT immediatly
comes to mind.)
And don't discount the low cost business as irrelevant -- the Internet
we have today was effectively funded by those pesky "I want it cheap"
end users.
BTW, there's a BSI (Federal Office for IT Security (in Germany))
project working on an IPv6 security guideline. Among other things we
(I'm one of the authors) strongly suggest to use a network topology
with "many small subnets" to get rid of a number of problems. The key
drawback of such a topology is that means you can't deploy IPv6 that
way along an existing ("NetBIOS-style") IPv4 topology with few large
subnets. That implies that dual-stacked subnets are troublesome and
should be used only for servers in "normal" (i.e. government and
medium-to-large business) setups, but unfortunately that's exactly
where hosters aren't "normal" and have to come up with a more
elaborate solution.
> Please repeat.
>
> There are no other customers in the same /64 subnet.
Again, don't assume everybody on the Internet to have the same
problems as you. One-size-fits-all approaches don't work well if the
the user base is as diverse as on the Internet.
And just repeating a mantra over and again doesn't make it right, it
only makes you believe in it:-)
>> Tell that to people in the low cost end user hosting business. With
>> business customers you are right, because they tend to be willing to
>> pay a bit more for reliable service at least to some degree, but end
>> users frequently think quite differently.
>
> What's so hard to understand about "... deserve all the pain you can get"?
Just because you can't hit the people causing the trouble that doesn't
give you the right to wantonly hit arbitrary bystanders instead.
Because your neighbor down the street bumped into my car doesn't give
me the right to blow up yours.
I am well aware that it is sometimes helpful to put some indirect
pressure on the people providing the infrastructure for spammers and
whatever, but doing so in this case and at this point will deter
people from approaching IPv6. That's a Bad Thing.
> Companies like Strato that have multiple customers in the same /64
> *have filters in place* to make sure that every customer will only
> use the set of addresses assigned to his server, and nothing else.
>
> This model of deployment is more complicated than "just slap a /64 on
> it, and every customer can run abuse from whatever address he wants to
> pick" - but it's the only way to be able to do any sort of abuse handling,
> not only SPAM.
Let me repeat: "There are no other customers in the same /64 subnet."
Sorry:-)
I never said you should do this entire thing without some kind of
filter mechanism. If you set up your filters to filter by /128,
that's fine if your filters offer the functionality and performance,
but as soon as people want multiple addresses (for virtual machines,
zones, jails, or just multiple services) then these filters get even
uglier than they are today.
And to get back to the blacklisting topic: If you dish out prefixes
anywhere from /$((128-$threshold)) to /65, that causes exactly the
problem the IPv6 "movement" has the least possible use for: Eventually
the entire /64 gets blacklisted and other people are affected in a way
that drives them back to IPv4.
> How are you going to trace back hacked machines etc. if you can't reliably
> associate a given IPv6 address with a given server?
Just to show that there are alternatives: One could do it the FC way,
using static ARP (IPv4) and ND (IPv6), preferably together with a
statically configured MAC-port mapping on your switches (if your
switch vendor supports this and you find out how they call it).
As far as I understand it, UI uses IPv4 "as is" and then tunnels IPv6
prefixes to individual customer machines (unfortunately, they only
give out /56'es). When I first heard about that I thought they had
been smoking some rather bad stuff, but that approach actually avoids
the entire dual-stack topology issue even in their kind of business
and even with virtual servers.
Yet another solution would be to put every customer into their own
subnet, giving them their own /64, and then set up IPv4 using
point-to-point routes to preserve IPv4 addresses. And no, that's not a
recommendation either, just to point out that there are alternatives.
Whatever you do to deal with the dual-stack issue, it's going to be
ugly one way or the other. You can only try to find the way that's
the least ugly for your particular needs.
> And if you can't do that, you shouldn't run an ISP.
Now you're talking sense:-)
Cheers,
Benedikt
--
Business Grade IPv6
Consulting, Training, Projects
Dipl. Inform. Tel.: +49 (0) 69 - 247 512 362
Benedikt Stockebrand Mobil: +49 (0) 177 - 41 73 985
Fichardstr. 38 Mail: me at benedikt-stockebrand.de
D-60322 Frankfurt am Main WWW: http://www.benedikt-stockebrand.de/
Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen
Umfragen. Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet.
No spam, no unsolicited sales calls, no telephone surveys, please. Calls
may be recorded for legal purposes.
More information about the ipv6-ops
mailing list