[Feature Request] Add CEL extension to validate IP address/prefix has prefix

[MarcusWichelmann]

Feature description:
There are already CEL extensions to validate if a string is a valid IP address or prefix with or without host bits. But I couldn't find a way to check whether an IP address or prefix is contained in another IP prefix. I'd like to propose adding a CEL extension for that.

Problem it solves or use case:
In networking related APIs, it's a common requirement that field values are not only valid addresses/prefixes by themselves, but also make sense in a broader scope.

Like in this example, where I would want to validate, that gateway is a valid IP address that is contained inside the IPv4 prefix specified in network.

message Netconf {
  string network = 1 [(buf.validate.field).string.ipv4_prefix = true];
  string gateway = 2 [(buf.validate.field).string.ipv4 = true];
}

Similarly, I'd like to have a way to validate that subnet is a part of network, both being prefixes:

message Netconf {
  string network = 1 [(buf.validate.field).string.ipv4_prefix = true];
  string subnet = 2 [(buf.validate.field).string.ipv4_prefix = true];
}

Proposed implementation or solution:

option (buf.validate.message).cel = {
  id: "gateway_part_of_network"
  message: "the gateway address must be part of the network prefix"
  expression: "this.network.containsIp(this.gateway)"
};

option (buf.validate.message).cel = {
  id: "subnet_part_of_network"
  message: "the subnet prefix must be part of the network prefix"
  expression: "this.network.containsIpPrefix(this.subnet)"
};

I'd say that containsIp / containsIpPrefix should just return false whenever the passed address/prefix is not valid and from the same address family (IPv4 / IPv6). Maybe, containsIp and containsIpPrefix could even be merged into one function, but I wouldn't know how to name that one.

Contribution:
I don't know if I have the resources myself right now to implement this, so foremost I'd like to ask for some feedback on this idea.

[timostamm]

Thanks for the proposal, Marcus. One design concern: The proposed functions combine several checks - validating receiver (network), validating argument (gateway), and validating that they match. Collapsing all three into a single boolean means we can’t surface distinct error messages for each failure mode. This will need a bit more thought before we can consider implementing it.