Re: [PATCH] xenstore-paths: Allow subnet prefix in IP address

[Teddy Astie <teddy.astie@xxxxxxxxxx>]

Le 08/06/2026 à 11:51, Tu Dinh a écrit :
> In the guest-reported IP address in xenstore, it's useful to know which
> subnet it belongs to.
>
> Add a specification for the IPv6 host address/prefix format specified by
> RFC 4291.
>
> For the IPv4 address/prefix notation, as there seems to be no equivalent
> RFC specifying the host address/prefix format, specify it ourselves.
>
> Signed-off-by: Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx>
> ---
>   docs/misc/xenstore-paths.pandoc | 12 ++++++------
>   1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/docs/misc/xenstore-paths.pandoc b/docs/misc/xenstore-paths.pandoc
> index 4994194..1fab3bf 100644
> --- a/docs/misc/xenstore-paths.pandoc
> +++ b/docs/misc/xenstore-paths.pandoc
> @@ -78,12 +78,12 @@ VALUES are strings and can take the following forms:
>   
>   * MAC_ADDRESS -- 6 integers, in hexadecimal form, separated by ':',
>                    specifying an IEEE 802.3 ethernet MAC address.
> -* IPV4_ADDRESS -- 4 integers, in decimal form, separated by '.',
> -                  specifying an IP version 4 address as described
> -                  IETF RFC 791.
> -* IPV6_ADDRESS -- Up to 8 integers, in hexadecimal form, separated
> -                  by ':', specifying an IP version 6 address as
> -                  described in IETF RFC 4291.
> +* IPV4_ADDRESS -- An IP version 4 address as specified by IETF RFC 791,
> +                  optionally appended with a "/prefix" value representing the
> +                  prefix length of the host address's subnet, with "prefix"
> +                  being a decimal integer in the range of 0 to 32.
> +* IPV6_ADDRESS -- An IP version 6 address or abbreviated "address/prefix"
> +                  combination as specified by IETF RFC 4291 and RFC 5952.
>   
>   Additional TAGS may follow as a comma separated set of the following
>   tags enclosed in square brackets.
I'm not convinced this is a good idea. This is technically a breaking 
change, as the proposed format now allows IPv4/subnet form, while the 
user of this info may not be aware and could fail to parse the IP.
If we need to expose additional infos, I think it's preferable to either 
expose a alternative IP node with this new format or put the additional 
info in a separate node.
Teddy

Attachment: OpenPGP_0x660FA9D102CBCFD0.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature