Re: A Zeroconf situation?

    Date:        Wed, 29 Oct 2003 14:33:30 -0800
    From:        "Phillip Remaker" <[email protected]>
    Message-ID:  <[email protected]>

  | I have an appliance.  A home gateway, a home router, a Networked
  | Refrigerator, An ethernet connected vacuum cleaner.... whatever....
  | Unconfigured, out of shrink wrap.  I drop it in a static addressed or
  | DHCP-served network, but I *don't* want to to claim a DHCP address

Notice here that it is you who doesn't want it to have a DHCP address,
not the appliance itself.   If it was in my house instead of yours
I can assure you I would want the exact same appliance to get an address
from DHCP.   Other than getting at the device and configuring it, which
is what we're all trying to avoid, there's no way to make the device
act differently.

The obvious answer here is that the DHCP servers act differently - yours
doesn't give the appliance an address (doesn't offer one), mine does.
In each case, the appliance tries to get a DHCP address, in your house
it fails, in mine it succeeds.   Then, as in the note Christian quoted,
when yours fails to get a DHCP address, it gives itself a LL one instead.

  | (there may be a VERY limited number of IPv4 addresses from the lcoal
  | DHCP server, and I would not want the device to presume that it can
  | have one of them).

The device should be presuming nothing - it should simply take the
best that is available to it in the environment into which it happens
to have been placed.

  | I want it to come up as IPv4LL, and unable to route, unable to claim a DHCP
  | address.  I want it to detect the presence of a DHCP server, but not claim
  | an address.

Why on earth would you want to detect the DHCP server in that event?
If it has nothing for you, you don't care if it exists or not.
If you want to see if there is a DHCP server that will tell you
other useful information (like the IP address of your Impress server)
then you can try a DHCPINFORM request after a DHCPDISCOVER has
revealed nothing.

  | Effectively,  we have two ships-in-the-night V4 subnets on a broadcast
  | domain.

Not quite.

  | Most V4 stacks won't have a link local and globally scoped address
  | on the same interface.

The idea is that if you're going to have any devices on your net which
are using LL addresses, and you want to be able to communicate with them,
then those V4 stacks can't be ignorant.   They don't need both addresses,
but they do need to know how to reach LL addresses (ie: that LL addresses
are out there on the LAN, and the device should simply ARP for one).

  | Even if I multicast from a non v4LL address to a
  | v4LL address, how would the v4LL device be able to respond to an 'off
  | subnet' address (apparently, it wouldn't?)

It would.   The LL spec requires LL using devices to ARP for *everything*
they need to reach.   If the destination is on the same LAN, it will reply.
If it isn't, a device with only LL can't communicate with it, which has
all cost one ARP request to discover.

  | So in short, is there a
  | 
  | 1) Means to communicate between a link local and globally scoped address?
  | Is it allowed?

yes, it is allowed.   What's more it all almost "just works" even with
current devices (or most of them) - they may need to be configured
with an explicit interface route for LL addresses (and devices with
multiple interfaces will probably only be able to talk to LL devices
on one of them without code updates) but it does all work.

All this has been discussed many times before.

  | The fundamenal idea is that I can drop an unconfigured device onto any
  | network in a non-disruptive way, and then discover and configure it while
  | not having to mess with the stack/addressing of the configuring machine.

This you would need to do, currently.   Once LL is truly accepted, we
can expect systems to simply "know" how to reach them without needing
anything special done to them to make it happen (that is, devices will
auto-configure themselves with a route to LL destinations, and multi-interface
systems will provide a means to choose which interface to use).
Short term, things will be a bit messy, but not actually hard.

Read the draft.   Look back over the list archives.

kre