Subject: [Geopriv] DHCP Size

From: Cullen Jennings <[email-masked]>
Date: Sat, 10 Mar 2007 12:32:13 -0800

One thing I have been getting concerned with is the size of DHCP  
responses with all the SIP/ECRIT/GEOPRIV etc usages of them. Has  
anyone looked at how big one could reasonable get?

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

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 10 Mar 2007 16:05:01 -0600

>anyone looked at how big one could reasonable get?

DHCP has some interesting limitations to Option size (RFC2131), including

         * the size limitation of any individual Option response (255 
bytes I believe)
         * the size of the aggregate of all responses within a message
         * and how to concatenate Options (RFC3396)

But generally, DHCP responses are limited to 576 bytes for all 
options (i.e. not just location), unless something special has 
occurred.  This WG cannot assume that only location will be in a DHCP 
(OFFER or ACK) response, even if that is all that was requested in a 
DISCOVER, REQUEST or INFORM message. Often many more options will be 
in that same response message - which is out of the control of the 
client, but under the control of the server. All of this is capped at 
576 bytes (unless something special has occurred).  Generally, if an 
OFFER or ACK  response is received in consecutive packets, the second 
packet's values overwrite the first packets values. In fact, I think 
any subsequence response with a new value within a specific Option 
overwrites what was there from the previous response.

I think it is possible some folks on this list assume DHCP has the 
normal MTU of 1500 bytes - and that isn't the case.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 10 Mar 2007 16:14:53 -0800

Makes sense - I was just starting to get a little worried that all  
the options together might be getting close to too big.

Could we try listing all the options that we can imagine might  
reasonable get put in the response to DHCP request from a SIP UA and  
check that there are no surprises.

On Mar 10, 2007, at 2:05 PM, James M. Polk wrote:

>         * the size limitation of any individual Option response  
> (255 bytes I believe)
> occurred.  This WG cannot assume that only location will be in a  
> DHCP (OFFER or ACK) response, even if that is all that was  
> requested in a DISCOVER, REQUEST or INFORM message. Often many more  
> options will be in that same response message - which is out of the  
> control of the client, but under the control of the server. All of  
> this is capped at 576 bytes (unless something special has  
> occurred).  Generally, if an OFFER or ACK  response is received in  
> consecutive packets, the second packet's values overwrite the first  
> packets values. In fact, I think any subsequence response with a  
> new value within a specific Option overwrites what was there from  
> the previous response.
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 11 Mar 2007 18:24:15 -0500

There is nothing preventing a client from requesting options separately; but then there is a need to determine how likely that is.

The only option I'd be concerned about is the civic address option.  Languages that require multi-byte characters could be a problem.  In particular, I think about the Taiwanese addresses which also have a multi-layer street hierarchy.  That would be more of Henning's domain.

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Sunday, 11 March 2007 11:15 AM
> To: James M. Polk
> Cc: [email-masked]
> Subject: Re: [Geopriv] DHCP Size
> 
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 11 Mar 2007 20:20:05 -0400

>
> The only option I'd be concerned about is the civic address  
> option.  Languages that require multi-byte characters could be a  
> problem.  In particular, I think about the Taiwanese addresses  
> which also have a multi-layer street hierarchy.  That would be more  
> of Henning's domain.

I don't have good statistical data on Taiwanese or Chinese address  
sizes, but, in general, I don't think multi-byte characters change  
much, compared to the Latin representation, since each Chinese  
character typically represents two or three Latin characters, which  
just happens to the UTF-8 expansion factor.

http://www.bitboost.com/ref/international-address-formats.html#PRC

gives some examples, including multi-layer street names, all of which  
are similar in length to US or European addresses.

I'm guessing (and I'm sure there are Chinese-speaking contributors on  
this list who can correct me...) that, say, Jiu Shi Fu Xin in one of  
the examples represents no more than 4 Chinese characters.

The longest address in that small sample has 125 bytes (including the  
occupant name), so this is not likely to cause problems.

If there's a multi-byte problem, it would be more likely with  
alphabetic languages, say Russian or Greek. With the typical  
expansion by a factor of 2, we'd still be around 200, i.e., well  
south of DHCP limitations.

Henning

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 11 Mar 2007 19:33:02 -0500

That sounds sensible.  The only potential problem occurs when civic addresses are requested in combination with other options.

For curiosity's sake, does the 576 byte limit include the 236 byte fixed part, or is it in addition to that?  A 200 byte address is a significant chunk out of 576 bytes, but it's even more when taken from 340 bytes.

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, 12 March 2007 11:20 AM
> To: Thomson, Martin
> Cc: GEOPRIV

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 11 Mar 2007 20:43:22 -0400

On Mar 11, 2007, at 8:33 PM, Thomson, Martin wrote:

> That sounds sensible.  The only potential problem occurs when civic  
> addresses are requested in combination with other options.
>
> For curiosity's sake, does the 576 byte limit include the 236 byte  
> fixed part, or is it in addition to that?  A 200 byte address is a  
> significant chunk out of 576 bytes, but it's even more when taken  
> from 340 bytes.

I don't see this as a major problem, for two reasons:

"DHCP clients may negotiate the use of larger DHCP messages through  
the 'maximum DHCP message size' option.  The options field may be  
further extended into the 'file' and 'sname' fields."

[RFC 2131]

In other words, the 'file' and 'sname' fields that contribute to the  
236 bytes you mention aren't really wasted and the real fixed header  
is only 44 bytes. Since DHCPINFORM can specifically ask for one  
option at a time, I see few problems here.

Henning