Subject: RE: Help! Static route option

From: Eric Michelsen <[email-masked]>
Date: Fri, 28 Jan 2000 13:41:55 -0800

...
> > I disagree that it doesn't work.  It works fine in any 
> situation that
> > requires only class-ful routes to be delieverd in DHCP 
> responses.  This
> > restriction doesn't limit your whole network, or even the 
> DHCP client, to
> > class-ful routing.  It simply means that for the 1 or 2 
> routes you might
> > plug into your DHCP server, they have to be class-ful.  
> 
> Right.   Unfortunately, class-ful routes are as rare as hen's teeth
> nowadays.   Furthermore, the behaviour of the client when presented
> with a class-ful route is already well-defined, so no further action
> needs to be taken.

I guess I'm lost.  If the behavior of the client is already well defined,
then what is the issue being debated right now?  Here's the original email
that started this thread:

> -----Original Message-----
> From: Ralph Droms [mailto:[email-masked]]
> Sent: Wednesday, January 19, 2000 6:06
> To: [email-masked]
> Cc: [email-masked]
> Subject: Help! Static route option
> 
> 
> 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.)

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jan 2000 17:04:54 -0500

> that started this thread:

Right, MacOS is doing something that is clearly the wrong thing.
But it doesn't matter, because really there _is_ no right thing.
There is a cost associated with pushing through new drafts.   The
default routes option is defined to do a particular thing which is not
useful.   If we define some new behaviour for it, that doesn't solve
anything, because somebody might continue to use the old behaviour.
So it's not worth the effort to push through a new draft "clarifying"
the old option - it would not do any good.

			       _MelloN_