format request: support for strings which can be recognized as valid IPv4 or IPv6 addresses with a CIDR mask or netmask

[Speeddymon]

Hello, as requested in this comment, I'm following up to file a separate issue.

I'm working in my org on a project using OpenAPI spec. I'm building an orchestrator in the middle between a data source I don't control nor trust at one end which populates some fields in my orchestrator based on human input, and on the other end is a consumer I also don't control but who reads from this field and expects the data to be trustworthy and valid, including matching a certain format. My field needs to hold a value for this consumer who allows both a plain IPv4 address, or an IPv4/CIDR mask format address, as this is for a firewall rule input to allow some traffic from either a single IP or a range of IPs in CIDR format. Internally, the consumer accepts a raw single IP (IPv4 or IPv6) and appends a /32 or /128 depending on the IP version if the CIDR isn't specified. So my field should be filled with either a plain IPv4 address such as 10.10.10.10, or an IPv4 address with a CIDR mask such as 10.0.0.0/8, however its possible for other data to be provided due to weak or nonexistent validation on the source I don't control, and due to difficulty surfacing errors in a place users will see it in the data consumer.

So I'd like to add some validation to my field beyond simple string type validation in order for my orchestration tool to catch the error itself and prevent it from reaching the consumer so that I can handle the error and make it visible to users. I'd like to ensure that the field causes an error if the value doesn't match a certain format by setting the format property for the field. So I tried to set format to ipv4 and I verified that when a raw IPv4 address is filled in, there is no issue, but if an IPv4 with a CIDR is filled in, then it doesn't match the format and I get an error, which is wrong for my use-case.

I'd like to request for either: the IPv4 and IPv6 formats to be extended to include CIDR masks and netmasks if it wouldn't be a breaking change to do so; or alternatively please add an additional format which will accept both an IPv4 or IPv6 address who may or may not include CIDR or netmasks.

This will help greatly with validation of IP address fields in use-cases wherein a string type field must be any of the following formats: a single IPv4 address by itself, a single IPv6 address by itself, or either of those with a CIDR or a netmask.

[handrews]

@Speeddymon this would be done by adding new formats - we can't change existing formats (some of which are specified by JSON Schema and not OpenAPI) as that will break existing users who would consider accepitng a CIDR or netmask for format: ipv4 to be an error. So we'd add more formats. This can be done by opening a PR on the format registry, which lives on the gh-pages branch in this repository.

Typically we'd add a format for each thing, and then you would use anyOf or oneOf to say that something could be either an address or a netmask, etc.

[Speeddymon]

Thanks @handrews.

I have taken a look at the gh-pages branch in registries/_format/ipv4.md and followed the link to the JSONSchema definition:

An IPv4 address according to the "dotted-quad" ABNF syntax as defined in RFC 2673, section 3.2 [RFC2673].

Following the link to RFC2673 section 3.2 (direct link to the relevant section here) states:

A Bit-String Label is represented in text -- in a zone file, for
example -- as a surrounded by the delimiters "[" and "]".
The is either a dotted quad or a base indicator and a
sequence of digits appropriate to that base, optionally followed by a
slash and a length. The base indicators are "b", "o" and "x",
denoting base 2, 8 and 16 respectively. The length counts the
significant bits and MUST be between 1 and 32, inclusive, after a
dotted quad, or between 1 and 256, inclusive, after one of the other
forms. If the length is omitted, the implicit length is 32 for a
dotted quad or 1, 3 or 4 times the number of binary, octal or
hexadecimal digits supplied, respectively, for the other forms.

So, is jsonschema wrong in not supporting the optional slash and length indicator? Should I open an issue upstream before considering to submit a new format here?

[handrews]

@Speeddymon the key part of the text there is according to the "dotted-quad" ABNF syntax

What that means is that only this part of the ABNF (the "dotted-quad" production and its dependency, "decbyte") is relevant.

     dotted-quad      =  decbyte "." decbyte "." decbyte "." decbyte

     decbyte          =  1*3DIGIT

So no, jsonschema is not wrong.

If you want a format that corresponds to the "bit-string-label" production, that would be a separate format from the existing IP v4 format.

[Speeddymon]

Upon re-reading with that context, this makes sense. I'll submit a PR for consideration, thank you!