TUBA Working Group Dave Katz INTERNET-DRAFT cisco Systems 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