[Users] vzctl 3.0.23: debian-add_ip.sh lenny (debian 5.0) IPv6 bug

[Benoit Branciard]

Michael H. Warfield a écrit :
> On Thu, 2009-03-05 at 20:50 +0100, Benoit Branciard wrote:
>> the debian-add_ip.sh script available in vzctl 3.0.23 does not set up 
>> IPv6 default route correctly for a Debian 5.0 (Lenny) container.
> 
>> The reason seems to be that the default behaviour of the ifconfig 
>> command changed from etch to lenny: when adding IPv6 addresses without 
>> specifying a prefixlen, the prefixlen is assumed to be /128 in Lenny 
>> instead of /0 in etch.
> 
> 	That doesn't make sense to me.  I would think the /0 (which should be
> all addresses are valid to the local subnet) would be, should be, wrong.

On a normal ethernet device yes, /0 is wrong.
On a venet device /0 is needed to force default route to be forwarded to 
the host. This seems messy, but this is the way it works.

> 	I see nothing where a /0 would be valid.  I find it weird that Etch
> would have been setting it up that way.

Yes, having ifconfig defaulting to /0 seems like a bug in Etch, which 
has been corrected in Lenny. /128 is a far more acceptable default value 
(that is, a single IP address).

But having debian-add_ip.sh NOT specifying the REQUIRED /0 (in venet 
context), and relying on a buggy default value, is another bug.

> 
>> The patch below corrects the problem by explicitely specifying the 
>> prefixlen, and works for both Etch and Lenny containers.
> 
> 	That patch is on the vnet devices.  If this is proper behavior in the
> vnet devices, that's just more evidence to me that the vnet devices are
> broken vis-a-vis IPv6.  

It works for me.

> Without mac addresses and not supporting
> stateless autoconf and neighbor discovery and router advertisements,

venet does not need router advertisements. It just needs an IPv6 address 
which is explicitely configured by the host administrator, and do not 
support stateless autoconf by design.

> 	If anything, the clients should get a correct /64 address and then
> somehow get their proper default route (either static or through router
> advertisements, but router advertisement doesn't work on the vnet
> system).  But, of course, that means the host is acting as a router with
> IPv6 forwarding enabled (net.ipv6.conf.all.forwarding = 1) which use to
> then interfere with default routing, but doesn't seem to anymore (that
> behavior may have been altered to correct non-compliance with test
> suites - I haven't played with that aspect in years).  Is that why
> this /0 kludge?  To avoid having to put the host in IPv6 forwarding mode
> and just fake out IPv6 forwarding in the vnet module?  

venet needs net.ipv6.conf.all.forwarding = 1 on the host to support IPv6 
properly.

> That would just
> be more non-standard behavior.  Where do you get your /64 from?  Is it
> local to that host and hard coded?  How do other hosts know to route to
> it then.  Is it the local /64 you are sitting on (a semi bridging mode?)
> how would neighbor discovery then work?  How are the scopes and
> multicast suppose to work when you do this with a /0?
> 

I believe venet does not support multicast and other fancy things. There 
must be some practical reasons for veth to exist :-)

I agree that when I came to OpenVZ, I found network management to be 
quite messy. But venet devices were found to be quite useable for the 
vast majority of containers hosting classical unicast services. Provided 
this patch is applied when it comes to lenny :-)



>> --- debian-add_ip.sh.0  2009-03-05 18:57:40.000000000 +0100
>> +++ debian-add_ip.sh    2009-03-05 19:02:43.000000000 +0100
>> @@ -87,8 +87,8 @@
>>              printf "
>>   auto ${VENET_DEV}:${ifnum}
>>   iface ${VENET_DEV}:${ifnum} inet6 manual
>> -       up   ifconfig ${VENET_DEV}:${ifnum} add ${ip}
>> -       down ifconfig ${VENET_DEV}:${ifnum} del ${ip}
>> +       up   ifconfig ${VENET_DEV}:${ifnum} add ${ip}/0
>> +       down ifconfig ${VENET_DEV}:${ifnum} del ${ip}/0
>>   " >> ${CFGFILE}.bak
>>          fi
> 
> 	Mike
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://openvz.org/mailman/listinfo/users


-- 
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.