FULL PRODUCT VERSION :
$ java -version
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
$ cat /etc/debian_version
testing/unstable
$ uname -a
Linux Solo 2.6.13 #1 Sun Sep 4 14:39:54 CEST 2005 i686 GNU/Linux


EXTRA RELEVANT SYSTEM CONFIGURATION :
IPv6 in module, bindv6only on

A DESCRIPTION OF THE PROBLEM :
With sysctl net.ipv6.bindv6only plugin can't download applet from IPv4 servers. Strace says, that it tries to connect to something like ::ffff:192.168.0.1, which fails. Downloading applets from IPv6 servers or using file:// works fine. Downloading applet from server with both A and AAAA entries in DNS fails. Removing all IPv6 addresses or doing echo 0 > /proc/sys/net/ipv6/bindv6only helps, but is unacceptable for me.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Mount procfs (important)
2. Turn IPv6 on
3. Set IPv6 addresses
4. echo 1 > /proc/sys/net/ipv6/bindv6only
5. mozilla-firefox http://some.ipv4.server/page


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Applet is downloading from server and starts.
ACTUAL -
Applet doesn't start. Logs from www server and proxy server (if connecting via proxy) says, that it wasn't tried to download. Strace says, that it tries to connect to ::ffff:192.168.0.1, which fails. Browser says: "Loading Java Applet Failed..."

ERROR MESSAGES/STACK TRACES THAT OCCUR :
  From java console:
Java Plug-in 1.5.0_04
Using JRE version 1.5.0_04 Java HotSpot(TM) Client VM
User home directory = /home/jarek


----------------------------------------------------
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
l:   dump classloader list
m:   print memory usage
o:   trigger logging
p:   reload proxy configuration
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
v:   dump thread stack
x:   clear classloader cache
0-5: set trace level to <n>
----------------------------------------------------

java.lang.InterruptedException: sleep interrupted
	at java.lang.Thread.sleep(Native Method)
	at com.topcoder.client.contestApplet.widgets.MoveFocus$1.run(Unknown Source)
	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)
load: class IRCApplet.class not found.
java.lang.ClassNotFoundException: IRCApplet.class
	at sun.applet.AppletClassLoader.findClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at sun.applet.AppletClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at sun.applet.AppletClassLoader.loadCode(Unknown Source)
	at sun.applet.AppletPanel.createApplet(Unknown Source)
	at sun.plugin.AppletViewer.createApplet(Unknown Source)
	at sun.applet.AppletPanel.runLoader(Unknown Source)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: open HTTP connection failed.
	at sun.applet.AppletClassLoader.getBytes(Unknown Source)
	at sun.applet.AppletClassLoader.access$100(Unknown Source)
	at sun.applet.AppletClassLoader$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	... 10 more
Exception in thread "Thread-18" java.lang.NullPointerException
	at sun.plugin.util.GrayBoxPainter.showLoadingError(Unknown Source)
	at sun.plugin.AppletViewer.showAppletException(Unknown Source)
	at sun.applet.AppletPanel.runLoader(Unknown Source)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
java.lang.NullPointerException
	at sun.plugin.util.GrayBoxPainter.showLoadingError(Unknown Source)
	at sun.plugin.AppletViewer.showAppletStatus(Unknown Source)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Exception in thread "thread applet-IRCApplet.class" java.lang.NullPointerException
	at sun.plugin.util.GrayBoxPainter.showLoadingError(Unknown Source)
	at sun.plugin.AppletViewer.showAppletException(Unknown Source)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Every java applet on IPv4 server. For example http://www.vilo.bydgoszcz.pl/chat.php
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
echo 0 > /proc/sys/net/ipv6/bindv6only or run in chroot without procfs.
Posted Date : 2005-10-27 11:32:50.0

N/A

N/A

This is debian bug 560142: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560142

bindv6only is the default on debian now, so this bug should be bumped up in priority.

the default value for "net.ipv6.bindv6only" is "0"
setting it to "1" breaks the rules and is nonsense.

see "http://www.kernel.org/doc/man-pages/online/pages/man7/ipv6.7.html"

The priority may be higher now that 1 is the default on debian:

net.ipv6.bindv6only=1 breaks some buggy programs
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560238

This bug is hitting me and I must confess it's quite annoying.

@nbreun 
Concerning the fact that net.ipv6.bindv6only=0 is the default on Linux, I agree of course but I don't see why setting it to 1 is "nonsense" ... I especially didn't find anything implying that in the manpage you linked to.
It even seems to me that other operating systems (including some *BSDs) made a different choice. I read somewhere about security problems whith the behaviour implied by setting this parameter to 1, I'll come back to you with the link as soon as possible.

Having been hit by this on Debian, and having lost my time and others' on this, I respectfully suggest that the priority of this be raised, to avoid that the same thing happen to others.
Also please note that at first sight this looked like a serious Java bug (Personally, I don't know or care whose "fault" it is).
Jean-Guilhem Cailton (jgc@arkemie.com)
OpenStreetMap Haiti

http://diario.beerensalat.info/2008/10/12/java_and_ipv6_on_bsd.html explains the issue for the BSD operating systems which have the same problem as Debian

I have added the patch at http://bazaar.launchpad.net/~openjdk/openjdk/openjdk6/annotate/head%3A/patches/ipv4-mapped-ipv6-addresses.diff to the (IcedTea based) Debian/Ubuntu package.

It would be nice if Sun/Oracle could take in account this bug. Distribution can patch the Openjdk but it is much harder with the Sun JDK.

It should not be a low priority bug but a critical one... Especially after 5 years...