IPv6 ND Managed-Config-Flag Is Just a Hint

IPv6 hosts can use stateless or stateful autoconfiguration. Stateless address autoconfiguration (SLAAC) uses IPv6 prefixes from Router Advertisement (RA) messages; stateful autoconfiguration uses DHCPv6. The routers can use two flags in RA messages to tell the attached end hosts which method to use:

One might assume that setting managed-config-flag in RA messages forces IPv6 hosts to use DHCPv6. Wrong, the two flags are just a polite suggestion.

Let’s start with the IPv6 Node Requirements (RFC 4294). Section 4.5 is very explicit: SLAAC must be supported, DHCPv6 may be supported.

RFC 4861 (IPv6 Neighbor Discovery) uses similarly non-committal language in Section 4.2: M flag indicates addresses are available DHCPv6, nothing more.

Can you enforce the use of DHCPv6 in case you want to track end-user IPv6 addresses for security/accountability reasons? Sure you can (there’s a workaround for every networking challenge caused by bad design or misguided expectations) – if you don’t advertise on-link prefixes in router advertisement messages, the hosts cannot auto-generate IPv6 addresses and are forced to use DHCPv6, or stay forever isolated from the beauties of IPv6-only Internet.

To do that on Cisco IOS, configure IPv6 prefix on the LAN interface and disable its propagation with the ipv6 nd prefix no-advertise interface configuration command. You need the IPv6 prefix configured on the LAN interface because Cisco IOS DHCPv6 server does not create host routes toward its clients and thus cannot reach the directly-attached hosts without an explicitly configured IPv6 prefix.

Enforce DHCPv6-only address configuration in Cisco IOS
interface FastEthernet0/0.100
 description Host Access LAN (VLAN 100)
 encapsulation dot1Q 100
 ipv6 address FEC0:1:2300:1::1/64
 ipv6 nd prefix FEC0:1:2300:1::/64 no-advertise
 ipv6 nd managed-config-flag
 ipv6 nd router-preference High
 ipv6 dhcp server VLAN_100

More information

