Cisco DHCPv6 Server Configuration

Hello Earl

An IPv6 interface will compute a global unicast IPv6 address only if the ipv6 address autoconfig command is issued AND there is an active IPv6 router on that subnet. So your first statement makes sense, that no IPv6 global unicast address is computed unless that command is issued on the interface.

Your second statement however shouldn’t be so. If you have the DHCPv6 stateless configuration on the DHCPv6 router configured, then R2 should be able to compute its global unicast IPv6 address. If no IPv6 global unicast address can be computed, then that means that R2 is not able to receive any RA messages from the DHCPv6 router. Can you confirm that your configuration is correct? You can also use the debug commands used in the lesson to see if the information request is being received by the DHCPv6 router.

Let us know how you get along so that we can help you further in troubleshooting.

I hope this has been helpful!


I’m trying to sort out an issue with DHCPv6 Lease times.
My issue is how do I set a lease to infinite.
The default Lease time for Cisco kit is 30 days, i would like to make it like a static address.
I’ve tried the information refresh infinite but that doesn’t appear to change the 30 days.


Hello Andy

I went into one of my production ISR 4331 routers and created an IPv6 DHCP pool called “laz”.
I attempted to change the information refresh infinite command, and I was able to do so:

R1(config)#ipv6 dhcp pool laz
R1(config-dhcpv6)#information refresh infinite
R1#show ipv6 dhcp pool
DHCPv6 pool: laz
  Information refresh: 4294967295
  Active clients: 0

You can see that the information refresh is set to 4294967295. The value for the refresh time interval is represented by a 32-bit value. According to RFC 8415, when this 32-bit number is set to all ones, the value is interpreted as infinity. This means that the information refresh value of 4294967295, which is 2^32 which is indeed the decimal number that corresponds to a 32-bit number of all ones, thus it means infinity.

What do you see on your device that indicates that this configuration doesn’t change the DHCPv6 behavior? Let us know so that we can further help you in your troubleshooting procedures.

I hope this has been helpful!


Hi Laz,
I was looking in the wrong place…
I was looking under

ISP#sh ipv6 dhcp bind
Client: FE80::5054:FF:FE04:4B25 
  DUID: 00030001525400044B25
  Username : unassigned
  VRF : default
  Interface : GigabitEthernet0/0
  IA PD: IA ID 0x00020001, T1 302400, T2 483840
    Prefix: 2001:DB8:1100::/48
            preferred lifetime 604800, valid lifetime 2592000
            expires at Nov 05 2021 11:18 AM (2590873 seconds)

and expecting the expires to change but as you pointed out

ISP#sh ipv6 dhcp pool
  Prefix pool: GLOBAL_POOL
               preferred lifetime 604800, valid lifetime 2592000
  DNS server: 2001:4860:4860::8888
  DNS server: 2001:4860:4860::8844
  Information refresh: **4294967295**
  Active clients: 1

is where I should have been looking.

I’ll have to start reading the RFC’s :thinking:

1 Like

Hi Community !

As we verify #show ipv6 dhcp pool on DHCPV6 Server , the STATEFUL DHCP pool is showing Active Clients where as STATELESS DHCP pool is showing Active Clients = 0, even though STATELESS DHCPV6 client received IPV6 address through AUTOCONFIG. Please explain if any config is missing.

Hello Raghu

When configuring DHCP pools for use with stateless DHCP, the DHCP server is not actually managing IPv6 addresses. It is just providing supplementary information such as DNS server addresses to the stateless clients. Since no actual IPv6 addresses are being provided by the DHCP pool, the “active client” number remains zero. An active client is only one for which IPv6 addresses are actively managed.

I labbed this one up as well just to verify.

I hope this has been helpful!


Hi Lazaros
Thanks for the explanation. :smile:

1 Like

Hi all,

very interesting discussion and lab. I’m trying to setup a similar IPV6 dhcp stateful environment using also a dhcp relay router so dhcp server and client are not on the same segment.
For now I have some problems because router acting as client is not able to get also the ipv6 address from dhcp; it seems that dhcp server is receiving request and seems reply…but in some parts the comunication is broken

Do you have in plan to describe in a lesson lab also this type of case?


Hello Stefano

That’s a good exercise to do. You can take a look at the following thread in Cisco’s community that describes how to set up a DHCPv6 relay.

Remember that for DHCPv6, it is possible to have your local router deliver the IPv6 prefix to the client, and still use DHCPv6 relay for other network parameters such as DNS server for example. So even if you do enable the relay feature, you may not be getting your IPv6 addresses from the relayed DHCPv6 server, but from the local router. In order to ensure that your IPv6 addresses are being delivered by the DHCPv6 server, you can use the no-autoconfig keyword as used in this lesson.

