Subject: Re: Comments on draft-ietf-zeroconf-reqts-02

From: Stuart Cheshire <[email-masked]>
Date: Mon, 27 Mar 2000 22:58:30 -0800

>It is easy to accidentally introduce a mis-configured DHCP server (perhaps
>appliances with wireless interfaces) into a DHCP network. Should all hosts
>in the ZeroConf network necesarily acquiesce to DHCP in this case?

I agree with this description of the problem. I strongly believe that the
appearance of a DHCP server should offer a host an additional IP address to
use, but not take away the existing link-local address that it already has.

Stuart Cheshire <[email-masked]>

---

From: Richard Johnson <[email-masked]>
Date: Wed, 29 Mar 2000 20:11:23 -0800 (PST)

> Stuart Cheshire <[email-masked]>

I completely agree with this.  I would, furthermore, like to address
the issue of whether or not DHCP support is a MUST for a small
zeroconf device.  I don't see any reason why someone couldn't create a 
small "toaster" which doesn't have enough memory to fully support
DHCP, but could easily do simple zeroconf to get an IP address.  Why
should we rule out such a product by stating that a zeroconf product
MUST use DHCP if a DHCP server is available?  I think that once we
allow for a zeroconf originated address in addition to a DHCP address, 
then we should also allow for *just* a zeroconf address.  Yes, this
may mean that the device is limited to the local link, but that's a
bridge (no pun intended) which we haven't crossed yet and may end up
not being a requirement in the end.

I'd like to see the draft wording say something like:

... if a DHCP server comes online after hosts are configured with a
zeroconf IP host configuration protocol then hosts MAY acquire a DHCP
originated address in addition to their zeroconf address.

/raj

---

From: Daniel Senie <[email-masked]>
Date: Wed, 29 Mar 2000 23:20:30 -0500

> originated address in addition to their zeroconf address.

On the surface, this all seems to make sense. The issue that arises is
how OTHER stations will talk to this type of station which can't migrate
to a real address.

In an environment where all other devices are using addresses from a
DHCP server, and NEVER used zeroconf, how will this device you propose
communicate? There's no reason why a PC running Windows or Linux, which
received an address at bootup time via DHCP would ever know that a
device is also on the same LAN using another block of IP addresses.

If we assume zeroconf only happens on stations when DHCP or other
configuration isn't present, then how do we manage to communicate?
Perhaps a router must exist, configured to route between zeroconf and
whatever blocks the DHCP server (or manual configuration) are providing?
Seems messy.

Further, I'm concerned that you're arguing that DHCP client adds so much
space to an IP stack as to be a problem for fitting in small devices. I
disagree with this assessment. Small embedded systems which can
accomodate a LAN interface can also handle the small bit of memory for
an IP stack and DHCP.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: Richard Johnson <[email-masked]>
Date: Wed, 29 Mar 2000 20:39:17 -0800 (PST)

> device is also on the same LAN using another block of IP addresses.

This seems to making the assumption that the agreed upon method of
getting an address via zeroconf is to allocate one randomly, etc., out 
of the special link-local address space.  Maybe we have already gotten 
to the point of deciding that's the way to go in all cases, but I
didn't think we had.  If the local link has, for example, a router but 
just doesn't have a DHCP server, then it would seem the host could
discover the network number and mask from the router and then allocate 
an address from *that* address space randomly, arp for it, etc.  If
this becomes an accepted method of doing zeroconf in this situation,
then the host wouldn't really need to acquire a DHCP address since it
would already have one in that address range.

I know, there are all sorts of other arguments which could be brought
up, and have been already, why this may or may not be a good or bad
idea.  I just didn't think the issue of what address space to use had
been completely decided in all cases yet.

/raj