Hi. On Wed, Apr 08, 2015 at 10:02:23AM +0200, Vincent Lefevre wrote: > On 2015-04-08 09:57:28 +0300, Reco wrote: > > On Wed, Apr 08, 2015 at 01:35:44AM +0200, Vincent Lefevre wrote: > > > On 2015-04-08 01:41:58 +0300, Reco wrote: > > > > SLAAC is a good thing if the host that advertises RA is an actual > > > > router. If it is not - you get exactly the behavior you got. > > > > > > Thanks for the information. Do you mean that random machines on > > > the network can send fake advertising? > > > > Yes. And by default - every host in a local network segment and their > > dog will accept this RA. Worse - there can be more than one RA > > advertiser on a network segment (and it leads to *very* funny results). > [...] > > > If SLAAC can be a bad thing on arbitrary networks, why is it enabled > > > by default? (IMHO, the default should be the safest.) > > > > Treat SLAAC as DHCP. It's considered pretty normal to run DHCP client in > > a foreign network and trust whatever information DHCP server sends the > > client. Heck, some clients are going that far as setting own hostname > > the way DHCP server told them. > > The only difference being that DHCP requires userspace client > > and SLAAC does not (in Linux). > > OK, so if I understand correctly, the problem I see with SLAAC is > similar to what I would get for IPv4 too with a rogue DHCP server.
Precisely. > > > > The correct way to deal with this then is to disable accepting RAs on > > > > your host: > > > > > > > > echo 1 > /proc/sys/net/ipv6/conf/all/accept_ra > > > > > > I did *not* do that yet, but I can see: > > > > > > ypig:~> cat /proc/sys/net/ipv6/conf/all/accept_ra > > > 1 > > > > > > i.e. it is already 1 (ditto for /proc/sys/net/ipv6/conf/eth0/accept_ra). > > > Or do you mean 0? > > > > My bad. Zero to disable, one to enable. > > OK. I suppose that I should use /etc/sysctl.conf to make this setting > permanent. net.ipv6.conf.all.accept_ra = 0 > > > But on the other machine that doesn't have this "scope global", > > > /proc/sys/net/ipv6/conf/*/accept_ra is also 1, so that I'm confused. > > > > If it's on the same network - check whenever you have ip6tables > > configured on that host. If it's a different network - it's no wonder. > > Yes, they are behind different routers (same place, but different > networks). For the other network, the machines are not administrated > by their end users, so that I suppose that it cannot have these > problems. Oh, then it solves this. By design NDC is limited to one network segment. Unless you're allowing to pass L2 traffic from one network to another - you should not have this problem. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150408083921.GA9544@x101h
