Skip to content

Incorrect handling of link local addresses and IPv6 scope #3813

@wfurt

Description

@wfurt

Describe the bug

I created listener to listen on LLA fe80::7260:3b3d:bd2b:c845%6 and I open connection to it from same host.
On Windows local & remote addresses are correct and have scope as expected.

Client [fe80::7260:3b3d:bd2b:c845%6]:65289 [fe80::7260:3b3d:bd2b:c845%6]:65288
Server [fe80::7260:3b3d:bd2b:c845%6]:65288 [fe80::7260:3b3d:bd2b:c845%6]:65289

Same test on Linux:

Client [fe80::9c3a:b64d:6249:1de8]:54041 [fe80::9c3a:b64d:6249:1de8%2]:48276

Client is missing scopeID.

Interestingly, in some cases scope is set for addresses other than LLA.
Connecting to ::1 on Linux and Windows

Server [::1%1]:41741 [::1]:50859
Server [::1%1]:65292 [::1]:65293

loopback address has scope set even if it should not.

In all cases so far the connection succeeded but it makes it difficult for companions and I'm. to sure (yet) about multi-machine setup where the scope is essential for selecting correct interface.

Affected OS

  • Windows
  • Linux
  • macOS
  • Other (specify below)

Additional OS information

No response

MsQuic version

main

Steps taken to reproduce bug

make simple listener and connect to it using LLA.
observe addresses on established connection on both client & server.

Expected behavior

LLA should always have scope set, global addresses should not have scope set.
Windows and Linux would have same outcome for same scenario.
Local and remote address on client and server should be exactly opposite.
But there should not be differences in scope.

Actual outcome

scope is missing in some cases on Linux. It can be incorrectly set for global addresses.

Additional details

No response

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions