Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt

From: Stuart Cheshire <[email-masked]>
Date: Wed, 11 Jul 2001 15:25:13 -0700

>If a link-local device has only 169.254/16 in its admittedly
>small routing table, won't it just look at the 10/8 address and
>decide there's no route to that network? There's no default
>route, and no way for it to know that it should try to ARP for
>that 10/8 address. So, it still won't communicate.

Or, hosts with only an LL address could run in "ARP for everything" mode.
In fact, this is exactly what shipping Mac OS systems do today.

>This box with the configured address would not know to ARP for
>the link-local address on the local wire, though, if it's only
>configured for non-link-local. I think any change in this area
>would require touching most hosts code to ensure compatability.

So you're saying that it might not work with some of today's hosts.

Is that a reason to outlaw it from *ever* working?

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

---

From: Aidan Williams <[email-masked]>
Date: Thu, 12 Jul 2001 10:52:59 +1000

> In fact, this is exactly what shipping Mac OS systems do today.

Very simple systems may not even need to ARP.  Packets arriving
will contain the relevant MAC address and could be turned around
fairly simply in order to respond without ARPing, or even consulting
routing tables.

> Is that a reason to outlaw it from *ever* working?

Personally, I think not.

It seems that the IPv4LL document as it currently stands encourages
multiple IP addresses per interface (169.254/16 and "the other one").
Another host could choose to use IPv4LL only.  In the event that
the multihomed host selects the "wrong" source address when communicating
with the IPv4LL host, the world doesn't have to stop and shouldn't be
required to.

regards
	aidan
____
:wq!

---

From: Daniel Senie <[email-masked]>
Date: Wed, 11 Jul 2001 22:48:45 -0400

>In fact, this is exactly what shipping Mac OS systems do today.

So the MAC runs with 169.254/16 addresses, but a /0 netmask so that it can 
arp everything? Interesting. Not a bad idea. Guess we should be asking 
whether the link-local draft should mention this as an option. My comments 
above were predicated on the belief that the netmask would be /16, as other 
systems seem to do (Windows, for example). Perhaps we should encourage the 
switch to /0?

>Is that a reason to outlaw it from *ever* working?

Perhaps we should encourage it instead? I suspect we'd need to adjust the 
document a bit, though. If we're going to talk about 169.254/16, we tend to 
imply the netmask be set to /16. I'm willing to consider Apple may have a 
better idea here. Let's see what other folks think.

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