[Devel] Re: [Users] 2.6.18-ovz028test015 and 2.6.18-ovz028test018 break IPv6

[Kirill Korotaev]

Michael,

Some more comments below from Alexey Kuznetsov (ipv6 maintainer),
he was not subscribed, so I added his answers below and put him on CC.

> 	Introduction...  I've been on the users list for a while and just
> joined the developers list.  Excuse the cross post but I'm not sure
> which would be most appropriate.
> 
> 	I work extensively with IPv6.  All of my devices are configured for
> IPv6 and I actively participate in the global IPv6 network and have for
> over 5 years.  I'm a member of the North American v6 Task Force,
> NAv6TF.org.  My name servers, ntp servers, smtp servers, and web servers
> all show active IPv6 traffic and have for years.  I'm also a big user of
> VMware and I'm also the author of an IPv6 paper that's up on their site
> somewhere.
> 
> 	So, I'll prefix this with a bit of a rant.
> 
> 	<Rant>
> 
> 	I don't use venet.  The way it's implemented, especially vis-a-vis
> IPv6, it makes no sense to me at all.  the venet0 devices have no
> hardware / mac layer addresses so how is IPv6 neighbor discovery and
> autoconfiguration protocols suppose to work?
Obviously, autoconfiguration does not make sense with venet.
If you want to see autoconfiguration working you use veth, not venet.

In venet approach all the address handling is made in host system.
Virtial environment itself are not _permitted_ to intervene, hence
autoconfiguration just does not make sense. All the addresses and routing
are made by host system and setup by host system.
This is not "IPv4 mind-think cocoon", it is "scalability, efficiency
and security cocoon". If you are not paranoid about these issues,
but prefer to have real IPv6, you should forget about venet.

>  These are really
> fundamental to the nature of IPv6 and, unless you want to use IPv6
> purely like it just IPv4 with fat addresses (which it is NOT) and live
> entirely in an IPv4 mind-think cocoon when working with IPv6, how can
> you expect this to work with fully implemented IPv6?
> 
> 	The bridged networking of the veth devices seem to be the only viable
> way to deal with this.  I HAVE tried using venet for IPv6 and failed
> miserably.
> 
> 	This is also how I deal with IPv6 on VMware.  I never use the local
> networking (host local or NAT) devices and only use the bridged devices
> there.  In the case of VMware, the bridged devices are the default and
> you can add the routed or nat'ed devices.  That makes a lot more sense
> to me.
> 
> 	So IPv6 HAS to work for me.  Consequently, I have to work with
> everything running over the veth devices.  The venet devices just do not
> cut it at all with IPv6, so are totally useless to me for both IPv4 as
> well as IPv6 (why split the network two ways).
> 
> 	Funny thing is, if you "turn on" IPv6 in the vz configuration files, it
> dicks things up royally by trying to force IPv6 routes out through the
> venet0 interface, which can't work, and interferes with stateless
> autoconfiguration and router discovery configuration.  Leaving IPv6 off
> in the config, then it doesn't insert bogus routes and everything
> configures properly on the veth devices and IPv6 works like a charm.
> Interestingly enough, the veth devices DO get their proper link-local
> and global-unicast addresses while vnet0 sits there with not even a
> link-local address (of course - it has no mac address so how could it
> possibly have a link-local address - duh...).
> 
> 	</Rant>
> 
> 	Now...  Onto the problem.  IPv6 is working sweet with
> 2.6.18-ovz028test010 on Fedora Core 6.  It would be nice to get it up to
> the FC6 2.6.19 (soon to be the 2.6.20) rebase but that's ok for now.
> When I tried 2.6.18-ovz028test015 and subsequently 2.6.18-ovz028test018,
> I found that IPv6 was totally broken.  While all my interfaces properly
> autoconfigure on test10, stateless autoconf appears to be totally broken
> on test15 and test18 and even manual configuration doesn't work (hints
> strongly at broken neighbor discovery there).
> 
> 	This may not be an OpenVZ problem, per se, though.  Some time in the
> very later part of the 2.6.18 kernel.org release updates, a problem was
> introduced that broke IPv6.  Some patch or another caused nodes to fail
> to join the "all nodes multicast" (ff02::1) address.  This is critical
> to IPv6 router discovery and advertisement, neighbor discovery, and
> autoconfiguration.  All fall down go boom.
Yes, you are right.
It is repaired by commit d88ae4cc97b24783ee4480697fbdcc02ab4133a6
(what is interesting is that it was unnoticed for so long in mainstream)

Alexey