Comment 30 for bug 1302080

Attaching debug log from nova-compute, as requested.

While it's true that a 2001:db8 prefix used for testing wouldn't be globally available, that's kind of besides the point, I think. Nobody would use 2001:db8-prefixes in production - there's no NAT or floating IPs in IPv6, so any production deployment of IPv6 will necessarily use globally reachable prefixes and likely RAs with the A-flag set, and thus be vulnerable to unauthorised access to the compute node.

I've tested briefly and I have not been successful in accessing the link-local address on the tap device from the instance or from bare-metal hosts outside of OpenStack residing on the same network. There's no response to ICMPv6 neighbour solicitations, and if I configure a static neighbour entry on the instance or the bare-metal host with the MAC address of the tap or brq device, the packets simply go unanswered. However, considering that the tap device is there only to provide forwarding at layer-2, it does strike me as wrong that there is active layer-3 configuration on it. For all I know, the fact that I cannot reach the link-local address from the instance is dependent on logic in the Linux kernel of the compute node which could change in the future. Therefore I think it would be prudent to set the disable_ipv6 sysctl on this device as well. Considering that disable_ipv6 does get set on the network node, it also seems more consistent that the same thing should happen on the compute nodes.