ndp

[6***@6bone.informatik.uni-leipzig.de]

hello,

exists there a maximum size of the ndp table? how can I determine the maximum
number of entries?

currently 'ndp -a | wc -l' reports 1492 entries and I am not sure if is a
problem or not.


thank you for your efforts

regards
Uwe

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ignatios Souvatzis]

Post by 6***@6bone.informatik.uni-leipzig.de
exists there a maximum size of the ndp table? how can I determine
the maximum number of entries?
currently 'ndp -a | wc -l' reports 1492 entries and I am not sure if
is a problem or not.

*Currently*, the ndp and the arp table are implemented as part of
the routing PATRICIA tree (but have link-level addresses instead of
network addresses as next-hop). So there's no limit different other
than the general routing table limitations. Hm, I think mostly
kernel memory limitations.

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Lars Schotte]

it should not be a problem and when there is a problem, it would be a bug.

the most big switches support up to 4K or 8K addresses, so you are with your 1500
MAC addresses in the middle of it. why would you have a switch that supports 8000
MAC addresses in one network, when your operating system would not handle that.

that would be pitty, wouldn't it?

On Mon, 18 Feb 2013 10:57:11 +0100

Post by Ignatios Souvatzis

Post by 6***@6bone.informatik.uni-leipzig.de
exists there a maximum size of the ndp table? how can I determine
the maximum number of entries?
currently 'ndp -a | wc -l' reports 1492 entries and I am not sure if
is a problem or not.

*Currently*, the ndp and the arp table are implemented as part of
the routing PATRICIA tree (but have link-level addresses instead of
network addresses as next-hop). So there's no limit different other
than the general routing table limitations. Hm, I think mostly
kernel memory limitations.
-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Fernando Gont]

Post by Ignatios Souvatzis

Post by 6***@6bone.informatik.uni-leipzig.de
exists there a maximum size of the ndp table? how can I determine
the maximum number of entries?
currently 'ndp -a | wc -l' reports 1492 entries and I am not sure if
is a problem or not.

*Currently*, the ndp and the arp table are implemented as part of
the routing PATRICIA tree (but have link-level addresses instead of
network addresses as next-hop). So there's no limit different other
than the general routing table limitations. Hm, I think mostly
kernel memory limitations.

That is actually a problem: it can be exploited for DoS purposes. --
even a remote address scanning attack might cause that as a side effect.

Cheers,
--
Fernando Gont
e-mail: ***@gont.com.ar || ***@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Fernando Gont

On Mon, Feb 18, 2013 at 07:40:58AM +0100,

Post by 6***@6bone.informatik.uni-leipzig.de
exists there a maximum size of the ndp table? how can I determine
the maximum number of entries?
currently 'ndp -a | wc -l' reports 1492 entries and I am not sure if
is a problem or not.

*Currently*, the ndp and the arp table are implemented as part of
the routing PATRICIA tree (but have link-level addresses instead of
network addresses as next-hop). So there's no limit different other
than the general routing table limitations. Hm, I think mostly
kernel memory limitations.

That is actually a problem: it can be exploited for DoS purposes. --
even a remote address scanning attack might cause that as a side effect.

That may be true of most uses of a routing-table like structure. I
am inclined to keep mechanisms for limits on entries separate from the
data structure choice, because what I think we want is resilience
against attack and good performance in normal cases.

[George Michaelson]

Post by Fernando Gont
That is actually a problem: it can be exploited for DoS purposes. --
even a remote address scanning attack might cause that as a side effect.
Cheers,

I have accidentally participated in an apparent DoS like this, when a
diagnostic 'is IPv6 working' account I hosted leaked to the wrong /32 and
an ISP somewhere in South America started to get saturated by a walk
across their announced space.

I believe there are commercial implementations of switch logic which do
some kind of ageing out of the ND cache to set limits on growth. Maybe a
Ptree for this stuff in NetBSD needs a timer, and a background process to
mark/sweep idle entries.

-G



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Lars Schotte]

routing the "wrong /32" should not happen. at least it should be impossible to
connect to each other. that would be a hard misconfiguration on more places.
that would only prove how badly it looks like to our planet's internet.

neighbor discovery does also give each node a timeout, so nodes that are not powered
on should not appear in the table.

On Wed, 20 Feb 2013 00:52:25 +0000 (UTC)

Post by George Michaelson
I have accidentally participated in an apparent DoS like this, when a
diagnostic 'is IPv6 working' account I hosted leaked to the wrong /32 and
an ISP somewhere in South America started to get saturated by a walk
across their announced space.
I believe there are commercial implementations of switch logic which do
some kind of ageing out of the ND cache to set limits on growth. Maybe a
Ptree for this stuff in NetBSD needs a timer, and a background process to
mark/sweep idle entries.
-G

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Lloyd Parkes]

Post by George Michaelson

Post by Fernando Gont
even a remote address scanning attack might cause that as a side effect.

I have accidentally participated in an apparent DoS like this,

So, the slightly rhetorical question is, why do we have entries in the NDP cache for hosts that don't exist?

I'm not 100% comfortable with cleanup threads and timers because they don't actually stop the data structure from becoming full, they just place a time limit on how long you can spend filling up the data structure. If incomplete or negative NDP entries were stored in a separate data structure from NDP cache, then a safer data structure could be used. An LRU cache or similar would result in entries being discarded when the cache is full rather than after a set time, but since this is only for incomplete or negative NDP entries, this is no great sin. An LRU cache would add a few cycles to the time taken for neighbour discovery, but that's no great sin either.

It should also be possible to borrow (very loosely) from the SYN cache & cookie hybrid to allow a fallback to some sort of stateless NDP. That would require more care and attention than I'm prepared to put into this email message though.

Cheers,
Lloyd
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Laight]

Post by George Michaelson
I have accidentally participated in an apparent DoS like this, when a
diagnostic 'is IPv6 working' account I hosted leaked to the wrong /32 and
an ISP somewhere in South America started to get saturated by a walk
across their announced space.
I believe there are commercial implementations of switch logic which do
some kind of ageing out of the ND cache to set limits on growth. Maybe a
Ptree for this stuff in NetBSD needs a timer, and a background process to
mark/sweep idle entries.

A background process won't run at the required interval - under stress
it won't be often enough, and the rest of the time it is too often.

If you just timestamp the entries you can prune idle ones during insert
(which is code that will already have the tree write locked).
The code also need only worry about items it the branch of the tree
it is processing.

David

[6***@6bone.informatik.uni-leipzig.de]

the netbsd router is connected to a nexus 7k. I am using a port-channel
with diffent vlans. the ipv6 routing point for the vlans is the netbsd
box.

The MAC address table on each nexus line card supports 128,000 MAC
addresses. Our nexus currently knows over 10.000 MAC Adresses.

If I now increase the number of vlan (and routing points) at the ipv6
router, the ndp table will increase over 4k over 8k and maybe over 16k
(because each node has a link-local and a global address, windows nodes
and ipv6 address-privacy). So I need to know the korrekt size of the ndp
table.



Regards
Uwe

Post by Lars Schotte
it should not be a problem and when there is a problem, it would be a bug.
the most big switches support up to 4K or 8K addresses, so you are with your 1500
MAC addresses in the middle of it. why would you have a switch that

supports 8000

Post by Lars Schotte
MAC addresses in one network, when your operating system would not handle that.
that would be pitty, wouldn't it?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de