Thanks for the PR. A couple of notes:

cc: @davidsh @wfurt @caesar-chen @rmkerr @karelz @scalablecory

@caesar-chen and @rmkerr are no longer on the team. Thus, they don't need to be added to PRs or issues. I will update the issue-guide.md file.

Area owner for System.Net.Primitives is the same as all System.Net.*

What is the behavior of this issue on prior versions of .NET Core? And IPv6 address parsing code is also present in System.Uri. Can you see what it is does with IPv6 addresses similar to this? We should be making equivalent fixes if a fix is required.

I didn't found area owner for System.Net.Primitives https://github.com/dotnet/corefx/blob/d3942d4671919edb0cca6ddc1840190f524a809d/Documentation/project-docs/issue-guide.md#areas

I think your link to the area owners document is out-of-date. The current document in master is already updated.
https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/issue-guide.md

I think your link to the area owners document is out-of-date. The current document in master is already updated.

Found the throuble I looking for area owner doc using github search and got an old version(passing throught api review process doc) also if the link seems up-to-date and in that doc there is an old link of owners.

Old versions

class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(IPAddress.TryParse("::2:3:4:5:6:7:8", out var addr) ? addr.ToString() : "error");
            Console.WriteLine(IPAddress.TryParse("1:2:3:4:5:6:7::", out var addr1) ? addr1.ToString() : "error");
        }
    }

D:\Users\marco_000\Downloads\TestIPV6\TestIPV6       
λ dotnet run -f netcoreapp2.0                        
::                                                   
1:2:3:4:5:6:7:0                                      
                                                     
D:\Users\marco_000\Downloads\TestIPV6\TestIPV6       
λ dotnet run -f netcoreapp2.1                        
::                                                   
1:2:3:4:5:6:7:0                                      
                                                     
D:\Users\marco_000\Downloads\TestIPV6\TestIPV6       
λ dotnet run -f netcoreapp2.2                        
::                                                   
1:2:3:4:5:6:7:0                                      
                                                     
D:\Users\marco_000\Downloads\TestIPV6\TestIPV6       
λ dotnet run -f netcoreapp3.0                        
::                                                   
1:2:3:4:5:6:7:0                                      
                                                     
D:\Users\marco_000\Downloads\TestIPV6\TestIPV6       
λ                                                                                                         

And IPv6 address parsing code is also present in System.Uri. Can you see what it is does with IPv6 addresses similar to this? We should be making equivalent fixes if a fix is required.

@davidsh I cannot open funcional tests with VS 2019 preview(cc: @ViktorHofer)

Btw System.Private.Uri uses shared common ipv6 parser updated by this PR.

@davidsh I cannot open funcional tests with VS 2019 preview(cc: @ViktorHofer)

You can also use command line to build and run tests, i.e. "msbuild /t:rebuildandtest" in the src/System.Private.Uri/tests/FunctionalTests directory.

Btw System.Private.Uri uses shared common ipv6 parser updated by this PR.

Not all code is in Common. Here is an example of code that isn't:
https://github.com/dotnet/corefx/blob/master/src/System.Private.Uri/src/System/IPv6AddressHelper.cs

You should verify functionality by adding some similar tests to System.Private.Uri here:
https://github.com/dotnet/corefx/blob/master/src/System.Private.Uri/tests/FunctionalTests/UriIpHostTest.cs

See recent PR #37734 which fixed other IPv6 address parsing problems across both IPAddress and System.Uri classes.

You can also use command line to build and run tests, i.e. "msbuild /t:rebuildandtest" in the src/System.Private.Uri/tests/FunctionalTests directory.

Yep tests run I'll add some tests asap thank's!

cannot open funcional tests with VS 2019 preview

@ViktorHofer, I'm hitting this same issue, with System.Net.NameResolution. Any ideas?

@davidsh PTAL
Added tests for System.Private.Uri thank's for pointing me right test file.
I followed the code and it jumps inside common address helper here https://github.com/dotnet/corefx/blob/master/src/System.Private.Uri/src/System/IPv6AddressHelper.cs#L20

I'd like to pause on this PR for now.

I've done some research on whether or not IPv6 addresses such as "::2:3:4:5:6:7" are actually valid IPv6 addresses.

According to WinRT Windows.Networking.Hostname API parsing, it is not valid. The following code throws an exception "The parameter is incorrect".

I think the premise of the issue raised by #38634 is not correct. I will follow-up after I've discussed with the IETF experts for the IPv6 RFC.

::1 is certainly valid. Did we not process it correctly before?

::1 is certainly valid. Did we not process it correctly before?

Yes, "::1" is valid. This PR is specifically about the case where there are 7 distinct groups of numbers and one compressor which is a leading compressor, i.e.

"::2:3:4:5:6:7:8". The debate is about whether "::" can represent at least a single "0" (or multiple) OR whether it can only represents two groups of zeroes (or more than that). I'm waiting to hear back from IETF rep.

It would be good to get the feedback. I did quick test with inet_ntop() and inet_pton() on Linux and they process "::2:3:4:5:6:7:8" as valid string expanded to "0:2:3:4:5:6:7:8"

It would be good to get the feedback. I did quick test with inet_ntop() and inet_pton() on Linux and they process "::2:3:4:5:6:7:8" as valid string expanded to "0:2:3:4:5:6:7:8"

@wfurt Thanks for the additional validations with the Linux native APIs!

After discussions with the IETF rep and the Windows team, the RFC is correct. So, the fixes for IPAddress class are correct. It turns out there is a separate bug for the WinRT Windows.Networking.HostName class that will be filed separately.

/azp run

Unrelated fails
NB. assertions on outerloop https://github.com/dotnet/corefx/pull/38654/checks?check_run_id=152066342