Subject: Help! Static route option

From: Ralph Droms <[email-masked]>
Date: Wed, 19 Jan 2000 09:06:27 -0500

Mail sent to [email-masked] by [email-masked]:

A quick question.

For the old DHCP Static Route Option (33) that has no mask, what is the
effective mask supposed to be?

Mac OS Open Transport currently uses a mask of all-ones, apparently in
the assumption that a route without a mask must necessarily be a host
route.

I'm wondering if maybe the intention of the Static Route Option was that
the mask should be derived programmatically from the class of the
destination address, in the old sense of Class A, Class B, Class C. In
other words, a route to destination 36.0.0.0 is assumed to have a /8 mask
because it is a Class A address. However, what would you do if the
destination were 36.17.23.194? That's a Class A address, but it has ones
in the host part, so it can't possibly be a route to net 36/8.

RFC 2132 doesn't provide any clarification on this.

(I know Static Route Pption is due to be replaced by "Static routes with
subnet masks option", but we'd still like to handle the old option in a
sane way too.)

Stuart Cheshire <[email-masked]>
   * <A HREF="http://ResComp.Stanford.EDU/~cheshire/">Web Page</A>
   * Wizard Without Portfolio, Apple Computer

---

From: Ralph Droms <[email-masked]>
Date: Mon, 24 Jan 2000 11:38:37 -0500

Message originally sent by Lars Viklund <[email-masked]>:

 > From: Bernie Volz [mailto:[email-masked]]
 > Subject: Re: Help! Static route option

 > So, if any DHCP Client implementors care to comment on how
 > they process
 > this option (or if they don't), please send to the list.

We ignore it.

Also, note that RFC 2132 says that the default route is an illegal
destination for a static route.

--
Lars Viklund
Axis Communications AB
SE-223 70 Lund, Sweden

---

From: Rob Stevens <[email-masked]>
Date: Mon, 24 Jan 2000 16:58:24 -0000

-----Original Message-----
From:	Ralph Droms [SMTP:[email-masked]]
Sent:	Monday, January 24, 2000 4:39 PM
To:	[email-masked]
Subject:	RE: Help! Static route option

 > this option (or if they don't), please send to the list.

[]  We neither ignore nor use it. The client writes a database
which can be interrogated by programs interested in
discovering what was returned by DHCP (Typically
startup scripts used in booting Unix workstations).  Interrogating this
option would give you a list of IP address pairs. How those
are interpreted is up to whoever is reading them.

In general our client does not use directly use options which
don't affect the state diagram of the DHCP protocol
(so the gateway, IP address, Mask are all things which
 the client would use).

Rob

---

From: Ralph Droms <[email-masked]>
Date: Sun, 30 Jan 2000 08:48:39 -0500

Mail sent by Stuart Cheshire, [email-masked]:

 >While I agree that this option should be depreciated (and am all for a
 >new option with the mask), IF there are clients that use it, it would be
 >nice to hear from these client implementors to understand how they are
 >currently interpreting it such that if someone needed to use it, they
 >could.

I totally agree that the option ought to be deprecated.

However, *IF* some DHCP server administrator out there decides to use it,
I'd like Mac OS to do something sensible. When customers want to buy our
computers and use them in a particular way, it is hard for Apple to take
a political stance and obstruct them unless there's a *really* good
reason to do that. In that spirit, this is the code I've decided to use:

#define ClassMaskOf(X)                                            \
     ((((X) & 0x80000000) == 0         ) ? 0xff000000 :            \
					(((X) & 0xC0000000) == 0x80000000) ? 0xffff0000 :            \
					(((X) & 0xE0000000) == 0xC0000000) ? 0xffffff00 : 0xffffffff )

mask = ClassMaskOf(rtToAddr);
if (rtToAddr & ~mask) mask = ~0;

If the destination makes sense as an old-style classful network number,
then I use that mask. If it has non-zero bits anywhere in the host part,
then I set the mask to all ones to make it a host route. I hope this is
the last time I have to look at that code. I will of course add support
for routes with masks as soon as it is standardized.