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

[Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx>]

On 24/06/2026 15:53, Teddy Astie wrote:
> 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.
> 

xenstore-paths.pandoc already states that "The values written are 
primarily for display purposes and must not be used for packet filtering 
or routing purposes". I don't think any toolstack currently checks for 
the field's content format (XAPI doesn't check, xl doesn't even know 
about the field). Given that guests can present just about any value to 
this field, it has always been considered an untrusted field and 
consumers must be able to accept unexpected formats.

The spec change also makes the network prefix optional, not mandatory. 
It'd be up to the field consumers to add support for network prefixes 
(or at least tolerate them) before rolling out the actual change.

Conversely, adding an alternative IP node requires the guest to report 
at multiple places at once just to ensure backwards compatibility, and 
makes treating the field itself more complex for the consumer. So I 
don't see the benefit of mandating yet another field for this purpose.

> Teddy



--
Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech