INTERIM_MEETING_REPORT_ Reported by Susan Thomson/Bellcore Minutes of the Address Autoconfiguration Working Group (ADDRCONF) The ADDRCONF Working Group held an interim meeting at Sun Microsystems in Menlo Park, California on 13-14 June 1995. Specification Overview and Discussion Sue Thomson presented an overview of the latest specification, particularly how it ties in with the latest Neighbor Discovery draft, and raised open issues. Addrconf information is advertised in Router Advertisements. In particular, there are flags in the fixed part of the Router Advertisement that indicate whether stateless or stateful mode is in use for address and other configuration parameters. The Prefix Information extension (which is also used by prefix discovery) contains the necessary information for obtaining and timing out prefixes, and addresses formed from those prefixes. On receiving Router Advertisements with a Prefix extension, the host updates its address list, adding any new addresses formed from new prefixes advertised, and resetting the lifetime of addresses formed from prefixes that are being readvertised. In the latest draft, two lifetimes are advertised per prefix: one to specify when addresses change from being valid to being deprecated, and one to specify when addresses changed from being deprecated to being invalid. The intention of the two lifetimes is to allow a graceful transition period during renumbering. That is, the deprecation time warns the host that an address is going to become invalid (the invalidation time must be no less than the deprecation time) and that the host should start using another (presumably longer lasting) address in new communications to minimise the risk of breaking communications when the old times out. The idea is to make the deprecation period long enough so that most, if not all, communications have switched over to using the new address by the time the old one becomes invalid. There was concern about application impact of deprecated addresses. However, all the specification intends to specify is some mechanism that enables an application (perhaps with the help of the network layer) to choose an address at the start of a communication that is likely to last for the duration of that communication, so that the problem of renumbering during a communication is avoided to the extent possible. There was a suggestion that protocols should be designed so that communications can survive address changes and so that deprecation is not needed. However, it was argued that this is not a problem that is likely to be solved soon and that the above is a reasonable compromise at this time. There was some discussion about how much to specify with respect to default source address preferences. It was clear that this is a slippery slope and that things quickly become complicated. The resolution was to simply specify that valid global/site-local addresses are preferred over deprecated addresses in choosing a source address for new communications, assuming there are other valid global/site-local addresses to choose from. It should be noted that there will always be at least one valid address to choose from, the link-local address. However, the rules should allow a deprecated address to be used if only the link-local is valid and the destination is (possibly) off-link. It is possible for hosts to get address and other information, such as MTU and hop limit, using both stateless and stateful mode. It is also possible that both stateless and stateful mode are configured to be on at the same time. There was some discussion about how much to specify with respect to the advertisement of conflicting information. (It is also possible for multiple routers to hand out conflicting information, e.g., the same prefix could be advertised with different lifetimes.) The implication of the current specification is that 1) the host accepts the union of all information received from all sources and 2) if conflicting information is received from different sources, the host will just update its state with the latest information received, i.e., there are no special rules for giving preference to one or the other. It was decided that this should be left as is, but such events may be logged. It was also decided that in the Neighbor Discovery (ND) document the router advertisement should be sent to the ``all-nodes'' multicast address, rather than the ``all-hosts'' address so that routers could discover and log that they had been configured to hand out conflicting information. Hosts are expected to attempt stateful autoconfiguration when no routers are detected on the link. It was suggested that we only do this on startup, since the need to do this at other times is rare. Default lifetimes for prefix advertisements were not specified in the current specification, the intention being to force system administrators to configure the lifetimes specifically since the lifetimes are expected to be environment-dependent. It was suggested that defaults should be set, but that they be very conservative, e.g., a deprecation lifetime of several days (longer than a long weekend) and an invalidation time of infinity. The value of infinity needs to be specified in the specification. There was agreement as to the transition between stateless and stateful configuration as outlined in the specification. An overview of the duplicate address detection algorithm was presented. It was agreed that there would be one change to the soliciting node part of the algorithm when the node is validating its address. Since inhibiting local loopback on sending out multicast packets is not always supported, it was agreed that the neighbor solicitation to detect a duplicate address must always be looped back. A duplicate address would then be detected if more than solicitation is received by a host. It was also noted that the IPv6 multicast document needs to be written and the local delivery requirements clarified. It was also agreed that if the stateful mode is being used to acquire addresses and these addresses are not the same as those that would be configured using the stateless mode, then the duplicate address detection algorithm should be applied to these addresses too. It is now defined that hosts should randomise their delay both before embarking on the duplicate detection algorithm (addrconf specification) and when sending a Router Solicitation (ND specification). If a host does both on initialisation, dithering is only necessary once and should be specified as such. This needs to be cleaned up. There was some discussion about how much space should be available for storing prefixes and addresses. There was a strong suggestion that hosts should be able to accept all advertised prefixes, and complain if not. The issue of whether addrconf information should be defined as part of Router Advertisements or advertised separately was discussed. It was noted that addrconf processing needs to be done as often as prefix processing and needs similar information so why not advertise together. Also, that Router Advertisements have been designed to advertise a range of information, not only that needed for router discovery, e.g., it is used to advertise other configuration information such as MTU and hop limit. There is, however, a demultiplexing issue -- folks felt that many implementations did this already for ICMP messages, and for those implementations that did not, new software needs to be written in any case, so this should not present a problem. The consensus of the group was to maintain the current approach, with further discussion to be done on the mailing list. In addition, there were several suggestions to add clarity to the document: o Provide more rationale for the concept of deprecated addresses. o Change the name or acronym of the Administered flag (M flag) in Router Advertisement. The alternative suggestion was ``Managed.'' o Make interface initialisation procedure more explicit. At the moment, the various functions that need to be done are not spelled out in order in one place. o Clarify the relationship between the network and upper layers in choosing source addresses in new communications. o Need to clarify use of ``hardware address'' vs. use of ``MAC address'' as tokens. The link-specific part of the document will be moved to ``IP-over-foo'' documents, yet to be written.