I got DHCPv6-PD aka prefix delegation up and running on a FortiGate. Yes! ✅ Configuring it is tricky since it’s not always clear which options to use. You cannot see everything in the GUI (it even changes depending on other options made later on or selects hidden and wrong default values), hence, you must set specific options via the CLI. I navigated around some bugs and finally got it running. Here we go:

Please refer to my previous blog post about DHCPv6 prefix delegation in detail.

Setup Notes

This is the basic lab, showing the ISP connection (green box, though not of interest for the following configs), as well as the Internet connection from the Forti (red box) and the internal clients (blue box):

• I’m using a FortiGate FG-60F with FortiOS 7.6.1.
• The wan1 interface is attached to an AVM FRITZ!BOX 7560 with FRITZ!OS 07.30, acting as the DHCPv6 server for addresses (IA_NA) as well as for prefixes (IA_PD, handing out /62 prefixes).
• Have a look at RFC 8415 “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)” respectively the IANA “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)” for more details concerning the DHCPv6 option types.
• The internal interface shall use a /64 out of the delegated prefix.
• With FortiOS 7.4.6, the FortiGate did not succeed in requesting anything over DHCPv6 at all. I’ve no idea why. Some notes here. Eventually, I tried an upgrade to FortiOS 7.6.1, in which it worked. The same problem still exists with FortiOS 7.6.1. In the end, disabling/enabling the DHCPv6 client on the wan1 interface made it work.
• The FortiGate receives its default route through the RA from the Fritzbox. (Remember that DHCPv6 does NOT send a default route at all. Everyone must rely on RAs in any case!)
• Though possible, I did not succeed in configuring the RA for the internal interface, serving a /64 out of the delegated range for the SLAAC method. Within the RA, the prefix did not show up at all. :( Most likely, I forgot to set the IAPD value with “set delegated-prefix-iaid 5” within the “config ip6-delegated-prefix-list” section since I was able to get this running on some later scenarios.
• Nevertheless, I configured the internal interface to send the RA with the M-flag while setting up a stateful DHCPv6 server on the FortiGate itself. With this option, I was able to hand out a /64 to the internal clients. ✅
• On several configuration options, you can choose a “subnet” which defaults to “::/0” in the GUI as well as in the CLI. This is like an identifier to set the n-th network within the delegated prefix. Always change this to something with a /64 (rather than the default /0) to get the job done correctly. Otherwise, the FortiGate chooses the full delegated prefix such as a /62 (rather than a /64) and uses it on its interface, which stands against any best practice, will kill SLAAC, makes me horribly sad, and so on.
• Within the configuration, you have to choose an “IAPD” value which defaults to 5. This value is randomly chosen by Fortinet and used later on to identify the delegated prefix. I left it by this value of 5. The ugly thing: You have to set this value for the stateful DHCPv6 server as well, but this cannot be done through the GUI. If you activate the DHCPv6 server with the “Delegated” IP mode, you’ll get an error in the GUI. That is: At least for this single entry you must use the CLI.
• At least in FortiOS 7.6.1, there is a bug in which the FortiGate does not reply to RSs with RAs. That is: Your clients won’t get the default route until the first RA that is sent on a regular basis by the Forti is received by those clients. As a workaround, I’ve set the min- and max-interval values to 10, respectively 30 seconds. Since the defaults are way higher (600 seconds = 10 minutes), clients have to wait really long until IPv6 is up and running.
• Another bug is related to the output of the routing table for IPv6 since it does not show the default route that is gathered from the RA on the wan1 interface. Funnily, this is only true for the get router info6 routing-table but not for the diagnose ipv6 route list output.
• Other quite useful information about FortiGate’s DHCPv6 configuration options can be found here and there.

Configuration of the wan1 Interface

Through the GUI (kudos to Fortinet, in that we can now configure more IPv6 stuff through the GUI ;)). Note the “IAPD 5” without a prefix hint.

CLI:

Configuration of the internal Interface

Basics are possible through the GUI, while you MUST set some values through the CLI later.

Here is everything from the CLI in which you can set the “delegated-prefix-iaid 5” for the DHCPv6 server. Note that I changed the “ip6-other-flag” to “disable” since you only need the M-flag for stateful DHCPv6:

Information

Some information can be gathered through the GUI and the CLI. Note the missing IPv6 default route in the GUI as well as in the first CLI command, while the second one lists the “gwy”:

The following Wireshark screenshot shows the DHCPv6 messages between the FortiGate (wan1) and the Fritzbox. The first reply (message nr. 6) is one that wasn’t working correctly (status code 13 = no binding), for whatever reason. I disabled/enabled DHCPv6 on wan1 again. Messages 18-21 are the correct ones, handing out the /62 prefix:

This is the DHCPv6 debug log during the complete startup of the wan1 interface. Maybe someone finds hints about the mentioned DHCPv6 “no binding” issues:

Finally, this Wireshark trace shows the client’s view. The FortiGate does not respond to router solicitations (RS, packets nr. 5, 12, 19), hence the real IPv6 process kicks in after it has received the first regular router advertisement (RA, nr. 43): [This trace was made while I had the O-flag still set to enable. Sorry for that.]

That’s it. Happy networking. ;)

Soli Deo Gloria!

Photo by Nick Fewings on Unsplash.