So if i am understanding you correctly, this ipv6 parameter called a RandomizeIdentifier, if enabled can assign any ipv6 address to a pc within a scope of available ipv6 addresses. Does this not make it harder to manage the ipv6 address pool or it does not matter since so many ipv6 addresses are available?
The idea behind using randomly generated interface ID (host portion) instead of using EUI-64 was solely based on privacy/security concerns for users, I think it’s because a bad guy can use the packets from users who are using (EUI-64) to track the actual physical computer. However with EUI-64, network engineers can easily track an IPv6 address to an end-device using the unique MAC address.
@lagapides can clarify!
Thanks for the reply. Maybe i am thinking about this wrong. With ipv4 you create a dhcp pool and then you assign a range of ip address to use with the pool so you know where the clients are getting the ip address from. In the example, Rene created the address pool STATEFUL, defined the prefix, address prefix 2001:1111:1111:1111::/64, but regarding the host IPs’, i am still not clear where they are coming from. There is no defined pool where the address are coming from. With the Randomizeidentifier, where is it pulling ipv6 address from? Just assigning any available host IPs’?
Let’s say I create an ipv4 dhcp pool with a 192.168.1.0/24 network, it means my hosts will have a total of 2^8-2=254 addresses (if I didn’t exclude any static IP with
ip dhcp excluded-address command) to pull from.
Now let’s go with IPV6, as we know IPV6 has 128 bits [64 bits for network id and 64 bits for host/interface id]. Rene created an IPv6 network **2001:1111:1111:1111:0000:0000:0000:0000/64 which leaves us with 4 hextets, 64 bits for our hosts to use. If we calculate, that’s 2^64 =18,446,744,073,709,551,616 addresses available to use.
Now back to your question, "With the Randomizeidentifier, where is it pulling ipv6 address from? " your operating system will take your network ID 2001:1111:1111:1111and add the randomly generated 64 bits to make it a full ipv6 address (128 bits) and assign them to your host or an interface. The results can be something like the one you mentioned above 2001:1111:1111:1111:79B1:61A1:85A2:5DD2
I hope you got it now
Hello Cecil, sales2161
Sales has got it right. The prefix just locks in the first 64 bits of the address, or the “network portion” of the address if we want to use IPv4 terminology. The rest can be random, or EUI-64 or even be assigned statically by a DHCPv6 server. It can be any of these because IPv6 also employs the Duplicate Address Detection (DAD)mechanisms, a part of the Neighbor Discovery (ND) Protocol used in IPv6, to ensure that no duplicates have been assigned. In this sense, with IPv6 you don’t have to keep track and manage addresses as much, the IPv6 mechanisms here take care of that.
More about DAD and ND can be found at this lesson:
I hope this as well as sales2161’s posts have been helpful!
Thanks for the feed back. I totally understand now.
Got it now. Thanks for the reply.
How can I configure DHCPv6 server to send a default route to a client?
or a default router address like in IPv4 DHCP?
For IPv6, the configuration for the default gateway is received from the router advertisement (RA) and not from the DHCP server. This is the way IPv6 functions by design. You can find out more information about the RA in the following lesson.
I hope this has been helpful!
Hi Rene and staff,
reading the lessons (and other doc), i find an ambiguity between autoconfig and SLAAC
In the DHCPv6 lesson SLAAC is defined as DHCPv6 stateless, is not it ?
DHCPv6 supports two different methods…Stateless configuration (also known as SLAAC…StateLess AutoConfiguration)
Reading this, SLAAC is supposed to be only when you use DHCPv6 stateless with flag M=0 and flag O=1
So autoconfig is not SLAAC ? (it seems that in other places autoconfig is (part) of SLAAC ? am i wrong ?)
This is just semantic, but we must have the same concepts under the same words
So the way i clarify the things in my mind is:
SLAAC is either just autoconfig or autoconfig + stateless DHCP(v6)
When it is just autoconfig (RA with M=0, O=0) the client has 2 address (link-local and GUA from the prefix send by the router + IID via EUI or random).
In autoconfig, i found 2 subcases: if you use default or not. With default a default route is inserted in the RIB of the client, the GW is the link-local of the client. If you dont use default there is no GW via autoconfig, just 2 address
IF SLAAC is (autoconfig + DHCP stateless), the client will obtain the same info like with DHCP stateful BUT there is no binding stored in the server DHCP (i suppose this could be interesting if the client is an object for example: am i right ? because you cannot have binding for too many objects)
At this step of my learning, and when i consider SLAAC as (autoconfig + DHCP stateless), i am not sure what is the default GW for the client: is it its link-local or its GW is a GUA address learned via DHCP ?
The main thing is to know if i am right or wrong with SLAAC ?
Your description is correct. SLAAC is a feature that provides the ability to address a host based on a network prefix that is advertised from the local network router using Router Advertisements (RAs).
As you state there are three options:
- use only SLAAC (M=0 O=0)
- use SLAAC plus some additional DHCP options such as DNS (M=0 O=1)
- use only DHCPv6 for all features and options (M=1 O=?)
So SLAAC is just the feature that allows a host to gain IPv6 addresses and default GW from the local router. In other words, it provides the bare essentials for IPv6 connectivity.
SLAAC is still SLAAC even if O=1. It still does exactly the same thing, except that it indicates to the host and says “Go to a DHCPv6 server to find more network parameters”. Once it obtains its IPv6 address and default gateway, the host will then find and use the DHCPv6 service (DHCPv6 stateless) for additional parameters.
SLAAC is not used at all if DHCPv6 stateful is used. This is similar to the traditional DHCP for IPv4 where bindings are maintained. If M=1 (the value of O is ignored in this case) then the host will not configure any network parameter, and will reach out to the DHCPv6 server for all network parameters.
The default gateway for the client is always given by the RA except when using stateful DHCPv6. Then it is the DHCP server that provides the gateway. The gateway is provided as a link local address when it comes from the RA. When it comes from the DHCPv6 server, it can be anything the administrator configures, either link local or global unicast.
I hope this has been helpful!
Hi Rene and staff,
i read the forum and i found questions (and answers) about where IID of R1’s interface f0/0 come from ? (because there is no range IID configured in the DHCPv6 stateful pool, like we know with IPV4)
Answer is: cisco does it randomly on R1, is not it ?
But my question is about configuring F0/0’s IID on the server DHCPV6; this is static configuration Rene use 0:0:0:1 for the lesson, but in production that seems too trivial and it would be better for security/privacy if we could use also a random IID, is not it ?
So i am surprised (with the IOS versions i am using) that cisco do not offer the option to generate a random IID for configuring static GUA with a given prefix on the router interfaces
I google a little but i dont find any answer to my question
Do i miss something ?
When implementing DHCPv6 in a stateful manner, yes, it looks like Cisco assigns the Interface ID of the client randomly. How this is assigned really depends on the operating system being used by the host. Some, like Windows, may use the eui-64 method to determine the IID for the GUAs for example.
Yes this is true, and this is confirmed in RFC4941 that a randomly assigned IID provides an improved level of privacy. However, this is the case for the client IPv6 addresses assigned via DHCPv6. The IID of the F0/0 interface of the DHCPv6 server must be static and cannot be randomly assigned, in order for DHCPv6 hosts to reach it.
Now you may say that using the
ipv6 nd managed-config-flag command will tell the host where to find the DHCPv6 server, even if the GUA address is randomly assigned. In this particular case, the DHCPv6 server is the same as the default router, so this would work. However, in most cases the DHCPv6 server is a centralized server (not on the same subnet as the hosts) and is required to have a static IPv6 address so it can be reached.
The randomization of the IID of DHCPv6 hosts involves privacy issues that have more to do with collecting information about individuals and their habits, where they go, from where they connect and so on. These privacy issues don’t have such a great impact on the DHCPv6 server, as this is simply a server that is not vulnerable to such privacy issues.
For servers and services, it is always best practice to have a statically assigned GUA or a constant DNS record that points to the valid IPv6 address so that they are accessible all the time.
I hope this has been helpful!
helpful ? yes it is
The true thing is: when you dive in DHCPv6, this is much more complex than DHCPv4. So i think this WAS one of the reasons not to introduce DHCPv6 in your company !!!
For those who are interesting i recommand 2 links from Pepelnjak
my post was not clear.When a host use DHCPv6 (is forced to) it receives an ipv6 IID from the server DHCPv6. This IID is built randomly by the server and sent to the host: and the server stores the binding with this host. The question was: independently of DHCP (v6), when you assign a static addr to an interface why IOS does not offer a option to set IID randomly ?
if you read the pepelnjak’s papers above, written in 2012 you will find
“At the moment (2012), DHCPv6 cannot be used to send the prefix length …to IPv6 hosts”
I wonder why DHCPv6 was built in a so complex way.
First, you have to use ND RA to send prefix/length and to force dhcpv6 with flag M=1 and prefix flag A=1 and prefix flag L=1
Second, the server dhcpv6 has to build randomly the IID and send it to the host
Is it right ?
Pepelnjak said “at the moment”, so what is the situation in 2020 ? 8 years later
It’s always great to see your posts, and to spend the time looking deeper into the concepts of IPv6!
Thanks for sharing those posts with us.
The answer here is “I don’t know”. This has to do with the policies adopted by each individual vendor and the way the operating system of the device is configured. Typically, if SLAAC is used, a Cisco device will use EUI-64 to generate its IID even for the global unicast address. A Microsoft Windows PC for example, will by default use a random interface ID, but can be configured to use the EUI-64 process. As far as I know Cisco devices cannot be configured to create a random IID. It’s not ideal from a privacy perspective, but there you go.
An effort has been made in IPv6 to disassociate the prefix length from the actual address. Unlike IPv4, where the subnet mask was an absolutely necessary component of the address, the prefix length here is something a little less connected. This is evident from comments I made in this other post responding to another query you had.
The prefix length is always provided by the default router via the RA.
I think the reasoning behind this architecture is to try to make IPv6 as “plug and play” as possible. What I mean is, if everything is set to the default, an IPv6 device plugged in to an IPv6 network, will automatically gain its default gateway and obtain network connectivity without a single configuration from a human being. This philosophy is phenomenal if you think about it, because from now on, new devices (TVs, cameras, refrigerators, washers, dryers, lights, cars, alarm systems, traffic signs, sensors, etc, etc, etc, etc…) will all automatically obtain network connectivity. Do you want to go in and configure each one? Or configure each network to function appropriately? These will all connect by default.
The whole concept behind all of this is to make future networks, which will be networks with devices that don’t have a direct human-computer interface, obtain network connectivity with zero configuration. In order to achieve this “simplicity” it was necessary to create a more complex autoconfiguration concept for such networks. For networks that require more information than is available from the autoconfig, like more traditional PCs, IP phones, mobile phones, laptops etc, such as DNS, and additional DHCP options, the additional functionality of DHCPv6 is added on top of the autoconfig capability.
And as always, I hope this has been helpful!
Great lesson! When I tried this lab today on GNS3 (2.2.25) using VIRL images, specifically IOSv 15.7 routers, concerning the stateless configuration, my stateless host could not compute a Global unicast ipv6 address unless i configured it first with the ipv6 address autoconfig command. If I did the stateless DHCP server first, then tried to enable autoconfig on my stateless host it would not compute a Global unicast address only a link-local. Is there a reason for this?
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.
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(config-dhcpv6)#exit R1(config)#exit R1#show ipv6 dhcp pool DHCPv6 pool: laz Information refresh: 4294967295 Active clients: 0 R1#
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!
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 DHCPv6 pool: CUSTOMERS Prefix pool: GLOBAL_POOL preferred lifetime 604800, valid lifetime 2592000 DNS server: 2001:4860:4860::8888 DNS server: 2001:4860:4860::8844 Domain name: NETWORKLESSONS.LOCAL Information refresh: **4294967295** Active clients: 1
is where I should have been looking.
I’ll have to start reading the RFC’s