Open pimzand opened 6 years ago
Thank you for getting to the bottom of this! :)
Sent from my iPhone
On Dec 27, 2017, at 9:09 AM, Pim Zandbergen notifications@github.com wrote:
I just closed issue #75 after concluding it was never a radvd issue, but one could argue it is.
Issue #75 describes a problem caused by sysctl setting /proc/sys/net/ipv6/conf/all/forwarding to 1 but leaving /proc/sys/net/ipv6/conf/enp31s0f0/forwarding at 0.
In this case, the kernel will forward IPv6 traffic from and to enp31s0f0, but Neighbor Advertisements sent from this interface will have the "router" flag set to 0.
When using radvd on this interface, radvd will advertise its address as a router nonetheless.
This will cause Windows hosts to add a route each time a router advertisement is received, and to drop that route each time a neighbor advertisement is received from that address. Eventually, Windows hosts will permanently drop the route, and start ignoring all router advertisements until the network link is dropped or the host is restarted.
radvd does check whether the system is actually a router, by checking the value of /proc/sys/net/ipv6/conf/all/forwarding. If radvd would check forwarding for the specific interface, here /proc/sys/net/ipv6/conf/enp31s0f0/forwarding, this issue could have been prevented.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
Hi, I'm fairly new to radvd because I'm trying to add IPv6 to my LAN. Maybe this is not the right place to ask, but I have a legitimate question which I think is related to this issue. I'd like to know if there is a reason at all for radvd to check /proc/sys/net/ipv6/conf/all/forwarding
in the first place, instead of individual /proc/sys/net/ipv6/conf/<interface>/forwarding
, since we can choose which interface to bind to in /etc/radvd.conf
.
For example: I tried radvd on a server which has several network interfaces (macvlan virtual ones, but I think that's not relevant here) and one virtual bridge (for libvirt/QEMU virtual machines; purely virtual bridge, not attached to any physical device). Let's say that, since I'm not too familiar with IPv6 yet, I don't want to route anything between the different networks for now, but only use radvd to advertise a network prefix, and only for the LAN (so, no routing between the physical and virtual networks, and certainly not to the Internet) .
So I wrote a simple /etc/radvd.conf
:
interface mvl1 {
AdvSendAdvert on;
prefix fdxx:xxxx:xxxx:xxxx::/64 {};
RDNSS fdxx:xxxx:xxxx:xxxx::1 {};
DNSSL example.com {};
};
In that precise case, why do I have to enable IPv6 forwarding for all interfaces (including vbr0, which is the virtual bridge), instead of only for mvl1 ? Is there a technical reason (historical or otherwise) for that ?
Raphaël Halimi notifications@github.com wrote:
Hi, I'm fairly new to radvd because I'm trying to add IPv6 to may LAN. Maybe this is not the right place to ask, but I have a legitimate question which I think is related to this issue. I'd like to know if there is a reason at all for radvd to check /proc/sys/net/ipv6/conf/all/forwarding in the first place, instead of individual /proc/sys/net/ipv6/conf/
/forwarding, since we can choose which interface to bind to in /etc/radvd.conf.
I totally agree. I think that it comes from KAME's original BSD code that basically insisted that the host be either a router or a host, and didn't comprehend that it might have different roles on different interfaces.
> anything between the different networks for now, but only use radvd to
> advertise a network prefix, and only for the LAN (so, no routing
> between the physical and virtual networks, and certainly not to the
> Internet) .
And, it's totally legitimate to not advertise a default route too, in which case it doesn't matter if one will forward packets or not.
I suspect that the test does reduce a great number of newbie mistakes though.
I just closed issue #75 after concluding it was never a radvd issue, but one could argue it is.
Issue #75 describes a problem caused by sysctl setting /proc/sys/net/ipv6/conf/all/forwarding to 1 but leaving /proc/sys/net/ipv6/conf/enp31s0f0/forwarding at 0.
In this case, the kernel will forward IPv6 traffic from and to enp31s0f0, but Neighbor Advertisements sent from this interface will have the "router" flag set to 0.
When using radvd on this interface, radvd will advertise its address as a router nonetheless.
This will cause Windows hosts to add a route each time a router advertisement is received, and to drop that route each time a neighbor advertisement is received from that address. Eventually, Windows hosts will permanently drop the route, and start ignoring all router advertisements until the network link is dropped or the host is restarted.
radvd does check whether the system is actually a router, by checking the value of /proc/sys/net/ipv6/conf/all/forwarding. If radvd would check forwarding for the specific interface, here /proc/sys/net/ipv6/conf/enp31s0f0/forwarding, this issue could have been prevented.