API Proposal: IPNetwork to support CIDR notation

[alrz]

Background and motivation

An implementation is exposed through HttpOverrides middleware package at /~https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HttpOverrides/src/IPNetwork.cs

This proposal is to promote it under System.Net namespace for a built-in support.

API Proposal

namespace System.Net
{
    public struct IPNetwork
    {
        // eg: "192.168.0.0/16"
        public static IPNetwork Parse(string);
        public IPNetwork(IPAddress, IPAddress);
        public IPNetwork(IPAddress, int);
        public bool Contains(IPAddress);
        // ..
    }
}

API Usage

var range = IPNetwork.Parse(cidr);
bool result = range.Contains(address);

Alternative Designs

No response

Risks

No response

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

An implementation is exposed through HttpOverrides middleware package at /~https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HttpOverrides/src/IPNetwork.cs

This proposal is to promote it under System.Net namespace for a built-in support.

API Proposal

namespace System.Net
{
    public struct IPNetwork
    {
        // eg: "192.168.0.0/16"
        public static IPNetwork Parse(string);
        public IPNetwork(IPAddress, IPAddress);
        public IPNetwork(IPAddress, int);
        public bool Contains(IPAddress);
        // ..
    }
}

API Usage

var range = IPNetwork.Parse(cidr);
bool result = range.Contains(address);

Alternative Designs

No response

Risks

No response

Author:	alrz
Assignees:	-
Labels:	api-suggestion, area-System.Net, untriaged
Milestone:	-

[alrz]

Relates to #42845

[pinkfloydx33]

Would this also include support for a built-in type converter (or similar) that would allow binding configuration containing such values?

At the moment we rely on a custom type converter to bind configuration containing such values (primarily for forwarded headers and ip whitelisting). We add the converters using TypeDescriptor.AddAttributes via a module Initializer in our shared library, but it's my understanding that it may not necessarily be safe to rely upon and only by chance has continued to work.

It would be nice to not need to do this and just have it work out of the box.

[scalablecory]

We previously rejected a CIDR proposal due to lack of customer demand: #36428

[karelz]

Triage: Still not high enough demand. Other libraries exist that solve it. Not desperately needed in BCL.

[karelz]

Duplicate of #36428