Finally! With PAN-OS 11.0 a long missing IPv6 feature was introduced: DHCPv6-PD aka prefix delegation. For the first time, we can now operate a PAN-OS firewall directly on the Internet (the IPv6-Internet that is) on many kinds of ISP connections. Remember: To get a routed IPv6 prefix requires DHCPv6-PD (if you’re not a BGP-homed enterprise). Hence, without that feature, we could not connect to the Internet with a Palo directly.

With DHCPv6-PD, the firewall can receive a prefix from the ISP (commonly a /48 or a /56), while handing out /64s to downstream layer 3 interfaces. Here we go:

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

My Setup

I’m sitting behind a fibre ISP connection from Deutsche Glasfaser. The ethernet1/1 interface is directly attached to the fibre modem. I’m referring to it as my “WAN interface”. (More details about the connection establishment are available in German.) I’m using a PA-440 with PAN-OS 11.1.1. The client-facing interfaces ethernet1/3.24 and ethernet1/7 shall hand out /64 prefixes via RAs.

Configuration of the WAN Interface

At first, the WAN interface (ethernet1/1 in my case) is enabled for IPv6 with the type “DHCPv6 Client”. In my scenario, I set the request type to “Non-Temporary Address” only. In the second step, the prefix delegation is enabled (with a prefix length hint of 48 – just because I can) and a name for the pool:

I enabled DAD (Duplicate Address Detection) on the WAN interface (the best practice for firewall interfaces is to NOT activate it, but to be IPv6-compliant facing the ISP I would recommend it), enabled NDP monitoring, and enabled the DNS recursive name server and domain search list via DHCPv6 as well to get that information via DHCPv6:

Configuration of Host-Facing Interfaces

To let the Palo assign a /64 per host-facing interface, you have to enable IPv6 with the type “Inherited” and add a “GUA from Pool”. This is the pool you’ve created in step 2 above.

Since I wanted to test static subnet-IDs, I chose “dynamic with identifier”. Note that the identifier is a number from 0-4095 (decimal) converted to hexadecimal for the last three characters in the fourth hextet. (That is: This process on the NGFW is meant to deal with /52 prefixes turned into /64. Can’t we use /48 prefixes?!? This would require a range from 0-65535. Or even better: Why can’t we just type in hexadecimal values? That doesn’t seem to me to be fully developed here.)

Example: If your ISP-assigned prefix via DHCPv6-PD is 2001:db8:2311:a300::/56, choosing an identifier of 15 (decimal) will convert to an f (hex) and will end in the following host-facing prefix: 2001:db8:2311:a30f::/64. Since I wanted to see a 24 as the subnet-ID to follow my VLAN, I chose an identifier of 36. The name of this “Assign Addr” portion is not relevant at all.

Address resolution and router advertisement as always (no M nor O flag in my lab):

On my first host-facing interface, ethernet1/3.24, I set the DNS support to manual to use statically configured recursive DNS servers and my own search list. (I’m using Google’s public DNS64 servers here since this subnet is IPv6-only with NAT64. More on this in upcoming blog posts.) On another subnet, ethernet1/7, I chose the DHCPv6 type as the recursive DNS server to use the ISP-provided recursive DNS server which came in via DHCPv6, while I did not want to use the provided DNS search list in my lab, hence I left it unchecked:

Further Less reading from PANW: DHCPv6 Client with Prefix Delegation.

Show It To Me Baby! (uh huh, uh huh)

Within the well-known Network -> Interfaces -> Ethernet view you can click on “Dynamic-DHCPv6 Client” for information about the WAN interface and on “IPv6-Inherited” for the host-facing interfaces:

Let’s start with the WAN interface. This “DHCPv6 Client Runtime Info” lists the client (1) and server (2) DHCPv6 information aka DUID, the IPv6 address of the interface itself (3) with its default gateway (4), along with the recursive DNS servers (5). Finally, the IPv6 prefix (6) which is why we are all here:

A further click on “Show Prefix Pool Assignment” lists all the dynamically assigned /64 prefixes to downstream interfaces, in my case those two configured layer 3 interfaces. Note the last two hex values aka subnet-IDs of 24 (configured as decimal 36) and 43 (configured as decimal 67):

The “IPv6-Inherited” on a host-facing interface, in my case ethernet1/3.24, shows the parent interface (eth1/1), the inherited prefix, and so on:

Command Line Interface

On the CLI you can use several commands for further troubleshooting. (Remember that you can find commands with something like this: find command keyword dhcpv6)

For example:

That is:

A Client’s Perspective

Following is a Wireshark screenshot from a router advertisement (RA, ICMPv6 message type 134) as seen by a client behind interface ethernet1/7. You can see the prefix with the correct subnet-ID of 43 within the “ICMPv6 Option: Prefix information”, as well as 2x the “Recursive DNS Server” which are the ones from my ISP gathered via DHCPv6:

However, note that the “Prefix” shows the full IPv6 address of the PANW interface rather than the first 64 bits only (with all other bits set to zero) which violates the standards (RFC 4861 “Neighbor Discovery for IP version 6 (IPv6)”, section 4.6.2):

What’s still missing?

With PAN-OS 11.1, Palo Alto Networks has added another IPv6 feature: IPv6 support for PPPoE. This was still missing in PAN-OS 11.0. With this feature, you can now operate a PAN-OS firewall directly on the WAN connection of residential ISPs. (I reported those missing features back then in 2015. 😂)

So, are we feature complete now? Unfortunately not. We are still missing a DHCPv6 server on PAN-OS. And, please, not only for IA_NA (Identity Association for Non-temporary Addresses) but also for IA_PD (Identity Association for delegated prefixes) as well! That is: DHCPv6-PD server-side. Yay.

And, we are missing DNS64 as well. This could easily be done within the DNS proxy. It would round up the IPv6 completeness of PAN-OS firewalls since all the other features such as RA with RDNSS/DNSSL and NAT64 are already there.

(A little fun fact at the end: The late Juniper ScreenOS firewalls had a working DHCPv6-PD implementation a decade ago! I blogged about it here in 2015, for example.)

Soli Deo Gloria!

Photo by Jamie Templeton on Unsplash.