7.3 Setting up L4 Switch for IPv6 Support

IPv6 provides large number of available addresses, increased security, and reliability. For supporting IPv6, the L4 switch should support addressing both IPv4 and IPv6 as seen in the following figure.

There is no change in listener configuration for Access Manager devices. Hence, real IP configuration and real server group configuration in L4 switch remain the same. Change is required only in the virtual server configuration to accept IPv6 connections.

Figure 7-2 L4 Switch Support For Both IPv4/IPv6

The existing IPv4 virtual server configuration is as follows:

  • server virtual vir-ipv4 10.50.50.1

  • predictor round-robin

  • port 8080

  • port 8443

  • bind 8080 real1 8080 real2 8080 real3 8080 real4 8080

  • bind 8443 real1 8443 real2 8443 real3 8443 real4 8443

Use the following procedure to configure the L4 switch for IPv6 support.

  1. Add an IPv6 virtual server for each of the corresponding IPv4 virtual servers:

    • server virtual vir-ipv6 2001::1

    • predictor round-robin

    • port 8080

    • port 8443

    • bind 8080 real1 8080 real2 8080 real3 8080 real4 8080

    • bind 8443 real1 8443 real2 8443 real3 8443 real4 8443

    NOTE:All real server configurations (real1, real2, real3, real4) in the above sample remains same for both IPv4 virtual server and IPv6 virtual server configurations.

  2. (Optional) To use a client IPv6 address for Authorization or Identity Injection Policies, L4 switch must be configured to send X-Forwarded-For IP header with each HTTP request.

IPv6 support is explained in the following scenarios. For simplicity IPv4 information is not provided. These scenarios support IPv6 in addition to IPv4. For more information on limitations for this support, see Section 7.3.3, Limitations.

7.3.1 Web SSO Over IPv6

Configuration: The L4 switch is configured to listen to the IPv6 Virtual IP addresses for both the Access Gateway and Identity Server clusters, for example, called IDP-v6 and AG-v6. The Identity Server and Access Gateway Servers should be configured in the L4 switch for listening to IPv6 requests as actual server groups IDP-Group and AG-Group. These groups serve the requests coming to IPv6 addresses configured in L4 switch.

The whole traffic to IDP-v6 and AG-v6 is forwarded to the Identity Server and Access Gateway clusters respectively with the source IP changed to the IP address of the L4 switch (IPv4-Internal).

How it works: Incoming traffic to the IDP-v6 and AG-v6 will be redirected to the IDP-Group and AG-Group based on load balancing algorithm configured in the L4 switch. The outgoing response traffic from the Identity Server and the Access Gateway Servers to the IPv6 clients will be first routed to IPv4-Internal and forwarded back to the client with source IP address of IDP-v6 and AG-v6. The traffic initiated from the Identity Servers to the Access Gateway Servers and vice versa for metadata exchange, artifact resolution and so on should also be routed through the L4 switch. Hence, the Identity Server and the Access Gateway Servers should resolve the Identity Server and the Access Gateway URL to the IPv4 addresses respectively as they understand only IPv4 addresses.

For example, if an internal DNS Server is used, then the DNS Server should be configured to resolve the Identity Server/Access Gateway Server URL. If the IPv4 address for the Identity Server is 10.75.75.1 and the Identity Server URL is www.idp.com, then the Identity Server clusters should have 10.75.75.1 www.idp.com in its hosts file.

The incoming traffic can be classified into the following:

  • Traffic initiated from IPv6 clients.

  • Connections initiated from the Access Gateway servers to the Identity servers.

However, both these can be considered the same as the responses from the Identity Server and the Access Gateway Servers will be using IPv4 address. The L4 switch converts the source to IPv6 address and forwards it to the respective remote parties. The clients can either be configured with IPv4 address or IPv6 address or both (dual stack). If the client is configured to use IPv6 address only or dual stack, it should resolve the published DNS names of the Identity Server and the Access Gateway Server to the IPv6 addresses respectively.

7.3.2 Federated SSO over IPv6

HTTP Browser clients coming in with IPv6 source address and published DNS names for Identity Provider and Service Provider URLs are accessible using IPv6 addresses. There are two ways you can access these, the Artifact or Post binding. For more information about these, see Configuring a SAML 2.0 Profile, Configuring a SAML 1.1 Profile, and Configuring a Liberty Profile.

