CURRENT_MEETING_REPORT_ Reported by Susan Thomson/Bellcore Minutes of the Address Autoconfiguration Working Group (ADDRCONF) There were two sessions of the working group, both held on Tuesday afternoon, 4 April. These are the minutes of both meetings. Review and Discussion Susan Thomson reviewed the basic approach to address autoconfiguration in IPv6 as discussed on the mailing list December 94/January 1995 and refined at the interim meeting held at Xerox PARC in February 1994. The approach being pursued is to have two separate mechanisms: one to enable plug-and-play behavior and distributed control (the stateless scheme) and one to enable system administered, distributed control (the stateful scheme). The stateless scheme is under the purview of this working group. The stateful scheme is being addressed by the DHC Working Group in the form of DHCPv6. A question was raised about whether there need be only one stateful scheme, and in particular whether an alternative approach of having a node multicast to a DNS server to look up its address had been considered. There was some discussion about how this might work, but no decision to pursue this. There was general agreement that the stateless draft should not use language that mandates DHCPv6 as the only stateful mechanism that might be used. An overview was given of the host and router behavior resulting from a discussion at the XEROX PARC meeting, and since modified to include a mechanism by which hosts verify that the addresses formed are not duplicates of other addresses on the link. Open Issues The open issues were then listed and the group discussed each in turn: o Definition of Host Token At the XEROX PARC meeting, it was agreed that tokens would be link-layer dependent, and that in the case of networks with IEEE 802 addresses, these would be used. It was noted that a token for a particular interface need not necessarily be the MAC address, but only a number drawn from the IEEE 802 space that was unique per link. o Message types/lifetime semantics The current proposal has been to piggyback off the Prefix Information extension in Router Advertisements. The problem is that all extensions in a Router Advertisement share a single lifetime which is set very low (of the order of minutes) for the purpose of detecting when routers go down in a timely fashion. This lifetime is deemed too small for prefix advertisements, which are used in address autoconfiguration. The consensus of the working group was that separate lifetimes were needed. There was discussion of what the second lifetime should apply to, whether to only prefixes used to form addresses or to prefixes used in neighbor discovery as well, and what the performance tradeoffs were of having a separate message advertising the prefix versus having the information advertised in a separate extension of the Router Advertisement. The performance tradeoffs were considered a non-issue. Several folks felt that the address configuration mechanism should be separated from neighbor discovery mechanisms entirely. The rough consensus of the working group was to separate neighbor discovery prefix advertisements from address configuration advertisements and have them advertised in entirely separate messages. o Address deprecation and deletion The current specification says that an address should not be removed as long as it is being actively used for communication, or is listed in the DNS. There is currently no ``timeout'' on the deprecated state. An address could remain deprecated for a very long time. Some people felt that an explicit indication was necessary to definitively tell a node to stop using an address. It was suggested that the address prefix advertisements should carry a ``kill lifetime'' value as well as a ``deprecate lifetime.'' There was no final resolution on this issue. Another related issue raised was when it was safe to reuse the network prefix, given that the deprecated state may last a long time. o Duplicate address detection There is no guarantee that the token is unique, even if it is the node's link-layer address. It is considered sufficient to detect duplicate addresses, but not automate duplicate avoidance. On a node with multiple addresses, it is sufficient to verify just one address on initialization. The current draft of the specification outlines a mechanism for duplicate address detection. Many people thought that this feature was important enough to be needed in every system. The group agreed that this feature should be a ``must implement'' feature that must be enabled by default. o Further configuration indicator On a prefix advertisement, a bit of information is used to indicate whether the host should contact DHCP for other configuration information after forming an address using the stateless scheme. The working group agreed that this was a useful feature. o Allow for DHCPv6 server in routerless scenario It is currently defined that in the case where no router advertisements are being heard, a host must query for a DHCPv6 server so that hosts in a routerless topology still works. While this complicates the protocol somewhat, it was agreed that support for this topology is needed. Other John Veizades led a discussion on automatic address configuration for ``terminal server'' configurations. He would like the nodes served by the terminal server to be able to autoconfigure their addresses without having to configure a separate prefix per link. He suggested defining a separate field in the address to enable a terminal server to hand out unique addresses to all nodes based on its address. Other suggestions were to just make the terminal server a router, or assign the box a range of IEEE 802 addresses, one for each of its serial links. No decision was reached on this issue. Allison Mankin, in her role as Area Director, made a suggestion to separate the autoconfiguration mechanism (on which there is basic agreement) from the reconfiguration part (which is still experimental) into two separate documents to try to expedite progress of the documents. This generated a lot of heat. No consensus was reached at the meeting to do this.