Subject: RE: [dhcwg] IDs on remote boot support for DHCP

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 7 Nov 2003 09:00:00 -0700

Kevin is correct, for DOCSIS 1.0/1.1/2.0.

See Annex D.1.1 of
<http://www.cablemodem.com/downloads/specs/SP-RFIv2.0-I04-030730.pdf> for
DOCSIS use of DHCP fields.

-- Rich

-----Original Message-----
From: Kevin A. Noll [mailto:[email-masked]]
Sent: Friday, November 07, 2003 10:21 AM
To: [email-masked]
Subject: RE: [dhcwg] IDs on remote boot support for DHCP

To the best of my knowledge, DOCSIS still specifies the use of the
'file' field for booting cable modems. I've never seen 'sname' used.

--kan--

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Barr Hibbs
Sent: Thursday, 06 November, 2003 6:08 PM
To: [email-masked]
Subject: RE: [dhcwg] IDs on remote boot support for DHCP

Ted--

Rob and I have already suggested that the use of the 'sname' and 'file'
fields be not just deprecated, but removed from the DHCP packet format (see
our I-D on RFC 2131 implementation issues that was discussed this morning in
the WG meeting) to expand the 'options' field and eliminate all of that muck
about overloading the 'sname' and 'file' fields.

The big question is "are there ANY DHCP clients that use 'sname' and 'file'
or options 66 and 67 to locate part of their boot images, or are all users
of this feature BOOTP clients?

--Barr

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Ted
> Lemon
> Sent: Thursday, November 06, 2003 11:51
>
> I've never heard of anybody using the sname field for anything.   I'd
> like to see its use deprecated, along with the server-name option.   I
> think we should have a single way of getting the identity of the server
> to contact, not fifteen different ways (okay, I'm exaggerating, but you
> get the idea).   Otherwise, neither the administrator nor the client
> implementor has any real way of anticipating which method to implement,
> or which to prefer if multiple methods are offered and multiple methods
> are implemented.   So you wind up with the sysadmin playing a big
> guessing game.   Yuck.   Frankly, I'm skeptical about any proposal to
> add a new method  in DHCPv4 for determining what file to load, or where
> to load it - we should have a good reason for doing this, not just
> "this way is better."
>
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

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

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

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

---

From: "Kevin A. Noll" <[email-masked]>
Date: Fri, 07 Nov 2003 12:27:01 -0500

Does anyone know if there are any BOOTP or DHCP server or relay 
implementations that actually make use of the 'secs' field?

I know there are clients that update 'secs', but I don't know
about any servers.

Thanks.

--kan--
--
Kevin A. Noll, KD4WOZ
CCIE 10948, CCDP
Perfect Order, Inc.		
[email-masked]
717-796-1936

---

From: "Barr Hibbs" <[email-masked]>
Date: Fri, 7 Nov 2003 09:34:51 -0800

Rich, Kevin--

thank you for clarifying that point

--Barr

> Woundy, Richard
> Sent: Friday, November 07, 2003 08:00
> To: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Nov 2003 12:11:17 -0600

> I know there are clients that update 'secs', but I don't know

Both the ISC DHCP server and Nominum DCS are able to make use of the 
secs field as a way to override load balancing in cases where a client 
doesn't get any reply from the load balance server that should have 
given it a reply.   This isn't required by the load balancing 
specification, IIRC, but I think you should have a pretty good reason 
for *not* doing it.

---

From: "Kevin A. Noll" <[email-masked]>
Date: Fri, 07 Nov 2003 13:37:03 -0500

Thanks, Ted.

On a related note, I've seen a certain OS vendor's DHCP client
increment the secs field in the upper-order octet rather than
the lower order.

e.g. 28 secs = 00011100	00000000

Does anyone have any idea why it's used this way? Or perhaps
my decoding of the field is incorrect?

--kan--

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Ted
Lemon
Sent: Friday, 07 November, 2003 1:11 PM
To: Kevin A. Noll
Cc: [email-masked]
Subject: Re: [dhcwg] secs field?

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 7 Nov 2003 13:48:03 -0500

This is a byte ordering issue. htons isn't being used in the OS vendor's
client to assure proper byte ordering.

A trick that can be used (it does have risks) in a server is to check the
value and if > 255 and the low order 8-bits are zero, assume that the bytes
are out of order and swap them.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin
A. Noll
Sent: Friday, November 07, 2003 1:37 PM
To: [email-masked]
Subject: RE: [dhcwg] secs field?

Thanks, Ted.

--kan--

---

From: Bud Millwood <[email-masked]>
Date: Sat, 8 Nov 2003 11:41:53 +0100

> implementations that actually make use of the 'secs' field?

Our DHCP server has a $SECS() function that can return this value at runtime, 
where it can be used in all sorts of decisions.

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
mailto:[email-masked]