Subject: bogus route announcements on IETF wireless LAN

From: Simon Leinen <[email-masked]>
Date: Wed, 4 Aug 2004 03:01:45 +0200

For some of us, IPv6 isn't really usable here at the IETF meeting,
because there are so many bogus route announcements.  At the moment, I
see four 6to4 prefixes (two of them with RFC1918 base addresses, no
idea where those come from), one site-local prefix, and two prefixes
from the IETF meeting range - no idea which of these would work.

If my host implemented RFC 3484, I could probably deprecate all these
prefixes, but unfortunately it doesn't.  So I have to disable
stateless address autoconfiguration (which is a pain) or use IPv4 :-(

So PLEASE turn off IPv6 router advertisements on your laptops.

Thanks!
-- 
Simon.

: root@acer[leinen]; ip -6 addr list dev eth1
5: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qlen 1000
    inet6 2002:c0a8:9101:7:202:2dff:fe84:f7d0/64 scope global dynamic 
       valid_lft 171085sec preferred_lft 85sec
    inet6 2002:c0a8:3401:7:202:2dff:fe84:f7d0/64 scope global dynamic 
       valid_lft 171085sec preferred_lft 85sec
    inet6 2002:8281:870f:6:202:2dff:fe84:f7d0/64 scope global deprecated dynamic 
       valid_lft 170528sec preferred_lft -472sec
    inet6 2002:8281:80a8:6:202:2dff:fe84:f7d0/64 scope global deprecated dynamic 
       valid_lft 161046sec preferred_lft -9954sec
    inet6 fec0::6:202:2dff:fe84:f7d0/64 scope site deprecated dynamic 
       valid_lft 170528sec preferred_lft -472sec
    inet6 2001:240:5bf:128:202:2dff:fe84:f7d0/64 scope global dynamic 
       valid_lft 2592000sec preferred_lft 604800sec
    inet6 2001:240:5bf:140:202:2dff:fe84:f7d0/64 scope global dynamic 
       valid_lft 2591984sec preferred_lft 604784sec
    inet6 fe80::202:2dff:fe84:f7d0/64 scope link 
       valid_lft forever preferred_lft forever
: root@acer[leinen]; ip -6 route list
2001:240:5bf:128::/64 dev eth1  proto kernel  metric 256  mtu 1500 advmss 1440 metric10 64
2001:240:5bf:140::/64 dev eth1  proto kernel  metric 256  mtu 1500 advmss 1440 metric10 64
2002:8281:80a8:6::/64 dev eth1  proto kernel  metric 256  expires 16115sec mtu 1500 advmss 1440 metric10 64
2002:8281:870f:6::/64 dev eth1  proto kernel  metric 256  expires 17063sec mtu 1500 advmss 1440 metric10 64
2002:c0a8:3401:7::/64 dev eth1  proto kernel  metric 256  expires 17119sec mtu 1500 advmss 1440 metric10 64
2002:c0a8:9101:7::/64 dev eth1  proto kernel  metric 256  expires 17119sec mtu 1500 advmss 1440 metric10 64
fe80::/64 dev eth1  metric 256  mtu 1500 advmss 1440 metric10 64
fec0:0:0:6::/64 dev eth1  proto kernel  metric 256  expires 17063sec mtu 1500 advmss 1440 metric10 64
ff00::/8 dev eth1  metric 256  mtu 1500 advmss 1440 metric10 1
default via fe80::20b:fcff:fe57:3c1b dev eth1  proto kernel  metric 1024  expires 179sec mtu 1500 advmss 1440 metric10 64
default via fe80::205:8500:8c86:cdb dev eth1  proto kernel  metric 1024  expires 171sec mtu 1500 advmss 1440 metric10 64
default via fe80::205:8500:8086:cdb dev eth1  proto kernel  metric 1024  expires 179sec mtu 1500 advmss 1440 metric10 64
default via fe80::204:23ff:fe78:827e dev eth1  proto kernel  metric 1024  expires 506sec mtu 1500 advmss 1440 metric10 64
default via fe80::204:23ff:fe7a:fb3e dev eth1  proto kernel  metric 1024  expires 561sec mtu 1500 advmss 1440 metric10 64
unreachable default dev lo  proto none  metric -1  error -101 metric10 255

---

From: Tim Chown <[email-masked]>
Date: Wed, 4 Aug 2004 06:18:10 +0100

> stateless address autoconfiguration (which is a pain) or use IPv4 :-(

Maybe, but it would be interesting to see which OS's actually implement
this properly.

> So PLEASE turn off IPv6 router advertisements on your laptops.

One other possibility is to see what sort of support there is for the
default router preferences method (draft-ietf-ipv6-router-selection) such
that the "proper" RA could be made with a high priority, and any client
observing that priority could ignore all the "accidental" medium (default)
priority RAs from laptops/etc.   What's the implementation status of this
draft?

Of course the flip side will be "errant" nodes advertising high priority 
routes in a network where the default RA priority is the desired one...

Tim

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 04 Aug 2004 15:51:03 +0900

>>>>> On Wed, 4 Aug 2004 03:01:45 +0200, 
>>>>> Simon Leinen <[email-masked]> said:

> stateless address autoconfiguration (which is a pain) or use IPv4 :-(

I'm not sure what you mean by "deprecate", but, anyway, RFC3484 cannot
be a perfect solution to this kind of problem, depending on your
destination addresses.

Meanwhile, we've developed an administration tool to invalidate such
bogus routers and prefixes.  The tool runs configured with known bogus
prefixes.  If it receives an RA containing a bogus prefix, it sends
a "forged" RA spoofing the source address back to the link, in which
  - the source IP address is the source of the bogus original RA
  - the router lifetime is 0
  - the preferred and valid lifetimes are both 0

The 0 router lifetime will remove the router from the default router
list immediately.  The 0 preferred lifetime will deprecate (in the
sense of RFC2462) addresses configured from the bogus prefix
immediately.

It's still not a perfect solution, but should be quite effective.

The source code of the tool is available at the following URL:
http://orange.kame.net/dev/cvsweb2.cgi/kame/kame/kame/rafixd/

I'm afraid it doesn't compile on other systems than BSD, but it would
be nice if someone in the IETF network admin could run such a tool.

Disclaimer: as you can easily imagine, the tool could also be used to
cause a DoS attack.  But we are always under the risk of this type of
DoS even without this particular tool.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]