In short, yes. The following article is based on the assumption that explicit proxy is being used for HTTP traffic.
As we progress into IPv6 networks, one of the more common transitory scenarios we will see will be similar to the following:
In the early stages of adoption of IPv6 networks, isolated “pools” of IPv6 networks will need to communicate with a predominantly IPv4 Internet. One of the many ways of facilitating this is using an explicit proxy deployment which converts IPv6 requests to IPv4 requests. More experienced IPv6 users will argue that this is equivalent to the now depreciated NAT-PT (protocol translation) and there are now better ways such as tunneling and relays to get an equivalent scenario working… but this is quite an easy and cheap way of achieving relatively good results.
The article assumes that an IPv6 network is already in place.
If link local IPv6 addresses are going to be used please be aware of the following:
1. Link-local addresses are not unique, so you must always specify an outgoing interface. To illustrate this a bit better, consider the output from this linux box when using ping6 or telnet with link-local addresses:
[root@localhost ~]# ping6 fe80::2d0:83ff:fe05:685
connect: Invalid argument
[root@localhost ~]# ping6 -I eth0 fe80::2d0:83ff:fe05:685
PING fe80::2d0:83ff:fe05:685(fe80::2d0:83ff:fe05:685) from fe80::20c:29ff:fe75:25fa eth0: 56 data bytes
64 bytes from fe80::2d0:83ff:fe05:685: icmp_seq=0 ttl=64 time=40.0 ms
64 bytes from fe80::2d0:83ff:fe05:685: icmp_seq=1 ttl=64 time=0.960 ms
64 bytes from fe80::2d0:83ff:fe05:685: icmp_seq=2 ttl=64 time=0.895 ms
— fe80::2d0:83ff:fe05:685 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2117ms
rtt min/avg/max/mdev = 0.895/13.951/40.000/18.419 ms, pipe 2
[root@localhost ~]# telnet fe80::2d0:83ff:fe05:685 8082
telnet: connect to address fe80::2d0:83ff:fe05:685: Invalid argument
telnet: Unable to connect to remote host: Invalid argument
[root@localhost ~]# telnet fe80::2d0:83ff:fe05:685%eth0 8082
Connected to fe80::2d0:83ff:fe05:685%eth0 (fe80::2d0:83ff:fe05:685%eth0).
Note how in either case you need to either add the –I eth0 switch or append the %eth0 to the IP address for the tool to work. The same case applies if you're using Firefox, where if you explicitly define the proxy link local IP, you must include the %interface:
Internet Explorer is more forgiving, no need to use the %interface, but remember to enclose the proxy IP in square brackets [ ] :
2. One other major troubleshooting drawback when using link local IPv6 addresses is that wireshark will not resolve link local addresses.
For those reasons this article uses unicast unique local (FC00::/7) IPv6 addresses in testing. Strictly speaking you can use any IPv6 address within that prefix, but in this testing the link-local address was copied and changed the first octet from FE80 to FC00. So for example on linux box you would add the IP by running:
[root@localhost ~]# ifconfig eth0 add fc00::20c:29ff:fe75:25fa/64
Configure similar IP addresses on the rest of the nodes.
Configuration on the ProxySG appliance
The Bluecoat proxySG requires minimal setup to get IPv6 working.
Using the CLI enter the following commands:
Enter configuration commands, one per line. End with CTRL-Z.
#(config interface 0:1)ipv6 auto-linklocal enable
There is no need to enable IPv6 forwarding. If you then navigate to the interfaces section, you can then see a link local IPv6 address configured on the interface. Simply add your unique unicast local address there:
Verify that you have met the following conditions:
- The proxy listener is set to intercept all explicit communication.
- The default gateway uses an IPv4 gateway and there is no IPv6 gateway configured.
- You have added the IPv6 address of the ProxySG to the Web browser.
You can then see the traffic entering in IPv6 and leaving your network using IPv4: