IPv6 Type 0 Routing Header issues

[Jeroen Massar]

Marco d'Itri wrote:
> On Apr 23, Roger Jørgensen <roger at jorgensen.no> wrote:
> 
>>> Speaking of which, during the last couple of months some folks appear
>>> to have been testing these.  Specifically, our egress source spoofing
>>> filters block some routing header packets between
>>> 2001:AD0:301:1002::/64 (DT-IPV6-EE-TLN-VS1) and 2001:730:5::/48
>>> (NEXTGEN-LAB).  I wonder what those folks are trying to do, maybe test
>>> ingress filters or map topology using 'roundabout' traceroute..
>> 2001:730:5::/48 is the network I control, and the other one I have no idea
>> about. Only thing in that netspace I'm somehow connected to is the
>> eu.irc6.net server that are located in 2001:AD0::/32 netblock.
> 
> It's probably safe to assume that what the original poster is seeing is
> the effect of a linux box with multiple tunnels configured on it but a
> single default route and no policy (source-based) routing.
> I see this often on my SixXS tunnel broker POP, and it's an easy way to
> weed out the users who sign up just for IRC and will attract a DoS
> sooner or later.

Actually, you don't need multiple tunnels for this, it is just
misconfiguration that already does the trick. Just have a /48 or other
prefix routed to a downstream who doesn't have that address or the block
routed to /dev/null or another device. Then when the packet comes there
and a default route is in place, the packet will follow the default
route and bounce back up to where it came from.

What I am wondering here is why devices are not configured to,
per-default, disable this behavior. Aka when a packet comes in on an
interface, don't route it back up that same interface. In general that
is useless. Of course there might be odd cases where it might be useful
(although I actually can't think up a single one), for which a switch
should be supplied to turn this filter off, but it should be there per
default imho.

One sees this a lot for DNS traffic it seems.

Greets,
 Jeroen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 311 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20070423/c0617382/attachment.sig>