Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: Oversized DHCP option issues (???)
----------------------------------------------------------------------
Message: 1
Date: Mon, 24 Jan 2022 23:49:58 +0800
From: ??? <weihau.chi...@gmail.com>
To: dhcp-users@lists.isc.org
Subject: Re: Oversized DHCP option issues
Message-ID:
<cadzkvkkbmruc1ffqedq4s+3kbvam5sxg_llrkc7sgaymy39...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
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.
------------------------------
Subject: Digest Footer
_______________________________________________
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 159, Issue 4
******************************************
