175340 - Implement IPv6 support on Win32

Status: RESOLVED FIXED

(NSPR :: NSPR, defect, P1)

Description

[Wan-Teh Chang]

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.

Comment 1

[John G. Myers]

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.
 

Comment 2

[Bob Clary [:bc] (inactive)]

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.

Comment 3

[Cyrus Patel]

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.

Comment 4

[Mathew McBride]

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

Comment 5

[Lorenzo Colitti]

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

Comment 6

[Darin Fisher]

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.

Comment 7

[Wan-Teh Chang]

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.

Comment 8

[Lorenzo Colitti]

Attachment: screenshot of firebird on WinXP - IPv6 works!

As you can see from the screenshot, IPv6 works in today's build of Firebird.
Great work guys!

Comment 9

[Lars Ehrhardt]

Attachment: Mozilla Win32/IPv6 Success

Just another success screenshot for Mozilla/Win32 Ipv6. 

Thanks guys!