What is IPV6 ?

From the IPV6 website

"IPv6 is short for "Internet Protocol Version 6". IPv6 is the "next generation" protocol designed by the IETF to replace the current version Internet Protocol, IP Version 4 ("IPv4")"

The ITEF RFC for IPV6 is here

What does it mean for AstroGrid ?

Many of the institutes that deploy AstroGrid services may already support IPV6 on their networks. This is a GoodThing^(TM) because it improves the data transfer between our services.

Can AstroGrid services use IPV6 ?

Yes, our systems are written in Java, and the Java network tools support IPV6.

Details on Java support for IPV6 available here

Are there any side effects ?

Yes, some AstroGrid services may fail when trying to access IPV6 services via IPV4 networks.

This is based on an investigation into problems I encountered trying to get a local AGINAB install to use the WFS SIAP service at Cambridge.

The symptoms I was investigating were :

• If I ran the tests on my machine at Cambridge, I could access the service.
• If I ran the tests on my machine at home I could not access the service.
• When run on a machine at home, the service calls failed with java.net.SocketException: Network is unreachable.
• However, I could connect to the service URL from my machine at home using a normal WebBrowser.

Investigating a bit further :

• I was running the tests on a Linux machine.
• Guy could access the service from a Windows machine at home.
• Kona could not access the service from a Linux machine at home.
• Kevin could access the service from a Windows machine at home.

The OS type and version appears to be significant.

From the ipv6.org website :

• Linux kernels version 2.2 and above ship with an IPv6 implementation built in
• Microsoft Windows XP includes an IPv6 implementation intended for development use and trial network deployments. For installation instructions ....

From the Sun Java website (emphasis mine) :

• Java 1.4.x supports IPV6 on Linux
• Java 1.4.x does not support IPv6 on Microsoft Windows (at the moment).

It may seem that running our Java tools on Linux would be an advantage, because we it allows us to use IPV6 if the server supports it. However, there are complications. This is what I've found out so far ....

To test this I used a simple JUnit test that tries to open a URLConnection to the target SIAP service.

try {
    String url = "http://archive.ast.cam.ac.uk/cgi-bin/wfs-siap/queryImage" ;
    URL url = new URL(target);
    URLConnection conn = url.openConnection();
    conn.setRequestProperty("POS",  "180,0");
    conn.setRequestProperty("SIZE", "0.5");
    InputStream in = conn.getInputStream();
    ....
    }
catch (Exception ouch)
    {
    ....
    }

The current registry entry for the WFS SIAP service lists the access URL as http://archive.ast.cam.ac.uk/cgi-bin/wfs-siap/queryImage

archive.ast.cam.ac.uk is a DNS alias for cass38.ast.cam.ac.uk, a Sun machine on the Cambridge network.

[..]$ host -a archive.ast.cam.ac.uk
....
;; ANSWER SECTION:
archive.ast.cam.ac.uk.  86400   IN      CNAME   cass38.ast.cam.ac.uk.
....

The DNS records for cass38.ast.cam.ac.uk list two addresses, an A record containing the IPV4 address, and an AAAA record containing the IPV6 address.

[..]$ host -a cass38.ast.cam.ac.uk
....
;; ANSWER SECTION:
cass38.ast.cam.ac.uk.   86400   IN      A       131.111.68.89
cass38.ast.cam.ac.uk.   86400   IN      AAAA    2001:630:200:4240:a00:20ff:fefb:1458
....

When the Java test is run on a Windows machine, it uses the IPV4 address and connects to the service.

When the Java test is run on a Linux machine, it gets both the IPV4 address and the IPV6 address. Because the local Linux machine and the remote service both support IPV6, the Java network tools try to use the IPV6 address.

This works when the service and the client are both connected to university networks. However, if the client machine is connected to the internet using an ADSL line, the connection fails.

The Cambridge network supports IPV6, and my own Linux network supports IPV6, but the ADSL line connecting the two does not.

How does this impact AstroGrid now ?