Many more IPv6 access network hints are described in the Building Large IPv6 Service Provider Networks webinar.


  1. Setting the Other Config flag is implied when setting the Managed flag (RFC2462#5.2), but not all routers will do so automatically, and the clients I've tried it with will happily do stateful addressing without the options, if so instructed by the RA.
  2. If you have configured an IPv6 address on a physical Interface or SVI, you can remove the prefix information from the RA with the following command:

    ipv6 nd prefix 2001:db8:dead:beef::/64 no-advertise

  3. Thanks! Turns out this is the only solution that works.
  4. Linux workstations seem to lack DHCPv6 client (at least I couldn't find it at all in my Fedora distribution) and thus use SLAAC even when you want them to use DHCPv6.
  5. Linux works fine with wide-dhcp6c (checked and verified for both Stateless/Statefull DHCPv6 --IA_NA/IA_PD as tested...with Kubuntu 8.04 64bit and (k)Ubuntu 11.10 x64bit)
  6. Funny thing about 'M' bit and 3 clients tested (cisco with dhcp pd client in dialer interface, a cpe with dual/stack firmware , and a linux with pppoev6+wide-dhcp6c - [linux test is kind old in such scenario some months ago..but will do it soon again]) all served by a 7206 vxr with 15.1.3S2 as BRAS (using AAA and "Delegated-IPv6-Prefix" attribute). In case it ('M') is set in virtual-template on BRAS, according to RFC 6204 - IPv6 CE Router Requirements :
    WAA-6: If the IPv6 CE router receives a Router Advertisement message
    (described in [RFC4861]) with the M flag set to 1, the IPv6
    CE router MUST do DHCPv6 address assignment (request an IA_NA

    What i got was the following:
    --- Cisco CE (a 2811 with 15.1M/12.4T)...never asks for IA_NA address and asks for IA_PD only
    --- The dual stack CPE...asks for IA_NA and IA_PD, and in case you have configured in BRAS virtual-template...neighbor peer default ipv6 pool <name>...well..it is not enough..till get an IA_NA...reply.
    --- Linux goes asking what you tell it to ask in configuration file (IA_NA/IA_PD) and only.

    In case ('M' bit) it is not set on virtual-template:

    --- Cisco CE it is not affected, still asks as before for IA_PD (explicitly)
    --- CPE never asks for IA_PD or IA_NA (of course according to RFC)...
    --- Linux..asks what you tell it to ask again...

    Why this different approach ? Is this due to RFC 5887 and explicit configuration on the clients that results on this different behavior?
  7. In /etc/wide-dhcpv6/dhcp6c.conf

    interface <name>
    send ia-na 0; // For Statefull DHCPv6 IA_NA and comment the rest (and vice versa)
    information-only; // For Stateless DHCPv6 (DNS and Domain name)
    request domain-name-servers;
    request domain-name;

    script "/etc/wide-dhcpv6/dhcp6c-script";
    id-assoc na { //For Stateful DHCPv6 IA_NA

    For PPPoE with DHCPv6 PD i have used the following (used to work with my old good Kubuntu 804 64bit):

    root@iordHp:/home/iord# cat /etc/wide-dhcpv6/dhcp6c.conf
    # Default dhpc6c configuration: it assumes the address is autoconfigured using
    # router advertisements.

    #interface eth0
    # send ia-na 0;
    # request domain-name-servers;
    # request domain-name;

    # script "/etc/wide-dhcpv6/dhcp6c-script";

    #id-assoc na {

    interface ppp0
    send ia-na 1;
    send ia-pd 0;
    request domain-name-servers;
    request domain-name;

    script "/etc/wide-dhcpv6/dhcp6c-script";

    id-assoc na 1 {

    id-assoc pd {
    prefix-interface eth0 {
    sla-id 0;
    sla-len 8;

    root@iordHp:/home/iord# cat /etc/ppp/peers/dsl-provider
    # Minimalistic default options file for DSL/PPPoE connections
    #lcp-echo-interval 30
    #lcp-echo-failure 4
    #mtu 1492
    #maxfail 0
    #holdoff 20
    plugin rp-pppoe.so
    #nic eth0
    #nic eth0

    #nic eth0
    user "iord"

    Orestis Iordanidis</name>
  8. That's nice to know, but in my totally personal opinion a typical user of a Linux desktop distribution should not be forced to build something as simple as DHCPv6 client from source.
  9. Ivan,
    it's only one statement to install the packet:

    -- apt-get install wide-dhcpv6-client

    The default configuration in/etc/wide-dhcpv6/dhcp6c.conf can be used for stateless DHCPv6:

    profile default

    request domain-name-servers;
    request domain-name;

    script "/etc/wide-dhcpv6/dhcp6c-script";

    The rest needs some google search... :-)
  10. ... if you're lucky enough to have the right Linux distro. Maybe it's time to leave Fedora behind? :'(
  11. Haven't tried it on my Fedora box but will do it for sure....(still using Fedora 8 64bit for Olive and Junos simulation via QEMU that unfortunately on all latest Linux distribution has not been working anymore...).
  12. Don't forget about the AdvAutonomous flag in the prefix information option -- you can advertise a prefix in a router advertisement but say that it shouldn't be used for SLAAC. I believe the Linux kernel will not autoconfigure an address based on a prefix option missing the AdvAutonomous flag.

    So, using SLAAC and DHCP address assignment are independent. You can set M+O and not AdvAutonomous for DHCP only, AdvAutonomous without M (O optional) for SLAAC only, or you can even set all three options and the host should get two addresses (three with privacy addresses), one with SLAAC and one with DHCPv6.
  13. Sorry, AdvAutonomous isn't the canonical name, that's just what radvd calls it. RFC4861 calls it the A flag, aka "autonomous address-configuration flag".
  14. Some comments:
    a) setting the AdvManagedFlag on the RA doesn't in any way, shape or form preclude a host from also deriving an address from a prefix. RFC-4862 clearly says so - "It should be noted that a host may use both stateless address autoconfiguration and DHCPv6 simultaneously. One Prefix Information option field, the "autonomous address-configuration flag", indicates whether or not the
    option even applies to stateless autoconfiguration."

    b) setting both "ipv6 nd managed-config-flag" and "ipv6 nd other-config-flag" isn't redundant. Yes, RFC-4861 reads "If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information." - but this is not necessarily true. The DHCPv6 server will only return what the client asks it for - the client could send a REQUEST with IA-NA or IA-TA, but *without* an ORO option - if the client doesn't send an ORO with DNS-SERVERS, the DHCPv6 server doesn't need to send back a DNS-SERVERS(23) option - it may or may not. So setting both isn't redundant and may save you some headaches

    c) the most serious issue with the suggestion is using the "ipv6 nd prefix SOMETHING no-advertise". You should actually use "ipv6 nd prefix SOMETHING no-autoconfig" to prevent hosts from using the prefix to derive an address.

    If you use the no-advertise, the prefix will not be included on the RA. What's the problem with that? Host not only use the prefix on an RA to generate addresses for SLAAC, but also to know which destinations are local and which ones aren't. Check RFC-4861, section 6.3.4. If the router advertise the prefix with the on-link flag set, hosts will consider destinations within the prefix as being present on the link - and will do NS to reach them, forward directly to destination. If you do NOT advertise the prefix, then the host has no clue that the prefix is local - and will forward packets to destination within its same prefix to the default router. Remember that DHCPv6 doesn't provide any information about the prefix length - just the address.

    So unless you want to see a lot of redirects from your router to your DHCPv6 clients - advertise the prefix, but with no-autoconfig :)
  15. Thanks for the feedback, will include some of (c) in this blog post plus write another post on the same topic.
  16. Moreover as far as RFC 6106 support seems that Linux got the support already (using RADVD -- server side to announce rdns ipv6 address and options while rdnssd -- client side is used to update dynamically /etc/resolv.conf). There is BSD support as well but havent tested yet:

    (server side using radvd)
    root@iordUbuntu:/home/iord# cat /etc/radvd.conf

    interface eth0
    AdvSendAdvert on;
    # IgnoreIfMissing on;
    MinRtrAdvInterval 3;
    MaxRtrAdvInterval 10;
    AdvHomeAgentFlag off;

    prefix 2001:db8:9:0::/64
    AdvOnLink on;
    AdvAutonomous on;
    AdvRouterAddr off;
    RDNSS 2620:0:ccc::2 2620:0:ccc::3 {
    AdvRDNSSPreference 8;
    AdvRDNSSLifetime 180;

    Client side (using ndisc6 and rdnssd with default configurations) :

    root@iord-HP:/home/iord# rdisc6 wlan0
    Soliciting ff02::2 (ff02::2) on wlan0...

    Hop limit : 64 ( 0x40)
    Stateful address conf. : No
    Stateful other conf. : No
    Router preference : high
    Router lifetime : 30 (0x0000001e) seconds
    Reachable time : unspecified (0x00000000)
    Retransmit time : unspecified (0x00000000)
    Prefix : 2001:db8:9::/64
    Valid time : 86400 (0x00015180) seconds
    Pref. time : 14400 (0x00003840) seconds
    Recursive DNS server : 2620:0:ccc::2
    Recursive DNS server : 2620:0:ccc::3
    DNS servers lifetime : 180 (0x000000b4) seconds
    Source link-layer address: D0:27:88:84:89:D4
    from fe80::d227:88ff:fe84:89d4

    root@iord-HP:/home/iord# cat /etc/resolv.conf
    # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
    nameserver 2620:0:ccc::2
    nameserver 2620:0:ccc::3

    Still RFC 6106 is not widely deployed. ..although (No Windows and Mac OS support) :-(

    Orestis Iordanidis
  17. For me this entry in interface config ultimately solved the DHCPv6 vs SLAAC problem.

    interface FastEthernet0/0
    ipv6 nd prefix default 2592000 604800 no-autoconfig no-rtr-address
    ipv6 nd managed-config-flag
    ipv6 nd other-config-flag

    The key factor is no-rtr-address - without router all host are silent. :-P
Add comment