Added by Junxiao Shi almost 8 years ago. Updated over 6 years ago.
100%
Description
Steps to reproduce:
nfd.conf, at face_system.websocket section, set both enable_v4 and enable_v6 to yesnfd-status -f | grep wsclientExpected: the face is local
Actual: the face is non-local
Updated by Junxiao Shi almost 8 years ago
See RFC 4291 section 2.5.5.2 on the semantics of [::ffff:127.0.0.1] addressing.
FaceScope after connecting to ws://127.0.0.1:9696 is non-local (wrong):
faceid=292 remote=wsclient://[::ffff:127.0.0.1]:40818 local=ws://[::ffff:127.0.0.1]:9696 counters={in={1i 0d 14B} out={0i 0d 0B}} non-local on-demand point-to-point
FaceScope after connecting to ws://[::1]:9696 (with [::1] button) is local (correct):
faceid=290 remote=wsclient://[::1]:56173 local=ws://[::1]:9696 counters={in={1i 0d 14B} out={0i 1d 821B}} local on-demand point-to-point
When face_system.websocket.enable_v6 is set to no, FaceScope after connecting to ws://127.0.0.1:9696 is local (correct):
faceid=262 remote=wsclient://127.0.0.1:40822 local=ws://127.0.0.1:9696 counters={in={1i 0d 14B} out={0i 0d 27B}} local on-demand point-to-point
Eric agrees to work on this.
Updated by Eric Newberry almost 8 years ago
The scope is determined from whether the address is loopback or not, as determined by Boost.Asio. I looked at the boost source and it appears that Boost does not consider loopback IPv4-mapped IPv6 addresses to be loopback. The code that determines this can be found here: https://github.com/boostorg/asio/blob/develop/include/boost/asio/ip/impl/address_v6.ipp#L163
Therefore, I see two options:
1) File a bug report with Boost.Asio and attempt to get them to recognize loopback IPv4-mapped IPv6 addresses. (We could possibly create a patch and submit it to Boost.) This would only apply to the latest development version of Boost, but it would resolve this problem in the future.
2) Parse the address ourselves to determine if it is loopback.
We could also pursue both options, using the second as a temporary fix.
In addition, I believe this issue affects all Transports that use Boost.Asio and IPv6, not just WebSocket.
Updated by Junxiao Shi almost 8 years ago
I agree with note-3 on pursuing both options.
draft-smith-v6ops-larger-ipv6-loopback-prefix-04 section 1 says:
The IPv4-Mapped IPv6 Address form of 127/8, ::ffff:127.0.0.0/104 [RFC4291], could be used to provide more host local loopback addresses.
This indicates ::ffff:127.x.x.x should be considered a loopback address.
Updated by Eric Newberry almost 8 years ago
I have create a pull request to Asio (https://github.com/chriskohlhoff/asio/pull/127). Next, I'm going to create a workaround in WebSocketTransport and possibly other Transports.
Updated by Junxiao Shi almost 8 years ago
TcpTransport would not suffer from the same problem because different listening sockets are used for IPv4 and IPv6.
Updated by Eric Newberry almost 8 years ago
Updated by Eric Newberry almost 8 years ago
A pull request has also been submitted to Boost.Asio (https://github.com/boostorg/asio/pull/42).
Updated by Junxiao Shi almost 8 years ago
Workaround on NFD side is merged. https://gerrit.named-data.net/2963
When Boost merges the pull request, we can reopen this issue to limit the workaround within a range of Boost versions.
Updated by Eric Newberry over 6 years ago
Eric Newberry wrote:
A pull request has also been submitted to Boost.Asio (https://github.com/boostorg/asio/pull/42).
The pull request was closed without merging. From Boost.Asio's author:
I put this proposed change before the C++ committee (LEWG) in the context of the Networking TS. They preferred the status quo.