CURRENT_MEETING_REPORT_ Reported by Susan Thomson/Bellcore Minutes of the Address Autoconfiguration Working Group (ADDRCONF) The ADDRCONF Working Group met once at the 33rd IETF on Wednesday, 19 July. (A second session had been scheduled, but the group finished all work before the end of the first session.) Sue Thomson lead the meeting. Specification Review Sue reviewed the changes made to the specification since the Danvers IETF meeting in April. This included the work done at the interim meeting of the working group that was held in July. The review brought up a couple of items for discussion: o In order to be usable by a host, the address prefix provided by the router must be short enough to accommodate the link-specific token. That is, the prefix must be equal to 128 minus the length of the link-specific token. The question was raised whether routers should be allowed to advertise prefixes that are shorter than the length required to accommodate the link-specific token, and have the host pad the gap with zeroes. It was argued that the configuration management interface on the router could zero-fill the prefixes just as well, and avoid situations where the same prefix with different lengths is advertised by a router. o Default values for the timers in the protocol were discussed. There was general agreement that the following values are ok: - Invalidate timer: infinity - Deprecate timer: one week Link Initialization Next, Sue walked through the steps of link initialization: 1. Form a link-local address. 2. Join the all-nodes multicast address. 3. Join the solicited-nodes multicast address. 4. Dither. 5. Send a neighbor solicitation for the link-local address. 6. Expect to receive solicitation looped back from the local network interface driver -- drop it when received. 7. Wait to receive packets. 7a. If second solicitation for the link-local address is received, another node is preparing to use that address (a duplicate has been detected). 7b. If a neighbor advertisement for the link-local address is received, another node is using that address (a duplicate has been detected). 8. Send a router solicitation. This lead to discussion of a number of issues: o Duplicate address detection. The specification includes a section explaining how a node can detect when an address generated using stateless address autoconfiguration is being used by another node. Some people felt that nodes should not be required to perform duplicate address detection since the failure case is quite rare and the cost to implement is non-trivial. Others argued that, while cases of duplicate addresses might be extremely unusual, they are extremely difficult for network administrators to diagnose and remedy when they do occur. After quite a bit of discussion, there was general agreement that duplicate address detection should be required for link-local addresses, and any address not based on the link-specific token. o Silently discard first duplicate solicitation. In the duplicate detection algorithm, a node is required to discard the first duplicate solicitation message for its own address that it receives. This is done because of the assumption that the network interface driver may loop back (deliver locally) the first solicitation that the node sends. Some people objected to this language, arguing that it was an implementation issue whether the driver loops back the solicitation packet. Others argued that the IP layer may not be able to disable the loopback at the driver level, so the safest thing to do is to enable loopback and expect one duplicate. o Serial-link hubs (e.g., PPP dial-in hubs). The issue of whether the specification should attempt to address the case of serial-link hubs was brought up. There was general agreement that this issue should be covered in the IPv6 over PPP specification document, and not in the address autoconfiguration specification. o Automatic resolution of duplicate addresses. The specification states only that a host should log the event when a duplicate is detected and stop using the address. Some suggested that the specification might be able to specify a mechanism by which the duplicate address could be resolved, allowing both hosts to continue functioning. But no proposal was offered for such a mechanism, so the group agreed to leave the specification as is. The Next Revision Finally, the group discussed whether the specification should be moved forward to Proposed Standard after another revision of the draft. It was agreed that the next version of the document should contain more explicit text on the interface initialisation procedure (perhaps in an Appendix). Also, the time that the host is determined to be in address validation mode needs to begin as soon as the host has formed its link-local address, rather than after first sending out the Neighbor Solicitation.