icon-unified.svg
Experience Center

Understanding IPv6 Support

As Internet Protocol version 6 (IPv6) gradually replaces its predecessor Internet Protocol version 4 (IPv4), enterprises and service providers are migrating their internal networks to IPv6 to overcome IPv4 exhaustion and other shortcomings of IPv4, such as performance, scalability, security, and more. Mobile internet access has accelerated the depletion of IPv4 address space, leading service providers to deploy IPv6-only addresses to mobile devices. To address the network infrastructure’s shift towards IPv6, the Zscaler service brings in IPv6 support using tunneling and network address translation (NAT) technologies.

IPv6 support is extended by Zscaler based on the traffic forwarding method and also whether the client device is inside a location.

  • For clients inside a location: Forward IPv6 traffic inside an IPv4 tunnel to Internet & SaaS Service Edges using a GRE tunnel or IPSec tunnel. Both web and non-web traffic can be forwarded using these tunneling methods.
  • For clients outside a location: Forward web requests using PAC files or Zscaler Client Connector using Z-Tunnel 1.0 to Service Edges via a self-hosted or ISP-provided NAT64 gateway. To forward both web and non-web traffic from IPv6 clients, use Zscaler Client Connector over Z-Tunnel 2.0 and a self-hosted or ISP-provided NAT64 gateway.

Zscaler highly recommends using Zscaler Client Connector as your preferred forwarding method for IPv6 traffic whenever feasible.

  • When forwarding your organization's IPv6 traffic to Zscaler's data centers, you must ensure that the traffic is forwarded only to IPv6-enabled data centers.

    • The following table provides the list of IPv6-enabled data centers for the respective Zscaler clouds:

      zscaler.netzscalertwo.netzscalerthree.netzscloud.net
      • Amsterdam II
      • Atlanta II
      • Auckland II
      • Boston I
      • Brussels II
      • Chennai II
      • Chicago
      • Copenhagen II
      • Dallas I
      • Denver III
      • Dubai I
      • Dusseldorf I
      • Frankfurt IV
      • Frankfurt VI
      • Helsinki I
      • Hong Kong III
      • Johannesburg III
      • London III
      • London V
      • Los Angeles
      • Madrid III
      • Manchester I
      • Marseille I
      • Melbourne II
      • Mexico City I
      • Miami III
      • Milan III
      • Montreal I
      • Moscow III
      • Mumbai VI
      • Munich I
      • New Delhi I
      • New York III
      • Nuevo Laredo I
      • Osaka I
      • Paris II
      • San Francisco IV
      • Sao Paulo IV
      • Seattle
      • Seoul I
      • Singapore IV
      • Stockholm III
      • Sydney III
      • Tokyo IV
      • Toronto III
      • Vancouver I
      • Vienna I
      • Warsaw II
      • Washington DC
      • Zurich
      • Amsterdam II
      • Atlanta II
      • Auckland II
      • Boston I
      • Brussels II
      • Chennai II
      • Chicago
      • Copenhagen II
      • Dallas I
      • Denver III
      • Dubai I
      • Dusseldorf I
      • Frankfurt IV
      • Frankfurt VI
      • Helsinki I
      • Hong Kong III
      • Johannesburg III
      • London III
      • London V
      • Los Angeles
      • Madrid III
      • Manchester I
      • Marseille I
      • Melbourne II
      • Mexico City I
      • Miami III
      • Milan III
      • Montreal I
      • Moscow III
      • Mumbai VI
      • Munich I
      • New Delhi I
      • New York III
      • Nuevo Laredo I
      • Osaka I
      • Paris II
      • San Francisco IV
      • Sao Paulo IV
      • Seattle
      • Seoul I
      • Singapore IV
      • Stockholm III
      • Sydney III
      • Tokyo IV
      • Toronto III
      • Vancouver I
      • Vienna I
      • Warsaw II
      • Washington DC
      • Zurich
      • Amsterdam II
      • Atlanta II
      • Auckland II
      • Boston I
      • Brussels II
      • Chennai II
      • Chicago
      • Copenhagen II
      • Dallas I
      • Denver III
      • Dubai I
      • Dusseldorf I
      • Frankfurt IV
      • Frankfurt VI
      • Helsinki I
      • Hong Kong III
      • Johannesburg III
      • London III
      • London V
      • Los Angeles
      • Madrid III
      • Manchester I
      • Marseille I
      • Melbourne II
      • Mexico City I
      • Miami III
      • Milan III
      • Montreal I
      • Moscow III
      • Mumbai VI
      • Munich I
      • New Delhi I
      • New York III
      • Nuevo Laredo I
      • Osaka I
      • Paris II
      • San Francisco IV
      • Sao Paulo IV
      • Seattle
      • Seoul I
      • Singapore IV
      • Stockholm III
      • Sydney III
      • Tokyo IV
      • Toronto III
      • Vancouver I
      • Vienna I
      • Warsaw II
      • Washington DC
      • Zurich
      • Amsterdam II
      • Atlanta II
      • Auckland II
      • Boston I
      • Brussels II
      • Chennai II
      • Chicago
      • Copenhagen II
      • Dallas I
      • Denver III
      • Dubai I
      • Dusseldorf I
      • Frankfurt IV
      • Frankfurt VI
      • Helsinki I
      • Hong Kong III
      • Johannesburg III
      • London III
      • London V
      • Los Angeles
      • Madrid III
      • Manchester I
      • Marseille I
      • Melbourne II
      • Mexico City I
      • Miami III
      • Milan III
      • Montreal I
      • Moscow III
      • Mumbai VI
      • Munich I
      • New Delhi I
      • New York III
      • Nuevo Laredo I
      • Osaka I
      • Paris II
      • San Francisco IV
      • Sao Paulo IV
      • Seattle
      • Seoul I
      • Singapore IV
      • Stockholm III
      • Sydney III
      • Tokyo IV
      • Toronto III
      • Vancouver I
      • Vienna I
      • Warsaw II
      • Washington DC
      • Zurich
      Close

    Furthermore, when using Zscaler Client Connector, you must forward your users' IPv6 traffic only to data centers in the IPv6-enabled subcloud managed by Zscaler. To learn how to do this, see Configuring IPv6 Settings.

    For information specific to Zscaler's data centers, see Cloud Enforcement Node Ranges.

  • Zscaler's My IP Address service (ip.zscaler.com) might not recognize IPv6 traffic passing through the Zscaler cloud. Exercise caution when using the My IP Address service for troubleshooting or verifying connectivity to the Zscaler cloud when IPv6 is enabled on the client.

