Numeric IPv6 addresses don't work

RESOLVED FIXED in mozilla1.6beta



15 years ago
10 years ago


(Reporter: Jens Kammann, Assigned: Lorenzo Colitti)



Windows XP

Firefox Tracking Flags

(Not tracked)




(4 attachments)



15 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

On a Windows XP (SP1) System with working IPv6 connectity (tunnel, tracert6 
working), Mozilla fails to load ip6 version of webpages: Eg. loads IPv4 version, http://[3ffe:b00:c18:1::10] should 
force ipv6 version, but results in "The connections was refused". However, 
manually fetching the page from the command line "telnet 3ffe:b00:c18:1::10 
80 ; GET / HTTP/1.0" works. Please see attached HTTP Debug log from Mozilla.

Reproducible: Always

Steps to Reproduce:
1.http://[3ffe:b00:c18:1::10] of any other ipv6-only webpage

Actual Results:  
"The connection was refused"

Expected Results:  
load and display the page

see attachment for HTTP log

Comment 1

15 years ago
Created attachment 133781 [details]
HTTP log when accessing http://[3ffe:b00:c18:1::10]

Comment 2

15 years ago
I'm not sure if patch for 205726 made it into 1.5.
Can you try again with latest nightly build (ie. trunk 1.6) ?

Comment 3

15 years ago
Almost the same result with the latest build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031022

Almost means, that e.g. still connects via IPv4, but
http://http://[3ffe:b00:c18:1::10] once showed the IPv6 version of the web site.
A second try of the same URL results just in an empty page with "Done" in the
status line. Unfortunately this was a one-time success: Even restarting or
rebooting did not bring up the IPv6 version of the site again.

Comment 4

15 years ago
can you attach a HTTP log for the failing session via "create a new attachment" ?
See instructions here:
perhaps related to bug 219088 ?

Comment 5

15 years ago
Created attachment 133982 [details]
Request for http://[2001:200:0:8002:203:47ff:fea5:3085]

This is the log for accessing http://[2001:200:0:8002:203:47ff:fea5:3085
(	- results in empty page and "done"

Comment 6

15 years ago
Marking NEW since it has log and CC'ing Lorenzo (if you mind, please let me know
or remove yourself from CC list) so that he can look at it and perhaps connect
to this host with his machine.
Ever confirmed: true

Comment 7

15 years ago
Jens, are you compiling Mozilla yourself or are you seeing this in
build? I saw this too, but I assumed it was due to IPv6 not working because I
was building with mingw.

This is what the log says:

1848[a28028]: ErrorAccordingToNSPR [in=-5986 out=80004005]
1848[a28028]:   connection failed! [reason=80004005]


which is the NSPR version of WSAEADDRNOTAVAIL:

Assuming that the call that is falling is connect(), this is what MSDN has to

WSAEADDRNOTAVAIL The remote address is not a valid address (such as ADDR_ANY).
If the address member of the structure specified by the name parameter is all
zeroes, connect will return the error WSAEADDRNOTAVAIL.

Somehow I doubt that the socket address being passed in is all zeros though. :)

I'll test it on a recent nightly and let you know what I see.
I don't think it's related to bug 219088, though: that one is about name resolution.

Comment 8

15 years ago
Lorenzo, I took the nightly build from and I should note that I
noticed the same behavior with the "old" Ipv6 stack of XP before I upgraded to
the current one.
Although I think this is not related to bug 219088, too, this bug also hasn't
been  fixed yet: Some webpages (e.g. load using IPv6, others (e.g. appear in the IPv4 version.

I am working on HTTP-Proxy development for a different project and I am planning
to upgrade our lab network to IPv6 pretty soon, so that I will have access to
several platforms (solaris, linux, windows in different languages) for further

Comment 9

15 years ago
Ok, I tested build 2003102504 on Windows XP SP1 with the Advanced networking
pack, and this is what I see.

Numeric IPv6 addresses: if I enter http://[2001:200:0:8002:203:47ff:fea5:3085]/
or any oher URL with a numeric IPv6 address and press enter, the progress bar
lights up for a fraction of a second, but nothing happens! The site does not
load and the browser continues to display the page it was displaying before
typing the URL. No error message appears. This is bad. :)

IPv6 hostnames: everything seems to work. gives me the IPv6
version, and tells me that I am using IPv6. also tells me I am connecting using IPv6.

This might be caused by the fix to bug 219376. If this is indeed the case,
builds from 5 October should work and builds from 6-7 october should have this
bug. Anyone want to test this?

Comment 10

15 years ago
Jens, do you confirm that numeric IPv6 addresses fail but IPv6 hostnames work?

If so, we can change the summary to "Numeric IPv6 addresses in URL cause page
load to fail silently" or something like that.

Note that in the first log file (the one for http://[3ffe:b00:c18:1::10]), the
error is -5980, which is destination unreachable. Are you sure you have
connectivity to that IPv6 address?


15 years ago
Blocks: 219376
Keywords: regression


15 years ago
Target Milestone: --- → mozilla1.6beta

Comment 11

15 years ago
The trace belows shows that I have a working IPv6 connectivity to 
[3ffe:b00:c18:1::10]. I also tested the address with Opera 7.21 on the same 
PC, no problems.

BTW I found a better example to demonstate the effect:

A)  (resolves to:)
B) http://[3ffe:81d0:ffff::3]

Expected behavior (tested with Opera 7.21):
A) IPv6 version of web page loads
B) same as A)
C) IPv4 version loads

Behavior of Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a)

A) IPv4 version of page loads (DNS issue ? Or fallback since IPv6 version 
fails ?)
B) Empty page, Status line "done"
C) IPv4 version loads

Tracing route to [3ffe:b00:c18:1::10]
from 2002:d536:8768::d536:8768 over a maximum of 30 hops:

  1      108 ms   108 ms   111 ms  2002:3eec:20cb::1
  7      533 ms   531 ms   531 ms
  8      543 ms   531 ms   529 ms [3ffe:b00:c18:1::10]


Comment 12

15 years ago
C) is, of course, an IPv4 address. No surprises here: bug 219376 is fixed.

B) I see this too: numeric IPv6 addresses don't work. This probably regressed on
20031006. Can you test this on Windows builds from 20031005 and 20031007 to see
if one works and one doesn't?

A) works fine for me. Can you attach an HTTP log of what happens when you try to
connect? With build 2003102504 (trunk) on XP I get the IPv6 version.
No longer blocks: 219376

Comment 13

15 years ago
Created attachment 134426 [details]
Log accessing - IPv4 shows instead of IPv6

Here's the requested log for case "A" ( IPv4 version loads,
but IPv6 is expected).
I am unable to locate Windows Installer Versions of the older versions you
request. I see only Linux an Os2 version. If you can point me to the place
where I can find these, I'll post also the other logs.


Comment 14

15 years ago
Jens, you might want to try these two builds:

Check that the first can connect to numeric IPv6 addresses and the second can't.

Regarding your log file, something strange is happening. It looks like mozilla
is not getting the IPv6 address at all, because the first connection it makes is
to an IPv4 address. Is it an option for you to use a packet sniffer to sniff the
DNS requests mozilla is making? In any case, this looks like a different bug.

Comment 15

15 years ago
Ok, I found the cause of the "numeric IPv6 addresses not working" problem.

The problem is that when a numeric IPv6 address is specified in the URL bar, the
sin6_scope_id field of the sockaddr_in6 structure is not zeroed out. I suspect
that happens because we are not calling getaddrinfo() on the IPv6 address, but
trying to fill in the socket address structure ourselves.

Patch coming up.
Assignee: darin → lorenzo
Summary: ipv6 problem in Mozilla for Win XP → Numeric IPv6 addresses don't work

Comment 16

15 years ago
Created attachment 134616 [details] [diff] [review]
wallpaper patch

One-line patch to ensure that the address returned by
nsHostResolver::ResolveHost does not contain garbage.

Comment 17

