T7723: dhcp-server add DHCP Option 26

[mzpqnxow]

Change summary

Support DHCP v4 option #26 - interface MTU

• Add interface-mtu to option-v4.xml.i
• Add interface_mtu -> interface-mtu translation in python/vyos/kea.py
• Add to smoke tests

Note, I have not actually run the smoke tests yet, I need to set up an environment to test in

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Code style update (formatting, renaming)
• Refactoring (no functional changes)
• Migration from an old Vyatta component to vyos-1x, please link to related PR inside obsoleted component
• Other (please describe):

Related Task(s)

• https://vyos.dev/T7723

Related PR(s)

None

How to test / Smoketest result

Enhancements were made to the existing test_service_dhcp-server.py script. I have not tested yet as I don't have an environment set up

Checklist:

• I have read the CONTRIBUTING document
• I have linked this PR to one or more Phabricator Task(s)
• I have run the components SMOKETESTS if applicable
• My commit headlines contain a valid Task id
• My change requires a change to the documentation
• I have updated the documentation accordingly

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[github-actions]

❌
PR title does not match the required format

[mzpqnxow]

I have read the CLA Document and I hereby sign the CLA

[mzpqnxow]

recheck

[mzpqnxow]

Looks like I may need to amend the actual commit message, not the PR description ...

[sever-sever]

Change the commit message
The format should be like in the PR message

[sever-sever]

Why 1-16?

[mzpqnxow]

Per the RFC, it's a 16bit value. But looking at it now, I think I misread how the notation in that file works and it should probably just be u16?

[mzpqnxow]

As far as the values chosen for the bounds - I'm open to any ideas on the best values to use.

I admit they're somewhat arbitrary choices (though I'm sure you recognize the upper bound as Jumbo)

In terms of standards, we could use 576 for the minimum. It's unreasonably small, but mentioned in the IPv4 RFC (RFC 791 section 3.1):

All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
or in fragments). It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.

The IPv6 RFC RFC 8200, section 5 requires a minimum MTU of 1280 - but this is DHCP IPv4, so I don't think we need to be troubled with that

I can't imagine 576 actually being used anywhere. At the same time, I've actually come close to needing to go below 1280 before on IPv4 interfaces (due to use of multiple layers of tunnels). So 576 seems reasonable.

[github-actions]

CI integration ❌ failed!

Details

CI logs

• CLI Smoketests (no interfaces) ❌ failed
• CLI Smoketests VPP 👍 passed
• CLI Smoketests (interfaces only) 👍 passed
• Config tests 👍 passed
• Config tests VPP 👍 passed
• RAID1 tests 👍 passed
• TPM tests 👍 passed