Description of problem:
When initializing the physical device (eth0/eth1) NetworkManager adds an ipv6
link local address. My LAN is running radvd so the device shortly also
auto-configures itself a ipv6 global addresse & route, so I have full IPv6
connectivity to the Internet at this point.

I then start VPNC to connect to the office VPN. This adds a tun0 and re-routes
IPv4 traffic for certain IPv4 subnets. My global IPv6 address / connectivity on
the physical device (eth0/eth1) is unaffected at this time - it continues to
operate independant on the IPv4 VPN connection.

Now I disconnect from the office VPN, which removes the tun0 device, but *also*
appears to flush all IPv6 addresses from my underlying physical device
(eth0/eth1) so I loose all IPv6 connectivity. This is obviously sub-optimal,
since there is absolutely no need to touch IPv6 addresses/routes when
de-configuring an IPv4 VPN connection.

Version-Release number of selected component (if applicable):
NetworkManager-0.6.4-5.fc6

How reproducible:
Always

Steps to Reproduce:
1. Connect machine (with wifi/ethernet) to a network which is IPv6 enabled with
a globally routed address prefix. ie a LAN with an radvd which advertises a
prefix for a subnet somewhere under 2000::/3 
2. Wait for NetworkManager to configure the eth0/eth1
3. Run ifconfig ethX  for your physical device
4. Observe IPv6 addresses:

# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:15:58:2F:E9:55  
          inet addr:192.168.254.132  Bcast:192.168.254.255  Mask:255.255.255.0
          inet6 addr: 2001:4830:1104:1:215:58ff:fe2f:e955/64 Scope:Global
          inet6 addr: fe80::215:58ff:fe2f:e955/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2832 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2385 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:2856220 (2.7 MiB)  TX bytes:331165 (323.4 KiB)
          Base address:0x3000 Memory:ee000000-ee020000 

5. Connect to a VPN  (in my case using NetworkManager VPNC plugin)
6. Run ifconfig ethN  again & observe IPv6 addresses are still present
7. Verify IPv6 connectivity by visiting 'www.kame.net' in firefox & looking for
an animated turtle graphic.
8. Disconnect from the VPN
9. Run ifconfig ethN  again & observe the lack of IPv6 addresses:

# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:15:58:2F:E9:55  
          inet addr:192.168.254.132  Bcast:192.168.254.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2832 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2385 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:2856220 (2.7 MiB)  TX bytes:331165 (323.4 KiB)
          Base address:0x3000 Memory:ee000000-ee020000 

10. Shift+refresh the firefox page www.kame.net & observe the turtle is no
longer animated - indicating you're connecting over IPv4 :-(

Actual results:
NetworkManager flushes all IPv6 addresses upon VPN disconnect

Expected results:
NetworkManager  leaves IPv6 addresses alone, or explicitly recreates them after
flushing them.

Additional info:
Running strace on the NetworkManager processes I can see that when disconnecting
from the VPN it runs

  ip addr flush eth1
  ip route flush eth1

This flushes both IPv4 & IPv6 addresses from the device.

After poking around in the code I find:


$ grep --after 20 src/nm_vpn_connection_deactivate vpn-manager/nm-vpn-connection.c
void nm_vpn_connection_deactivate (NMVPNConnection *connection)
{
        g_return_if_fail (connection != NULL);

        if (connection->vpn_iface)
        {
                nm_system_device_set_up_down_with_iface (connection->vpn_iface,
FALSE);
                nm_system_device_flush_routes_with_iface (connection->vpn_iface);
                nm_system_device_flush_addresses_with_iface (connection->vpn_iface);
        }

        if (connection->ip4_config)
        {
                /* Remove attributes of the VPN's IP4 Config */
                nm_system_vpn_device_unset_from_ip4_config
(connection->named_manager, connection->parent_dev,
                                connection->vpn_iface, connection->ip4_config);

                /* Reset routes, nameservers, and domains of the currently
active device */
                nm_system_device_set_from_ip4_config (connection->parent_dev);
        }

This last line above 'nm_system_device_set_from_ip4_config' is what causes the
addresses to all be flushed & IPv4 re-initialized.

In other places which call 'nm_system_device_set_from_ip4_config' -eg 
nm-device.c  - the call is followed by a call to
nm_system_device_add_ip6_link_address  which enables IPv6 autoconf on the device.

Thus the minimal effort fix is to add a call to
nm_system_device_add_ip6_link_address in the nm_vpn_connection_deactivate method.