service dhcp-server ... option tftp-server-name only accepts an IPv4 address or an FQDN. A provisioning URL as used by many VoIP phones (Yealink, Polycom, Cisco) is rejected:

set service dhcp-server shared-network-name LAN subnet 192.0.2.0/24 option tftp-server-name 'http://prov.example.com/phones'

The constraint in interface-definitions/include/dhcp/option-v4.xml.i is:

<validator name="ipv4-address"/>
<validator name="fqdn"/>

The error message is is not a valid IPv4 address.

Kea does not require this. In its own example (doc/examples/kea4/all-options.json), option 66 tftp-server-name is of type string, and the value is sent unchanged. The restriction exists only in VyOS.

Side effect: the fqdn validator is only the regex [A-Za-z0-9][-.A-Za-z0-9]*. A hex-encoded URL (for example 687474703a2f2f..., also with a leading 0x) is therefore accepted as a "hostname". Kea sends those characters as plain text, not as the decoded bytes. A phone then shows the hex digits instead of the URL. The same hex value works on a MikroTik, because there it is encoded as raw bytes. So hex is not a usable workaround on VyOS.

Expected: a URL (http, https, ftp, ftps, tftp) is accepted for tftp-server-name and sent as the option 66 string. Existing IPv4 and FQDN values stay valid.

Reported in T9267 (follow-up by @DuxOv8 after the hostname/vendor-class matching was merged). Not related to the client-class matching itself.

Proposed fix: add a URL pattern to the existing constraint in option-v4.xml.i (constraints are ORed, so nothing that is valid today becomes invalid), plus a smoketest in test_service_dhcp-server.py. A fix is prepared and will be sent as a PR once this task exists.

Out of scope, only mentioned for context (separate feature requests if wanted):

• client-class per subnet is a single value, Kea accepts a list of classes.
• A client class can carry option-data in Kea, VyOS only renders the class name and its match expression. Today a separate range with its own client-class and options is needed per model.