Dynamic Configuration of IPv4 Link-Local Addresses
RFC 3927

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    zeroconf mailing list <zeroconf@merit.edu>, 
    zeroconf chair <zeroconf-chairs@tools.ietf.org>
Subject: Protocol Action: 'Dynamic Configuration of Link-Local 
         IPv4 Addresses' to Proposed Standard 

The IESG has approved the following document:

- 'Dynamic Configuration of Link-Local IPv4 Addresses '
   <draft-ietf-zeroconf-ipv4-linklocal-18.txt> as a Proposed Standard

This document is the product of the Zero Configuration Networking Working 
Group. 

The IESG contact persons are Thomas Narten and Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-ipv4-linklocal-18.txt

Technical Summary

This specification serves three important functions.  First, it documents
the IPv4 Link-local autoconfiguration protocol as shipped by Microsoft and
Apple in popular operating system releases since 1998.  Second, it offers
definite rules for how this protocol should operate in the future.  This
differs in particular ways from the code which Apple and Microsoft have
implemented.  The changes come from experience with the existing implem-
entations as well as Working Group assessment.  Third, a set of unsolved
issues are called out for implementors - focussing on use of Link-Local
configuration for multihomed hosts.

It is important for this specification to be issued as a standard as
soon as possible since the number of non-standard implementations are
multiplying.  In particular, some implementations make assumptions
about the setting of the "TTL" of packets sent by hosts which are
incompatible with the recommendation set by the specification
supported by IETF WG consensus.  The longer we wait, the less
interoperation we will see in practice.  It is not a question of
adoption: This protocol is already widely adopted.  We must prevent it
from further mutations.

The current version of this protocol will not break existing
implementations with the one exception.  Those implementations which
assumed that all datagrams would be sent with a TTL of 255 in order to
drop incoming messages with TTLs not equal to 255 will not properly
interoperate with hosts which implement the current specification.
The TTL filtering feature appeared roughly at draft 3 and was removed
as of draft 9 of this protocol specification.  Most existing
implementations and all existing Windows implementations interoperate
with the current specification.

It is important to note that there are differences between the current
version of this protocol and those implemented and deployed on Apple
and Microsoft platforms.  The current version of the protocol is
documented in this specification, as well as the deployed versions of
the protocol.

Working Group Summary

Working group consensus has been slowly achieved through many contentious
and laborious discussions.  Several issues arose which were only decided
by compromise:  Avoiding a 'solution' for multihomed problems, requiring
that advertisements of link local addresses cease once routeable address
configuration exists, omission of special 'faster timers' text and other
areas.  The consensus, while rough, expresses the end result of years of
exacting scrutiny of this document by several reviewers.

Protocol Quality

The basis of this protocol has been deployed on millions of hosts.  The
modifications to the protocol are quite minor and have received a very
high degree attention during the critical review phase.

This protocol has been reviewed for the IESG by Thomas Narten.