17 years ago
11 years ago


(Reporter: wtc, Assigned: wtc)


Windows XP
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [4.5])


(2 attachments)

Windows XP has IPv6 support but does not have getipnodebyname
and IPv4-mapped IPv6 addresses.

We can emulate them in NSPR.

1. Implement PR_GetIPNodeByName in terms of getaddrinfo.

2. Implement NSPR PR_AF_INET6 sockets that can connect to
or bind to IPv4-mapped IPv6 addresses.

Note that it is difficult or even impossible to implement
NSPR PR_AF_INET6 listening sockets that can accept both
IPv4 and IPv6 connections.  I am not sure if other platforms
implement this.
Priority: -- → P1
Target Milestone: --- → 4.3
Blocks: 110565
Note that you can implement a listening socket that can be bound to either a
native or IPv4-mapped IPv6 address.  It's just that implementing a listening
socket that is unbound or bound to the unspecified address that is difficult.
Target Milestone: 4.3 → Future
from Briefing on New Defense Department Internet Protocol

we're going to insist that acquisitions and programs that move on after the
first of the next fiscal year, which is October, will be IP 6-compatible

IPv6 is not a luxury. We need to get this targetted.

Excuse my ignorance, but why is creation of _listening_ sockets an issue? 
After all, Moz is a client, not a server.

I see that my current Moz instance is listening on localhost:1381 (and only Moz
itself is connected to it),...

a) why is this?
b) why is it using (high-overhead) TCP/IP sockets and not windows messages or 
   even pipes or mailslots?
c) if the only client is going to be itself why care about IPv4/v6 differences?
   Simply settle on the use of one or the other (or use "native") for these 
   intra-machine connections.
Excuse me if im spamming.. (hopefully not) 

We also need to support rfc2732:

Which basically means If I want to go to 6bone using it's IPV6 ip:

http://3ffe:b00:c18:1::10 is in violation of that RFC
http://[3ffe:b00:c18:1::10] is legal. But Mozilla at the moment, rejects both
the illegal syntax, and *choke* the legal one. 

I don't know why we need to create listening sockets, but I know that IE does it
too.  I don't seem to see external connections from the internet connecting to
that port, so a IPv6 listening socket for a simple loopback connection is redundant.
seems to be useful.

CC'ing myself
Regarding comment #4: Mozilla already handles this correctly when IPv6 is
enabled (e.g. on Linux). For example, I can connect to http://[2001:760:4::1]/

However, if I just enter 2001:760:4::1 in the url bar and press enter, nothing
happens. Mozilla should report an error in this case, but it doesn't. That's bug
this bug is essentially solved by the patch for bug 211501, which just landed on
the NSPR trunk and NSPRPUB_PRE_4_2_CLIENT_BRANCH (which is used by mozilla).  i
think we can consider this bug FIXED now.
Depends on: 211501
Thanks, Darin.

IPv6 support for Win32 will first appear in NSPR 4.5.
This support is not complete (for example,
PR_GetIPNodeByName and IPv4-mapped IPv6 addresses
still aren't supported for Win32), but is good enough
for Mozilla (1.6 alpha).

If there is demand for the unimplemented features,
I'll open specific enhancement requests.
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [4.5]
Target Milestone: Future → ---
As you can see from the screenshot, IPv6 works in today's build of Firebird.
Great work guys!
Just another success screenshot for Mozilla/Win32 Ipv6. 

Thanks guys!
You need to log in before you can comment on or make changes to this bug.