Mozilla should support IPv6 on those platforms where NSPR supports IPv6.

Updated patch (id=4678) works on both Linux and NT (both platforms with no native IPv6 support).

Reassigning to module owner for review and checkin. Putting on M15 radar, adding patch keyword. Tested on Solaris, Linux, and Windows. Needs testing on Macintosh. Patch contains unrelated bugfix to Macintosh DNS code--fields were not being correctly nul-terminated. Patch makes a subtle change to the semantics of nsISocketProviderService. The sockets created by this interface now have to handle PR_AF_INET6 addresses instead of PR_AF_INET addresses. For this reason, this change should go in as soon as is reasonable. Patch does not address the FTP EPSV command, needed for transfers between two IPv6 hosts. That issue is being tracked as bug 28874.

this is very cool. thanks jgmyers. assigning this to gordon

Found a bug in the IPv6 address literal handling.

Fixed a minor bug where nsDNSService::Lookup() wasn't recognizing IPv6 format address literals. Reassign back to gordon.

Thanks for the update John. The Mac code for converting the hostEnt still looks a bit funny, but I'll take a closer look at it. I'll try and get this in today.

The mac code is fixing an unrelated bug, where the h_name string was not being NUL-terminated and the h_addr_list array was not being NULL-terminated. Also, if too many addresses are returned to fit in the buffer, yet at least one address fits, it returns as many addresses as fit instead of failing the lookup.

If you don't like the Mac DNS changes, I don't think they're strictly necessary. It's just that if one has to convert the lookup result, one might as well convert it all the way to IPv6.

I reviewed jgmyers's patch 7091. 1. nsSocketTransport.cpp, lines 719,730: the change to the if-else brace identation style is not necessary. Note that the PR_OpenTCPSocket(PR_AF_INET6) change is necessary. 2. nsSocketTransport.cpp, lines 1579,1599: I would say #ifdef PR_LOGGING instead of #if PR_LOGGING. Also, the three lines mNetAddress.ipv6.family = PR_AF_INET6; mNetAddress.ipv6.flowinfo = 0; mNetAddress.ipv6.scope_id = 0; don't seem to be necessary because these three fields have already been set to those values by the memset and PR_SetNetAddr calls in the nsSocketTransport constructor. 3. nsDnsService.cpp, lines 455,464: I'm not sure about the "if (i > 0) break" change. I would just fail if too many addresses are returned to fit in the buffer. 4. nsDnsService.cpp, lines 483,496, nsDNSLookup::InitiateLookup: I would just call PR_StringToNetAddr blindly on the string mHostName to determine if it is numeric (either IPv4 or IPv6). jgmyers' hex and colon modification is correct, though.

jgmyers wrote: > The mac code is fixing an unrelated bug, where the h_name > string was not being NUL-terminated and the h_addr_list > array was not being NULL-terminated. These two fixes are independent of IPv6 and should be checked in.

> 3. nsDnsService.cpp, lines 455,464: I'm not sure about > the "if (i > 0) break" change. I would just fail if > too many addresses are returned to fit in the buffer. Could you explain why you would fail in this situation? How is failure in any way desirable? If a host has N addresses in DNS, where N is the largest number of addresses that fit in the buffer, a correctly written client will try the addresses in order until either one works (RFC 1123 section 2.3). Mozilla, on the other hand, will only try the first address. If an additional alternate address for the host is added to DNS, the currennt code will then make that host unreachable by the client. With the proposed fix, a correctly written client would try the first N addresses and Mozilla will act as it had before the additional address was added--it will only try the first address in the list.

Currently, the socket transport just tries the first address. We plan on cycling through the list in the future.

Cycling through the list is admittedly a separate bug. The three-line fix to have it truncate instead of fail if there are too many addresses to fit the buffer should be checked in, whether as part of this bug or a new bug on the Mac DNS conversion code. In about 30 minutes, I will be on vacation and without net access until about Apr 14. Hopefully, wtc can do any code changes required by code review.

I need to think and look at the code more to see what's the right thing to do if the returned addresses cannot all fit into the buffer. In any case, this issue is unrelated to the IPv6 stuff. We should check in the IPv6 portion of the patch, if approved by gordon or the PDT.

Patch has been integrated and checked in.

Relieving tever of IPv6 related QA.

VERIFIED: see bug 136898 for the meta bug.