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.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → 4.3
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.
from Briefing on New Defense Department Internet Protocol <http://www.defenselink.mil/transcripts/2003/tr20030613-0274.html> <quote> 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 </quote> 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: http://www.ietf.org/rfc/rfc2732.txt Which basically means If I want to go to 6bone using it's IPV6 ip: 3ffe:b00:c18:1::10 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. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcetcpip/html/cmconaddingipv6capabilitytoipv4application.asp 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 62402
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.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
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.