Rob,
glad you introduced this topic.
Given that a server sends a flag meaning "I have more options for you than
would fit in the DHCPACK packet," how would a client receive the remaining
data?
Possibilities include:
(1) Server uses the "parameter request list" option to specify which options
ARE included in the DHCPACK packet -- the client would use a DHCPINFORM
message to request any from its (the client's) original parameter list that
weren't included by the server.
(2) Server uses the "parameter request list" option to specify which options
ARE NOT included in the DHCPACK packet -- the client would use a DHCPINFORM
message to request any of interest.
(3) Server does not indicate which options have or have not been returned
(using the "parameter request list" option), leaving the determination of
which additional options to request in a DHCPINFORM message entirely to the
client, comparing the options requested to the options returned in the
DHCPACK message.
(4) Server uses some server-specific mechanism to determine which options to
return if they all do NOT fit in the DHCPACK message. Subsequent DHCPINFORM
request messages are answered with any remaining options from the
DHCPREQUEST message, plus those requested in the DHCPINFORM message, until
the packet is filled. This process could be repeated several times before
all [default or requested] options are given to the client.
Alternative (4) opens up a whole new discussion topic: what options SHOULD
be returned.
--Barr
> -----Original Message-----
> From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Rob
> Stevens
> Sent: Wednesday, October 15, 2003 15:45
> To: dhcwg@ietf.org
> Subject: [dhcwg] Bit in "flags" field indicating option overflow?
>
>
> I think it's fair to say that the question of which options to return
> to a client remains an area of confusion in the protocol. The language
> of 2131 is convoluted. And I don't believe there is a clear consensus
> on the question of whether servers should only return what clients ask
> for, or whether they should return everything they know. The latter is
> potentially a problem due to packet overflow; a problem that is likely
> to become worse as vendors define their own options.
>
> Is there any interest in the idea of using another bit in the "flags"
> field that servers can use to tell clients that there was more data
> than could fit in the packet?
>
> Another idea is to use option 55 (parameter request option) in
> messages from servers to clients which could contain a list of all
> options which could not be included due to space considerations.
>
> Rob Stevens
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg