Dynamic Configuration of IPv4 Link-Local Addresses
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, zeroconf mailing list <firstname.lastname@example.org>, zeroconf chair <email@example.com> 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.