15 years ago
Note that this patch solves the numeric IPv6 address problem, but what we should
really be doing is calling getaddrinfo on the hostname, even if it's a numeric
IPv6 address.

getaddrinfo will always be smarter that we are, and it understands stuff such as
scope identifiers that we shouldn't really be dealing with. But trying to
resolve all numeric addresses will bring bug 219376 back to life, so what can we do?

Since a platform that supports IPv6 must have getaddrinfo, and RFC 2553 says
that getaddrinfo must be able to understand numeric addresses, if
nsHostResolver::ResolveHost gets a numeric address it could check what type of
address it is and copy it if it's an IPv4 address and resolve it if it's an IPv6
address. But this would mean tinkering with address families and adding
platform-specific code in the DNS resolver, which is not very nice either.

Maybe this can be fixed by changing PR_StringToNetAddr so it uses getnameinfo()?
CC'ing wtc for thoughts.

Comment 18

15 years ago
Comment on attachment 134616 [details] [diff] [review]
wallpaper patch

In the meantime, this is a 99% solution that should probably go into 1.6b

Darin, can you rubber-stamp this?
Attachment #134616 - Flags: review?(darin)

Comment 19

15 years ago

PR_StringToNetAddr should have zeroed the PRNetAddr object.
Since we didn't do that before, I can't do that right now
even though it's the right thing.  (This is for backward
compatibility.)  So, your patch is correct.  Darin may be
able to figure out a way to only do the memset(,0,) call if
PR_StringToNetAddr will be called.

PR_StringToNetAddr currently uses the deprecated inet_pton
function, which I remember doesn't handle scope id's.  Your
suggestion of using getnameinfo is good.  I remember there
is already a bug filed on this.  If not, Darin, could you
write an enhancement request?

Comment 20

15 years ago
Comment on attachment 134616 [details] [diff] [review]
wallpaper patch

r+sr=darin, but please add a detailed comment explaining this hack, and
reference this bug.  thanks :)
Attachment #134616 - Flags: superreview+
Attachment #134616 - Flags: review?(darin)
Attachment #134616 - Flags: review+

Comment 21

15 years ago
wtc: see bug 34843.  that has to do with using getnameinfo.

Comment 22

15 years ago
so there are several other places where PR_StringToNetAddr is called.  should we
add a similar hack to those as well?

see nsProtocolProxyService.cpp and nsCookieService.cpp

btw, this patch has been checked in on the trunk.

>Maybe this can be fixed by changing PR_StringToNetAddr so it uses getnameinfo()?

maybe this is necessary for IPv6 to really work.  otherwise, we do have to fix
all the callers.  ok... now, hmm... wait a second.  if it is okay to make
PR_StringToNetAddr call getnameinfo (which will effectively touch all fields of
PRNetAddr), why isn't it okay to have PR_StringToNetAddr zero out the PRNetAddr
struct?  how is it that getnameinfo doesn't similarly break binary compatibility?

i think it is reasonable for PR_StringToNetAddr to always return a PRNetAddr
that is meaningful.  it should not require that the result buffer be zero'd out
a priori.

Comment 23

15 years ago
Darin, zeroing PRNetAddr before use is not a hack.  It is the
right thing to do.  Unfortunately, I learned about it too late.

The reason I can't change PR_StringToNetAddr to zero out the
PRNetAddr struct is that the caller may have set the 'port'
field of the PRNetAddr struct.

Comment 24

15 years ago
>so there are several other places where PR_StringToNetAddr is called.  should we
>add a similar hack to those as well?
>see nsProtocolProxyService.cpp and nsCookieService.cpp

I checked and it seems that we don't have to change anything else. Everywhere
PR_StringToNetAddr is called (according to LXR at least), the caller either
looks only at the return value and not the returned address, or uses the
returned address to copy it into a PRIPv6Addr, which does not contain the scope

Comment 25

15 years ago
Shall we resolve this?

Reporter, can you still reproduce the problems?

Comment 26

14 years ago
Marking fixed since one of the problems reported was fixed and we were never
able to reproduce the other one.


14 years ago
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.