The PCI DSS was written with IPv4 in mind and it requires that NAT be used to protect servers containing cardholder information. IPv6 networks do not need NAT and, in fact, use of NAT is less than ideal. The PCI DSS does not address the use of IPv6, and some organizations have concerns that their PCI auditor will require them to perform NAT when they start using IPv6.
The credit card companies have collaborated on a program that guides merchants, processors, service providers and other organizations that handle cardholder data to secure that sensitive cardholder information. Visa, MasterCard, American Express, Discover and JCB have collaborated on requirements for their banks to transfer risk down to merchants for operating insecure systems that lead to compromised cardholder data. The goal is to create a set of minimum standards and requirements that banks, merchants and service providers must follow to ensure that the integrity of their payment systems are maintained.
The Payment Card Industry's Data Security Standard (PCI-DSS) documents the 12 focus areas for standards that help secure cardholder data. The first area within the Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures (Version 2.0, October 2010) is about how PCI-compliant organizations should "Build and Maintain a Secure Network" to protect systems that hold cardholder data.
Let us examine one particular section of the PCI DSS document within the section titled "Requirement 1: Install and maintain a firewall configuration to protect cardholder data." Within the current PCI DSS version 2.0 (page 23, section 1.3.8) there is a mandate for the use of NAT for IPv4 servers containing sensitive information. Here is a quote from that document:
"PCI DSS Requirements 1.3.8 Do not disclose private IP addresses and routing information to unauthorized parties. Note: Methods to obscure IP addressing may include, but are not limited to: - Network Address Translation (NAT) - Placing servers containing cardholder data behind proxy servers/firewalls or content caches, - Removal or filtering of route advertisements for private networks that employ registered addressing, - Internal use of RFC1918 address space instead of registered addresses. Testing Procedures 1.3.8.a Verify that methods are in place to prevent the disclosure of private IP addresses and routing information from internal networks to the Internet. 1.3.8.b Verify that any disclosure of private IP addresses and routing information to external entities is authorized."
This means that servers containing cardholder data should use RFC 1918 IPv4 addresses and be sequestered behind firewalls, IPSs, and other security controls.
If we try to get deeper insight into this requirement we can look to the Payment Card Industry (PCI) Data Security Standard (DSS) Navigating PCI DSS, Understanding the Intent of the Requirements (Version 2.0, October 2010) document. The guidance for this section 1.3.8 states the following.
"Restricting the broadcast of IP addresses is essential to prevent a hacker "learning" the IP addresses of the internal network, and using that information to access the network. Effective means to meet the intent of this requirement may vary depending on the specific networking technology being used in your environment. For example, the controls used to meet this requirement may be different for IPv4 networks than for IPv6 networks. One technique to prevent IP address information from being discovered on an IPv4 network is to implement Network Address translation (NAT). NAT, which is typically managed by the firewall, allows an organization to have internal addresses that are visible only inside the network and external address that are visible externally. If a firewall does not "hide" or mask the IP addresses of the internal network, a malicious individual could discover internal IP addresses and attempt to access the network with a spoofed IP address. For IPv4 networks, the RFC1918 address space is reserved for internal addressing, and should not be routable on the Internet. As such, it is preferred for IP addressing of internal networks. However, organizations may have reasons to utilize non-RFC1918 address space on the internal network. In these circumstances, prevention of route advertisement or other techniques should be used to prevent internal address space being broadcast on the Internet or disclosed to unauthorized parties"
At least this document acknowledges IPv6 and gives a hint that things may be different for IPv6, but it does not give any more deeper explanation. Outside of this one mention of IPv6, the next-generation Internet protocol is not mentioned anywhere else in the document.
PCI Council Board of Advisors and Special Interest Groups (SIGs) sometimes provide additional guidance to organizations seeking compliance. An example of this is the Wireless SIG that provides additional information for environments that use wireless LANs. However, there is no PCI SIG that has been covering the topic of IPv6.
Furthermore, if we do a search on "IPv6" on the PCI website, we get no additional information on the use of IPv6 in PCI-accredited environments.
There are two issues here. The first and larger issue is that the PCI standards are not keeping up with the times and considering IPv6. Not all PCI-compliant organizations' internal server-farm servers will be IPv6-enabled right away, but over time dual-protocol will be the norm. The fact of the matter is that all modern computer operating systems have IPv6 installed by default and it often functions as the preferred protocol. The majority of all computers that contain cardholder data are running IPv6 without any IPv6 security measures in place.
The second issue here is that NAT is not used in IPv6 environments. You can read this other blog article on why NAT is not needed for IPv6 and the related issues. Organizations do not want to use NAT with their IPv6 deployments. Even if an organization wanted to use NAT for IPv6, Network Prefix Translation (NPT) configuration may not even be possible on many of today's firewalls or routers. Few devices support NPT today.
This raises the question: is it possible to acquire PCI compliance if an organization has deployed IPv6? For an organization to meet this requirement in section 1.3.8 if they are not using NAT, they must show that they are using "compensating controls." They must show that they have other security measures in place that essentially meet 1.3.8, but in other ways. Through diversity of defense, defense in depth, the use of IPv6-capable firewalls, using proxy servers or an SLB/ADC, Unicast Reverse Path Forwarding (Unicast RPF), access-lists, etc. A reverse proxy server could be placed in front of the PCI server in question and configured with an IPv6 VIP on the external-facing side and use RFC 1918 IPv4-only communication to the real-server on the inside interface. Maybe this is one way to meet the "spirit of the law" without actually deploying NPT.
Even if you have all manner of dual-protocol compensating controls, with your PCI auditor follow the letter of the law in section 1.3.8 of the current DSS and not signoff that requirement unless you are using NAT for IPv6. For large merchants within the Level 1 category, a Qualified Security Assessor (QSA) on-site review is required annually. If we look deeper at the "Testing Procedures" 1.3.8.a and 1.3.8.b within the PCI DSS, it would be possible to meet these objectives with an IPv6-capable system.
If your auditor insists that you implement NAT for IPv6, then you can simply refer them to this article and this article on NAT for IPv6 and explain to the auditor that your IPv6-enabled systems are secure without the use of NAT. The good news is that your organization gets to pick the QSA. Therefore, the next time you approach your annual review you should select a QSA that is IPv6-knowledgeable.
Hopefully the next version of the PCI DSS significantly updates its guidance for IPv6-enabled systems. It would be insufficient if the new version of the PCI DSS had a simple statement in the footnotes that states: "all of these requirements are valid for IPv4 and IPv6 systems." IPv4 and IPv6 are different from each other in subtle ways and this needs to be addressed, without ambiguity, in the standards. Leaving room for interpretation by auditors who are unaware of the nuances between IPv4 and IPv6 will only lead to overly conservative PCI audits or audits that completely ignore IPv6 and lead to security vulnerabilities.