Subject: RE: zeroconf and non-zeroconf scenarios

From: "Hattig, Myron" <[email-masked]>
Date: Wed, 10 May 2000 16:01:00 -0700

Sorry for the cross posting but ...

> Although I said in my last message that a vendor COULD make a 
> NAT gateway 
> to work with self-configured link-local devices, that doesn't 
> necessarily 
> mean that I'm endorsing the idea. Bernard is right that if you're 
> building a NAT gateway, it makes more sense to put a simple 
> DHCP server 
> into it.

Here's why I'm hesitating on assuming a home gateway will have a DHCP
server:

There is no such thing as a simple DHCP server. DHCP in home networks 
requires a server-to-server mechanism to choose which DHCP server is 
the "best". The current drafts on "mini-DHCP" and "server-to-sever" 
options are far too insufficient. Whatever options get defined 
may also require support on the DHCP client. For example, how will 
the client know to start using a new DHCP server unless it watches 
for the "server-to-server" option.

Modifying the DHCP client makes one of the arguments for DHCP 
null-and-avoid, the argument is that using DHCP in home networks 
does not involve modifying DHCP clients. The alternative argument
is that if you must modify clients, then just modify them to support
a ZC autonet protocol. 

Here is the scenario to show why server-to-server negotiation is 
required: 

Someone hooks up two computers at home through shared internet 
access PC software such as Microsoft ICS, Intel Anypoint ISS, 
Winproxy. Two of these products include DHCP servers. 
One includes an install tool that configures link-local
addresses (to be compatible with "autonet"ed addresses).

Now someone purchases an xDSL gateway which also has a DHCP server 
but the person does know enough to uninstall the PC software. 
All the machines on the network continue to use the default route 
configured from DHCP server running on the PC, thus no traffic is 
ever routed through the xDSL gateway. Power-cycling the PCs ;-) 
may not even fix the problem. 

This will be a very common scenario that all  gateway vendors 
(hardware and PC software) will have to address. 

An alternative is to only use link-local addresses on the LAN, 
then NAT them. At this point, I'm not strongly advocating one
approach over another, (I'd like to see a clearly articulated
home networking DHCP solution that also accounts for interaction 
between DNS server and DHCP server) but I think it is too soon
to preclude NATing link-local addresses. I just want us to 
proceed cautiously.

-myron

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 16 May 2000 07:21:58 -0700

>DHCP in home networks requires a server-to-server mechanism to 
>choose which DHCP server is the "best". 

This is an issue only if there is more than one home gateway
running a mini-DHCP server. In that case, it is worth remembering
that DHCP was designed so that more than one server could handle a
given segment. As long as both gateways allocate addresses
from the same scope, there will not necessarily be a problem.

>Whatever options get defined may also require support on the 
>DHCP client. 

The client can ignore the options because a server 
should not respond to a client DHCPDISCOVER without 
sending its own DHCPDISCOVER in order to figure out
if there is another DHCP server present. Thus in
normal operation the client will only receive one
offer. 

>For example, how will  the client know to start using 
>a new DHCP server unless it watches for the 
>"server-to-server" option.

If home gateways are coming up and down it is conceivable
that a new server could be in place, or even that the 
client could receive more than one offer. At worst, this
could result in a client being allocated an IP address
that is otherwise in use. However, if client and servers
do the checks recommended in RFC 2131, then this should be
detected. 

>addresses (to be compatible with "autonet"ed addresses).

Given that in such a situation it is possible for clients
to auto-allocate addresses, it seems that there are some
of the same issues in running one mini-DHCP server as in
running two of them in that duplicate detection is required.

>may not even fix the problem. 

This problem is not caused by DHCP -- it's a routing problem. 
Turning off a mini-DHCP server *does not* result in the
gateway being turned off. Fixing this is tricky because
both gateways could respond to router solicitations; so it
looks to me that something like the "silent RIP" feature
is required to address this issue. 

>then NAT them. 

Not sure this would help the scenario above. You'll still have
two gateways, no?

>I'd like to see a clearly articulated
>between DNS server and DHCP server

Isn't this just draft-ietf-dhc-dhcp-dns-12.txt?