Edits to draft-ietf-zeroconf-ipv4-linklocal-17.txt

During the "authors 48 hours" final review period we found various minor 
changes that needed to be made to the document. They are, in my opinion, 
typographical, grammatical, and editorial in nature, and none of them 
changes the technical content or intent of the document. Admittedly, 
there were a couple of glaring errors, like the description of passive 
mode ftp being completely backwards, but correcting those mistakes does 
not change the spirit nor the details of the protocol being specified.

In the interest of full transparency, we're informing the (ex) Working 
Group members on [email protected], so that everyone has the opportunity 
to see the (proposed) final document before the RFC editor publishes it, 
and comment if they find any errors. After so many years of work, we 
don't want to publish RFC 3927 with silly mistakes in it.

Below is a summary of the changes:

1. Various minor typographical nits (spurious extra spaces, spelling 
mistakes, "ad-hoc" and "adhoc" should be "ad hoc", error in ascii-art 
diagram, grammatically incomplete sentences, punctuation errors, etc.)

2. For most of the life of draft-ietf-zeroconf-ipv4-linklocal, the term 
"address conflict" was used exclusively, rather than "collision". However 
towards the end of the process some text was added that was inconsistent 
with this. Those have been changed back to "address conflict" for 
consistency with the rest of the document.

3. The terminology section introduces a very specific term "ARP Probe", 
but the term was not always written with a capital 'P' in all places.

4. Incorrect (or at least strange) text.

4a. Source and/or destination address

      IPv4 Link-Local addresses SHOULD
      only be sent when a Link-Local address is used as the source
      address.

should say:

      IPv4 Link-Local addresses SHOULD
      only be sent when a Link-Local address is used as the source
      and/or destination
      address.

4b. The host SHOULD use a routable...

   The host SHOULD use a routable address in preference to an IPv4
   Link-Local address except for communication to peers for which the
   host has an existing TCP connection at the time in which the host
   obtained a routable address configuration.

This says that if a host has *any* existing TCP connection to a peer,
then it can use it's LL address in preference to its routable address in
*all* future UDP or TCP communication with that peer. Is that what it 
meant to say? No. The new text says:

   Where both an IPv4 Link-Local and a routable address are available
   on the same interface, the routable address should be preferred as
   the source address for new communications, but packets sent from or
   to the IPv4 Link-Local address are still delivered as expected. The
   IPv4 Link-Local address may continue to be used as a source address
   in communications where switching to a preferred address would cause
   hardship to a specific upper-layer activity (e.g., an existing TCP
   connection). For more details, see Section 1.7.

4c. Set the IPv4 TTL to 1?

   A sensible default for applications which are sending from an IPv4
   Link-Local address is to explicitly set the IPv4 TTL to 1.

This would be *REALLY* bad advice to put in the document.

Inexperienced application writers would take this to mean that if they
want their application to work with IPv4LL, then they should (to quote
the *exact* words of the document) "explicitly set the IPv4 TTL to 1".

I foresee developers making a home networking product, and because they 
want it to work with IPv4LL, they will follow the advice of the RFC and 
use a setsockopt() call to explicitly set the IPv4 TTL to 1. When they 
test their software or device in the target environment, it will work 
fine, and they will ship it that way. Unfortunately, when you or I buy 
this device, any attempt to communicate more than one hop away will fail, 
even if the device has a perfectly correct routable address -- because 
the developer explicitly set the IPv4 TTL to 1, as mandated by this 
document. D'oh!

There's an ironic own-goal here. The same people who were opposed to 
IPv4LL because it would encourage the creation of devices that work only 
on the local link, shot themselves in the foot by allowing text in the 
document that will cause the very failure they wanted to prevent.

This text has been removed. The advice to set the TTL to 1 may be 
applicable to OS vendors making TCP/IP stacks, but not to application 
writers.

4d. Passive mode ftp

   For example, FTP [RFC959] passive mode
   transmits the IPv4 address of the client.  Assume a client starts up
   and obtains its *passive* IPv4 configuration at a time when the host
   has only a Link-Local address.  Later, the host gets a global IP
   address configuration (for one of its interfaces).  The client uses
   this global IPv4 address to contact an FTP server off of the local
   link for which it had (or still has) an IPv4 Link-Local address
   configured.  If the FTP client transmits its stale out-date passive
   IPv4 configuration to the FTP server, the FTP server will be unable
   to reach the FTP client.  The passive FTP operation will fail.

This was completely backwards. Passive mode ftp DOES NOT suffer the 
failure described; it is active mode ftp that has a potential failure. 
New text:

   For example, FTP [RFC959] (when not using
   passive mode) transmits the IP address of the client. Suppose a
   client starts up and obtains its IPv4 configuration at a time when
   it has only a Link-Local address. Later, the host gets a global IP
   address, and the client contacts an FTP server outside the local
   link. If the FTP client transmits its old Link-Local address instead
   of its new global IP address in the FTP "port" command, then the FTP
   server will be unable to open a data connection back to the client,
   and the FTP operation will fail.

---

The first version of RFC 3927, as it originally came from the RFC editor 
for review, can be fetched from:

<http://files.zeroconf.org/rfc3927old.txt>

The revised version can be fetched from:

<http://files.zeroconf.org/rfc3927new.txt>

The changes, in "diff -u" format, can be fetched from
<http://files.zeroconf.org/rfc3927diffs.txt>,
or you can get the old and new for yourself and compare them using the 
"diff" tool of your choice.

The lines in rfc3927new.txt are intentionally NOT re-wrapped to 72 
characters, because that has the potential to turn a one-word change into 
a one-paragraph diff. The RFC editor will re-wrap the lines and 
repaginate as necessary before publication.

Stuart Cheshire <[email protected]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org