Subject: [dhcwg] DHCP packets options field >= BOOTP vendor options (64 bytes)?

From: Sanjeev Verma <[email-masked]>
Date: Mon, 17 Oct 2005 15:51:14 -0700

Is it OK for a dhcp client to send a discover with options field less
than 64 bytes?
  As per RFC951, vendor options field is 64 bytes. I take it to mean
that even if vendor options are less than 64 bytes, the rest of the
bytes will be sent out.
  For DHCP discover packet, options have to be there to specify, at the
least, DHCP message type.
  Does that mean that DHCP discover will carry 4 bytes magic cookie, 3
bytes of message type option, end-field and then 56 bytes (of 0s
perhaps) to match BOOTP vendor options field size? Or can the client
leave out those 56 bytes, reducing the packet size by 56 bytes?

thanks in advance,
Sanjeev.

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

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 18 Oct 2005 10:43:17 -0700

> Is it OK for a dhcp client to send a discover with options field less

I do think, at least, ISC's server implementation would permit it;

        /* If we didn't at least get the fixed portion of the BOOTP
           packet, drop the packet.  We're allowing packets with no
           sname or filename, because we're aware of at least one
           client that sends such packets, but this definitely falls
           into the category of being forgiving. */
        if (result < DHCP_FIXED_NON_UDP - DHCP_SNAME_LEN - DHCP_FILE_LEN)
                return ISC_R_UNEXPECTED;

And then some.

But I suspect doing so is inadvisable.

> perhaps) to match BOOTP vendor options field size?

I can't speak for the RFC authors' intents, but that is ISC dhclient's
interpretation; a minimum length of 300 is enforced (after IP/UDP), bytes
on the other end of the END option are left zeroed.

I think this is probably the safest, most compatible approach.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Sanjeev Verma <[email-masked]>
Date: Thu, 20 Oct 2005 14:49:33 -0700

Thanks for replying David.

  Interestingly, RFC1542 in section 2.1 second para says:

      o The IP Total Length and UDP Length must be large enough to
        contain the minimal BOOTP header of 300 octets (in the UDP
        data field) specified in [1].

  But I could not find any minimal BOOTP header recommendation of 300
octets in RFC951.

  Anyway, I agree that client should send 300 bytes minimal BOOTP
packet. However, server should be prepared to handle 300 - 64 + 8 = 244
bytes of DHCP packet.

-Sanjeev.

David W. Hankins wrote:
> ------------------------------------------------------------------------
>

---

From: Andre Kostur <[email-masked]>
Date: Thu, 20 Oct 2005 15:38:18 -0700

>   But I could not find any minimal BOOTP header recommendation of 300
Section 3, page 3. It defines the length of each field.  Add them all 
together, and you get 300 bytes.

---

From: Sanjeev Verma <[email-masked]>
Date: Thu, 20 Oct 2005 19:26:42 -0700

You are counting vend[64] field as well. That field is optional.
-Sanjeev.