Re: LL63

It is true that the additional paragraph doesn't make much sense:

"  Several early implementations of IPv4 Link-Local have modified the
   DHCP  state machine in an attempt to make IPv4 Link-Local more
   reliable, and the  field experience we have gained from this has
   shown that it does not work  - reliability of DHCP service is
   significantly reduced.   If increased reliability of IPv4 Link-Local
   is desired, we recommend that the IPv4 Link-Local state machine track
   the DHCP client state machine and, in cases where it is not certain
   that the DHCP-assigned address is correct, the  IPv4 Link-Local state
   machine acquire an IPv4 Link-Local address without causing the DHCP
   state machine to relinquish its address."

Appendix A provides several examples of behavior that is not conformant
with RFC 2131 in *both* MacOS and Windows.  So saying that the DHCP state
machine was modified is correct, although it seems somewhat odd
to attribute this to an "attempt to make IPv4 Link-Local more reliable";
more likely it came out of a desire to reduce address assignment delays.

Advising that the IPv4 Link-Local state machine track the DHCP state
machine seems strange at best.  It does make sense to assign an IPv4
Link-Local address early on (which addresses the assignment time issue),
but there is more to this than is described here, so it's best to leave it
out.

Here is a proposed fix:

"As documented in Appendix A, early implementations of IPv4 Link-Local
have modified the DHCP state machine.  Field experience shows that
these modifications reduce the reliability of the DHCP service.

A device that implements both IPv4 Link-Local and a DHCPv4 client
should not alter the behavior of the DHCPv4 client to accommodate
IPv4 Link-Local configuration. In particular configuration of an
IPv4 Link-Local address, whether or not a DHCP server is currently
responding, is not sufficient reason to unconfigure a valid DHCP
lease, to stop the DHCP client from attempting to acquire a new IP
address, to change DHCP timeouts or to change the behavior of the
DHCP state machine in any other way.

Further discussion of this issue is provided in [DNAv4]."

-------------------------------------------------------------------------
Examples of non-conformance to RFC 2131:

A.1:

"   Mac OS sends nine DHCPDISCOVER packets, with an interval of two
   seconds between packets. If no response is received from any of these
   requests (18 seconds), it will autoconfigure."

"   Autoconfigured Mac OS systems check for the presence of a DHCP server
   every five minutes. If a DHCP server is found but Mac OS is not
   successful in obtaining a new lease, it keeps the existing
   autoconfigured IP address. "

A.2:

"DHCP sends two packets, with timeouts of one and
   two seconds.  If no response is received (three seconds), it begins
   autoconfiguration.  DHCP continues sending packets in parallel for a
   total time of 60 seconds."

"   If DHCP is not successful, it waits five minutes before starting over
   again.  "

A.3:

"   When in INIT state, the Windows 98/98SE DHCP Client sends out a total
   of 4 DHCPDISCOVERs, with an inter-packet interval of 6 seconds.  When
   no response is received after all 4 packets (24 seconds), it will
   autoconfigure an address."

"   Autoconfigured Windows 98/98SE systems check for the presence of a
   DHCP server every five minutes."

A.4: