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

From: Jim Busse <[email-masked]>
Date: Wed, 11 Jul 2001 12:08:39 -0700

Sturart and Thomas:

Thanks for the clarification.  I had thought about this several months ago,
so let me explain my conclusions from that thinking.

Device A could  join Device B's network.  In that case, the Device B could
have the manually configured address 10.0.0.1, which would mean that Device
B's network configuration is out of scope for Zero Configuration.  (After
re-re-reading the requirements doc, I can find no requirement for a Zeroconf
device to join a manually configured network installation).  Device B's
network may still be Zeroconf, but I think that means that somehow a 10.
configured DHCP server must have been available during the boot of all the
other devices on this network, and/or every device on Device B's subnet is
similarly manually configured.  (Still open is the case where this DHCP
server has died, after all the connections have been established, then we're
into a timing thing).  A work-around for Device A to be able to join Device
B's network is provided in sect. 2.3.1, where an app could listen to traffic
and make some scope choices available to the user of Device A

Device B could join Device A's network.  I would argue that in this case,
Device B has to release it's IP address.  This is as has been pointed out,
not the way the world works, but the world hasn't been very friendly at
providing easily configured networks, either.  My argument is that since
Device B has a manually configured address, it too is out-of-scope for
Zeroconf.  I don't have a work-around for this.

I think to bring this DeviceA/DeviceB  interoperation into scope would
require a change in the requirements document to indicate any
manually-configured device should (must?) be able to join a Zeroconf
network.  I think this isn't realistic.

Thanks for listening.

I still like the original wording

Jim Busse

 -----Original Message-----
From: 	Thomas Narten [mailto:[email-masked]] 
Sent:	Wednesday, July 11, 2001 6:28 AM
To:	Jim Busse
Cc:	Stuart Cheshire; [email-masked]
Subject:	Re: draft-ietf-zeroconf-ipv4-linklocal-03.txt 

Jim Busse <[email-masked]> writes:

> >   If the destination address is in the 169.254/16 prefix (including the
> >   169.254.255.255 broadcast address), the host MUST use its link-local
> >   source address.
> >
> >too strong?

> In my opinion, is no reason to change the wording to "should".  I think
the
> concept that the169/254/16 prefix packets are coming from a "friendly"
> link-local network, the use of some other address may look like an
> "intruder".  I like the original wording best.  Maybe Thomas could give a
> reason for the "too strong"?   

Stuart captured my concern precisely. Namely, if two nodes are on the
same link, and one uses a global address rather than a link local (it
might not even have a link-local address!), I don't think you want to
outlaw communication when there would seem to be no harm.

So, actually, I'm mostly OK with the above wording, since it basically
says if you can use a link-local address, you MUST. What I worry is
too strong, is saying you MUST drop packets if the src/dst addresses
are not both link-local. To make it absolutely clear, perhaps the text
"(if it has one)" could be added to the above text., i.e.:

   If the destination address is in the 169.254/16 prefix (including the
   169.254.255.255 broadcast address), the host MUST use its link-local
   source address (if it has one).

Thomas