We need to be aware that IPV4/IPV6 issues may cause network connection problems. Essentially, if the client and server systems support IPV6 then by default Java will try to use IPV6.

If the IPV6 connection fails, because one of the links in the chain connecting client and server does not support IPV6, the Java network tools will not retry the connection using IPV4.

This probably does not impact our core services, although there may be issues with installations at smaller institutes that do not have IPV6 connections.

However, this may cause problems with our client software, particularly the tools invoked using JavaWebStart or JNLP.

• If the client is run on a university machine, then it will probably be on an IPV6 network.
• If the client is run on a Unix or Linux machine, then it will try to use IPV6.
• If the client is run on a Windows 2000 machine, then it will not try to use IPV6.
• If the client is run on a Windows XP machine, then it may try to use IPV6, it will depend on the local JDK and Windows versions.

Possible fixes

Avoid IPV6 addresses

Make sure that none of the services contacted by clients has an IPV6 address. Not very practical, as the Astronomer installing the service might not know (or want to know) how the DNS settings for their institute are configured. Plus, this means that we can't use IPV6 for transfer between any of our services.

Use IPV4 proxies

We can use http proxies with IPV4 addresses for all of our services. For example, as part of the testing for this I setup a http proxy http://capc49.ast.cam.ac.uk/siap for http://archive.ast.cam.ac.uk/cgi-bin/wfs-siap/queryImage. The proxy is setup using httpd on a machine at Cambridge that does not (yet) have an IPV4 address.

This isn't really a long term solution, it is probably worse than 1), but it works as an interim solution.

Disable IPV4 on the client

There are two Java system properties that we can use to prevent the Java networking tools from trying IPV6 addresses.

• java.net.java.net.preferIPv4Stack
• java.net.preferIPv6Addresses

Details available here.

This isn't ideal, but it is probably the best option so far.

It does mean that even if the client is running on a university network with full IPV6 support, it will still use IPV4 to connect to our services.

BTW - Does anyone know if we can set system properties when we launch JavaWebStart applications ?

Yes we can - in the java webstart jnlp file there's places in the schema to specify system properties, parameters, and commandline options. -- NoelWinstanley - 21 Apr 2005

A nice solution would be a gadget called when the application first starts that tries to connect to a known IPV6 address, and sets a configuration property to disable IPV6 if the connections fails with Network is unreachable.

Failover to alternative AstroGrid services

Failover to alternative services is something that we are going to have to look at within AstroGrid anyway.

We could give each of our services had two registry entries, one direct to the service, and a second one via an IPV4 only proxy. The client tools would try the default entry, and then failover to the IPV4 proxy if the direct connection failed.

Modify Java net tools to failover from IPV6 to IPV4

Unfortunately, this isn't built in to the current Java network tools.

It would be nice if we could figure out a way of wrapping the Java networking tools to try an IPV4 address if an IPV6 address fails. I'm not sure if this would be possible, and if we did, it could be tricky to make sure 3rd party tools like Axis and Tomcat used our modified tools.

Linux 2.6.12 kernel

The latest kernel updates for FedoraCore^? 3 (2.6.12-1.1372_FC3) can cause IPV6 problems with Java JDK-1.4.2, even if the target host does not have an IPV6 address.

Watching the network traffic with a packet sniffer I can see Java making two DNS requests, one for an IPV6 AAAA record and another for an IPV4 A record. It looks like Java JDK-1.4.2 tries to use IPV6 even if the DNS server did not reply with an IPV6 AAAA record.

This happened when I added the latest kernel update to an existing FedoraCore^? 3 system. This means updating an existing (working) system can cause IPV6 problems.

Tomcat localhost shutdown

A symptom of this problem is when tomcat's startup.sh script will start successfully, but the shutdown.sh script will fail to shut tomcat down again.

The fix for Tomcat is to add -Djava.net.preferIPv4Stack=true to the JAVA_OPTS environment variable.

For more details see : IPV6Warning

Maven downloads

Amongst other things, maven fails to download jars from remote repositories. The symptoms are

java.net.SocketException: Invalid argument or cannot assign requested address

