Subject: avoiding proxies

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 30 Jul 2003 09:05:35 -0500

From my point of view, the problem with mandating the use of either of
these solutions is that they would both introduce the use of mandatory
proxies to some extent, and would prevent the application-layer DNS from
working in their absence. This is a bad idea, in my opinion, as it
interferes with several basic design tenets.

In the case of RA (as I understand it), the clients and servers couldn't
function without a proxy in any event, even if they were on the same
subnet. In the case of DHCP, a client and server could function in the
absence of a proxy if they were both on the same subnet, but not in other
scenarios. Stick the ~discovery capability into the service itself, and
this is all avoided.

On a related but separate point, generalized configuration services as a
whole should still be available as an option, and DHCP should be capable
of providing all of the necessary configuration information if that
service is already being used. So I'm in favor of adding whatever is
necessary to DHCP, but it should not be *required* in the default case.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Tim Chown <[email-masked]>
Date: Wed, 30 Jul 2003 15:45:35 +0100

> scenarios. Stick the ~discovery capability into the service itself, and

Wouldn't the RA always be local and on link though, as each link will have
at least one router for off-link traffic?   Thus there would not need to
be an RA proxy as such.   There would be a need for DHCP forwarding though,
as one would be unlikely to have a DHCP server on every link, unless all
routers included DHCPv6 Lite support.

I think many enterprise networks now don't have clear L2 and L3 equipment
boundaries.  Functionality is combined, and to some extent blurred.  In 
our enterprise network, which uses a lot of combined L2/L3 equipment, our 
core "switch" can forward DHCP requests from routed VLANs.  It could
equally handle RAs on links too, of course.

I note that in many enterprises DHCP is not used.  Hosts are manually
configured, yet such enterprises have well known DNS resolvers.

At our own enterprise (university) where we have DHCP we use it for the
basic network config stuff (that is handled in v6 by RAs), plus DNS, DNS
search path, NTP, NIS and some boot parameters.   I don't know how typical
that is in a campus department.

The interesting question is how the DNS resolver (and/or other) information
is configured to the router, for the RA method to work.

Tim

---

From: Rob Austein <[email-masked]>
Date: Wed, 30 Jul 2003 10:55:44 -0400

<hat wg-co-chair=off just-another-bozo-on-this-bus=on>

> interferes with several basic design tenets.

One can chose to co-locate a DHCP-lite server with the DNS name
server, at which point DHCP is no longer a proxy by the definition you
appear to be using.  There's still some involvment by the router in
everything but the single subnet case, but that's unavoidable (in
kind, anyway -- one can argue about the degree of router involvement).

</hat>

---

From: Tim Chown <[email-masked]>
Date: Wed, 30 Jul 2003 15:45:35 +0100

Tim

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 31 Jul 2003 13:09:36 +0859 ()

Eric;

> interferes with several basic design tenets.

I'm not sure what you mean "proxy". But, it is not a business of
"discovery" (whatever "discovery" means) protocols to relay service
to other subnets if a server for the service is not available link
locally.

On the Internet, the mechanism to relay requests to servers over
multiple links is called routing.

The mechanism to propagate relaying directions to the servers over
multiple links is called a routing protocol.

> scenarios. Stick the ~discovery capability into the service itself, and

ND can be bloated to poorly perform some aspect of routing, of course.

						Masataka Ohta

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 31 Jul 2003 00:14:17 -0500

on 7/30/2003 11:10 PM Masataka Ohta wrote:

> I'm not sure what you mean "proxy".

I mean a third-party agent with knowledge of the application and/or the
environment. My examples were poorly formed but are valid in the general
sense, since we are still talking about relying upon extraneous agents
which have to be managed explicitly and separately from the application
end-points themselves. Certainly there are advantages to doing so
voluntarily (equitable benefit from the investment in resources), but
requiring this model really needs to be avoided.

> multiple links is called routing.

Exactly, let's let routing do the job it is supposed to be providing
already anyway, rather than layering on even more mandatory services.