Subject: [dhcwg] client pads all packets to 576 octets, can't add Option 82

From: Chuck Anderson <[email-masked]>
Date: Tue, 15 Dec 2009 17:21:44 -0500

I have a strange DHCP client that pads all packets it sends to 576 
octets with extra zeros.  This is causing a problem when the Relay 
Agent or L2 switch attempts to add Option 82 information to the 
packet.  In fact, the L2 switch doing the Option 82 adding in this 
case is actually dropping the packet since it can't add the option 
since that would make the resulting packet bigger than 576 octets.

1. Is it allowed for a client to pad packets in this way?  Does it 
ever make sense to have this behavior?

2. Is it allowed for a DHCP Relay or L2 switch that is adding Option 
82 information to remove such padding to make room for the Option 82 
to be added to the packet?

My reading of RFC 3046 only suggests that the packet should be 
forwarded without adding the Option 82 info in case the packet would 
become too big.  It doesn't suggest how big is too big, other than to 
say they "MAY have a configurable for the maximum size".

Thanks.

---

From: Chuck Anderson <[email-masked]>
Date: Tue, 15 Dec 2009 22:48:25 -0500

On Tue, Dec 15, 2009 at 06:39:18PM -0800, Andre Kostur wrote:
> Is there an option 255 in the packet?  Offhand there isn't anything 
> prohibiting a device from sending all pads at the end of the packet, 
> and the relay should be able to add option 82 at the end as well.  
> True, the relay isn't guaranteed that the server can receive packets 
> larger than 576 bytes, but I'd be surprised if it can't.

Yes, it is a "normal" packet with a 255 End Option, followed by 234 
zeros (or however many zeros to make the total IP size 576).

So are packet bigger than 576 IP+UDP+BOOTP bytes legal?

I'm trying to work with the L2 switch vendor to have the relay 
behavior fixed to not drop such client packets and properly add the 
Option 82 info.  Should I suggest that they simply accept the 576-byte 
packet and:

1. add the Option 82 after the 200+ bytes of zero padding, even if the 
total IP size ends up > 576?

2. add the Option 82 right after (or before?) the 255 End Option, but 
before the padding?

3. remove the padding, then add the Option 82?

4. give up on adding the Option 82 and pass the unaltered packet 
as-is?

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 16 Dec 2009 09:32:35 +0530

Please see my response in line.

Thanks,
Bharat

> total IP size ends up > 576?

As per RFC 3046, Option 82 must be added before End Option. I think DHCP server won't process anything after it finds End option in a DHCP message.
 
> 2. add the Option 82 right after (or before?) the 255 End Option, but 

As mentioned above, this also won't work.

> 3. remove the padding, then add the Option 82?

I think this could be done. But I am not comfortable in suggesting that it should remove something which was added by the client. I think you should try to find out what is the size limit on a DHCP packet going out of your relay agent? Is it smaller than 1472 byte? I was thinking that even if a 576 bytes packet come in and if MTU of relay agents outgoing interface is 1500 byte, relay agent should still be able to add the option-82 without removing anything what client had added.

> 4. give up on adding the Option 82 and pass the unaltered packet 

This may not be of much use because DHCP server may discard this packet based on its own configuration.

---

From: Chuck Anderson <[email-masked]>
Date: Wed, 16 Dec 2009 01:09:50 -0500

On Wed, Dec 16, 2009 at 09:32:35AM +0530, Bharat Joshi wrote:
> As per RFC 3046, Option 82 must be added before End Option. I think 
> DHCP server won't process anything after it finds End option in a 
> DHCP message.

Yes, on a closer reading of RFC 3046 I see that now.

> As mentioned above, this also won't work.

#2 should be corrected to read:

2. add the Option 82 right before the 255 End Option, but before the 
padding?

which at this point seems like the only correct way.

> I think this could be done. But I am not comfortable in suggesting 
> that it should remove something which was added by the client. I 
> think you should try to find out what is the size limit on a DHCP 
> packet going out of your relay agent? Is it smaller than 1472 byte? 
> I was thinking that even if a 576 bytes packet come in and if MTU of 
> relay agents outgoing interface is 1500 byte, relay agent should 
> still be able to add the option-82 without removing anything what 
> client had added.

The packet should be semantically the same if you adjust the UDP 
length and IP length to only encompass exactly the length up to the 
End Option 255, essentially truncating any Pad options after the End 
Option.  The only time I see that this may become an issue is with RFC 
3118 Authentication for DHCP Messages, since the padding may be part 
of the authenticated data.

So at this point, I'm going to recommend to the vendor that they allow 
packets up to the MTU of the interface after appending Option 82 
(solution #2, leaving the existing padding intact).

As to why the client pads all packets to 576 bytes, I think this stems 
from this language in RFC 2132:

"3.2. End Option

   The end option marks the end of valid information in the vendor
   field.  Subsequent octets should be filled with pad options."

and this language from RFC 2131:

"The 'options' field is now variable length. A DHCP client must be
prepared to receive DHCP messages with an 'options' field of at least
length 312 octets.  This requirement implies that a DHCP client must
be prepared to receive a message of up to 576 octets, the minimum 
IP datagram size an IP host must be prepared to accept."

Thanks all.