Subject: RE: Help! Static route option

From: Eric Michelsen <[email-masked]>
Date: Fri, 28 Jan 2000 11:48:46 -0800

I mispoke about our imlementation using static routes for the default
router.  That is explicitly forbidden in RFC-2132, and we do the right
thing.

More below:

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Monday, January 24, 2000 7:24
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Help! Static route option 
>
> > I'm all for deprecating it when the route-with-mask option 
> is available.
> > Even so, it will take a while before all the DHCP servers 
> support it, so it
> > may still be reasonable to clarify its use until a better option is
> > available.
> 
> Clarifying it doesn't make sense when talking about existing
> implementations - they are already doing whatever they're going to do,
> which normally will be to not request the option and to ignore it if
> it's received.   We don't _want_ future implementations, so
> clarification doesn't help there either.

The point is that there are existing *servers* which support the existing
options.  Those servers won't go away overnight.  In the meantime, there are
*new client* implementations, which may be forced to work with older
servers.  Therefore, it *does* make sense to define how new clients should
interpret the older option.
 
> The current option _doesn't work_, so there is simply no point in
> anybody ever implementing it, clarification or no.   I will try to
> have a draft out today for a classless static routes option, and then
> we can stop arguing about this.

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.  

Similarly, RIPv1 works fine, too.  There are thousands, if not millions, of
RIPv1 implementations working today with standard class-ful routing
interpretation of routes-without-masks.

Frankly, why would anyone put static routes in their DHCP responses anyway?
Isn't that what ICMP Redirects are for?  Or is this meant for DHCP clients
which are actually routers, and get their routing information from the DHCP
server?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jan 2000 14:55:35 -0500

> router.  That is explicitly forbidden in RFC-2132, and we do the right

That's good to hear.

> interpret the older option.

Nope.   Sorry.   The option doesn't work, so existing servers that
support it might as well not support it, for all the good it will do
for clients.

> 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.

> which are actually routers, and get their routing information from the DHCP

I think it's there for completeness, actually.   The netmasked routes
option could be useful in some corner cases, but by and large you're
right that it would be better to use RIP or OSPF to distribute the
routes.   ICMP redirects, maybe not - most people disable routing
updates via ICMP redirect these days.

			       _MelloN_