[ipv6hackers] IPv6 for for (developer) dummies

Karl Auer kauer at biplane.com.au
Fri Sep 14 15:53:18 CEST 2012

On Fri, 2012-09-14 at 10:07 +0100, Arturo Servin wrote:
> 	My understanding is that you do not need to do anything special to
> migrate Java apps.

It's really not that simple. It depends on the application.

Start with a simple grep for "IPv4", "IPv6", "Inet4Address",
"Inet6Address". The locations will be those where someone has been
specific about the IP protocol. It may be valid, it may be an area where
someone was thinking ahead or flagging an issue, or it may be an area
needing adjustment.

The porting mantra is "send, get, input, display, store, retrieve, use".
Most of the following is not really Java specific (but some of it is).

If your application sends an IP address anywhere, then those areas of
code may need to be adjusted. If the code is using InetAddress, the
changes may be minimal. If you are lucky.

If your application gets IP addresses from anywhere (over the wire, from
other devices, via DNS etc), then those areas of code may need to be
adjusted. If the code is using InetAddress, the changes may be minimal.
If you are lucky. Look for uses of InetAddress methods like getByName(),
getAllByName(), getByAddress(), getAddress(), getHostAddress(),
getHostName(), getCanonicalHostName() and so on. Watch out for code
using getByName() with DNS names; such code probably should be using
getAllByName() and dealing with multiple addresses.

If your application displays an IP address, you will almost certainly
need to adjust the code, as Java's own display possibilities for IP
addresses are very limited, and more so for IPv6 addresses (no
compression). Also, IPv6 addresses need more space to display on screen
or to print out, so forms and what-have-you will need adjusting.

If the user must input IP addresses you have the display issue as well,
plus the need to validate the input. Simple validation by attempting to
convert the input from a string to an InetAddress (getByName()) is
probably not good enough, and certainly not if you need any kind of
dynamic validity checking.

If your application stores addresses anywhere, then those areas of code
- and the storage schema - will need to be checked and probably
adjusted. IPv6 addresses take up more room in storage, and any back-end
data validation that is going on needs to take IPv6 into account. If you
are using InetAddress you may be lucky.

If your application retrieves IP addresses from a database - well, I'm
sure by now you get the idea.

And the biggy - if you application *uses* IP addresses itself, all the
related logic will need to be checked and possibly adjusted. Listening
on ports and connecting to ports is relatively straightforward provided
you use InetAddress, but even then you have to do everything twice.

In all of the above areas, look for places where assumptions have been
made about the size of an address - display size, storage size, etc.
These are distressingly commonly decoupled from the objects that will
use the space. And also search your codebase for any hardcoded

Don't forget configuration and logging modules; there's no point having
an IPv6-aware application with no way to configure it to actually use
IPv6. And with logging, don't forget any external consumers of the log
data - monitoring programs and the like. These will need to be modified
to handle the different output from your application.

Don't forget your test rig; from an IPv6 conversion perspective, your
test rig is an "application" and all of the above applies equally well
there. And any test that involves IP addresses implicitly or explicitly
must be extended or additional tests added to make sure that the tests
test the IPv6 cases as well.

When adjusting, be aware of IPv4 bias in variable names, function names,
class names and so on. Fix it where you can, document it where you
Finally, be aware that some Java implementations do not properly prefer
IPv6 addresses over IPv4 addresses. Some have a system configuration
setting for this, some have the setting and ignore it. Do getByName() on
a known dual-stack name and see if you get an IPv4 address or an IPv6

The above is just the beginning; this is a surprisingly deep rabbit
hole. With Java, by far the majority of IPv6 issues are not really
language issues, they are more issues of application design and coding
practice. That's not really good news, though, is it?

Regards, K.

Karl Auer (kauer at biplane.com.au)

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

More information about the Ipv6hackers mailing list