Imperva provides IPv6 support for websites on Imperva’s service.
In this topic:
- What is IPv6?
- The transition from IPv4 to IPv6
- Imperva as your IPv6 gateway
- Providing the end user’s IP address
- IPv4/IPv6 load balancing
- Compressing IPv6 zeros
IPv6 (Internet Protocol Version 6) is the successor to Internet Protocol Version 4 (IPv4). IPv6 is being deployed to fulfill the need for more Internet addresses. The growth of the Internet will soon use up the IPv4 addresses.
IPv6 uses 128-bit addresses that enable up to 2128 addresses (three hundred and forty trillion, trillion trillion unique IP addresses), which is a lot more than IPv4.
An example IPv6 address is:
IPv6 is designed to allow the Internet to grow significantly, both in terms of the number of connected hosts and the total amount of data traffic transmitted.
Currently, IPv4 is still the prevalent Internet Protocol used for addresses. Only a small percentage of traffic is currently transmitted via IPv6 (maybe less than 5% of total Internet traffic). A variety of Internet leaders, governments and regulation entities throughout the world are leading the migration to IPv6.
The new IPv6 will coexist with the older IPv4 for some time, possibly for many years. The two protocols are not designed to be interoperable, thus complicating the transition to IPv6. However, several IPv6 transition mechanisms have been devised to permit communication between IPv4 and IPv6 hosts.
Imperva provides IPv6 support of both client-side and server-side IPv6 traffic. This means that IPv6 is supported both for traffic between your end users and Imperva’s PoP and also for traffic between Imperva’s PoP and your origin servers.
In this way, Imperva can act as an IPv6 gateway for you, so that you can retain your IPv4 setups and Imperva will service your clients who send IPv4 and IPv6, as needed. This saves you the significant investment of updating your origin servers’ set up to support IPv6 and allows you to service your clients without having to upgrade your servers.
When a client connects via IPv6, we attempt to connect to the IPv6 origin address. If it is not available or does not exist, we connect to the origin’s IPv4 address. For example, if your origin server only services IPv4 and an end user sends an IPv6 message, then Imperva acts as an IPv6 gateway. Imperva receives the IPv6 message and forwards the message to your origin server according to the server’s unique IPv4 address.
The question arises of how your origin server can access and parse the IP addresses of end users sending IPv6 addresses. For example, for logging and statistics.
For this purpose Imperva adds an RFC HTTP X-Forwarded-For header to each end user request before forwarding it to your origin server. This is done in a similar manner to how each HTTP proxy adds another X-Forwarded-For header before forwarding. An X-Forwarded-For (XFF) HTTP header is an existing standard (not originating from IPv6) for identifying the originating IP address of a client connecting to a web server through an HTTP proxy.
Note: A Request for Comments (RFC) is a formal document from the Internet Engineering Task Force (IETF) that is the result of committee drafting and subsequent review by interested parties.
Imperva uses the X-Forwarded-For header to append the actual IP address of your end user.
Imperva can append X-Forwarded-For headers that contain the end user’s IPv6 addresses. Appending this X-Forwarded-For header enables your origin server to see the actual IP address of the end users. Otherwise, the origin server does not see end users’ IP addresses, but only sees Imperva’s IP address.
Imperva does not activate this functionality by default because, some parsers on the origin side (mostly the ones used by logging and statistics applications), may not be able to parse IPv6 addresses and will not function properly. Therefore, in order to get this functionality, you must open a ticket and request it.
In general, an end user’s IP address is not required by applications on your origin server. This is because these applications can communicate with end users using Imperva’s proxy IP (that was sent in the request). However, if these applications require an end user’s IP address, then it can be extracted from the X-Forwarded-For header. For example, an application might require an end user’ s IP address for statistical purposes, marketing purposes or other purposes that detect the geolocation of the end user.
The following describes how Imperva handles the situation where you have multiple origin servers. In this case some of your origin servers are IPv4 only, some are IPv6 only and some are dual stack (IPv4 and IPv6).
The dual stack server is treated as if it is two different servers even if they are running on the same physical device.
By default Imperva handles load balancing of IPv4 and IPv6 as follows:
- IPv4 traffic is sent to all servers.
- IPv6 traffic is only sent to the servers that support IPv6.
- However, if all your servers that support IPv6 are down, then IPv6 traffic is sent to your IPv4 servers.
Imperva also enables you to configure load balancing so that IPv6 traffic is only sent to IPv6 servers and IPv4 traffic is only sent IPv4 servers. Alternatively, you can configure that Imperva sends traffic to any origin server, regardless of whether it is IPv4 or IPv6.
Contact Imperva support to configure this feature.
Note: Each IP address, regardless of whether it is IPv4 or IPv6 appears separately in the Imperva dashboard. Traffic is not separated by server in any way. For example, in the scenario described above, each request from a different user (meaning each IP address) to any server appears separately in the Imperva dashboard. The dual stack server appears in the Imperva dashboard as if it is two different servers even if they are running on the same physical device.
Imperva supports both compressed-zeroes format and non-compressed zeros format for entering IPv6 addresses
Many IPv6 addresses contain long sequences of zeros. Imperva simplifies the representation of such IPv6 addresses, by removing contiguous sequences of zeros according to RFC conventions and using the standard library to do these conversions.
For example, the following address: 1111:0000000000:000000000:555 is represented by: 1111::555