problem with dhcp setup
John Jason Brzozowski
john_brzozowski at cable.comcast.com
Wed Jun 27 01:48:05 UTC 2007
Having the client fail to run if dhcov6.oro is missing was a bit
inconvenient. I would certainly prefer something that is more forgiving.
On 6/26/07 6:15 PM, "David W. Hankins" <David_Hankins at isc.org> wrote:
> On Tue, Jun 19, 2007 at 11:05:10AM -0800, Ted Lemon wrote:
>> Oh, that's right. Sorry, it's been a long time since I looked at
>> that part of the spec. So if you send an ORO, then the server can't
>> send you anything you didn't ask for in the ORO. If you don't send
>> an ORO, it can send you whatever it wants. But if you send an ORO
>> and don't request the right stuff, then what I said stands - you
>> really don't want the server to volunteer options in that case.
> But...Section 18.1.1 ("Creation and Transmission of Request Messages"):
> The client MUST include an Option Request option (see section 22.7)
> to indicate the options the client is interested in receiving.
> This is why ISC "dhclient -6" insists that a dhcp6.oro be configured,
> or it'll fail to run.
> Either we do a Request eventually in runtime, or we will have already
> done one if we're restarting ("Confirm"), or we're likely to have to
> do one if anything happens to our lease. Better to fail early than
> I just wrote this off as yet another part of rfc3315 that wants
> you to "be liberal." Send, receive, whatever.
> But if that's not the case we should probably tell dhcwg. I'll
> send a note anyway.
> Sorry about the "send dhcp6.oro 1, 2, ...;" stuff by the way. I know
> its kludgy. I want to do a proper option request semantic (with a
> default list, since we MUST supply one) sometime before 4.0.0 final
> hopefully. I didn't want that work to delay testing, which we're
> obviously getting. :)
> THANKS for that by the way Suprasad. Let us know how it goes good
> or bad!
John Jason Brzozowski (CISSP, RHCT)
e) mailto:john_brzozowski at cable.comcast.com
More information about the dhcp-users