Subject: RE: draft-ietf-dhc-csr-02.txt

From: Bernie Volz <[email-masked]>
Date: Thu, 22 Jun 2000 14:05:09 -0400

Don't know if they are archived.

The existing (RFC 2132) Static Route option only specifies
<network>/<router> pairs and therefore has no means to communicate a
class-less network.

You do ask a good point ... why give the client routing information other
than the default route. In general, there is no need to give the client
specific routes since it can learn them via ICMP redirects from the default
router.

However, there are other cases where that is not true. For example, with
multiple networks on a single cable, you might want to let the clients know
that this is the case (since ICMP redirects aren't really great at
communicating this information).

BTW: That does raise a good question ... how about allowing the <router>
address to be 0.0.0.0 in the CSR option to specify "this network is local to
the interface"? 

- Bernie Volz

-----Original Message-----
From: Charles Ragan [mailto:[email-masked]]
Sent: Thursday, June 22, 2000 1:52 PM
To: DHCPv4 discussion list
Subject: RE: draft-ietf-dhc-csr-02.txt

Hi,

Are these messages archived somewhere....?

I'm joining in a bit late and I want to see what the reasoning is for
additional routes in the clients.

I've considered the following:

1-same physical network, same logical- would still use the default gateway
- probable icmp redirect to 'other' routing host on physical net (router
being 'more knowing')

2-same physical network, different logical - default gateway does NOT
participate in the second logical (i.e. secondary addressing)...I could see
the use here, but would entire dhcp scope carry route information for this
'other' logical subnet?

3-if the dhcp scope became a 'more' focal point for modifiying routes,
based on the typical environment (i.e. dhcp is owned by a different group
than the router jockeys, I could see where routing information mods could
cause confusion amongst the two groups.)....where it seems that >90% of the
traffic would still traverse a local (more knowing) router anyways....

Sorry for the 'jumping in late'....

Charles

At 09:40 AM 06/22/2000 -0400, Bernie Volz wrote:
>I have no problem if we were to deprecate option 33.
>
>However, there will likely always be clients that continue to support just
>it (at least for a while). And, while those clients exist and if SOME
>routing information must be given to them (other than default routes), then
>all you may have is Option 33.
>
>Also, when new clients that support CSR are released, servers may not yet
be
>configured with this new option data and thus these clients may need to
>continue to use option 33 for "limited" routing information.
>
>So co-existance is necessary.
>
>- Bernie
>
>-----Original Message-----
>From: Eric A. Hall [mailto:[email-masked]]
>Sent: Wednesday, June 21, 2000 7:44 PM
>To: DHCPv4 discussion list
>Cc: DHCPv4 discussion list
>Subject: Re: draft-ietf-dhc-csr-02.txt
>
>
>
>> > If that's not the goal, maybe just deprecating 33 is the best thing
>> > to do. Since the predominate client(s) don't support 33 that's no
>> > loss to most of the end-users.
>> 
>> This is precisely the point, and this is what the proposed language
>> effectively does.
>
>It should state it explicitly if the justification can withstand debate.
>If it cannot, then both of them should continue to be supported. At the
>very least, support for both would at least allow admins with complex
>networks and 33-capable clients to transition from one to the other.
>
>-- 
>Eric A. Hall                                      http://www.ehsco.com/
>Internet Core Protocols        http://www.oreilly.com/catalog/coreprot/

"There is no 'i' in TEAM!"

Charles Ragan
Principal Consultant
NetCare/Lucent Technologies 
800-467-1467 Pager
509-546-0899 Fax 
http://www.lucent.com/netcare

---

From: Ralph Droms <[email-masked]>
Date: Thu, 22 Jun 2000 17:49:07 -0400

>Don't know if they are archived.

http://www.listproc.bucknell.edu/cgi-bin/archdex?list=dhcp-v4