CURRENT_MEETING_REPORT_ Reported by Susan Thomson/Bellcore Minutes of the Address Autoconfiguration Working Group (ADDRCONF) Sue Thomson presented, as part of the agenda, a list of open issues that needed to be addressed in the current draft. These issues formed the basis for discussion in two of the three sessions. In the first session, Dave Katz presented an overview of the current draft during which some of the above issues and a few others were raised. The minutes are structured by issues discussed. Formation of Local-use Address There was a suggestion that the term local-use address be renamed. The term is used in the current draft to mean an address of intra-link scope. One name suggested was local link address, but there was no agreement to use this. A network prefix needs to be defined for this type of address. There must be one way of forming this address given a particular link type. In the case of IEEE 802 addresses, this is done by concatenating a well-known network prefix with the IEEE 802 address. How to form an ATM address was left as an open issue. There were no objections to the current proposal for assignment on point-to-point links. Formation of Stateless Address There seemed to be a feeling that more than one algorithm for forming an address should be possible per link type. Matt Crawford, for example, presented a scheme that hashes on a host token to produce a shorter host part for the address. It was unclear what mechanisms could be used to ensure uniqueness in stateless mode. It is necessary that the various algorithms be defined, given certain parameters. At the least, there should be a standard mechanism for forming an address which all servers must implement. In the case of IEEE 802 addresses, an address is produced by concatenating an 80-bit network prefix with the IEEE 802 address. There was some debate about whether there should be a default mode of operation to ensure that two servers use the same mechanism for forming an address by default. The group decided to define a default, in order to ensure that two servers assign unique addresses in plug `n' play operation. There was a suggestion that there should not be a stateless mode at all. Relationship Between Address Lifetime and Holding Time Currently the holding time is really just a refresh interval, rather than a tight bound on how long the address may be used by a host. The question was raised whether the holding time should be allowed to also specify a tight bound on an address so that address reuse can still be supported by the protocol. While this is not an issue for the stateless mode, it is an issue for the stateful case. The resolution was to leave the draft as it stands. The question was raised as to what to do with incoming messages if an address is not refreshed, but not explicitly invalidated. The thoughts were to refuse subsequent connections, and accept UDP. Protocol Usage (Link Layer versus ICMP versus UDP) The argument for sending address assignment requests at the link layer is that the host needs to form a temporary address in order to get a permanent address. This was called ``aesthetically bogus.'' It was pointed out that this would mean a separate protocol per link layer. In IPv4, UDP is not required. A suggestion to use ICMP for the front-end protocol and UDP for the backend protocol did not receive much support. It was agreed that the same protocol should be used for both front-end and back-end. After a little discussion, a consensus was reached not to use link layer. After much discussion, ICMP was chosen by the flip of a coin. Other Useful Parameters to Address Assignment Request There was a quick consensus that the specification needs to be clearer on parameters used for each interface type. There was a feeling that the domain name may be a useful parameter (e.g., to disambiguate when host tokens are not guaranteed to be unique), although it was not clear when it would be used. There was a suggestion that there be a field in the address reply that indicated what method was being used by the server for address assignment. This might be useful for network management. There was no agreement to add this. Server Advertises or Host Retries? How do you know when a server comes up: server advertises or host retries? It was suggested that servers advertise in the manner of routers creating router advertisements. However, this does not scale in stateful mode. There was a discussion of renumbering: servers say when to renumber by sending ``Hello'' messages to tell hosts when to re-request address. The problem with this is that servers are duplicating a function that is already present in routers which means it must be ensured that information advertised is properly synchronized. It was suggested that address configuration be a router function for simplicity. Addrconf and Determinism There is a strong requirement that address requests produce the same results, given the same input parameters. There was a suggestion that this be a mandatory requirement. This is important to keep in mind since protocols have been designed on the assumption that host addresses remain constant, e.g., DNS and SNMP MIBs. Addrconf and DNS Autoregistration of Inverse Mapping When DNS is in use, there is the question of which entity updates the inverse mapping in DNS. The host may not always have the authority to do so. Two alternatives were suggested: the addrconf server could do so on the host's behalf since it can validate that the address being registered is indeed the one assigned to that host (or at least has the right prefix). The second alternative was to have the server reply with credentials that the host could pass on to prove that the update is valid. It was unclear what the security implications of the latter approach was. The current draft specifies the first alternative above, in which the DNS autoregistration is done as a byproduct of each address assignment. Having autoregistration be a byproduct of the assignment operation could be problematic for several reasons, one of which is that DNS updates need only be done when a new address is handed out, not on every refresh. Also, the DNS update should be done asynchronously so that successful address assignment is not prevented if DNS is unavailable. There was some agreement that the host should drive the registration process (whether through the server or otherwise) and that the address assignment operation should be separate from the registration operation. This does introduce overhead for hosts attached to links where latency is an issue, though. So, the capability for doing both in a single request may be desirable. Also, the reply to an address request should indicate to the host whether to register the address through the server or not. There were a couple of strong statements to the effect that address autoconfiguration should not rely on the DNS dynamic update mechanism being implemented. There is parallel effort, however, in the DNSIND Working Group to specify such an extension to DNS. Relationship Between Addrconf and DHCPng There is other information that may need to be autoconfigured besides the address including a domain name and protocol stack parameters. It is the intention that DHCPng will provide this information. [Note that having DHCPng perform stateful address configuration and having the addrconf protocol perform only stateless address configuration has subsequently come under consideration.] The addrconf protocol should indicate to the host in a reply to an address request whether it needs to consult DHCPng for further information. Advanced Dentist's Office Scenario In this configuration, two links are connected by a multihomed host. No router is present. It is possible that, if the host tokens used to form an address are only defined to be unique on a link the addresses formed with intra-link scope are not unique. The suggestion was to manually configure a server in the multihomed host with a different network prefix per interface. ``Anonymous'' Addresses The need was mentioned for the address assignment request to return an address even if no host token was provided. This is for hosts that do not have a token or do not care that the same address be handed out each time an address needs to be assigned. There was not agreement that such a function was needed.