This article is deprecated at this point but I’m leaving it up for posterity. Palo Alto implemented DHCPv6-PD functionality in V11. I have not tested its functionality but this is the documentation necessary for you to configure it. https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-new-features/networking-features/dhcpv6-client-with-prefix-delegation

I recently came into possession of a Palo Alto Networks PA-220 through work for lab purposes. I wanted to use it as my home router as I've found this is the best way to get actual experience setting up devices for production without the real-world stakes and also to get actual traffic flowing through the device rather than simulated traffic. Configuring IPv4 was pretty trivial, I simply configured the outside interface as a DHCP client, the inside interface as the gateway IP address of my previous router, a NAT policy, a DHCP pool, and lastly a security policy.

I count myself as a proponent of IPv6 and since IPv6 is supported on Palo Alto firewalls, I wanted to get it set up on my shiny new box. There are, however, some hurdles to overcome in doing that. First off, I have a home internet connection from AT&T not a business connection so I can't exactly call them up and ask them to put a static route for the IPv6 block pointing at my gateway. Secondly, Palo Alto does not support DHCPv6 Prefix Delegation which would have made this setup a whole lot easier. Nevertheless, this is still a step up from my previous gateway, a Meraki MX67 which has NO IPv6 support at all (although the rumor on the street is that it's coming).

You see, most home routers that support IPv6 use a technology known as DHCPv6 Prefix Delegation to dynamically learn the IPv6 block that it can use to configure internal subnets. AT&T in this case, assigns me a /60 block giving me 15 internal /64 networks. While the PA-220 can be configured statically with an IPv6 address, it can't register this block with the upstream router as owning the entire /60 for a route to be configured. This presents a problem that I had to fix.

I had a plan to solve all of this but the first step in this was to just get basic connectivity configured. Getting the GUA prefix was easy from the AT&T router and I went ahead and configured it on the outside interface of my PA-220 with an EUI-64 address and configured the inside interface with the next /64 in the /60 block.

The next hurdle that I had to get over was, "what the heck is my default gateway for my external interface?" I couldn't find this information on any device, so I ended up connecting my laptop to the AT&T provided router (in passthrough mode) and pulled up Wireshark. Looking for the Router Advertisement packets, I was able to find the link-local address of that router and configure it as a default route.

After some wrangling of the syntax of the ping command on the Palo Alto CLI, I was able to confirm connectivity at this point. Not my favorite design choice from Palo Alto. (“ping inet6 yes source 2001:db8::1 host 2001:4860:4860::8888”, SERIOUSLY!?)

However, pings from an internal client were still failing as expected. AT&T's upstream router knows about my locally connected network but doesn't know where to send traffic to my internal network.

NAT to the rescue! Err, not quite NAT but NPTv6. If you're not familiar with NPTv6, it's Network Prefix Translation. Essentially, NPT is a stateless swap of the prefix while leaving the host portion of the address alone. NPTv6 was originally meant to allow an organization to change their provider assigned space without having to re-IP their entire organization. So, in this case, I was going to use NPTv6 to swap my internal /64 prefix with the external /64 prefix. It should be stated that NPTv6 isn't a security mechanism and is here strictly to maintain connectivity.

The setup for an NPTv6 policy isn't terribly difficult but does require you to configure NDP Proxy on the external interface. Essentially, the external interface of the PA-220 is going to respond with its own MAC address to any ICMP Neighbor Discovery requests on behalf of any internal clients.

The last piece of this puzzle was to allow ICMPv6 packets through my security policy.

To sum up, the steps to configuring IPv6 on my Palo Alto Firewall were:

• Assign IPv6 addresses

• Configure NDP Proxy

• Configure RDNSS options

• Configure a default route

• Configure NPTv6 Policy

• Configure Security Policy

I should say, this is a hack way of implementing IPv6 and all of this will be unnecessary once Palo Alto implement DHCPv6 Prefix Delegation. There appear to be a number of feature requests for it from what I can see surfing the internet, but time will tell how long that takes.

My dual-stack configuration is working fine as I write this and I'd love to tell you what percentage of my traffic is IPv6 only but I haven't figured out how to get those statistic yet.

There are some drawbacks to be noted, this is a pretty static configuration that will absolutely break if AT&T ever changes the link-local address of their upstream router or assigns me a different IPv6 block. If Palo Alto ever updates with prefix delegation support, I’ll reconfigure to use that.

My future plans are to create an IPv6 only network here at the house with NAT64 on a different SSID but that will have to come later.