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.