Next-Generation Firewall
How NPTv6 Works
Table of Contents
How NPTv6 Works
Understand how NPTv6 works, checksum-neutral mapping, bi-directional translation,
NPTv6 applied to a specific service, and NPTv6 with dynamically assigned IPv6 address
prefix.
| Where Can I Use This? | What Do I Need? |
|---|---|
|
When you Create an NPTv6 Policy, the
Palo Alto Networks® firewall performs a static, one-to-one IPv6 translation
in both directions. The translation is based on the algorithm described in RFC
6296.
In one use case, the firewall performing NPTv6 is located between an internal network and an
external network (such as the internet) that uses globally routable prefixes. When
datagrams are going in the outbound direction, the internal source prefix is replaced
with the external prefix; this is known as source translation.
In another use case, when datagrams are going in the inbound
direction, the destination prefix is replaced with the internal
prefix (known as destination translation). The figure below illustrates
destination translation and a characteristic of NPTv6: only the
prefix portion of an IPv6 address is translated. The host portion
of the address is not translated and remains the same on either
side of the firewall. In the figure below, the host identifier is
111::55 on both sides of the firewall.
It is important to understand that NPTv6 does not provide security. While you are planning your NPTv6 NAT
policies, remember also to configure security policies in each direction.
A NAT or NPTv6 policy rule cannot have both the Source Address
and the Translated Address set to Any.
In an environment where you want IPv6 prefix translation, three
firewall features work together: NPTv6 NAT policies, security policies,
and NDP
Proxy.
The firewall does not translate the following:
- Addresses that the firewall has in its Neighbor Discovery (ND) cache.
- The subnet 0xFFFF (in accordance with RFC 6296, Appendix B).
- IP multicast addresses.
- IPv6 addresses with a prefix length of /31 or shorter.
- Link-local addresses. If the firewall is operating in virtual wire mode, there are no IP addresses to translate, and the firewall does not translate link-local addresses.
- Addresses for TCP sessions that authenticate peers using the TCP Authentication Option (RFC 5925).
When using NPTv6, performance for fast path traffic is impacted
because NPTv6 is performed in the slow path.
NPTv6 will work with IPSec IPv6 only if the firewall is originating
and terminating the tunnel. Transit IPSec traffic would fail because
the source and/or destination IPv6 address would be modified. A
NAT traversal technique that encapsulates the packet would allow
IPSec IPv6 to work with NPTv6.
Checksum-Neutral Mapping
The NPTv6 mapping translations that the firewall performs are checksum-neutral,
meaning that “... they result in IP headers that will generate the same IPv6
pseudo-header checksum when the checksum is calculated using the standard Internet
checksum algorithm [RFC 1071].” See RFC 6296, Section 2.6, for more information about checksum-neutral
mapping.
If you are using NPTv6 to perform destination NAT, you can provide the internal IPv6
address and the external prefix/prefix length of the firewall interface in the
syntax of the test nptv6 CLI command. The CLI responds with
the checksum-neutral, public IPv6 address to use in your NPTv6 configuration to
reach that destination.
Bi-Directional Translation
When you Create an NPTv6 Policy, the
Bi-directional option in the Translated
Packet tab provides a convenient way for you to have the firewall
create a corresponding NAT or NPTv6 translation in the opposite direction of the
translation you configured. By default, Bi-directional
translation is disabled.
If you enable
Bi-directional translation, it is very important to make
sure you have security policies in place to control the traffic in both directions.
Without such policies, the Bi-directional feature will allow
packets to be automatically translated in both directions, which you might not
want.
NPTv6 Applied to a Specific Service
The Palo Alto Networks implementation of NPTv6 offers the ability to filter packets
to limit which packets are subject to translation. Keep in mind that NPTv6 does not
perform port translation. There is no concept of Dynamic IP and Port (DIPP)
translation because NPTv6 translates IPv6 prefixes only. However, you can specify
that only packets for a certain service port undergo NPTv6 translation. To do so,
Create an NPTv6 Policy
that specifies a Service in the Original Packet.
NPTv6 with Dynamically Assigned IPv6 Address Prefix
Beginning with PAN-OS 11.1.5, NPTv6 also supports source translation for an interface
that has a dynamically assigned IPv6 address prefix (assigned by DHCPv6, PPPoEv6, or
a cellular/5G interface). In the example topology, the firewall's WAN interface
facing the DHCPv6 Server (Ethernet1/1) has a dynamically assigned IPv6 prefix
(2021:8::4c/64). That IPv6 prefix can change over time. The Host1 and Host 2 source
addresses are translated to that prefix in outgoing packets beyond the firewall.
