Bug 786133

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20100101
> Firefox/16.0
> 
> In the setup of the traditional network with ifup for IPv6 using DHCP, both
> DHCPv4 and DHCPv6 are enabled. However for IPv6 the router advertises whether
> DHCP6 is available and for what in the so-called M and O bits.

Yes, [M]anaged-address and [O]ther-config, which are _hints_ if dhcp6 is
available on the network for autoconfig purposes. These flags are not all.
The router advertisement is a structure which contains (the most relevant
things only) the flags + prefix list with an autonomous and onlink flags
for each prefix:

{
       AdvManagedFlag       on|off
       AdvOtherConfigFlag   on|off

       prefix XXXXXXXXXXXXX/64 {
              AdvOnLink     on|off
              AdvAutonomous on|off
       }
}

The kernel makes a router discovery and configures prefix routes when
OnLink is "on" and stateless IPv6 addresses when Autonomous is "on"
(eui64 & temp, except configured differently).

> In my test case I disabled the DHCP6 server in the router, which means that
> both the O and M bits are zero,

OK.

> however DHCP version 6 was enabled in the setup.

BOOTPROTO=dhcp in the ifcfg file. OK.

> The result was that the interface did not get a global IPv6 address, only
> a link-local address.

I were never able to reproduce such a behavior. I always get the 
autoconfig addresses (eui64 + temp) via router RA.

_Except_:
- Forwarding is enabled, which disables autoconfig,
- autoconf or similar flag is disabled
- when the router does not send any RA or the RA does not sent
  at least one /64 prefix with the autonomous flag set to "on".

You seem to not only change BOOTPROTO=dhcp to BOOTPROTO=dhcp4
in the ifcfg file to avoid the "dhclient -6" start, but seem
to set forwarding=1 or autoconf=0 or something like this.

> Only after disabling DHCP version 6 from the interface I got this
> global address. However enabling the DHCPv6 server in the router,
> I can choose that only the O bit will enabled, which means that
> the interface does not get the global IP address from the DHCPv6
> server, but only the default gateway and/or the DNS address(es).

Not exactly: unlike DHCPv4, a DHCPv6 client never configures any
gateway (there is no option for) --> in-kernel router discovery.

> The global IP address should be derived from Stateless Address
> Autoconfiguration (SLAAC). Deriving the address from SLAAC is
> further dependent on the value of the use_tempaddr, either 0,
> 1 or 2.

I know.

> Furthermore the current choice is to have fixed addresses,
> both for IPv4 and IPv6, or using DHCP for both.

You mean your choice. OK. When you want it static, then configure
it, e.g.:

ifcfg-eth0:
   BOOTOROTO=static
   IPADDR="192.168.1.42/24"
   IPADDR6="2001:db8::42/64"

ifsysctl:
   # disable autoconf addresses
   net.ipv6.conf.eth0.autoconf = 0
   # enable default router configuration, even forwarding==1
   #net.ipv6.conf.eth0.accept_ra = 2

routes:
default 192.168.1.1 - eth0
#default fe80::42    - eth0

> However, having a fixed IPv6 address one can still use DHCPv6
> to get the default gateway and/or the DNS address(es).
             ^^^^^^^^^^^^^^^            ^^^^^^^^^^^
No, it can't -- see above.              Yes.

> In fact it would be better to have the fixed IPv6 address without
> the prefix which comes from the router advertisement.

See above. Just set IPADDR_1="2001:db8::42/64".

> In my view this type of configuration should be present in this
> YaST module.

It basically is I think.

You can set IPADDR* variables in ifcfg file also with BOOTPROTO=dhcp
and also IPv6 addresses in IPADDR with BOOTPROTO=dhcp4 to avoid the
DHCPv6 client start.

The current implementation of the dhcpv6 client isn't using the RA
flags to choose between "info-only" and "address" mode.

And without a daemon, there is no clean way to implement it with
sysconfig.

That's why we're working wicked, a daemon based framework which will
obsolete sysconfig -- see http://gitorious.org/wicked/wicked.

It already reads the M and O flags and will use them in it's "auto"
dhcp6 mode (default) as soon as I find time to add the handling of
the flags to the dhcpv6 client (supplicant) there.

Thus it is a WONTFIX (in sysconfig) for this enhancement -> it's a
task for WICKED.

BTW: You may install "radvd" and start "radvdump" to monitor
     (on another console) what your router is sending exactly.

My main point is that the YaST module Network Settings lacks proper facilities to configure, with this module, a bit more advanced settings for IPv6. Now it looks like configuring IPv6 is the same as configuring IPv4, however configuring IPv6 needs it own approach, which is not present in this module. So this is/was a plea for improving this module.

Does the answer above mean that this module will vanish and be replaced by something that cooperates with wicked? It that case I will focus on that method. After all YaST is meant for the simple user, but to get the same facilities for IPv6 as YaST offers for IPv4, it needs some improvement.

(In reply to comment #3)
> My main point is that the YaST module Network Settings lacks proper facilities
> to configure, with this module, a bit more advanced settings for IPv6. Now it
> looks like configuring IPv6 is the same as configuring IPv4, however
> configuring IPv6 needs it own approach, which is not present in this module. So
> this is/was a plea for improving this module.

Yes, you're right -- several improvements at IPv6 side make sense.

> Does the answer above mean that this module will vanish and be replaced by
> something that cooperates with wicked? It that case I will focus on that
> method.

This is the plan. Wicked has some converters from ifcfg for the "1st days"
(migration time).

> After all YaST is meant for the simple user, but to get the same
> facilities for IPv6 as YaST offers for IPv4, it needs some improvement.

Yes. The problem is, that the "follow ra hint" mode needs a "backed"
(with a daemon to listen to the events) supporting it first.

I have the feeling that a special case of System Settings in the NetworkManager system is aiming at the same goal as the traditional ifup system. Namely the case that System Settings only has one configuration and no user configuration is used.
The configuration part of NetworkManager is far from complete, but the daemon does have the support for the RA hint and starts DHCP6 when an O or M bit is present.