From: Brent Cook <bcook@breakingpoint.com>
To: <netdev@vger.kernel.org>
Subject: Possible DoS with 6RD border relay
Date: Wed, 4 Jan 2012 10:48:44 -0600 [thread overview]
Message-ID: <201201041048.44509.bcook@breakingpoint.com> (raw)
Hi All,
I have been doing some testing of Linux serving as a 6RD border relay. It
seems that if a client sends 6RD-encapsulated packets and varies the lower 64-
bits of the 6RD address over the range of the neighbor table size (the bits
below the delegated prefix), it causes the neighbor table to quickly overflow.
However, viewing the neighbor table never shows more than a handful of
entries. When the neighbor table overflows, packet routing on my test system
slows from 1Gbps to a couple of Mbps at most.
[28765.764079] net_ratelimit: 32003 callbacks suppressed
[28765.764084] ipv6: Neighbour table overflow.
[28765.764171] ipv6: Neighbour table overflow.
root@target1:~# ip neigh
fe80::1a:c5ff:fe02:2 dev test2 router FAILED
2001:1234::3 dev test2 lladdr 02:1a:c5:02:00:02 REACHABLE
192.168.2.1 dev mgmt0 lladdr 04:7d:7b:06:8d:2d REACHABLE
1.0.0.1 dev test0 lladdr 02:1a:c5:01:00:00 REACHABLE
If I send packets much more slowly, the system works as expected. If the 6RD
client sends from a constant address rather than varying the lower bits, it
also works fine. I tested the two neighbor table checks in sit.c and
The network topology looks something like this:
6RD client -> Router -> Linux (6RD BR) -> IPv6 host
The 6RD client is at 1.1.1.1/24
The Linux BR is at 1.0.0.2/24, the IPv4 router is at 1.0.0.1/24 and the IPv6
host is directly attached on a second physical interface at address
2001:1234::3
A configuration script for configuring the BR follows:
#!/bin/bash
PREFIX1="2001:0db8" # 6rd ipv6 prefix
intf1=test0
intf2=test2
modprobe sit
## Setup the tunnel, it will create an interface named '6rd'
ip addr add 1.0.0.2/24 dev $intf1
ip link set $intf1 up
sudo ip route add 1.1.1.0/24 via 1.0.0.1
ip addr add 2001:1234::1/64 dev $intf2
ip link set $intf2 up
ip tunnel add 6rd mode sit local 1.0.0.2 dev $intf1 ttl 64
ip tunnel 6rd dev 6rd 6rd-prefix ${PREFIX1}::/32
ip addr add ${PREFIX1}::1/32 dev 6rd
ip link set 6rd up
sysctl -w net.ipv6.conf.all.forwarding=1
next reply other threads:[~2012-01-04 16:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-04 16:48 Brent Cook [this message]
2012-01-04 17:02 ` Possible DoS with 6RD border relay Brent Cook
2012-01-04 17:25 ` Eric Dumazet
2012-01-04 17:35 ` Brent Cook
2012-01-04 17:53 ` Eric Dumazet
2012-01-04 19:26 ` Brent Cook
2012-01-05 4:22 ` Brent Cook
2012-01-05 19:20 ` David Miller
2012-01-04 17:02 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201201041048.44509.bcook@breakingpoint.com \
--to=bcook@breakingpoint.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).