Federated SSO over IPv6 Using Artifact Binding

Configuration

The L4 switch is listening in to the IPv6 Virtual IP addresses for the Identity Server cluster. Let us call it as IDP-v6. The IPv4-Internal in the L4 switch is connected to the actual Identity Server cluster. IDP-v6 listens to IPv6 clients. The whole traffic to the IDP-v6 will be forwarded to the Identity Servers with the source IP changed to IPv4-Internal. The Identity Servers listen on the IPv4 addresses only. These IPv4 addresses of the Identity Servers should be configured as real server group, say IDP-Group in the L4 switch. This group should serve the requests coming to IDP-v6 address configured in the L4 switch. Incoming traffic to the IDP-v6 addresses will be redirected to the IDP-Group based on the load balancing algorithm configured in the L4 switch.

In case of IDP Servers acting as a Service Provider in an Artifact binding scenario, it needs to resolve the Artifact received from the Identity Provider. Hence, the Service Provider must directly contact the remote Identity Provider. There will be traffic initiated from the Service Provider in federated SSO using Artifact binding. The L4 switch needs another IPv6 interface (IPv6-Internal) to forward connections from IPv6 addresses of the Identity Servers to IPv6 addresses of remote Identity Providers. The Identity Server acting as Service Provider must be configured to contain both IPv4 and IPv6 addresses. This facilitates communication with the IPv6 address of the L4 switch. If the Identity Server is acting as an Identity Provider, there is no connection initiated from the Identity Server even in the artifact binding scenario. Hence, an internal IPv6 interface in the L4 switch is not required.

How it Works?

The outgoing response traffic from the Identity Servers to the IPv6 clients will be first routed to IPv4-Internal and forwarded back to the clients with source IP address as IDP-v6 address.

When an Identity Server is acting as a Service Provider, the traffic will be initiated from the internal Identity Servers to the remote Identity Providers. This is routed through the L4 switch and the Identity Servers should resolve the remote Identity Provider URL to the remote IPv6 address. The DNS server configured for the Identity Server should be configured to resolve the Identity Provider URL to the remote IPv6 address.

When the Identity server is acting as an Identity Provider, the incoming traffic to this Identity Server can be classified into the following:

  • Traffic initiated from IPv6 clients.

  • Traffic from the remote Service Provider.

However, the response from the Identity Server uses IPv4 address in both cases. L4 switch converts the response to IPv6 address and forwards it to remote IPv6 clients and Service Providers respectively.The clients can either be configured with IPv4 address or IPv6 address or both (dual stack). If the client is configured to use IPv6 address only or dual stack, it should resolve the published DNS name of the Identity Server to IDP-v6 address.

Federated SSO over IPv6 using Post Binding

Configuration

The L4 switch is listening in to the IPv6 Virtual IP addresses for the Identity Server cluster. Let us call it as IDP-v6. The IPv4-Internal in the L4 switch is connected to the actual Identity Server cluster. IDP-v6 listens to IPv6 clients. The traffic to the IDP-v6 will be forwarded to the Identity Servers with the source IP changed to IPv4-Internal.

The Identity Servers listen on the IPv4 addresses only. These IPv4 addresses of the Identity Servers should be configured as real server group, say IDP-Group in the L4 switch. This group should serve the requests coming to IDP-v6 address configured in the L4 switch. Incoming traffic to the IDP-v6 addresses will be redirected to the IDP-Group based on the load balancing algorithm configured in the L4 switch.

Since there is no traffic initiated from the Identity Provider or Service Provider in federated SSO using Post binding, the Identity Servers should listen only using IPv4 address.

How it Works?

The outgoing response traffic from the Identity Servers to the IPv6 clients will be first routed to IPv4-Internal and forwarded back to the clients with source IP address as IDP-v6 address.

Since it is Post profile only incoming traffic will be from IPv6 clients. The clients can either be configured with IPv4 address or IPv6 address or both (dual stack). If the client is configured to use IPv6 address only or dual stack, it should resolve the published DNS name of IDP to IDP-v6 address.

7.3.3 Limitations

The following scenarios are not supported:

  • Access Gateways communicating over IPv6 to the Web Servers listening in IPv6 addresses.

  • Identity Servers communicating over IPv6 to the LDAP User stores listening in IPv6 addresses.