[libvirt] IPV6 and routing
Gene Czarcinski
gene at czarc.net
Sun Oct 7 16:10:41 UTC 2012
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
More information about the libvir-list
mailing list