Can you share some more details of the specific trouble you are facing in your particular implementation? Maybe we’ll be able to help you further…

I hope this has been helpful!


Hello Laz,
Thanks a lot for your suggestion that confirmed my experience on the Lab.

My issue at the end was a trivial routing problem due to the mechanism how the DHCP relay router send packet to DHCP server , using Always as source ip the wan interface and not the interface facing clients

I’ll send as soon as possibile a description of my Lab and a synthesis of configs applied.

Just a note : for my experience using a Cisco iOS router to simulate an IPv6 client It Is Better to not enable IPv6 unicast-routing as with routing enabled i was not able ti have a a vallid default route installed.

Thanks and good Day to all


Hello Stefano

Thanks for sharing your solution! Looking forward to seeing your description of the lab for more detailed info.

Yes, thanks for pointing that out. That would be best practice since most IPv6 hosts, such as a PC or a mobile device are not capable of IPv6 routing, so that would be a more accurate simulation.

Thanks for your input!


I have got an issue with the command
#ipv6 address dhcp

I couldn’t find dhcp after address, when i put ?
It gives other options but not dhcp.

Hello Abdalla

It seems that your device simply doesn’t support the DHCP option for IPv6 addresses. There are indeed some IOS versions that will not support this. Can you share your IOS version with us so we can verify?

I hope this has been helpful!


Thank you Lagpides,
Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 15.2(4)S5, RELEASE SOFTWARE (fc1)
Technical Support:
Copyright (c) 1986-2014 by Cisco Systems, Inc.
Compiled Thu 20-Feb-14 06:51 by prod_rel_team

ROM: ROMMON Emulation Microcode
BOOTLDR: 7200 Software (C7200-ADVIPSERVICESK9-M), Version 15.2(4)S5, RELEASE SOFTWARE (fc1)

Hello Abdalla

The 7200 series routers are indeed older routers with an end of sale data in 2012 and end of support date of 2017. Although they do support some IPv6 features, I believe that they are limited, and this is why you do not find the command in the CLI.

To confirm this I tried going into the archived data section of the Cisco Feature Navigator to find the exact features that the device supports, however, I was unable to find it, or the service was down at the time. Cisco states that the data in the archived section may be incomplete, so I was unable to confirm. However, you can attempt to go to this Cisco tool and determine if the configuration of an IPv6 address on an interface via DHCP is supported.

I hope this has been helpful!


I cannot help but notice

ipv6 DHCP interface FastEthernet 0/0

And show interface brief dont seem to give you any information about the prefix on the client.

Is there a command to determine what prefix was assigned to my client?

Hello Patrick

That’s a good question. Looking at the output of the show ipv6 dhcp interface FastEthernet 0/0 command in the lesson, you can see that it displays a /128 prefix like so:

 Configuration parameters:
      IA NA: IA ID 0x00030001, T1 43200, T2 69120
        Address: 2001:1111:1111:1111:255A:E159:32AF:5E42/128
                preferred lifetime 86400, valid lifetime 172800
                expires at Jul 19 2014 08:30 PM (172750 seconds)
      DNS server: 2001:4860:4860::8888

I also tried to lab this up in CML, and found that the output of the above command is a little different:

R1#show ipv6 interface gi 0/1
GigabitEthernet0/1 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::5054:FF:FE0A:8FA6 
  No Virtual link-local address(es):
  Global unicast address(es):
    2001:1111:1111:1111:AD88:B915:BE2A:969, subnet is 2001:1111:1111:1111:AD88:B915:BE2A:969/128 
  Joined group address(es):
  MTU is 1500 bytes
!>-- output omitted--<

Again, however, the subnet is indicated as /128. I tried all of the above with the fully DHCPv6 learned address as well as with the SLAAC learned address, and it seems that the result is the same. I always get an indicator of /128 rather than the expected /64 that is offered by the DHCPv6 server.

Looking at the debugs, I see that the DHCP server sends a /64 address:

