Subject: RE: zeroconf and non-zeroconf scenarios

From: Stuart Cheshire <[email-masked]>
Date: Mon, 8 May 2000 18:10:00 -0700

>Not sure what the use of this would be, since the purpose of the NAT
>box probably is to connect the network to the Internet. It would
>make more sense for the NAT box to assign itself a private IP
>address (say from 192.168/16), and start up a mini-DHCP server to 
>re-address the zeroconf workstations. In the process the zeroconf
>workstations will also configure themselves with the default
>gateway address and whatever else they need, via the mini-DHCP.

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.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer

---

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

Sorry for the cross posting but ...

> building a NAT gateway, it makes more sense to put a simple 

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: "Hattig, Myron" <[email-masked]>
Date: Wed, 10 May 2000 16:15:49 -0700

> but the person does know enough to uninstall the PC software. 

The text should be: 
"but the person does NOT know"

-myron