Oversized DHCP option issues

蒋圩淏 weihau.chiang at gmail.com
Mon Jan 24 15:49:58 UTC 2022


Hello Richard and Glenn,

Sorry for the late reply. I've checked the DHCP protocol rules and
reached these:

## The flaw in ISC-DHCP server design

Richard said that:

> I see no way to specifically configure option concatenation, but I think the server will do it automatically as required.

Sadly, it doesn't. Take a 260-byte message as an example, it would set
the length to 255, but trail the 260 bytes without splitting, or even
truncating. It could overwrite the next section and break the packet
structure.

The contents length could also be limited by packet size, as Richard
investigated that,

> As for size, I think the packet size may still be a limitation. Rather than live with the minimum 576 MTU, assuming everything can handle at least MTU 1500,
>
>         option dhcp-max-message-size 1236;
>
> (the rest of 1500 is overhead)
>
> As far as I can tell, isc-dhcp does not presently support MTU larger than 1500 even if large packets are enabled for all involved hosts, so this is the largest useful value at this time. If the client specifies that option, that will take precedence over the server configuration, so that's one more thing that could go wrong.

Also, the DHCP protocol is considered to be run with an incomplete
network stack, so most of the servers does not send packets larger
than MTU, in isc-dhcp case even 1500. As indicated in RFC 2131:

> The client SHOULD include the 'maximum DHCP message size' option to let the server know how large the server may make its DHCP messages.

But most clients do not send this message, and DHCP servers could not
determine whether clients have a well-configured network stack. Maybe
that’s the reason why most DHCP servers do not support long variable
splitting, as it would be much less useful.

As option 121 is not supported in most proprietary and legacy DHCP
client implementations, for example, Apple's DHCP client does not read
this option, and Microsoft's implementation uses another option 249,
this could be less powerful to utilize. DHCP itself is a rather simple
protocol.

## My intended usage

As Glenn writes:

> this looks like it would mean the clients only use that low bandwidth router if the others are not contactable? To me this looks like something that would depend on client behaviour - so it might work as you want for some clients and not others.

I'm trying to configure my network that supports transparent VPN to
our school, as our school's internet policy does not allow incoming
new connections.

The school has a long IP network list, and not as easy as shown below.
It has at least 40 non-aggregatable CIDR networks, and need to store
in around 2 or 3 255-byte lists. If more things like journal
subscriptions, academic resources are needed, it would be longer than
any reasonable MTU.

>   option classless-routes code 121 = array of uint8;
>
>  option classless-routes 32, 1,1,1,1, 5,5,5,1,
>  24, 2,2,2,   5,5,5,1,
>  24, 3,3,3,   5,5,5,1;

Things like OpenVPN can push route tables through their commands, but
I'm trying to mimic the internet connection inside our school, as some
devices have difficulties connecting to our school's VPN.

This transparent VPN is running on a Raspberry Pi, and is done using
the iptables to distinguish this, with other devices' gateway pointing
to Raspberry Pi. This led to a network speed decrease as all network
traffic had to travel through the cable connecting the original router
and Raspberry Pi twice.

A solution to this is to adjust the routing table on other devices
that only routes the needed IP network to Raspberry Pi and others
through the router directly. This configuration automation leads to
RFC3442.

It looks like this configure intention was impossible with current ISC
DHCP tools. It is also impractical to use this in the civil networks
as most devices, windows, Mac OS, and iOS, maybe Android, don't
support this. To realize this,

- The DHCP server and client should support larger-than-MTU (using
IPv4's fragmentation) to send/receive messages up to 65536 bytes (UDP
limitation), when the client has the ability to establish the IPv4
stack.
- The DHCP server should support RFC 3396, long variable segmentation.
- The DHCP client should support Option 121.

It may still have a long way to go.


More information about the dhcp-users mailing list