Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/94jul/addrconf-minutes-94jul.txt

Text File | 1994-11-01 | 6KB | 124 lines

Address Autoconfiguration BOF (ADDRCONF)

Reported by Susan Thomson/Bell Communications Research

A BOF was held in Toronto to discuss the charter of a proposed working
group for dealing with IPv6 autoconfiguration issues.  The meeting was
co-chaired by Dave Katz and Sue Thomson.


Scope and Timeline

Sue Thomson discussed the scope and timeline of the proposed working
group.  The intention is that the working group be short-lived with the
minimal purpose of specifying a host address autoconfiguration protocol
for use with IPv6.  The timeline must follow the aggressive schedule of
IPv6, i.e., protocol specifications should be available as drafts for
review in September, and be ready to be submitted as Proposed Standards
in December.  It is recognized that there is more to host
autoconfiguration than just address configuration and that attention
needs to be paid to easing configuration of routers as well.  However,
address assignment is the minimal configuration requirement (it is
conceivable that some hosts may not need more than this), and it was
argued that autoconfiguration of other information should be considered
outside of the scope of this working group, at least for now.  There is
also a need for cooperation with other working groups, such as IPv6
(system discovery) and DNS (which is investigating extensions to enable
autoregistration of addresses).


Architecture

Dave Katz presented a straw man architecture for address
autoconfiguration.  He started off with some new taxonomy.  In
particular, it was noted that an autoconfiguration mechanism requiring
minimal administration and state need not be ``serverless.''  A
``stateless server'' (a server that maintains no non-volatile state) can
also be used to provide automatic address configuration.  The term
``semi-autonomous'' (rather than serverless) was used to refer to a host
that forms an address from information known to the host, such as a
unique host ID, and information learned from an outside source such as a
network prefix advertised by a neighboring router.

The goal is to provide a single mechanism that enables host address
autoconfiguration with or without administrative control in a range of
networks, from small routerless networks to large globally attached
networks.  The basic requirements are that the mechanism must eliminate
the need for manual host configuration and support both initial address
assignment when bootstrapping and readdressing (when, for example, a
host's site changes provider and provider-rooted addresses are in use).
The mechanism should be deterministic to the extent feasible so that the
same address is assigned to a host whenever possible.

The basic elements of the presented straw man architecture is as
follows:  automatic address configuration is performed by a server.  A
stateless server meets requirements for fully automatic operation and a
state-based server for tight administrative control.  The argument
against allowing ``semi-autonomous'' operation as described above was
that hosts should be ignorant about routing and addressing structure in
order to avoid host dependencies on the routing paradigm, should it ever
change.  The exception to this design principle is that a host may form
an address usable only on the directly-connected subnetwork autonomously
by concatenating a well-known prefix with the host cookie.  This address
would be used during the bootstrap process to acquire an address with
wider scope from a server and when no autoconfiguration servers are
available.

A stateless server is normally co-located with a router.  The
presentation viewed stateless autoconfiguration as an integral part of
router functionality; there was an objection to doing this.  The basic
function of the server is to hand an address to a host for some period
of time, given a host identifier (cookie) and optionally a hint
regarding what the address should look like, e.g.  an IPv4 address if an
IPv4-compatible address is needed for transition purposes.  It was
initially proposed that the lifetime be fixed to a maximum of 65535
seconds (approximately 18 hours).  However, there was a strong consensus
that this limit was too small.  On receiving an address request from a
host, a server forms an address from the host cookie and the topological
information known to the router and returns this to the host with the
specified expiration time.

To enable tight administrative control, a stateless server may be
configured to forward address requests to a state-based server.  It was
noted by various people that this mode of operation is similar to that
of DHCP, but different to that of the initial SIPP address
autoconfiguration proposal which did away with relay agents by having
hosts automatically configure an address with intra-subscriber domain
scope.  The SIPP proposal, however, did not allow tight administrative
control on a per subnetwork basis which now appears to be requirement.

There was some discussion about which layer of the protocol stack would
be used to transport address autoconfiguration messages.  Three
alternatives were discussed:  UDP (compatible with DHCP, but requires
hosts to know a well-known port and is not necessarily appropriate for a
bootstrapping function), data link layer, in ICMP (may make most
architectural sense, but does mean that address configuration will be a
different protocol from that used for other configuration information
such as is now provided by DHCP). There appeared to be consensus that
ICMP should be used, with data link layer being the least preferred.

During the presentation, there were many questions, many trying to
anticipate what was to come.  Other pertinent points not mentioned above
include:


   o The mechanisms presented assume a host has an identifier that is
     unique at least within the subnetwork.  We need to consider
     point-to-point links where hosts have no cookie.

   o Security concerns must be addressed.  It was pointed out that
     addresses are not secret and can be typed in, so address
     configuration cannot be the basis for security.  Some sort of
     ``smart card'' device to authenticate a host/user is probably
     needed.


Next Steps

Sue Thomson agreed to get the BOF minutes done, and to draft a charter
for a proposed working group on host address autoconfiguration.  Dave
Katz volunteered to take a first cut at writing drafts of the address
configuration architecture and protocol specification.