[libvirt] IPV6 and routing

[Gene Czarcinski]

On 10/07/2012 06:28 AM, Gene Czarcinski wrote:
> On 10/06/2012 05:29 PM, R P Herrold wrote:
>> On Sat, 6 Oct 2012, Gene Czarcinski wrote:
>>
>>> OK, what am I missing? What don't I understand?
>>>
>>> If IPv6 is going to be useful in virtualization, then there must be 
>>> some "easy" way to have other systems understand that the 
>>> virtualization host is acting as a router for the virtual IPv6 
>>> networks it runs. While being able to go between the virtualization 
>>> hosts and the virtual guests is very useful, I do not consider this 
>>> sufficient.
>>
>> We programatically, on a per VM basis, set up our ebtables and 
>> iptables rules at pmman.com (thus my 'ROADMAP' question earlier this 
>> week). Under RHEL 6's (and thus CentOS') KVM and libvirtd stock 
>> setup, there was a built-in filter as provided by libvirtd install -- 
>> as I recall: a 'clean-traffic' filter -- that we had to amend out, 
>> compared to prior xen setups under the earlier RHEL variant
>>
>> Have you dumped and examined the running rules affecting IPv6 traffic?
>>
>> -- Russ herrold
>>
>>
> The ip6tables rules look fine. The problem is not that the packets are 
> not sent to the target .... they are .. I ran wireshark on the 
> target's NIC. The problem is getting the response back to the 
> virtualization host.
>
> Shortly after I wrote my message I "discovered" something called 
> "neighbor discovery proxy" and two attempts at implementing it: npd6 
> and ndppd. This is the RFC: http://tools.ietf.org/html/rfc4389
> and here is a short description from npd6:
>> If you have a Linux gateway router terminating your ISP feed 
>> supporting IPv6, this may be just what you need. To summarise the 
>> problem it solves: your ISP has given you an /64 (or some other size) 
>> IPv6 prefix, with the last 64 bits (or whatever) entirely for your 
>> own use on a private-side of the network. The IPv6 addresses in use 
>> by your own devices may well not even be known to you – it’s possible 
>> that you use DHCP6 to statically pre-allocate them (yuck!) or more 
>> likely you are using /radvd/ on the gateway to advertise the 
>> ISP-supplied IPv6 prefix and let the devices themselves choose what 
>> they wish to tag on to that. It may be vaguely predictable (based 
>> upon the device’s Ethernet MAC address) or totally unpredictable (as 
>> per the Windows 7 box I looked at the other day!)
> ...
>>
>> And to do this today you need to /statically pre-configure/ that full 
>> address into the Linux system. And if it changes, you need to change 
>> it. And if a new one appears, you need to ad it. And so on. Oh, and 
>> to add insult to injury, you cannot even display a list of which ones 
>> you have already configured in the system!!
>>
>> And thus I offer npd6 as a solution: it runs on the gateway, and 
>> requires little configuration. You tell it your prefix and which is 
>> the ISP’s interface. There are a few optional knobs and levers. Then 
>> it runs and automatically responds to /any/ Neighbor Solicitation 
>> received from the ISP for a device with your prefix.
>>
>
> This "sounds" like it may be a solution and I have started some 
> testing to see if and how they work.
>
>
The more I look into this, the more I do not like the answer but it is 
what it is.

First of all, ND-proxy is not the answer.  Even if I could get it to 
work on one network, it would not "turn the corner" to another network.

Unfortunately, radvd is not the answer either.  Although I can configure 
radvd on the virtualization host, the router advertisements it does are 
ignored (by RFC requirement) by the system having the default route.  As 
far as I can see, the only thing that a RA is good for is establishing 
the default route.

As things currently exist, I have come to the conclusion that there are 
two answers that will work.

1. Manually configure the IPv6 address/network on the virtualization 
host.  On the default route system, add a static route to the 
virtualization host.  Things will then work.

2.  It hurts, don't do it: use a bridge in the virtualization host for 
IPv6 virtual networks which need to access external systems.

BTW, this is also needed for support of IPv4 routed networks.  This can 
be made a little easier by using 172.16.<nn>.0/24 networks and adding a 
single static route for 172.16.0.0/16.

But for IPv6, there is just a lot of stuff that only works for networks 
with a 64 prefix.  When other prefixes (greater or lesser) are 
specified, things get "strange."  By RFC definition, RA only works with 
prefix=64.

There is a form of nat for IPv6 in the works ("prefix translation") in 
ip6tables.  But, time will tell on how useful that will be.

Gene