Subject: RE: Suitability of v4LL in a managed network [was Application software needs to be "zeroconf-aware"?]

From: "Christian Huitema" <[email-masked]>
Date: Sat, 11 Jan 2003 22:14:45 -0800

On Sun, 12 Jan 2003, Brad Hards wrote
> On Sun, 12 Jan 2003 11:22, Vincent Lubet wrote:
>> I agree it's very reasonable not to require an LL address to be
>> assigned when a non LL address is assigned to a network interface.
> http://www.zeroconf.org/w3onwire-zeroconf.pdf contains a good intro to why
> this is needed.

The referenced document makes three arguments:

1) That if a server configuration changes, the clients will cease to function if they cannot find a server, i.e. resolve the server's name;

2) That if  a node with only a DHCP configured address will not be able to communicate with a node that only have an autoconfigured address;

3) That there will be simple devices that only have autoconfigured addresses.

I would contend that the first argument is a requirement on name resolution, not on addressing. If you can resove the name, the main drawback of the transition requirement is the possible instability of addresses. But 169.254.x.x addresses are in fact not very stable; they can be lost as the result of some form of collision. In a DHCP environment, the DHCP allocated addresses are in fact likely to be more stable, not less.

The second argument is really a requirement on routing, not address allocation. It is not necessary that hosts actually allocate a 169.254.x.x address to their interface, if they are capable of simply sending local ARP requests for 169.254.x.x. Similarly, nodes with only a 169.254.x.x address could easily send ARP requests for all addresses, since presumably they have only one interface and no configured router. Communication does not require address allocation.

We may debate whether building IPv4 devices that are not DHCP aware is a good idea -- I think not. But in any case the third argument is satisfied by the "liberal" part of my recommendation. If DHCP hosts accept to communicate locally with 169.254.x.x addresses, then the simple devices are not excluded.

We have established that having two addresses with different scopes is not neutral: it will confuse some applications. It is thus not reasonable to mandate that all hosts configure dual addresses on all interfaces. On the other hand, I just established that if a host is aware of the 169.254.x.x convention, then the host can in fact communicate with 169.254.x.x hosts on the link using a DHCP allocated address. In short, it suffices to be zeroconf aware to maintain connectivity; allocating a 169.254.x.x address is overkill. 

-- Christian Huitema

---

From: Brad Hards <[email-masked]>
Date: Sun, 12 Jan 2003 17:49:09 +1100

Think of it another way.
If you already have a connection to a host with IPv4LL address, and you become 
capable of gaining a routable address, it is better to add the routable 
address, not replace the IPv4LL address. Dumping a working address is 
gratitous breakage for a capable host.

I think you can have your cake, and eat it too, if you have the right level of 
support from your name service code.

Brad
- -- 
http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you?

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Jan 2003 09:24:06 -0500

On Sat, 11 Jan 2003 22:14:45 -0800
"Christian Huitema" <[email-masked]> wrote:

> 1) That if a server configuration changes, the clients will cease to
> function if they cannot find a server, i.e. resolve the server's name;
> 
> 2) That if  a node with only a DHCP configured address will not be able to
> communicate with a node that only have an autoconfigured address;
> 
> I would contend that the first argument is a requirement on name resolution,
> not on addressing. If you can resove the name, the main drawback of the
> transition requirement is the possible instability of addresses.

I disagree with this part. Not all apps are client/server (so other cases need
to be considered) and some applications find out addresses of their peers by
means other than name resolution.

Am generally in agreement with the rest of your message.

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Jan 2003 09:27:20 -0500

> Think of it another way.
> If you already have a connection to a host with IPv4LL address, and you
> become capable of gaining a routable address, it is better to add the
> routable address, not replace the IPv4LL address. Dumping a working address
> is gratitous breakage for a capable host.

depending on a particular app's requirements, a v4LL address might or might
not be considered "working".
 
> I think you can have your cake, and eat it too, if you have the right level
> of support from your name service code.

it is incorrect to assume that address selection can be performed by name
service code - first because apps get their addresses by a variety of means,
second because the name service code has no idea about the context in (or
purpose for) which an address will be used, third because this is overloading
an existing interface and will cause breakage for apps that expect the old
interface, fourth because it is poor separation of function.