Subject: [dhcwg] DHCPv4: Relay agents and packet sizes

From: Bud Millwood <[email-masked]>
Date: Tue, 3 May 2016 13:17:48 +0200

Hello all, hope everyone is well. Long time no see. I could use some advice:

Our DHCP server responds to clients with the same size packet as the
client sends us unless A) it's smaller than the minimum size or B) the
max-message-size option is present. In the case of (A) we bring it up
to the minimum size, in the case of (B) we use the max-message-size.

I have a CMTS that is placing both Remote ID and Circuit ID in DHCPv4
packets, and the Circuit ID is quite large (40 bytes?). I'm running
out of space in my response packet.

There is no max-message-size here, and we aren't overloading the file
or sname fields.

Any advice on the best way to handle this? For maximum compatibility,
should I be overloading the file/sname fields, or increasing the
packet size? (Increasing seems downright crazy)

What approaches do you use when you're getting squeezed like this?

Thanks in advance for any advice.

- Bud

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 May 2016 13:11:10 -0400

The expectation is that the remote-id and circuit-id options are not
counted as part of the packet size for the client, because they are
stripped by the relay agent.   I'm fairly sure that I handled this by
simply allowing the option buffer to get bigger.

Also, the maximum packet size is (IIRC) 576 by default, not "whatever size
the client sent."

On Tue, May 3, 2016 at 7:17 AM, Bud Millwood <[email-masked]>
wrote:

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Bud Millwood <[email-masked]>
Date: Wed, 4 May 2016 10:20:09 +0200

Thanks for the advice Ted, I really appreciate it!

My concern has always been that the clients have already allocated
their buffer and won't have enough sense to allocate a larger buffer
for packet reception. But I suppose if it's that or no packet at all,
the clear choice is to increase the buffer size. Also I went back and
re-read the relay agent RFC and remembered that it's added onto the
packet, not into it, so essentially I just have a space problem. As
usual.

As for the max packet size, I purposefully decided to go with whatever
size made it into the server, under the impression that there was a
good chance it would make it back. It is, however, configurable to
force it to drop back to the max packet size. As a side note, I've had
good experience with this policy. I don't think I've ever had to
configure my server to limit the output packet size because the input
packet size was too large to get back to the client.

Thanks again for the tips!

- Bud

On Tue, May 3, 2016 at 7:11 PM, Ted Lemon <[email-masked]> wrote:
> The expectation is that the remote-id and circuit-id options are not counted
> as part of the packet size for the client, because they are stripped by the
> relay agent.   I'm fairly sure that I handled this by simply allowing the
> option buffer to get bigger.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 May 2016 11:55:18 -0400

Question: RFC 2131 says this:

   A DHCP client must be
   prepared to receive DHCP messages with an 'options' field of at least
   length 312 octets.

It sounds like you are reporting that some clients do not follow this rule.
  Is that right?   I find it hard to believe, because most of the time
clients don't send many options, and need many more options back.   Or is
it your experience that clients send packets with 312-octet option buffers?
  I'm a bit confused by what you're reporting here, but I haven't hacked on
DHCP servers in a while, and am willing to believe nearly any report of
brokenness in clients based on past experience.

BTW, I was remembering how I implemented the relay options, and I actually
wound up having a separate bit of code that unpacks and repacks them, IIRC,
rather than using the same packet assembly code that I used for sending
options to clients and receiving options from clients.   I've never heard
reports of problems with it, FWIW.

On Wed, May 4, 2016 at 4:20 AM, Bud Millwood <[email-masked]>
wrote:

> counted