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

From: Stuart Cheshire <[email-masked]>
Date: Tue, 8 Feb 2005 22:59:39 -0800

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-masked], 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-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

---

From: Robert Elz <[email-masked]>
Date: Wed, 09 Feb 2005 15:45:32 +0700

Date:        Tue, 8 Feb 2005 22:59:39 -0800
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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.

I think that one is actually a technical change, but I see no reason
not to make it, except perhaps that it isn't what the WG approved.

  | 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,

Yes, I guess that it is possible to imagine that someone may be so
stupid as to read the text that way, though I doubt anyone would
actually ever do it.   Correcting that is (just) reasonable, but ...

  |    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.

This is not an acceptable replacement.   "cause hardship" ??   What on
earth does that mean - "I'd have to execute an assignment statement,
that's a hardship, so I won't do it".   Let's remain a little more in
keeping with the intent of the text that was agreed.

Replace the 4 lines quoted above with (a spelling checked version of...)

	IPv4 Link-Local address may continue to be used as a source address
	in communications where switching to a preferred address would
	cause communications failure because of the requirements of an
	upper layer protocol (e.g., an existing TCP connection).
	For more details, see Section 1.7.

(to readers of this message, note that that text begins in the middle of
a sentence.)

  | 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.

This is definitely a technical change, and totally inappropriate at this
stage.

  | 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".

Yes, so they can, and provided they note the exact words of the
document "sending from an IPv4 Link-Local address", what they're
doing is just fine.    If they keep the TTL at 1 when sending from
a routable address (to other than a link-local address), that's
simply a bug (one which, incidentally, I cannot imagine surviving
even the most rudimentary of testing by the implementor).

  | 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.

I foresee developers doing all kinds of crazy things, but I won't change
the specifications to attempt to handle them all.   People are idiots,
almost all of us, we know that - and we know we do things incorrectly.
Eventually we also fix our mistakes (most times).

  | 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.

Put the text back.   Deleting this was a decision the working group could
have made when the document was under discussion, but there is no longer a
working group to approve any change like this (and I kind of doubt it would
have been approved anyway).

No problems with any of the other changes.   Or perhaps I should say,
given that they're made, they're OK - on the other hand, if someone had
asked *me* to actually make some of the meaningless editorial changes that
have been made, I'd not have been happy at all...

kre

---

From: John Schnizlein <[email-masked]>
Date: Wed, 9 Feb 2005 12:00:21 -0800

The 48-hour edit period is not the right time and place to reverse a 
contentious decision that went back and forth for some time before it 
was settled.

John

On Feb 8, 2005, at 10:59 PM, Stuart Cheshire wrote:

> changes that needed to be made to the document.
...
>    ...
> This text has been removed.

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Wed, 9 Feb 2005 20:53:10 +0000

Hi Stuart, folks,
   The A48 is not the place to correct any technical oddities remaining 
in a document
after the WG *and* the IESG have worked on it.
 From what I've read, this text and the whole document reflects the 
opinion and level
of understanding of the majority of the WG. I'm sure you would have 
heard if this
were not so. Thus, please let the pain stop - put it back and get the 
RFC "out the door".

Conversely, in keeping with your explanation/rationale, I trust that 
Apple will
interpret this *suggestion* to the best interest of its customers, as 
always.

all the best,
   Lawrence