Re: A Zeroconf situation?

I agree with kre - the decision about whether a device should get a DHCP
address should be made by the DHCP server, not the device.  In that way, the
decision is controlled by the network administrator and a device can adapt
to whatever local policy is in place.  In particular, it is precisely the
netadmin who knows how many IP addresses are available on a network, and who
can best construct a policy about which devices are assigned a global IPv4
address through DHCp and which are not.

The DHCP specification allows for differential assignment of addresses to
hosts requesting DHCP service - that is, a server is free to decide not to
respond to a request from a host for a DHCP address.  The specification
makes no statement about the policies a server might use in responding to a
host.  Most DHCP servers provides a variety of mechanisms for controlling
the assignment of DHCP addresses.

I believe the current IPv4LL spec adequately addresses the issue of packets
exchanges between a device with an IPv4LL address and a device with a
routable IPv4 address - both unicast and multicast.

- Ralph

At 05:47 PM 10/30/2003 +0700, Robert Elz wrote:
>     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