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

[Ted Lemon <[e-mail]>]

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 <[e-mail]>
wrote:

> 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 <[e-mail]> 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.
> >
> > 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 <[e-mail]>
> > wrote:
> >>
> >> 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
> >>
> >> _______________________________________________
> >> dhcwg mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dhcwg
> >
> >
> >
> > _______________________________________________
> > dhcwg mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dhcwg
> >
>