Page MenuHomeVyOS Platform

DHCP Option 66 (tftp-server-name) should accept arbitrary strings
Open, LowPublicFEATURE REQUEST

Description

It is pretty common to use arbitrary string values in Option 66 to provision IP Phones. However, VyOS does not accept this for an unknown reason (which I consider a bug):

set service dhcp-server shared-network-name <network-name> subnet <subnet> static-mapping <mapping-name> option tftp-server-name "http://1.2.3.4:65000/provisioning/abcxyzdefghi/cfg{mac}"

will fail with:

Error: http://1.2.3.4:65000/provisioning/abcxyzdefghi/cfg{mac} is not a valid IPv4 address
  
  
  
  Invalid value
  Value validation failed
  Set failed

This should be an easy fix and perfectly backwards compatible.

Details

Version
VyOS 1.5-rolling-202411070006
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Event Timeline

rchrist updated the task description. (Show Details)
rchrist updated the task description. (Show Details)

This is not a bug, this is according to RFC
@Apachez I recall you have cited it but do not recall where it was here or at the forum

This is not a bug, this is according to RFC

Can't see this in RFC2132

9.4 TFTP server name

   This option is used to identify a TFTP server when the 'sname' field
   in the DHCP header has been used for DHCP options.

   The code for this option is 66, and its minimum length is 1.

       Code  Len   TFTP server
      +-----+-----+-----+-----+-----+---
      | 66  |  n  |  c1 |  c2 |  c3 | ...
      +-----+-----+-----+-----+-----+---

Kea itself(!) which VyOS is using, defines Option 66 as string:
https://kea.readthedocs.io/en/kea-2.0.0/arm/dhcp4-srv.html#dhcp4-std-options-list

Name	Code	Type	Array?	Returned if not requested?
...
tftp-server-name	66	string	false	false

Type: String. Other options are defined as Type ipv4-address, however Option 66 is not.

can be ipv4 or hostname

In summary:

Option 66: Can be an IP address or hostname (string), depending on implementation.
Option 67: Should always be a string representing the boot file's path/filename.

Interesting interpretation of the standard. Guess it's time to go bare metal again

DHCP option 66 is not intended to carry an HTTP URL. According to RFC 2132, option 66 is specifically designed to provide the TFTP (Trivial File Transfer Protocol) server name, typically used to specify a hostname or IP address of a server from which the client can download a boot file via TFTP, not HTTP.

@syncer Yeah, it was at the forum:

https://forum.vyos.io/t/dhcp-server-tftp-server-name/13965/5

"
You are expected to use DHCP option 209 aka configuration-file and DHCP option 210 aka path-prefix to get the URI your client can request from the server (along with the tftp-server-name):

https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

https://datatracker.ietf.org/doc/html/rfc5071#section-4

https://datatracker.ietf.org/doc/html/rfc5071#section-5
"

So in short Option66 tftp-server-name shall only be IPv4/IPv6-address or FQDN. Then the client is expected to use option209 and option210 to create the full URI needed unless it want to traverse the content of the TFTP-server on its own (some do that like blindly request "/path/file"). Other option is to use option67 along with option66 to create the full URI. Or use option43.

However I wouldnt be surprised if lack of enforcement regarding allowed characters have made some implementations of DHCP-servers to allow whatever you want as option66 which gives that some clients (incorrectly) expect the full URI through option66 and have no clue on what to do if they get option67, option209, option210 and/or option43 along with the DHCP-reply.

If its common of this misuse of option66 I would suggest that VyOS would allow for URI characters (@, :, / and what else) but type a warning during re/config like:

WARNING: `dhcp-server shared-network-name <network-name> subnet <subnet> static-mapping <mapping-name> option tftp-server-name` contains according to RFC5071 illegal characters.

Perhaps first check with the sourcecode of KEA what they actually allow when it comes to characters and length for option66?

For KEA6 its defined as "The IPv6 address of a TFTP server" with example of IPv6-address:

https://github.com/isc-projects/kea/blob/master/doc/examples/kea6/all-options.json#L2035

While for KEA4 its defined as "string" with example of FQDN:

https://github.com/isc-projects/kea/blob/master/doc/examples/kea4/all-options.json#L793

They also have examples where they define more than one TFTP-server at once (using "," as delimiter with or without trailing space):

https://github.com/isc-projects/kea/blob/master/doc/examples/kea4/global-reservations.json#L118

syncer changed the subtype of this task from "Bug" to "Feature Request".Thu, Nov 14, 10:41 AM