Re: IPv6 default routes / NM vs. kernel autoconfig vs DHCP6



On 08/03/2012 05:33 PM, Dan Williams expounded in part:
That's correct, but at the time that bug was filed I did not know enough
about IPv6 configuration to suggest the correct course of action.  I now
know much more and realize that adding it back was a mistake.  We should
really deprecate that option and just alias it to "automatic".

DHCPv6-only without RAs is fundamentally broken.  Any valid
configuration needs RAs, if only for the default route.

Now, NetworkManager-0.9.4.0-9.git20120521.fc17.i686 is giving me IPv6 fits again. 

RAs set the M bit.  Here is radvdump (prefix altered):
#
# radvd configuration generated by radvdump 1.8.5
# based on Router Advertisement from fe80::862b:2bff:fe5a:191f
# received by interface em1
#

interface em1
{
    AdvSendAdvert on;
    # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
    AdvManagedFlag on;
    AdvOtherConfigFlag on;
    AdvReachableTime 0;
    AdvRetransTimer 0;
    AdvCurHopLimit 64;
    AdvDefaultLifetime 1800;
    AdvHomeAgentFlag off;
    AdvDefaultPreference medium;
    AdvSourceLLAddress on;

    # Prefix changed
    prefix 2001:db8:dead:beef::/64
    {
        AdvValidLifetime 2592000;
        AdvPreferredLifetime 604800;
        AdvOnLink on;
        AdvAutonomous on;
        AdvRouterAddr off;
    }; # End of prefix definition

}; # End of interface definition
But NM never sends the DHCP6 request, and ends up with:
em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.9.34  netmask 255.255.255.0  broadcast 192.168.9.255
        inet6 2001:db8:dead:beef:20c:f1ff:fed9:97b4  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::20c:f1ff:fed9:97b4  prefixlen 64  scopeid 0x20<link>
        inet6 2001:db8:dead:beef:d979:aa8e:a917:b833  prefixlen 64  scopeid 0x0<global>
        ether 00:0c:f1:d9:97:b4  txqueuelen 1000  (Ethernet)
        RX packets 1110860  bytes 582055968 (555.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 690568  bytes 79404585 (75.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
But, I can run dhclient -6 -v manually, and it works fine:

Internet Systems Consortium DHCP Client 4.2.4-P1
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Bound to *:546
Listening on Socket/em1
Sending on   Socket/em1
PRC: Confirming active lease (INIT-REBOOT).
XMT: Forming Confirm, 0 ms elapsed.
XMT:  X-- IA_NA f1:d9:97:b4
XMT:  | X-- Confirm Address 2001:db8:dead:beef::34
XMT:  V IA_NA appended.
XMT: Confirm on em1, interval 1090ms.
RCV: Reply message on em1 from fe80::216:3eff:fe09:b3bd.
RCV:  X-- Preference 255.
RCV:  X-- Server ID: 00:01:00:01:17:03:9b:cb:00:16:3e:1b:96:d0
message status code Success: "All addresses still on link."
PRC: Bound to lease 00:01:00:01:17:03:9b:cb:00:16:3e:1b:96:d0.
And the interface does indeed have the DHCP address.  Method in NM GUI is set to Automatic.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]