Re: DNSBL and IPv6

"Emanuele Balla (aka Skull)" <[email protected]>
Newsgroups gmane.ietf.asrg
Message-ID <[email protected]>
On 10/25/12 5:37 PM, Paul Smith wrote:
> On 25/10/2012 15:37, Emanuele Balla (aka Skull) wrote:
> 
>> For point 1, there will be a limit to this change rate, at least when we
>> speak about bots, and it's even been cited here already: a single
>> machine can't use too many addresses without saturating its router
>> neighbor table.
>> Which is a valid esteem for the number of different IPs the
>> IPv6-address-change-mechanism will be able to use effectively, then?
>> Truth is we don't know for sure...


> Hmm - I've heard talk about this problem of saturating the router
> neighbour table. To be honest, I'm not entirely sure what a 'neighbour
> table' is...

Basically, the ARP table, except for IPv6 not using ARP at all...

> But, why would people have a /64 block if the router can't
> cope with it?

The point is a /64 allows basically an infinite number of devices in one
single network (2^64 being big enough to be considered infinite for our
purpose).

This doesn't mean a router should be able to manage an infinite amount
of devices: no router could accomplish this requirement... :-)

The router basically needs to cope with a given number of devices inside
the /64. Maybe 10, maybe 100, maybe 1000, but a limited amount, compared
to 2^64. The neighbor table must be able to keep track of IPv6-MAC
associations for each device.

But if one of these devices starts changing address quickly enough, it's
going to saturate the router memory (or only the neighbor table) at some
point...

What happens next depends on how the router will manage the issue...



-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.