The fix is to add -Djava.net.preferIPv4Stack=true to the MAVEN_OPTS environment variable (the maven shell scripts don't read the JAVA_OPTS used by Tomcat).

The easiest way to do this is to add the following to a file called .mavenrc in your home directory.

if [ -z "$MAVEN_OPTS" ] ; then
  MAVEN_OPTS="-Djava.net.preferIPv4Stack=true"
fi

For more details see : IPV6Warning

-- DaveMorris - 25 Jul 2005

---

Geek notes

For the terminally sad ones amongst us that would be interested in getting IPV6 to work on their ADSL connection.

Simple test from Maven

The easiest way to test your system is to add the following goals to a maven.xml file and then run them.

    <!--+
        | Send a direct request to the (IPV6) FWS SIAP service.
        +-->
    <goal name="frog">
        <get verbose="true" src="http://cass38.ast.cam.ac.uk/cgi-bin/wfs-siap/queryImage" dest="siap.xml"/>
    </goal>
    <!--+
        | Send a request via an IPV4 only proxy.
        +-->
    <goal name="toad">
        <get verbose="true" src="http://capc49.ast.cam.ac.uk/siap" dest="siap.xml"/>
    </goal>
    <!--+
        | Disable java.net IPV6 support.
        +-->
    <goal name="newt">
        ${systemScope.setProperty('java.net.preferIPv4Stack','true')}
        <get verbose="true" src="http://cass38.ast.cam.ac.uk/cgi-bin/wfs-siap/queryImage" dest="siap.xml"/>
    </goal>

• The first one defaults to using the IPV6 address, and will fail if your connection does not support it.
• The second one calls the same service via a http proxy which does not have an IPV6 DNS entry.
• The third one uses a system property to disable the java.net support for IPV6.

IPV6 over IPV4 tunnel

For now, the easiest will probably be to use some form of IPV6 over IPV4 tunnel, routing IPV6 traffic from your LAN to a node at a friendly university network. If anyone knows how to set this up, can you let me know.

ISP support

I have contacted my ISP to ask if they do support IPV6, initial response was er ... not sure, we'll get back to you. If anyone knows of an ISP that does support IPV6 can you let me know.

Response from my ISP

At present the Demon network does not support IPV6

As with other ISP's are projects team are currently working on projects relating to IPV6, but they have not yet published any timescales for implementation

Tiscali seem to support it - that is to say your test above works fine for me. I can't find anything on their website confirming it though. -- JohnTaylor

Hardware support

The main stumbling block will probably be the ADSL router connecting you local systems to the ADSL line.

I currently use a D-Link router, and they do provide access to the Linux source code for the firmware. I contacted D-Link technical support, and eventually got through to someone who knew what IPV6 was. Unfortunately, they seemed to think that it wasn't a firmware problem, the current D-Link hardware would not support IPV6.

This LinkSys router looks like a better option. Primarily because it will support the OpenWrt firmware, which appears to contain some level of support for IPV6.

If I find out anything more I'll let you know.

-- DaveMorris - 21 Apr 2005

A recent SlashDot article about IPV6 support for the Linksys WRT54G router contains some useful comments on IPV6 deployment.

-- DaveMorris - 27 May 2005

We also encountered similar problems with some machines at the ESO workshops.

The workshop network has a Linux server running a database, and the delegates were running AstroGrid services on their laptops.

Some of the delegates experienced problems establishing a JDBC connection to the database server from their Linux laptops, the fix was to disable IPV6 on the client.

I suspect that although the server and client supported IPV6, the wireless network did not.

Blackcat Networks

I recieved an email from Ray Robertson at Eckoh Technologies to say that Blackcat Networks do support IPV6 over ADSL.

Details of their ADSL services are here : http://www.blackcatnetworks.co.uk/services/adsl

Key points are :

• Fixed IP address
• They will allocate a /48 of IPv6 address space if required
• Native IPv6 not IPv6 over an IPv4 tunnel

-- DaveMorris - 25 Jul 2005