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
Domain name: NETWORKLESSONS.LOCAL
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):
FF02::1
FF02::1:FF0A:8FA6
FF02::1:FF2A:969
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!
Laz
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
R1#
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!
Laz
Hello!
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,
David
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!
Laz
DHCPV6(config)#ipv6 dhcp pool STATEFUL
DHCPV6(config-dhcpv6)#address prefix 2001:1111:1111:1111::/64
DHCPV6(config-dhcpv6)#dns-server 2001:4860:4860::8888
DHCPV6(config-dhcpv6)#domain-name NETWORKLESSONS.LOCAL
DHCPV6(config)#interface FastEthernet 0/0
DHCPV6(config-if)#ipv6 address 2001:1111:1111:1111::1/64
DHCPV6(config-if)#ipv6 dhcp server STATEFUL
DHCPV6(config-if)#ipv6 nd managed-config-flag
DHCPV6(config-if)#ipv6 nd prefix 2001:1111:1111:1111::/64 14400 14400 no-autoconfig
Totally lost here. The above is taken from the DHCPv6 Server config lesson. Itâs regarding configuration of a Stateful DHCPv6 server.
- Donât global unicast prefixes need to come from an ISP to ensure they are unique? If so, why would there be a need to manually configure one anywhere? Shouldnât a router already have this prefix from the ISP?
- What happens if you accidentally type in the wrong global unicast prefix and it doesnât match what the ISP assigned you? Couldnât this risk address collision?
- Assuming you are getting the prefix from the ISP, why are you manually assigning an IPv6 address to this interface? Canât it just get one as a DHCPv6 client or use SLAAC from the ISP-provided prefix?
- Why are you manually typing in the 2001:1111:1111:111::/64 prefix in the ipv6 nd prefix command? You already assigned an address to the interface. Couldnât you just use the default parameter? Cisco NetAcad does this.
- Whatâs with the 4-hour lifespans on that prefix? What would happen when those 14,400 seconds expire?
Sorry for all the questions. This topic has me completely stumped.
Hello CJ
If weâre talking about a single IPv6 address that is assigned to the external interface of the edge router, then that will often be assigned directly by the ISP using their own DHCP server. Alternatively, you may assign it as a static address on the interface of the router. However, if you as an organization are provided with a block of global unicast IPv6 addresses by your ISP to use for your own Internet-facing services, (i.e. web server, email, VPN service etcâŚ) then you must manage them yourself. So it is conceivable that you are given the 2001:1111:1111:1111::/64 prefix by the ISP, but you are using your own DHCP server to assign them to the hosts you choose.
ISPs will typically have safeguards against such errors. They will typically only accept packets from your network that have an acceptable source IPv6 address. So if you were to use a different address that already exists on the Internet, the ISP would be able to identify it and filter it out.
The DHCP server itself must have an IP address assigned to it, and this will typically be static. If the ISP has given us a block of global unicast addresses, then it is likely that the DHCP server itself will also be assigned one of those addresses. This however is not mandatory, as the DHCP server may be assigned an internal IPv6 address.
It is possible to issue the following command:
DHCPV6(config-if)#ipv6 nd prefix default
This will cause the prefix of the interface itself to be used for DHCP. However, you do not need to be confined only to this prefix. The DHCP server can assign DHCP addresses with prefixes other than that assigned to the specific server interface.
The lifetime parameters of the ipv6 nd command are part of the fundamental operation of the ND protocol. The command as shown in this Cisco IOS command reference documentaiton indicates two parameters: the preferred lifetime and the valid lifetime. I have created a NetworkLessons note on the topic for more detail.
I hope this has been helpful!
Laz
Is it possible to set the default gateway in the IPv6 DHCP server?
Hello Mariusz
DHCPv6 does not typically set the default gateway for IPv6 clients. The default gateway is typically distributed through Router Advertisements (RA) sent by routers, not through DHCPv6. Indeed, DHCPv6 has no standard option specifically designed for directly assigning the default gateway to clients in the same way that it does for IPv4. This is a significant difference from IPv4, where the default gateway is often distributed via DHCP.
You must configure the default gateway on the clients based on the Router Advertisement messages from the local router, which will include the default gateway information.
I hope this has been helpful!
Laz
Hi Laz,
As always, thanks for the detailed response. Apologies but Iâm still a bit confused on something here.
The DHCPv6 lesson is omitting the topics of DHCPv6 leases and NDP lifetimes which I believe is causing confusion. If you are using Stateful DHCPv6, then NDP RAs are only being used to advertise a default gateway, correct? If thatâs the case, how are the lifetimes being configured here even relevant? Based on what Iâm reading about these lifetimes, they are only useful if using SLAAC. Wouldnât the IPv6 addresses be using DHCPv6 leases instead of the lifetimes?
Hello CJ
Keep in mind that with DHCPv6, there is no concept of âlease timeâ like there is with DHCP for IPv4. The only timers involved are the preferred and valid timers. When using DHCPv6, these timers are determined using the DHCPv6 server, and by default on a Cisco device, the preferred lifetime is 86400 seconds (one day) while the valid lifetime is set to 172800 seconds (two days).
If DHCPv6 is not used and we are using SLAAC instead, then these timers are determined by the local router and are communicated to the host using the RAs. The RAs incle prefix information options, and among them are the preferred and valid lifetimes.
You can configure these values on the DHCPv6 server as part of the address prefix command like so:
address prefix IPv6-prefix [lifetime {valid-lifetime preferred-lifetime | infinite }]
More information about this command can be found here:
Similarly, you can configure a local IPv6 router that uses SLAAC to advertise a particular valid and preferred lifetime using the ipv6 nd prefix command. More information about this command can be found here:
I hope this has been helpful!
Laz
Hello Laz and Rene,
Thanks for the lesson. I found in Cisco documentation the following:
For DHCP IPv4 Relay Agents:
Now, when I labbed this with CML, the DHCP server gets all DHCP relayed packets from the client with an IP source address of the DHCP relay agentâs interface facing the client, this is, the interface configured with the ip helper-address command. I have also seen many books stating that this described behaviour is normal and correct.
However, very interesting fact is that for IPv6 it sees to be the opposite: I labbed too with DHCPv6 and relay agent, and the source of the relayed DHCPv6 packets that the DHCPv6 server gets is the relay agentâs interface facing the server. I found on Cisco documentation:
So, just to make sure: for IPv4 by default, the IP address of the interface facing the client is the source for DHCP relayed packets; for IPv6, the IP address of the interface facing the server is the source for DHCPv6 relayed packets. Both cases for packets going to the server. Is this correct?
Please correct me if it is wrong, I just want to verify with more experienced people. I donât know if is a feature of a specific version or if is meant to be like that.
Thanks,
Jose
Hello Jose
For IPv4, when the DHCP server responds to the request, it uses the address in the GIADDR field as the destination IP address for that response, which is the client-facing interface of the device acting as the relay agent. Now I wasnât sure about what IP address is used as the source of the actual DHCP message in the IP header. This of course is a different field than the GIADDR (Gateway Address) field in the DHCP header. I checked out a packet capture and confirmed that the source address of the IP packet also uses the same client-facing interface address! So both the GIADDR field of the DHCP header and the source IP address in the IP header have the same address.
However, for IPv6, the behavior is different. The DHCPv6 relay agent does not modify the source address of the relayed packets. Instead, it uses the IP address of the interface on the relay agent that is facing the DHCPv6 server. This is because DHCPv6 operates differently than DHCPv4 when it comes to relay agents.
In DHCPv6, there is no direct equivalent to the GIADDR field found in DHCPv4. However, the functionality provided by the GIADDR field in DHCPv4 is achieved through other mechanisms in DHCPv6.
Specifically, in DHCPv6 relay agents encapsulate the clientâs message in a Relay-Forward message, adding their own information to it. This information is included in the Relay Message Option (Option Code 9), which is then forwarded to the DHCPv6 server. Additionally, a relay agent can include an Interface-Id Option (Option Code 18) in the Relay-Forward message to specify the interface or link where the client resides. This enables the server to identify the correct subnet or scope for the clientâs configuration. Furthermore, the Link-Address field in the Relay-Forward message serves a role similar to the giaddr field in DHCPv4. It contains the address of the relay agentâs interface on the clientâs link, allowing the server to determine the appropriate configuration for the client.
So the relay agent will use the server-facing interface as the source and destination of the DHCPv6 messages, but will also contain information within its DHCPv6 messages concerning the client-facing interface, as well as the prefix or subnet on which the client resides. The same information is relayed, but simply in a different fashion.
All of these mechanisms are described in detail in the respective RFCs that define each protocol.
I hope this has been helpful!
Laz
1 Like