Hi,

On Fri, May 24, 2013 at 11:59:03PM +0200, Samuel Thibault wrote:
> Hello,
> 
> To make it short: yes, the ipv6 pool environment variables are useful,
> for user-defined scripts to be run at connection for instance to
> propagate routes, do accounting, etc.  The patch below adds them.

You keep claiming that "yes it's useful".  The lack of feedback on the
list is partly due to the "To make it short" part of your mail...

I'm a bit reluctant to add more code until I can see a clear use case
which can't be answered by the plethora of existing environment variables.

Specifically, "ifconfig_ipv6_local" and "ifconfig_ipv6_netbits" already exist,
and the pool will never produce any other netbit length, nor will the
server ever reconfigure it's ipv6_local address in response to whatever
is pushed to clients.  So the only thing that I couldn't see right away
in the environment is "what IPv6 address did the remote receive?" and
that one *is* available as parameter to the "learn-address" script already
today...

(It brings up an interesting question, though.  Should we issue a warning
if an "ifconfig-ipv6-push" is used that uses a different network or 
netbits length than the ipv6 transfer net configured on the server?  What
do we expect to happen if this is configured?)


Looking at the code:

> +      if (tunnel_type == DEV_TYPE_TAP || (tunnel_type == DEV_TYPE_TUN && 
> tunnel_topology == TOP_SUBNET))
> +     {
> +       setenv_int (mi->context.c2.es,
> +                         "ifconfig_ipv6_pool_netbits",
> +                         mi->context.c2.push_ifconfig_ipv6_netbits);
> +     }
> +      else if (tunnel_type == DEV_TYPE_TUN)
> +     {
> +       setenv_in6_addr_t (mi->context.c2.es,
> +                         "ifconfig_ipv6_pool_local_ip",
> +                         &mi->context.c2.push_ifconfig_ipv6_remote,
> +                         SA_SET_IF_NONZERO);
> +     }

This whole bit is overly complicated.  Unlike IPv4, there is no "this
could be a remote or a netmask" distinction, and both netbits and 
context.c2.push_ifconfig_ipv6_remote are always defined, no matter 
what sort of tunnel type or topology.  So if you wanted to set these
variables at all, you could do unconditionally - but then, I can't see
any added value to "ifconfig_ipv6_netbits" and "ifconfig_ipv6_local", as
said before...

Blindly copying the way something is done for IPv4 doesn't make it 
"right" for IPv6.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             g...@greenie.muc.de
fax: +49-89-35655025                        g...@net.informatik.tu-muenchen.de

Attachment: pgpqnu2xVTOQ9.pgp
Description: PGP signature

Reply via email to