Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
25727003:
Enable IPv4 address mapped to IPv6. (Closed)
|
Created:
7 years, 2 months ago by halyavin Modified:
7 years, 2 months ago Reviewers:
jar (doing other things) CC:
chromium-reviews, cbentzel+watch_chromium.org Base URL:
svn://svn.chromium.org/chrome/trunk/src/ Visibility:
Public. |
DescriptionEnable IPv4 address mapped to IPv6.
Chrome can't connect to IPv4 address mapped to IPv6 because
Windows requires IPv6 socket not to have IPV6_V6ONLY option
to connect to IPv4 address. See
http://msdn.microsoft.com/en-us/library/windows/desktop/bb513665(v=vs.85).aspx
TEST= open http://[::ffff:<IPv4 address>] in the browser.
BUG= none
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=227332
Patch Set 1 #
Total comments: 4
Patch Set 2 : #Messages
Total messages: 13 (0 generated)
Can you clarify why this comes up in practice? Are we listening on sockets in the client? ...and in such scenarios, do we have to accept connections from both IPv4 and IPv6? It seems that if we're originating the connection, then we'll have an IPv4 (or v6) address, and never really care about the address that responds to us (and expect it to match what we connected to). Also, how are you handling older-than-vista systems, wherein the article cited says: "In order to support both IPv4 and IPv6 on Windows XP with Service Pack 1 (SP1) and on Windows Server 2003, an application has to create two sockets, one socket for use with IPv4 and one socket for use with IPv6. These two sockets must be handled separately by the application." Can you explain what else you've changed to make this work on XP? https://codereview.chromium.org/25727003/diff/1/net/socket/socket_descriptor.cc File net/socket/socket_descriptor.cc (right): https://codereview.chromium.org/25727003/diff/1/net/socket/socket_descriptor.... net/socket/socket_descriptor.cc:42: if (setsockopt(result, IPPROTO_IPV6, IPV6_V6ONLY, (const char*)&value, nit: please use C++ style reinterpret_cast<const char*>(&value) https://codereview.chromium.org/25727003/diff/1/net/socket/socket_descriptor.... net/socket/socket_descriptor.cc:45: result = kInvalidSocket; nit: easier to read is a direct: return kInvalidSocket;
On 2013/10/04 02:49:18, jar wrote: > Can you clarify why this comes up in practice? Are we listening on sockets in > the client? ...and in such scenarios, do we have to accept connections from > both IPv4 and IPv6? > > It seems that if we're originating the connection, then we'll have an IPv4 (or > v6) address, and never really care about the address that responds to us (and > expect it to match what we connected to). This is happens in a NaCl application that contains IPv6-only code. The code converts IPv4 addresses to IPv6 ones. Unfortunately, client connections to IPv4 address mapped to IPv6 need this flag too. > > Also, how are you handling older-than-vista systems, wherein the article cited > says: > > "In order to support both IPv4 and IPv6 on Windows XP with Service Pack 1 (SP1) > and on Windows Server 2003, an application has to create two sockets, one socket > for use with IPv4 and one socket for use with IPv6. These two sockets must be > handled separately by the application." > > Can you explain what else you've changed to make this work on XP? I hoped that IPv6 address will not be generated on Windows XP but now I see that IPv6 is used on all systems. I don't see any other way other than changing family from AF_INET6 to AF_INET in this case (not implemented in the CL yet).
https://codereview.chromium.org/25727003/diff/1/net/socket/socket_descriptor.cc File net/socket/socket_descriptor.cc (right): https://codereview.chromium.org/25727003/diff/1/net/socket/socket_descriptor.... net/socket/socket_descriptor.cc:42: if (setsockopt(result, IPPROTO_IPV6, IPV6_V6ONLY, (const char*)&value, On 2013/10/04 02:49:19, jar wrote: > nit: please use C++ style > > reinterpret_cast<const char*>(&value) Done. https://codereview.chromium.org/25727003/diff/1/net/socket/socket_descriptor.... net/socket/socket_descriptor.cc:45: result = kInvalidSocket; On 2013/10/04 02:49:19, jar wrote: > nit: easier to read is a direct: > return kInvalidSocket; Done.
On 2013/10/04 13:16:48, halyavin wrote: > On 2013/10/04 02:49:18, jar wrote: > > Can you clarify why this comes up in practice? Are we listening on sockets in > > the client? ...and in such scenarios, do we have to accept connections from > > both IPv4 and IPv6? > > > > It seems that if we're originating the connection, then we'll have an IPv4 (or > > v6) address, and never really care about the address that responds to us (and > > expect it to match what we connected to). > > This is happens in a NaCl application that contains IPv6-only code. The code > converts > IPv4 addresses to IPv6 ones. Unfortunately, client connections to IPv4 address > mapped to IPv6 need this flag too. > > > > > Also, how are you handling older-than-vista systems, wherein the article cited > > says: > > > > "In order to support both IPv4 and IPv6 on Windows XP with Service Pack 1 > (SP1) > > and on Windows Server 2003, an application has to create two sockets, one > socket > > for use with IPv4 and one socket for use with IPv6. These two sockets must be > > handled separately by the application." > > > > Can you explain what else you've changed to make this work on XP? > > I hoped that IPv6 address will not be generated on Windows XP but now I see that > IPv6 is used on all systems. I don't see any other way other than changing > family from AF_INET6 to AF_INET in this case (not implemented in the CL yet). Just to be sure I'm clear on this: a) This change should only have an impact on NaCl. Correct? I would generally expect Chrome to create a socket that matches the type of the destination address, and never have to face this mapping issue. Correct? b) You still need a change to make this work on XP (actually, anything pre-Vista). Do you have a bug for that? thanks, Jim
On 2013/10/04 23:31:21, jar wrote: > Just to be sure I'm clear on this: > > a) This change should only have an impact on NaCl. Correct? I would generally > expect Chrome to create a socket that matches the type of the destination > address, and never have to face this mapping issue. Correct? Yes. The only way to see this bug in chrome is to enter IPv4 mapped to IPv6 address manually in the address bar: http://[::ffff:1234:5678]. > > b) You still need a change to make this work on XP (actually, anything > pre-Vista). Do you have a bug for that? I just created issue https://code.google.com/p/chromium/issues/detail?id=304456 -- Andrey Khalyavin
lgtm
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/halyavin@google.com/25727003/9001
Step "update" is always a major failure. Look at the try server FAQ for more details. http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/halyavin@google.com/25727003/9001
Sorry for I got bad news for ya. Compile failed with a clobber build on win. http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win&number... Your code is likely broken or HEAD is junk. Please ensure your code is not broken then alert the build sheriffs. Look at the try server FAQ for more details.
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/halyavin@google.com/25727003/9001
Message was sent while issue was closed.
Change committed as 227332 |