*Aug 14 08:27:25.877: IPv6 DHCP: Sending ADVERTISE to FE80::5054:FF:FE0A:8FA6 on GigabitEthernet0/1
*Aug 14 08:27:26.986: IPv6 DHCP: Received REQUEST from FE80::5054:FF:FE0A:8FA6 on GigabitEthernet0/1
*Aug 14 08:27:26.987: IPv6 DHCP: Using interface pool STATEFUL
*Aug 14 08:27:26.987: IPv6 DHCP: Looking up pool 2001:1111:1111:1111::/64 entry with username '0003000152540004ED3B00030001'
*Aug 14 08:27:26.988: IPv6 DHCP: Poolentry for user found
*Aug 14 08:27:26.988: IPv6 DHCP: Found address 2001:1111:1111:1111:E5A8:CA6A:9088:C670 in binding for FE80::5054:FF:FE0A:8FA6, IAID 00030001
*Aug 14 08:27:26.988: IPv6 DHCP: Updating binding address entry for address 2001:1111:1111:1111:E5A8:CA6A:9088:C670
*Aug 14 08:27:26.988: IPv6 DHCP: Setting timer on 2001:1111:1111:1111:E5A8:CA6A:9088:C670 for 172800 seconds
*Aug 14 08:27:26.989: IPv6 DHCP: SAS retured Null falling to link local

… but the client receives a /128 prefix:

*Aug 14 08:27:29.295: IPv6 DHCP: Received REPLY from FE80::5054:FF:FE0D:7AC7 on GigabitEthernet0/1
*Aug 14 08:27:29.295: IPv6 DHCP: Processing options
*Aug 14 08:27:29.295: IPv6 DHCP: Adding address 2001:1111:1111:1111:E5A8:CA6A:9088:C670/128 to GigabitEthernet0/1

Even when I look up the routing table, I see the route of the directly connected network as /128.

However, because we are still able to ping the interface of the DHCPv6 server, this means that the prefix understood by the router cannot be /128. If it was, it would assume the destination address is outside of the local subnet, and would look for a default router, which is not configured.

So to answer your question, I’m not sure. For some reason, all indications in the client, whether using DHCPv6 or autoconfig, seem to show a /128 prefix, but the routing seems to be operating correctly. Let me pass this one by @ReneMolenaar as well to see his opinion. Will get back to you shortly! In the meantime…

I hope this has been helpful!


Hello again Patrick

After having a chat with Rene, I have a bit more info to share with you on this topic. The DHCPv6 server knows that the particular host requires a /64 prefix since that is already configured locally in the DHCP configuration. So the DHCPv6 server will generate the last 64 bits of the address for the client. These last 64 bits are generated randomly. Once that is done, it will send this address to the host along with additional information such as DNS server. However, within the DHCPv6 messages, we don’t find the information of the prefix of /64. The DHCPv6 server will just inform the host of the 128 bit address without any prefix information. That’s why we see a /128 in all of the show output on the router.

The prefix is defined not by DHCPv6, but by the router advertisements (RAs) from NDP.

So the client learns its /128 IPv6 address from the DHCP server and learns about its prefix of /64 from the RA. In order to find the prefix that has been assigned to a particular address learned via DHCPv6, we need to take a look at the information about the IPv6 router (default gateway) that NDP has arranged for us. To do this we can use the show ipv6 routers command. Below, I’ve done this in the lab topology I had set up:

R1#show ipv6 routers
Router FE80::5054:FF:FE0D:7AC7 on GigabitEthernet0/1, last update 0 min
  Hops 64, Lifetime 1800 sec, AddrFlag=1, OtherFlag=0, MTU=1500
  HomeAgentFlag=0, Preference=Medium
  Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
  Prefix 2001:1111:1111:1111::/64 onlink
    Valid lifetime 14400, preferred lifetime 14400

Here you can see clearly what the prefix is.

I find it strange that the interface and the routing table don’t indicate the /64 prefix for this particular address. When I configure the IPv6 address statically, I see the prefix in both the show ipv6 interface command as well as in the routing table.

In any case, it’s good to know how this information is displayed within an IOS router so we can find it when we need it.

I hope this has been helpful!



Going back to the /128 thing again. So a stateful DHCP server provides only a /128 address while the prefix information is learned from the NDP messages, specifically RAs.

What I just don’t understand is why isn’t the prefix (in my example, 2001:DB8:1:1::/64) being installed into the RIB?


The client obtained its IPv6 from the stateful DHCP server (a /128 one) but it didn’t install the /64 prefix information from the RAs into the RIB? Or is this just a bug with virtual environmetnts or something? Because this causes the host to send all packets destined to H2, to the default gateway first which is also the DHCP server in my scenario.


Thank you in advance.

Kind regards,

Hello David!

The fact that the routing table and the IP address on the interface show /128 as the prefix was not such a problem if routing were to take place correctly. But in your case packets are being incorrectly sent to the default gateway rather than directly to H2. Try to issue the show ipv6 routers command on H1 as I did in my previous post to see what prefix is actually being received from the local router. Is it /64? Try it and let us know before we continue troubleshooting.

I hope this has been helpful!