Subject: 4. Does OS X currently assign both LL and global address at the same time?

From: Stuart Cheshire <[email-masked]>
Date: Thu, 6 Feb 2003 02:29:51 -0800

Several people have asserted that OS X currently does not assign both LL 
and global addresses at the same time, and have gone on to conclude from 
this that the LL spec should not encourage (or even allow) a host to have 
both LL and global addresses at the same time, because there is no 
operational experience of this behaviour.

The initial assertion is false (and, unavoidably, that means that any 
conclusions drawn from this incorrect assertion are also suspect).

To see this for yourself, do the following:

1. Open the Network Control Panel and make sure that both Ethernet and 
AirPort are enabled. Make sure that Ethernet is listed first as the 
preferred interface, and AirPort second. Make sure that both are set to 
"DHCP".

2a. Join an active working wireless network, so that your AirPort 
interface obtains a routable address via DHCP.

2b. Verify that you can browse the web, etc.

3a. Directly connect some kind of Rendezvous device (another Mac, 
Rendezvous network camera, Rendezvous network printer, etc.) to your Mac 
using an Ethernet cable. There being no DHCP server on this Ethernet 
cable, both the Mac and the other Rendezvous device will self-assign 
link-local addresses on this link.

3b. Verify that you can communicate usefully with this Rendezvous device 
(e.g. print a web page on the Rendezvous printer).

Result: Macs today *do* assign both LL and global addresses at the same 
time, and furthermore, doing this enables useful end-user functionality.

Implications of this:

1. Applications having to deal with LL and routable is not a new thing 
introduced by the draft. It is with us today. In this example the 
addresses were assigned on different interfaces, but the implications for 
application software running on that host are substantially the same as 
if both were on the same physical interface.

2. Applications having to deal with addresses with different reachability 
is not a new thing introduced by IPv4LL. It is with us today. In the 
above scenario, we could have attached a DHCP server to the Ethernet 
link, and it could have assigned 10.0.0.2 to the Mac and 10.0.0.3 to the 
printer. In that case there would be no IPv4LL addresses involved, but 
any applications running on the multi-homed host would still have had to 
deal with the fact that the machine had an address 10.0.0.2 which was 
useful for communicating with the printer, but had no useful 
applicability outside that physical link.

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