TUBA Working Group                                             Dave Katz
INTERNET-DRAFT                                             cisco Systems
<draft-ietf-tuba-addr-assign-00.txt>                          March 1994


        Dynamic Assignment of OSI NSAP Addresses in the Internet


Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any Internet
   Draft.


Abstract

   There are currently two mechanisms defined for dynamic assignment of
   OSI NSAP addresses.  This memo specifies a single mechanism for hosts
   to use that maximizes flexibility while allowing administrative
   control, and requires no configuration on the host.

   The method described in the memo is intended to be implemented
   universally in all end systems supporting CLNP, both for TUBA [1] and
   pure OSI systems.  This document will be submitted to ISO for
   consideration as a standard.  Additionally, the method described
   could also be used in CATNIP [2] networks.


1. Passive Address Assignment

   The first method of dynamic address assignment, which I shall call
   the "passive" method, was first implemented by DEC Phase V end
   systems.  In this scheme, when a host is first initialized, it
   passively listens on its local subnetwork for ES-IS [3] Intermediate
   System Hello (ISH) packets.  When it hears one, it performs surgery
   on the network address it finds therein, replacing the system ID of
   the router with a globally unique value found in a ROM (typically the
   MAC address of one of its interfaces), and claims the resulting
   address as its own.  It then emits End System Hello packets,
   notifying routers of its choice.  If no ISH is heard, the host will
   choose an address consisting of AFI 49 ("local") followed by its
   unique value.

   This method has the advantage that it is allows the host to be
   completely autonomous, requiring no additional protocol to be
   defined.  It has at least a couple of weaknesses, however.  First of
   all, it allows no administrative control over the choice of address
   (or whether to allow one to be assigned at all!)--some network
   administrators do not take kindly to machines popping up on their
   networks willy-nilly and becoming full-fledged, globally reachable
   network entities.  Secondly, if there are multiple area addresses in
   use in the area, or if the LAN is a level-2 circuit, the host will
   hear multiple area addresses, and is faced with some ambiguity over
   what its address should be.


2. Active Address Assignment

   In response to the need for address assignment, and in recognition of
   some of the problems with the passive approach, ISO defined Addendum
   1 to the ES-IS protocol [4], providing a mechanism for address
   assignment.

   Unlike the passive method, the ISO standard method uses a
   request/response model, putting the decision over address assignment
   in the hands of the address assignment entity, rather than the host.
   In this scheme, the host multicasts a Request Address (RA) packet
   (consisting of only a basic ES-IS packet header), and the address
   assignor replies with a unicast Assign Address (AA) packet containing
   the network address that the host should use.

   A proposed extension to this protocol [5] gives the host the ability
   to suggest a system ID to the assignor, allowing the host to provide
   some other bit of a priori information to the algorithm (such as an
   IP address in a dual-stacked TUBA host).

   If the host does not receive a response to its Request Address packet
   after a reasonable number of attempts, the standard specifies that
   the host should assign itself an address consisting of AFI 49
   ("local") followed by one of its subnetwork addresses, which allows
   the host to communicate on its local subnetwork only.


3. The Dilemma

   Each of these approaches has its advantages.  Probably the biggest
   advantage to the passive approach is that it can work today without
   any help from the routers (especially since the active approach is
   not widely implemented as yet).  To make the active approach
   mandatory would mean that some end systems could not do automatic
   address assignment, a situation that we want to avoid.  However, the
   passive approach does not lend itself well to administrative control
   or to more clever approaches to address assignment.


4. The Address Assignment Process

   The goal is to have a *single* mechanism specified for implementation
   in the hosts, such that it could be implemented today in a way that
   provides the advantages of both methods without requiring any manual
   configuration.  The mechanism works as follows:

   The host first sends ES-IS Request Address packets.  It may
   optionally add the Suggested System ID option defined in [5] if it
   wishes to influence the system ID portion of the assigned address.
   If an Assign Address packet is received, the host uses the address
   carried therein according to the ES-IS standard.  When the holding
   time on the assigned address is in danger of expiring, the host shall
   perform the address assignment process again.

   If no Assign Address packet is received after a number of tries, the
   host falls back into the passive approach.  It builds its own network
   address by taking the address of a router (as announced in an ES-IS
   ISH packet) and putting one of its subnetwork addresses, or some
   other value known to be unique within the IS-IS area, into the system
   ID portion of the address.  The host shall choose a holding time not
   to exceed 65535 seconds for this assignment, and shall perform the
   address assignment process again should it choose to continue to
   communicate after the holding time expires.  The host shall not
   continue to use the self-assigned address after the holding time
   expires.

   If no ISH packets are received within a reasonable amount of time,
   the host shall construct a network address by using AFI 49 and
   concatenating its subnetwork address or other value known to be
   unique on all attached subnetworks.  The host shall choose a holding
   time and adhere to the rules specified in the previous paragraph.

   If an ISH is heard after the host has assigned itself a local
   address, and the host desires connectivity beyond the local
   subnetwork, the host may choose to perform the address assignment
   process at any time.

   Note that the host may choose to invoke the address assignment
   process at any time;  in particular, to avoid loss of connectivity,
   it is recommended that the address assignment process be performed
   prior to the expiration of the holding timer.


5. Administrative Issues

   It may be desirable to control the access of newly-attached hosts.
   In particular, for administrative purposes, it may be desirable to
   not allow global internetwork access to and from a host for some
   period of time (for instance, when a new system is first connected).
   Note that simply ignoring the Request Address packets will not have
   the desired effect, since the host will perform the passive
   assignment method and simply give itself a global network address.

   This can be avoided by explicitly assigning an address of only local
   scope (i.e., starting with AFI 49) in response to the Request Address
   packet.  This will effectively limit the host to communications on
   the local subnetwork (and particularly cautious network
   administrators could filter out any traffic sourced from an address
   under AFI 49 in order to eliminate outgoing traffic as well).

   It should be noted, of course, that this process is not secure in any
   real sense, but will avoid problems when well-behaved host software
   is in use.


References

   [1] Piscitello, D., "Use of ISO CLNP in TUBA Environments," RFC 1561,
   1993.

   [2] Ullmann, R., "CATNIP--Common Architecture for Next-generation
   Internet Protocol," draft-ietf-catnip-base-02.txt, 1994.

   [3] ISO, "End system to Intermediate system routeing exchange
   protocol for use in conjunction with the Protocol for providing the
   connectionless-mode network service (ISO 8473)," ISO 9542:1988.

   [4] ISO, "Dynamic Discovery of OSI NSAP Addresses by End Systems,"
   ISO 9542 Amendment 1, 1992.

   [5] Katz, D., "Suggested System ID Option for the ES-IS Protocol,"
   Internet Draft, 1994.


Author's Address

   Dave Katz
   cisco Systems
   1525 O'Brien Dr.
   Menlo Park, CA  94025
   USA

   Phone:  +1-415-688-8284
   Fax:    +1-415-688-8282
   Email:  dkatz@cisco.com