Bug #3682
closed
WebSocketTransport wrong FaceScope for [::ffff:127.0.0.1]
100%
Description
Steps to reproduce:
- in
nfd.conf, atface_system.websocketsection, set bothenable_v4andenable_v6toyes - start NFD
- open wsface.htm
- click [127.0.0.1] button (nothing would happen on the webpage)
- execute
nfd-status -f | grep wsclient
Expected: the face is local
Actual: the face is non-local
Updated by Junxiao Shi over 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
Updated by Eric Newberry over 8 years ago
- Status changed from New to Feedback
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 over 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 over 8 years ago
- Status changed from Feedback to In Progress
- % Done changed from 0 to 50
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 over 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 over 8 years ago
- Status changed from In Progress to Code review
- % Done changed from 50 to 100
Updated by Eric Newberry over 8 years ago
A pull request has also been submitted to Boost.Asio (https://github.com/boostorg/asio/pull/42).
Updated by Junxiao Shi over 8 years ago
- Status changed from Code review to Closed
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 almost 7 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.