Re: IPV6 and routing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]