Can't connect to IPv4 literal on DNS64/NAT64 network |
|||
Issue descriptionChrome Version: 71.0.3578.98 OS: macOS 10.14.2 What steps will reproduce the problem? (1) Connect to a DNS64/NAT64 network (2) Go to http://193.15.228.195 What is the expected result? The browser should show the IPv4/IPv6 test page, as Safari does. What happens instead? It says http://193.15.228.195/ is unreachable. Presumably if Chrome uses Mac's stock network functions like getaddrinfo() then the OS should automatically synthesize the IPv6 network for you.
,
Dec 14
,
Dec 14
Can you attach a net-log covering an attempted browse to http://193.15.228.195 on a NAT64 network? http://dev.chromium.org/for-testers/providing-network-details
,
Dec 14
Here is it.
,
Dec 17
What is "the IPv4/IPv6 test page"? This sounds like a feature request. What does Safari do? It doesn't sound like Safari works in this situation either. Does getaddrinfo() return the IPv6 address given an IPv4 literal?
,
Dec 17
> What is "the IPv4/IPv6 test page"? It's just the http://ipv4.tlund.se/ page. 193.15.228.195 is its IP address. > This sounds like a feature request. Maybe. DNS64 doesn't synthesize IPv6 address for you, so it's the client's responsibility to discovery the IPv6 prefix and synthesize the IPv6 address for IPv4 literal. > What does Safari do? If you type http://193.15.228.195/ and hit enter, then it just goes to the page that http://ipv4.tlund.se/ points to. > It doesn't sound like Safari works in this situation either. No. It's working on Safari. > Does getaddrinfo() return the IPv6 address given an IPv4 literal? Yes, but only on macOS and iOS. I suppose Apple has RFC 7050 built into its network stack.
,
Jan 2
Ah I misunderstood "the IPv4/IPv6 test page" to mean some page built into Safari, but now I see you mean the ipv4.tlund.se public web page. I'm not sure what the appropriate behavior is in this case. I'll need to look at the specs for this. Do you happen to know which O/S's getaddrinfo() implementations support this translation of an IPv4 literal to an IPv6 address in DNS64 mode? I could imagine a fix in Chrome where for HostResolverImpl requests for an IPv4 literal on devices with only IPv6 addresses, we fall back to getaddrinfo() (perhaps using HOST_RESOLVER_SYSTEM_ONLY).
,
Jan 2
I feel like the specs don't allow for getaddrinfo() translating IP address literals to other IP addresses: https://tools.ietf.org/html/rfc7230#section-2.7.1 "If the host identifier is provided as an IP address, the origin server is the listener (if any) on the indicated TCP port at that IP address." I'm not saying Chrome shouldn't support this, but I'm trying to explain why it doesn't already.
,
Jan 2
CC dschinazi@ who wrote the IPv6 synthesis logic behind getaddrinfo() for iOS and macOS. I think only Apple implemented IPv6 synthesis on getaddrinfo(), as documented here: https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-DontLinkElementID_4 AFAIK other platforms don't seem to do that. I understand why Chrome doesn't support this now, but it could be great if Chrome supports it. No rush to fix it though.. If we want to support it for all platforms then we may need to implement RFC 7050 for Chrome, which may look like this: https://chromium-review.googlesource.com/c/chromium/src/+/1392286/3/remoting/protocol/rfc7050_ip_synthesizer.cc |
|||
►
Sign in to add a comment |
|||
Comment 1 by yuweih@chromium.org
, Dec 14