The following sections explain how IPv6 traffic is forwarded and processed by the Zscaler service, the configuration workflow, and logging:

  • You can forward your organization's IPv6 traffic from a location to the Zscaler service and enforce security policies on IPv6 traffic. Although Zscaler's cloud infrastructure can handle IPv6 traffic, the outer packets arriving in a tunnel at the Service Edges must be IPv4 packets. Therefore, to apply policies on your organization’s IPv6 traffic, the Zscaler service requires you to forward the IPv6 traffic inside IPv4 tunnels to the Service Edges. You can establish an IPv4 tunnel between your organization’s network from a specific location and the Service Edges using one of the following traffic forwarding methods:

    In addition to enforcing security policies on IPv6 traffic, the Zscaler service also provides customized DNS64/NAT64 mechanisms to establish connections between IPv6 clients and IPv4 destinations (IPv4-only or dual-stack destinations).

    With this IPv6 support for clients inside a location, the Zscaler service supports the following use cases:

    Close

  • Clients from unknown locations (remote users) can use Zscaler Client Connector or PAC files to forward their traffic to Service Edges. When using PAC files or Zscaler Client Connector with Z-Tunnel 1.0, only web traffic is forwarded to Service Edges via explicit proxy mode. However, if you are using Zscaler Client Connector with Z-Tunnel 2.0, both web and non-web traffic can be forwarded.

    For IPv6 clients that are connected to an IPv6 internet, a NAT64/DNS64 service is needed, as Service Edges can only be reached via an IPv4 internet. You can use a self-hosted or ISP-provided NAT64 gateway to perform the address translation from IPv6 to IPv4.

    The NAT64/DNS64 service is not needed for dual-stack clients if they are connected to the internet with support for both IPv6 and IPv4 concurrently.

    With this IPv6 support for clients outside a location, the Zscaler service supports the following use cases:

    • The IPv6 traffic from a client outside a location is forwarded to the Service Edge using Zscaler Client Connector or PAC file. The Zscaler service uses the DNS64/NAT64 mechanism (for Z-Tunnel 2.0) or regular DNS resolution (for Z-Tunnel 1.0 or PAC file) to establish an IPv4 connection. For non-web traffic forwarded using Z-Tunnel 2.0, an IPv4 connection is established if the destination IPv6 contains a NAT64 prefix recognized by Zscaler. Otherwise, an IPv6 connection is established.

      The following illustration shows how IPv6 traffic is forwarded to IPv4 destinations using PAC files or Z-Tunnel 1.0:

      An illustration of IPv6 clients connecting with IPv4 destinations using PAC files and ZTunnel 1.0

      The following illustration shows how IPv6 traffic is forwarded to IPv4 destinations using Z-Tunnel 2.0:

      An illustration of IPv6 clients connecting with IPv4 destinations using ZTunnel 2.0

      Close

    • The IPv6 traffic from a client outside a location is forwarded to the Service Edge using Zscaler Client Connector or PAC file. The Zscaler service establishes an IPv6 connection with the destination using the DNS64/NAT64 mechanism for web traffic. For non-web traffic forwarded using Z-Tunnel 2.0, an IPv6 connection is established.

      The following illustration shows how IPv6 traffic is forwarded to IPv6-only destinations using a PAC file or Z-Tunnel 1.0:

      An illustration of IPv6 clients connecting with IPv6 destinations using PAC files and ZTunnel 1.0

      The following illustration shows how IPv6 traffic is forwarded to IPv6-only destinations using Z-Tunnel 2.0:

      An illustration of IPv6 clients connecting with IPv6 destinations using ZTunnel 2.0

      Close
    Close

  • The Zscaler service prefers an IPv4 connection whenever possible, and an IPv6 connection is established for IPv6-only destinations. The preference for IPv4 connections (via NAT64) has the following advantages:

    • Better utilization of existing IPv4 infrastructure
    • Applying rich-security policies on IPv6 traffic
    • Accessing IPv4 services from the IPv6 network

    The following sections explain how the traffic forwarded from IPv6 clients using different proxy modes is handled by the Zscaler service.

    • When web traffic from IPv6 clients arrives at a Service Edge in explicit proxy mode via Zscaler Client Connector over Z-Tunnel 1.0 or using PAC files, the Zscaler service establishes an IPv4 or IPv6 connection to the destination based on how the server can be reached, as described in the following bullet points:

      • If the destination is reachable only via IPv4, then the Zscaler service establishes an IPv4 connection.
      • If the destination is reachable via IPv4 or IPv6, then the Zscaler service establishes an IPv4 connection.
      • If the destination is reachable only via IPv6, then the Zscaler service establishes an IPv6 connection.
      Close

    • When traffic from IPv6 clients arrives at a Service Edge in transparent proxy mode using an IPv4 tunnel (GRE or IPSec) or via Zscaler Client Connector (Z-Tunnel 2.0 only), the Zscaler service establishes an IPv4 or IPv6 connection to the destination based on how the server can be reached, as described in the following bullet points:

      • If the destination IPv6 address has a prefix match with NAT64 prefixes supported for the organization, then the IPv4 address is extracted from the destination IPv6 address and an IPv4 connection is established.
      • If the destination IPv6 address is a regular IPv6 address, an IPv6 connection is established.

      For establishing an IPv4 connection with the destination, the Zscaler service employs the NAT64/DNS64 mechanism to translate IPv6 packets of the inbound traffic to IPv4 packets. This translation depends on the following parameters:

      • Type of traffic (DNS queries or non-DNS traffic)
      • The prefix used in the inbound IPv6 packets
      • DNS64/NAT64 prefix configurations in the Admin Portal

      For DNS queries, the Zscaler service tries to resolve the domain name for an A record. If an A record is available, an AAAA record is synthesized using DNS64 and an IPv4 connection is established using NAT64. If an A record is not available, an AAAA record is used to establish an IPv6 connection.

      The Zscaler service uses the well-known prefix and its default NAT64 and DNS64 prefixes for the DNS64/NAT64 mechanism and organizations do not require any additional configuration. However, organizations can configure their network-specific NAT64/DNS64 prefixes in the Admin Portal. To learn more, see About NAT64 Prefixes and About the DNS64 Prefix.

      Close
    Close

  • To enable IPv6 support for your organization and obtain access to IPv6 configurations and settings, contact Zscaler Support.

    To allow the Zscaler service to handle your organization’s IPv6 traffic, you need to enable IPv6 support for your organization under Infrastructure > Internet & SaaS > Traffic Forwarding > IPv6 Configurations > Settings. Enabling IPv6 support for your organization allows you to route your users’ IPv6 traffic to the Zscaler cloud using one of the supported forwarding methods. However, to allow and process IPv6 traffic that is tunneled using GRE or IPSec within an outer IPv4 tunnel, you need to additionally enable IPv6 support for the locations from where the traffic originates. If IPv6 support is not enabled for a location, the IPv6 traffic arriving at the location is dropped. To learn more, see Configuring Locations.

    If you are using Zscaler Client Connector set up with Z-tunnel 2.0 to forward your IPv6 traffic, you need to configure the application appropriately.

    After enabling IPv6 support, you can optionally configure your network-specific NAT64 and DNS64 prefixes in the Admin Portal. To learn more, see Configuring IPv6 Settings.

    When IPv6 support is enabled and the necessary configurations are complete, the IPv6 traffic from your organization can be routed to the Service Edge inside an IPv4 tunnel, and the Zscaler service tries to translate the IPv6 packets to IPv4 packets using a built-in NAT64/DNS64 mechanism to establish client-server communication over IPv4 instead of IPv6. If an IPv4 connection is established, the Zscaler service applies policies that are configured based on IPv4 addresses in the Admin Portal on the translated IPv4 traffic. However, if the destination is an IPv6-only server, the Zscaler service establishes an IPv6 connection.

    The Zscaler service allows you to configure and enforce limited policies on IPv6 server-bound connections. You can configure these policies in the following ways:

    • You can configure policies based on Locations or Location Groups criteria to be enforced on all IPv6 traffic that originates from those locations. When a sub-location is added to a location with the IPv6 option enabled, the Zscaler service automatically creates a new Other6 sub-location that identifies all of the IPv6 addresses in that location. Using Other6 as the location criteria, you can define policies for all of the IPv6 traffic that originates from that location. To learn more, see About Sub-Locations.

      The Locations and Location Groups criteria are supported in various web and firewall policies.

      Close

    • You can configure policies based on URL Categories to be enforced on traffic bound to specific IPv6 sites or destinations. The Zscaler service allows you to add individual domains or IP addresses to URL categories, which can then be used in policies to control the traffic bound to those IPv6 destinations. To learn more, see Configuring Custom URL Categories.

      The URL Categories criterion is supported in various web and firewall policies.

      Close

    • You can configure policies based on Source or Destination IP Address Groups to be enforced on traffic originating from or destined to any IPv6 device. The Zscaler service provides predefined source and destination IPv6 address groups, All IPv6, which encompasses all IPv6 source or destination addresses. Using All IPv6 as the source or destination group criteria, you can define policies for all traffic originating from or destined to an IPv6 device. To learn more, see About Source or Destination IP Address Groups.

      The Source and Destination IPv6 Address Groups criteria are supported in various web and firewall policies.

      Close
    Close

  • The Zscaler service records and displays logs for your IPv6 traffic on the respective Insights Logs page:

    In addition, the Nanolog Streaming Service allows you to stream your logs in real time from the Zscaler Nanolog to your security information and event management (SIEM) system. To learn more, see Adding NSS Feeds.

    Close
Related Articles
Understanding IPv6 SupportConfiguring IPv6 SettingsAbout NAT64 PrefixesAbout the DNS64 Prefix