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

[Michael H. Warfield]

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.
Looking at my systems, I don't see a single /0 address anywhere.
Loopback has a specific ::1/128 address but then all other addresses
are /64's including the link local addresses.  Most of my global unicast
addresses and routes are assigned via stateless autoconfig but where I
have static assignments for servers, they're all /64 (which is what a
standard subnet is suppose to be).  Some of my tunnels are either /128
or /112 depending on the specifics of the PtoP tunnel convention (varies
with broker).  That's normal standard IPv6 behavior that's expected.

	I see nothing where a /0 would be valid.  I find it weird that Etch
would have been setting it up that way.  That doesn't sound valid in the
first place.  Maybe something peculiar to the vnet interfaces, which
I've been avoiding because of non-standard IPv6 behavior.

	All my stuff is Fedora, CentOS, or Ubuntu on hard iron and only Fedora
and CentOS in OpenVZ containers.  All the containers are using veth
devices and stateless autoconfig.

> 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.  Without mac addresses and not supporting
stateless autoconf and neighbor discovery and router advertisements,
that has always just seemed outside of standard working behavior on
IPv6.  It might "work" (for some value of "work") but looks wrong and
would not be surprising if it broken in some corner cases.  There are
reasons for standards and this would be non-standard behavior unless I'm
seriously misunderstanding what's going on here.

	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?  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?

> --- 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
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://openvz.org/pipermail/users/attachments/20090306/321db9fe/attachment.bin